My guess is that at some point this image was rotated from its original capture orientation in an editing program. That change is often written to the EXIF metadata as a rotate command, e.g. [EXIF] Orientation : Rotate 270 CW as in the example on the related ticket, etc. Other image viewers will pick up on this and implement it for display. However, right now ImageMagick in AtoM is stripping out EXIF orientation metadata, so this transformation is lost.
Your resizing is likely overwriting the original image - i.e. saving it as a new image, so the orientation change is not needed as your viewer was already displaying it correctly when you edited it. At least, these are my best guesses as to what's going on behind the scenes!
AtoM does not have the ability to rotate uploaded images, and currently the bug ignoring the EXIF orientation metadata is not on the shortlist for 2.8. As such, your best bet is to try manipulating it in an editing program as you have, e.g.:
- Try making a copy using Save As - perhaps, like your crop experiment, it will no longer require the rotation information, but you don't need to actually crop anything
- Barring that, you could find an EXIF metadata editing application and see if you can fix it directly
- Finally, perhaps you could make a crop on an access copy for AtoM that is barely noticeable, or some other minor change that will allow the orientation to work as expected, as in your cropping experiment
Not ideal perhaps, but for the odd cases where this becomes relevant, hopefully one of these will work.
Cheers,