Crop and resize not working as expected

[demir]

Describe the bug
Crop and resize not working as expected for some images. I have two versions of the image. One version is high quality (3,6 MB). The other version is low quality (585 kb). Crop and resize working as expected for the low-quality image. But when I use the high-quality image, crop and resize are not working as expected.

For resize; URL must be /widthxheight/
For crop; URL must be /AxB:CxD/ -> means manually crop the image at left-top point AxB and right-bottom point CxD;

With the high-quality image, width and height seem to be swapped.
Image dimensions are: 3024x4032
Resizing high-quality image with /3024x4032/ returning a wrong sized image. Likewise, crop works incorrectly.

CloudWatch Logs: Aws throws a extract_area error.

Error: extract_area: bad extract area

PS:
High-quality image format: jpeg (converted from .heic format) (portrait)
Low-quality image format: jpeg (generated from high-quality image) (portrait)

High-quality image:
https://user-images.githubusercontent.com/3108789/184628632-4f983c33-0987-4ac0-9064-316658d2e9a4.jpg

Low-quality image:
https://user-images.githubusercontent.com/3108789/184628672-82a5a063-5916-415c-b4f6-49ad975ca3bd.jpg

Expected behavior
Crop and resize should work the same for every image.

Please complete the following information about the solution:

• Version: v6.0.0
• Region: eu-central-1
• Was the solution modified from the version published on this repository?
• 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
https://user-images.githubusercontent.com/3108789/184627227-64778043-fb3c-4df9-9428-72552c923450.png
https://user-images.githubusercontent.com/3108789/184627297-018b5f78-91b6-4d7c-b723-50c905b4761b.png
https://user-images.githubusercontent.com/3108789/184627484-c756c451-1b8e-4e4d-a46e-94b51e645a1a.png
https://user-images.githubusercontent.com/3108789/184627577-525a6137-c6b9-4e10-ba5f-89c76ae514d7.png
https://user-images.githubusercontent.com/3108789/184627591-5f688276-1477-4f47-bb7d-96a904ad5579.png
https://user-images.githubusercontent.com/3108789/184627596-a11bcea8-faf9-40fb-93a0-e5e73260b5ba.png
https://user-images.githubusercontent.com/3108789/184627599-6d8fdfbf-6b91-4c52-bad2-221d317d6ce1.png

[fisenkodv]

@demir thank you for your feedback. We will look into it and add it to our backlog.

[dougtoppin]

@demir tks for your report, we are looking at this now and will reply when we have more information

[match-generobichaux]

I may be experiencing the same issue....lambda function is throwing the same error....
Error: extract_area: bad extract area
It is very sporadic...but about 10% of our calls are throwing a 500 error (which is when Lambda throws the error

#400

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[demir]

The problem has not been solved.

[schana]

The behavior you're seeing is due directly to the different exif orientation values between the two images. The low res version has a value of 1 and the high res has a value of 6. To force the solution to process the exif metadata before applying the transformations, you could use a url like /filters:strip_exif()/3024x4032/. We'll look into how we can change the behavior for a future release to have this use case be more intuitive.