When rotating, ajpegtran sometimes reduces resolution

[nicolas-raoul]

Context: #6857 (comment)

Looking at this part of ajpegtran.c, the new Jpegtran-based rotation seems to set transformoption.trim = TRUE. This may reduce the resolution—for example, a 4000×3000 (with 16x16 MCU block size) image may become 2992×4000 after a 90° rotation.

When normal ajpegtran rotation would result in a loss of information, several solutions could be considered:

1. Use EXIF rotation instead
2. Pad the margin with black color to form full MCU blocks, and save these blocks with 100% quality
3. Accept that the margin will be lost

I would be in favor of 1 (only in cases where there would be information loss).

[nonani]

I also tried the app mentioned #6857 (comment), and it looks like it uses trimming as well.
I think this really comes down to a trade-off. As I confirmed earlier, changing only the EXIF orientation works fine in the Commons app and on Wikimedia Commons.

However, not all image viewers respect EXIF orientation. For example, Android Studio’s image viewer still shows the image in its original orientation. The same thing could happen when someone downloads an image from Commons and opens it in a viewer that ignores EXIF orientation.

So, if it doesn’t need to take those viewers into account, EXIF-only rotation seems reasonable and preserves the full resolution. But if we want the saved image to appear correctly in any viewer, trimming a few pixels and accepting a small reduction in resolution is probably the cleanest option.

[nonani]

I also tested this with a debug build from the current main branch. After rotating and uploading the image, I confirmed that the bottom edge had been trimmed. As shown below, the blue 8 px border at the bottom is present in the original image but missing after the rotation and upload.

Before: 4000 × 3000 → After rotation 90 degree -> Save -> rotation 270 degree -> Save -> Result: uploaded 4000 × 2992