Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add experimental image orientation fix #724

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

happycollision
Copy link

@happycollision happycollision commented May 27, 2024

NOTE: This PR is incomplete, but the functionality is all there. It needs documentation and I need to better understand the tests in the Vite package to get those working the way I want. Everything else is ready. I don't have time for docs today, but I will get to them next week at the latest.

I will also rename commit summaries to be in keeping with the format you prefer, but won't do that right away.

Please feel free to start giving feedback about the runtime code and the idea itself.

Addresses #700 via an experimental setting.

  • Quick Checklist

馃毃 I have not done everything on this list yet. I will do them, but I wanted to get some eyes on this draft first.

  • I have read the contributing guidelines
  • I have written new tests, as applicable (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)
  • I have added a changeset, if applicable 馃毃馃毃馃毃 This PR needs a changeset. Just haven't done it yet.
  • What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

A new setting is added to both Vite config and as an option to pass into applyTransforms.

{
  experimental: {
    preserveInitialOrientation: boolean
  }
}
  • What is the new behavior (if this is a feature change)?

This opt-in feature will pre-rotate/flip/flop an image based on the EXIF orientation data so that downstream developers can think about their images without first considering whether or not the image appearance is affected by metadata or by actual pixel locations. Two images that look the same might have completely different results when applying flip, flop, or rotate. If you take removeMetadata into account, there are even more permutations to consider.

This new setting removes the need to consider all these things.

  • Does this PR introduce a breaking change? (What changes might users need to make in their application due to this
    PR?)

I have attempted to test initial behavior and ensure that, unless you opt-in, that behavior is exactly the same. So no, there shouldn't be any breaking changes.

  • Other information:

Copy link

changeset-bot bot commented May 27, 2024

鈿狅笍 No Changeset found

Latest commit: c939952

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@happycollision happycollision marked this pull request as draft May 27, 2024 21:26
@happycollision
Copy link
Author

happycollision commented May 28, 2024

I've discovered that the .withMetadata() method keeps all metadata while allowing you to write to some of that metadata at the same time. This means it is incompatible with the removeMetadata option. Looking into a different solution now...

The options object will allow more configuration without blowing up the
arity of the function.

Backwards compatible, though I suggest deprecating the old style if you
keep this change.
To stay backwards compatible and ensure that current users are not
affected by upcoming changes, we need to test the current behavior of
the `flip`, `flop`, and `rotate` transforms when applied to images with
EXIF orientation metadata.

The images added to __fixtures__ are all rotated via EXIF orientation.
Whether or not they appear correctly in your image viewer is dependent
on its ability to read that orientation metadata. The resulting PNG
files show the problems that people run into when they don't account for
orientation metadata in their image processing. The next commit will
introduce a new setting that attempts to give developers the results
they actually expect.
This experimental setting is intended to give developers an easy way to
treat their images intuitively based on how they actually look on
screen, instead of how they are actually written on disk.

There is an overhead to certain orientations that might be too high a
cost to pay, but that is why this is experimental. Working on this
feature has made me believe that the best place to add the DX
improvement is actually within Sharp itself. In the meantime there is
something here worth trying out.
@happycollision happycollision changed the title Fix unexpected image orientation feat: add experimental image orientation fix May 29, 2024
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: It is probably better to write tests for this experimental feature in a completely separate file, and group them all together, instead of spreading them across the existing flip, flop, and rotate tests.

@@ -32,6 +32,7 @@
"dev": "rollup -cw",
"build": "rollup -c",
"test": "vitest run",
"test:watch": "vitest watch",
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't get into watch mode without this, but I didn't mean to add it to the commit. Will drop.

@@ -32,6 +32,7 @@
"dev": "rollup -cw",
"build": "rollup -c",
"test": "vitest run",
"test:watch": "vitest watch",
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. I meant to drop this change.

experimental?: {
/**
* Sharp's handling of image orientation probably does not match the
* expectations of users of imagetools. Enabling this option tries tp preserve
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo s/tp/to

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect the arrow to point left in this one. I am missing something on the vite side of things at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant