autoOrient misbehavior when combined with additional rotation

[mbklein]

Possible bug

Is this a possible bug in a feature of sharp, unrelated to installation?

• Running npm install sharp completes without error.
• Running node -e "require('sharp')" completes without error.

If you cannot confirm both of these, please open an installation issue instead.

Are you using the latest version of sharp?

• I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of sharp that is not the latest, please open an issue against that package instead.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

  System:
    OS: macOS 15.5
    CPU: (12) arm64 Apple M2 Max
    Memory: 231.33 MB / 32.00 GB
    Shell: 5.9 - /opt/homebrew/Cellar/zsh/5.9/bin/zsh
  Binaries:
    Node: 22.16.0 - ~/.asdf/installs/nodejs/22.16.0/bin/node
    Yarn: 1.22.11 - ~/.asdf/shims/yarn
    npm: 10.9.2 - ~/.asdf/plugins/nodejs/shims/npm
    pnpm: 10.12.1 - ~/.asdf/installs/nodejs/22.16.0/bin/pnpm
    bun: 1.1.14 - ~/.asdf/shims/bun
  npmPackages:
    sharp: ^0.34.3 => 0.34.3 

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows.
Use sharp.cache(false) to switch this feature off.

• Adding sharp.cache(false) does not fix this problem.

Does this problem relate to images appearing to have been rotated by 90 degrees?

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

• To auto-orient pixel values use the parameter-less rotate() operation.

• To retain EXIF Orientation use keepExif().

• Using rotate() or keepExif() does not fix this problem.

What are the steps to reproduce?

1. Load any image.
2. autoOrient() to rectify the image based on the EXIF orientation value.
3. Apply an extract() transformation.
4. Apply a rotate() transformation.

What is the expected behaviour?

The extraction and rotation would work just as they would if the source image were already in EXIF orientation 1.

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

The mbklein/auto-orient-test repo demonstrates the issue. Follow the instructions in the README and then check the output directory. (It's easiest to get a visual sense of what's happening if you can view them in a 4x32 grid sorted by filename.)

I would expect all of the output to look like the 1-noauto results (with the 1 in the center of the image replaced with the correct source orientation), but even the rotated 1-auto results are incorrect, despite not needing any reorienting to begin with. It's hard to tell exactly what's wrong with the auto-crop results, but the rotated auto-full results make it clear that there's some confusion about the bounding box. The rotated output is being constrained to the extract region's width and height instead of expanding the box to allow the rotated image to fit.

Please provide sample image(s) that help explain this problem

The issue arises on every image I've tried, but the proof of concept above uses the examples from recurser/exif-orientation-examples

[mbklein]

On further experimentation, I believe that the issue only arises when you use extract followed by rotate, even if the extraction area is the full frame. So autoOrient + extract seems to be constraining the output's bounding box in a way that neither does on its own.

[lovell]

Thanks for reporting this Michael.

Commit 08b4242 further separates orientation and rotation logic, adding a couple of new tests based on your repo that would previously have failed.

Here's partial output from your sample repo when run with this change - does this look correct?

[mbklein]

Yes, that is exactly what the results for orientations 1 & 2 should look like. Thanks for addressing this so quickly. It's going to save me a whole lot of trouble downstream.

[mbklein]

Trying to run my test code against the main branch (using both nodejs 22.14.0 and 24.4.1) , I'm getting

node_modules/sharp/lib/output.js:1585
          sharp.pipeline(this.options, (err, data, info) => {
                ^

TypeError: A boolean was expected
    at Sharp.<anonymous> (node_modules/sharp/lib/output.js:1585:17)
    at Object.onceWrapper (node:events:621:28)
    at Sharp.emit (node:events:519:35)
    at finish (node:internal/streams/writable:953:10)
    at node:internal/streams/writable:934:13
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21)

on the pipeline.toBuffer() call. I'm not on my usual dev machine, and I know this error has come up before in contexts where nodejs or npm did something weird, but I can't seem to get past it even after rm -rf package-lock.json node_modules && npm install.

If you're comfortable with the fix without my full test, no worries. Otherwise, unless you know of a quick fix for that error, I can try again when I get my own laptop back.

[lovell]

Thanks for testing - the fix involves C++ changes so you'll need to use npm install --build-from-source

[mbklein]

The error persists even after a successful --build-from-source (in a clean directory). I'll keep plugging away at it.

Got it working. Testing now.

[mbklein]

Every orientation is now transforming correctly when autoOrient() is applied 👍🏻