Orientation gets really tricky when an image has conflicting information in EXIF vs XMP or even native fields, and multiple libraries and also MediaWiki have had faulty behaviour on this front.
If we are working with newer versions of libraries, which had fixes for the priority order of these fields, then maybe that is what is at play here ?

Specifically.. these seem all to be 90 or 270 degree EXIF rotated images, meaning that logically they are width/height flipped, and correct representation depends the EXIF information in the file.

There is a hint here in https://github.com/aws-solutions/serverless-image-handler/issues/235 which implies that this can be because metadata is stripped before thumbnailing, that might be related ?

So, I think the difference I am seeing is because I had not set RESPECT_ORIENTATION = True in my local thumbor config file. That option is set on beta. The default for that option is False.

When I add that option to my local thumbor config, the 4 files mentioned in the description are rendered in the correct orientation.

@roman-stolar @Vlad.shapik please double-check, but I think this bug is a false alarm.

In T318548#8329085, @dom_walden wrote:

So, I think the difference I am seeing is because I had not set RESPECT_ORIENTATION = True in my local thumbor config file. That option is set on beta. The default for that option is False.

When I add that option to my local thumbor config, the 4 files mentioned in the description are rendered in the correct orientation.

@roman-stolar @Vlad.shapik please double-check, but I think this bug is a false alarm.

Hi @dom_walden
I've double-checked your assumptions and everything works fine with RESPECT_ORIENTATION = True as you described. There is no bug related to the incorrect orientation of thumbnails.
Thank you.