Fix imaginary with rotated exif images

[CarlSchwan]

Now do the operation in two steps:

1. Rotate the image according the exif data
2. Do the actual operation

This should only have a performance impact on image with exif rotation
data to do the rotation. For all the other images the autorotate steps
should be almost instant.

[artonge]

Why do it in two steps instead of one?

[CarlSchwan]

Why do it in two steps instead of one?

It's actually only one step /pipeline with two operations in it. Since imaginary can't do two operations at the same time, you do them sequentially.

[artonge]

Why do it in two steps instead of one?

It's actually only one step /pipeline with two operations in it. Since imaginary can't do two operations at the same time, you do them sequentially.

So the rotation wasn't done previously?

[CarlSchwan]

Why do it in two steps instead of one?

It's actually only one step /pipeline with two operations in it. Since imaginary can't do two operations at the same time, you do them sequentially.

So the rotation wasn't done previously?

From that I understood, image can be either rotated by rotating the pixel position or by adding some exif metadata to tell the image viewer that the image is rotated. It seems that libvps or imaginary didn't handle the case of the exif metadata rotation correctly as it tried to do the croping with the not rotated dimension creating a disturbed image.

So now when we see exif rotation metadata, we first rotate the pixels to match the EXIF metadata and then do the cropping. For images without exif rotation metadata, the autorotate step is skipped as there is nothing to do.

[PVince81]

👍