Page MenuHomePhabricator

File size shrinks during rotation (action: 'imagerotate') // Rotation not lossless?
Open, MediumPublic

Description

I don't know whether it is really a bug or just some JPEG-encoding-internal-strangeness

Test at https://commons.wikimedia.org/wiki/File:Bot-Test.jpg

API query at:
https://commons.wikimedia.org/w/api.php?action=query&prop=info|imageinfo&iiprop=size|comment&titles=File:Bot-Test.jpg&iilimit=5

Start size: 324829; then, after first rotation 281901, then 275364, then 270655 and finally after 4 rotations just 268076 Bytes:

<ii size="268076" width="512" height="512" comment="Bild um 90 Grad im Uhrzeigersinn gedreht" />
<ii size="270655" width="512" height="512" comment="Bild um 270 Grad im Uhrzeigersinn gedreht" />
<ii size="275364" width="512" height="512" comment="Bild um 270 Grad im Uhrzeigersinn gedreht" />
<ii size="281901" width="512" height="512" comment="Bild um 90 Grad im Uhrzeigersinn gedreht" />
<ii size="324829" width="512" height="512" comment="Reverted to version as of 18:08, 29 November 2012" />

Expected result: After 360° rotation and if the image is not cropped, the file size is supposed to be the same.

Why isn't simply the Metadata of the file manipulated (the EXIF-Orientation-tag). The image-scalers would do the remaining work.


Version: 1.21.x
Severity: normal
See Also:
https://rt.wikimedia.org/Ticket/Display.html?id=4821
https://bugzilla.wikimedia.org/show_bug.cgi?id=36221

Details

Reference
bz46549

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:18 AM
bzimport set Reference to bz46549.
bzimport added a subscriber: Unknown Object (MLST).

AFAIK we bother to rotate the file properly in order to help our reusers who viewers may or may not support EXIF rotation. The problem of 360 degree rotation altering the file still stands, of course.

Where did the rotated images come from (eg, what tool did you use?)

AFAIK there's nothing built-in to MediaWiki that's designed to perform lossless rotation and then upload the result, so there's something non-default going on.

(In reply to comment #2)

Where did the rotated images come from (eg, what tool did you use?)

That was my first question as well. :-) It required re-reading the bug summary to figure out that Rainer really did mean the MediaWiki API (cf. https://commons.wikimedia.org/w/api.php; grep "action=imagerotate").

Ok I'll withhold my comments about whether this API method is a good idea or not... ;)

But the reason it's not lossless on JPEGs on the live cluster is most likely because 'jpegtran' is not installed on the application servers, so it's falling back to ImageMagick or some such.

I've filed a request to get jpegtran installed on app servers in RT:

https://rt.wikimedia.org/Ticket/Display.html?id=4821

Someone should poke ops people IRL or on IRC to make sure it doesn't fall through the cracks...

The fact that the file size is smaller, doesn't necessarily mean that it has a loss of quality. The program rotating the image may do some optimization of it, although I agree that it's odd that it's always smaller.

On Windows I use a program called IrfanView which has some options labeled as "JPG Lossless rotation" which also changes the file size.

(In reply to comment #7)

I've filed a request to get jpegtran installed on app servers in RT:

https://rt.wikimedia.org/Ticket/Display.html?id=4821

Someone should poke ops people IRL or on IRC to make sure it doesn't fall
through the cracks...

And I suspect the problem is that the API apaches are doing the rotation, but they won't have libjpeg-turbo-progs etc

Maybe we could just disable the api module on the cluster for now....

(In reply to comment #1)

we bother to rotate the file properly in order to help our reusers

This is not really true. Wikimedia's Wikis respect the Exif-Orientation tags set by digital cameras and if you download a picture, or just request the original through clicking on the file at the file description page, you get them in the wrong orientation despite the thumbnail looks fine.

In any case, if the reuser is a professional they know what they have to do; if they aren't it isn't that important that they get the original file (they can save thumbs). Note Bug 31366 about this issue.