Images lose orientation when edits do not include rotate (e.g. with edits={ "animated": true } and autoWebPParameter=Yes)

[kotom320]

Describe the bug With autoWebPParameter=Yes, images that contain EXIF orientation (e.g., Orientation=6) lose correct orientation when edits does not include rotate. Current observations with the same EXIF-rotated JPEG:

• edits={}: Safari shows correct orientation, Chrome shows incorrect orientation.
• edits={ "animated": true }: Chrome still shows incorrect orientation.
• In the public demo (no animated option), testing with resize only to create a “no-rotate” edit path shows another symptom: when width/height are provided, the result appears as if width and height were applied swapped (likely due to orientation not being baked before resize).

To Reproduce

1. Enable autoWebPParameter=Yes.
2. Use a JPEG with EXIF Orientation ≠ 1 (sample attached: Orientation6.jpeg).
3. Case A — No edits: request with{} → Safari: correct, Chrome: incorrect.
4. Case B — Edit path without rotate (animated): request with { "animated": true } → Chrome: incorrect (still rotated).
5. Case C — Edit path without rotate (resize only, as in the demo): request with → Appears as if width/height are applied in the opposite way (dimension swap symptom).

Expected behavior Orientation should always be baked into the pixel data (via autoOrient()), so images are displayed correctly in all browsers regardless of EXIF orientation support.

Please complete the following information about the solution:

• [X] Version: [e.g. v7.0.6]
• [X] Region: [e.g. ap-northeast-2]
• [X] Was the solution modified from the version published on this repository?
• [X] If the answer to the previous question was yes, are the changes available on GitHub?
• [ ] Have you checked your service quotas for the sevices this solution uses?
• [ ] Were there any errors in the CloudWatch Logs?

Screenshots

• original image(orientation=6)

-chrome

-safari

Additional context

[bios6]

Hi,

Thanks for raising this issue, we will take a look at this and get back to you.

Thanks!

[gsingh04]

@kotom320 thank you for raising this concern. We touched upon this in 7.0.5, wherefilters:rotate() performs auto-orient.

We do want it to come as user-intent for auto-orientation. I see you are using base64 encoded requests. Does this help - https://docs.aws.amazon.com/solutions/latest/serverless-image-handler/rotate-images-manually.html. So you still need to provide it as user-intent rotate: null and that would apply auto-orient.

[MitchellJeppson]

I'm using 7.0.7 and still getting the same behavior when using rotate: null

[gsingh04]

let me try to replicate this behavior at my end. @MitchellJeppson is there an image that you can share which i can use.

[mortezarajabi]

I've set autoWebPParameter=No and set the rotate value to 0 in edits and it fixed the image rotation issue in Chrome. In my case the images taken vertically by phone was rotating to horizontal in Chrome.