Last modified: 2013-05-30 12:24:44 UTC
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.
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.
I believe this relates to https://gerrit.wikimedia.org/r/#/c/44005/
Urrrrrggghghghllllllllll
(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...
https://gerrit.wikimedia.org/r/#/c/52707/ ^ It was merged 4 days ago...
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.
