Fix image rotation on upload

[MrRoco]

What does it do?

Added an Exif check for edited images and if the have been Orientated.
If Orientated, make sure the image is also saved with the correct data.

Why is it needed?

Certain software doesn't save the edit data correctly which will cause rotated imaged to be reverted back after upload.

How to test

Rotate an image, upload it to the site, check if the image is still in correct position.

Related issue(s)/PR(s)

Resolves: #16785 and also resolves #15484

[SnowCreative]

Hey, really nice! About once a year I get a client asking me why the photo they just uploaded is rotated on their website.

[smg6511]

@MrRoco - Can you specify at least one software package that does not correctly save the data? That'll help in testing the PR.

[MrRoco]

@MrRoco - Can you specify at least one software package that does not correctly save the data? That'll help in testing the PR.

Hello, it's really random, most of the times its from clients who use windows.

[matdave]

@MrRoco - Can you specify at least one software package that does not correctly save the data? That'll help in testing the PR.

It used to happen on phones all the time when people uploaded directly. It's why it's a built in helper on my MODX Buddy package (along with resizing).

[jaygilmore]

@MrRoco It possibly would have been preferrable to do this with Imagick and a fallback to GD and not add another dependent call to phpThumb but that's not a huge deal. It's doubtful we'll ever remove it and I dont' think it's commands will ever change.

@smg6511 here are some images I created with the altered exif data using exiftools on the commandline.
exif-tests.zip

All but the original have the exif data altered but not the pixel orientation. The original has no orientation tag. These should help if you wanted to test.

[smg6511]

@jaygilmore Thanks for the files. The trouble with those is they do not have the Orientation exif tag, which is what this solution is reliant on. What I'm unclear on is exactly what exif data needs to be incorrect to create this issue.

I've noticed that when you edit the orientation of an image it's Orientation flag seems to always get set to 1. Same with if you save an image as anything other than its raw form (e.g., for iPhone from HEIC to jpg) ... sets it to 1. Makes sense, it's reset to the default indicating it's the intended viewing orientation.

So, is the referenced software glitch that it doesn't reset Orientation to 1 when editing/exporting? And is Orientation only meant to record the original way the device (be it a smartphone or digital SLR) was oriented upon taking a given picture?

[jaygilmore]

@smg6511 it appears that I did it incorrectly when I set the Orientation flag. Here's a new set of files.

It's my understanding that if you set the rotation and the pixels are then rotated, the new position is 1. So, if you're using anything that would set the orientation and it saves the oriented pixels on output it will set that Orientation flag to 1 because it's now in a new state.

I verified as follows:

exiftool -n -Orientation compass-rose-orient*.jpeg
======== compass-rose-orient-1-normal.jpeg
Orientation                     : 1
======== compass-rose-orient-3-rotate-180.jpeg
Orientation                     : 3
======== compass-rose-orient-6-rotate-90.jpeg
Orientation                     : 6
======== compass-rose-orient-8-rotate-270.jpeg
Orientation                     : 8
    4 image files read

test-orientations.zip

[smg6511]

@jaygilmore - Thanks for the updated files. With these, there is no difference in the output (i.e., the resulting image after upload). It could be because the images are square (? ... but probably not) or that there's other information that triggers the issue.

@MrRoco - Did you test this PR against an image(s) with bad exif info and, if so, can you share it/them here?