sharp icon indicating copy to clipboard operation
sharp copied to clipboard

Width and height swapped in iOS photos

Open akowalska622 opened this issue 1 year ago • 4 comments

Possible bug

On some iOS imported pictures height and width is being swapped. It never happens to landscape pictures and it usually happens to portrait pictures, but not to all of them.

I've been using version 0.32.6, then updaded to 0.33.4 to be able to use keepExif()

I've read Sharp swaps width and height #3987 thread and linked threads, but nothing helped.

Rotation like in Resizing images taken on iOS also rotates them #2297 issue didn't happen to me.

I'm using uploadthing.com, so image is firstly uploaded and then I fetch it via url to get metadata.

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

  • [x] Running npm install sharp completes without error.
  • [x] 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?

  • [x] 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 14.4.1
    CPU: (8) arm64 Apple M1
    Memory: 83.08 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 10.1.0 - ~/.nvm/versions/node/v20.9.0/bin/npm
    pnpm: 9.0.6 - ~/.nvm/versions/node/v20.9.0/bin/pnpm
    Watchman: 2024.01.22.00 - /opt/homebrew/bin/watchman
  npmPackages:
    sharp: 0.33.4 => 0.33.4 

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.

  • [x] 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().

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

What are the steps to reproduce?

  1. Try to get metadata from an iOS picture What I tried:
  1. const imageMetadata = await sharp(buffer).metadata();
  2. const imageMetadata = await sharp(buffer).withMetadata.metadata();
  3. const imageMetadata = await sharp(buffer).keepExif().metadata();
  4. const imageMetadata = await sharp(buffer).rotate().keepExif().metadata();
  1. Read metadata of iOS picture - width and height is usually swapped on portrait oriented pictures.

What is the expected behaviour?

Width and height is correctly read from original picture dimensions.

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

Here's the minimal, standalone code sample which reproduces the bug, using existing uploadthing links.

Here is the repo I'm currently working in (with uploadthing configured) linked to the sharp line. Commited just a bare version, but I've tried all possible combinations from What are the steps to reproduce? section.

Example of affected picture:

Link: https://utfs.io/f/ce384dab-dd57-4fef-83f4-8a92caef413d-1xd4jf.jpeg Picture info read on MacBook: Screenshot 2024-05-20 at 20 28 51 Width and height read by sharp: Screenshot 2024-05-20 at 20 29 30

Example of not affected portrait picture:

Link: https://utfs.io/f/644f2559-ae65-4b70-a073-85d2923ed0e9-1xd3ua.jpeg Picture info read on MacBook: Screenshot 2024-05-20 at 20 30 15 xd3ua.jpeg Width and height read by sharp: Screenshot 2024-05-20 at 20 30 50

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

Affected picture

uploadthing: https://utfs.io/f/ce384dab-dd57-4fef-83f4-8a92caef413d-1xd4jf.jpeg original pic: IMG_6357

Not affected picture

uploadthing: https://utfs.io/f/644f2559-ae65-4b70-a073-85d2923ed0e9-1xd3ua.jpeg original pic: IMG_6271

akowalska622 avatar May 20 '24 18:05 akowalska622

same thing here. input image has: 3024x4032 and output image has: 4032x3024

alexandreerick avatar May 20 '24 20:05 alexandreerick

I've added a simple node script to reproduce it with bare minimum code. Updated in description, also added here for convenience.

akowalska622 avatar May 21 '24 07:05 akowalska622

Did you see https://sharp.pixelplumbing.com/api-input#metadata ?

This is read from the header of the input image. It does not take into consideration any operations to be applied to the output image, such as resize or rotate.

In addition, please see the getNormalSize() example provided in the same section of the docs.

lovell avatar May 21 '24 07:05 lovell

My bad for omitting this part of metadata doc, thanks!

With getNormalSize() it works perfectly fine! I'm wondering though, should it be included in the library? As far as I understand, you need to reproduce this function in your repository, right?

I understand limitations, it's just really confusing at the beginning

akowalska622 avatar May 21 '24 07:05 akowalska622

Closing the issue, as @lovell comment helped me. I keep the above question raised though for further discussion :)

akowalska622 avatar May 24 '24 09:05 akowalska622

Did you see https://sharp.pixelplumbing.com/api-input#metadata ?

This is read from the header of the input image. It does not take into consideration any operations to be applied to the output image, such as resize or rotate.

In addition, please see the getNormalSize() example provided in the same section of the docs.

Thank you for help. It should be strongly highlighted in the documentation under some kind of alert style

evgenytk avatar Nov 04 '24 18:11 evgenytk