1
votes

It looks like when taking an HDR photo from an iOS device, because Apple doesn't rotate images and shoots them all in landscape, there's EXIF metadata (orientation in specific) that tell other software how to present that photo.

The weirdness happens when someone attempts to send/share/use/upload a resized version of the original HEIC image taken by the iPhone camera.

iOS Resizing tool

That OS resizing tool messes up the precious EXIF orientation metadata, and therefore we're left with an image that's not rotated and doesn't contain any metadata for actually presenting it properly.

We have a php server that receives such photos uploaded from people, and many of them complain about uploading resized photos through a webview and getting a messed up orientation.

Not sure how to fix this, considering that the photos we end up with have an exif orientation value of 1 (which means no orientation needed) - curtesy of that iOS resizing tool (even if before getting resized the image had an exif orientation value of 6)?

https://drive.google.com/file/d/168ZxbXI0IFofoTr7pPDOULtE-VO7HcVC/view?usp=sharing

Couldn't find a way to actually share the original HEIC image, so I just shared the output of the Actual Size option (image00006) and the Small option (image00001). The finger in the example photo is always pointing towards the ceiling, and the orientation of the iPhone while taking the photo was portrait.

1

1 Answers

1
votes

I'm having this exact same problem! I wrote a little script that will alert the user what the orientation value is. And as long as it's the actual image size, it will say for example 6 (which means it's sideways, and iphone displays the image as right side up which is fine).

But the problem lies when the user changes actual size to small, medium, or large and that orientation seems to default to 1, even though the new resized image is still sideways.

I read somewhere that when the iphone resizes the image, it copies a brand new 'jpeg' file just before the upload. When it does this, it doesn't seem to carry over the exif orientation value (for example 6), it just defaults everything to 1!

So any php logic or javascript to handle it when it's resized can't rotate it correctly since it's reading the exif data as a 1 value even though the image is sideways. However the actual size (original image) has an exif value of 6 and IS correctly rotated whether the dev is using php or javascript exif data to do this.

This problem seemed to have been posted by some users on github almost a year ago and still nothing was done. If this is an ios issue, I wish someone higher up can take a look at this.