Page MenuHomePhabricator

Rotation parameters from EXIF fail in Mediawiki
Closed, ResolvedPublic

Description

(Not sure if this problem is related to any of the tasks in T33504.)

As reported on https://commons.wikimedia.org/wiki/Commons:Forum#Mal_was_kniffeliges, there are rotation problems with some images. (Edit: Now archived in https://commons.wikimedia.org/wiki/Commons:Forum/Archiv/2017/August#Mal_was_kniffeliges)

See file versions of
https://commons.wikimedia.org/wiki/File:Rostockstein.jpg
https://commons.wikimedia.org/wiki/File:Carrie_Brownstein_of_Wild_Flag_-_outdoor_stage_Coachella_2012.jpg

When opening the original files in a browser, everything looks fine. Only the Mediawiki thumbnails are rotated or stretched badly.

Event Timeline

Thgoiter created this task.Aug 22 2017, 7:53 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 22 2017, 7:53 AM
dr0ptp4kt triaged this task as Normal priority.EditedSep 6 2017, 4:45 PM
dr0ptp4kt moved this task from Untriaged to Triaged on the Multimedia board.
dr0ptp4kt added subscribers: matthiasmullie, dr0ptp4kt.

This appears to require more technical investigation.

^ Note, removed inaccurate statement about reaching users...that was for a different task.

TheDJ added a subscriber: Gilles.Sep 18 2017, 1:27 PM

Possibly related to Thumbor work ? Maybe @Gilles will know.

Gilles added a comment.EditedSep 18 2017, 9:34 PM

Default orientation EXIF field, seemingly conflicting width/height fields:

MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170813000933\!Carrie_Brownstein_of_Wild_Flag_-_outdoor_stage_Coachella_2012\ \(2\).jpg  | grep Width
Related Image Width             : 4000
Zoom Source Width               : 4000
Zoom Target Width               : 4000
Canon Image Width               : 4000
AF Image Width                  : 320
AF Area Widths                  : 34 20000 19 431 266 431 60 19 17080
Cropped Image Width             : 4000
Exif Image Width                : 4000
Image Width                     : 3000

MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170813000933\!Carrie_Brownstein_of_Wild_Flag_-_outdoor_stage_Coachella_2012\ \(2\).jpg  | grep Height
Related Image Height            : 3000
Canon Image Height              : 3000
AF Image Height                 : 240
AF Area Heights                 : 41 -19832 -15800 11656 -5536 -18916 0 11548 -18800
Cropped Image Height            : 3000
Exif Image Height               : 3000
Image Height                    : 4000

MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170813000933\!Carrie_Brownstein_of_Wild_Flag_-_outdoor_stage_Coachella_2012\ \(2\).jpg  | grep Orientation
Orientation                     : Horizontal (normal)

MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170813000933\!Carrie_Brownstein_of_Wild_Flag_-_outdoor_stage_Coachella_2012\ \(2\).jpg  | grep Rotation
MBP-de-Gilles:Downloads gillesdubuc$

Mediawiki is correct when it sets the size, Thumbor seems to be overzealously rotating the image, or just consuming "Exif Image *" instead of "Image *".

Another one of the provided files has different symptoms. In this case it has a "Rotation" field instead of an "Orientation" one:

MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170803192131\!Rostockstein.jpg | grep Orientation
Orientation                     : Horizontal (normal)
MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170803192131\!Rostockstein.jpg | grep Width
Exif Image Width                : 2347
Image Width                     : 2347
MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170803192131\!Rostockstein.jpg | grep Height
Exif Image Height               : 3568
Image Height                    : 3568
MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170803192131\!Rostockstein.jpg | grep Rotation
Rotation                        : Rotate 90 CW

Again, OS X and Chrome seem to agree on the same orientation, and Thumbor overzealously rotates it.

The last example is of the "Rotation" kind, this time with a different syntax:

MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170917235407\!Cerkiew_św._Michała_Archanioła_w_Wólce_Wygonowskiej_1.JPG | grep Orientation
Orientation                     : Horizontal (normal)
MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170917235407\!Cerkiew_św._Michała_Archanioła_w_Wólce_Wygonowskiej_1.JPG | grep Rotation
Rotation                        : 90
MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170917235407\!Cerkiew_św._Michała_Archanioła_w_Wólce_Wygonowskiej_1.JPG | grep Width
Zoom Source Width               : 4000
Zoom Target Width               : 4000
Canon Image Width               : 2592
AF Image Width                  : 100
AF Area Widths                  : 18 0 0 0 0 0 0 0 0
Face Width                      : 0
Exif Image Width                : 1914
Related Image Width             : 2592
Image Width                     : 1914
MBP-de-Gilles:Downloads gillesdubuc$ exiftool 20170917235407\!Cerkiew_św._Michała_Archanioła_w_Wólce_Wygonowskiej_1.JPG | grep Height
Canon Image Height              : 1944
AF Image Height                 : 100
AF Area Heights                 : 18 0 0 0 0 0 0 0 0
Exif Image Height               : 2565
Related Image Height            : 1944
Image Height                    : 2565

I believe this is coming from ImageMagick's auto-orient feature, which Thumbor uses.

When I use ImageMagick directly, -auto-orient causes all 3 of these images to rotate the same way Thumbor does.

The IM documentation is lying/misleading, as it mentions only the Orientation EXIF field: https://www.imagemagick.org/script/command-line-options.php#auto-orient

When clearly it seems to be taking into account the value of "Rotation", as well as the values of "Exif Image *" when they conflict with "Image *"

This would all suggest that ImageMagick's -auto-orient should be avoided and the "Image Width/Height" + "Orientation" fields need to be the sources of truth about orientation, based upon which Thumbor should pick its Imagemagick rotation parameter explicitly.

Gilles claimed this task.Sep 18 2017, 9:35 PM
Gilles added projects: Thumbor, Performance-Team.

Unfortunately due to Mediawiki's filtering of EXIF before it reaches the image table, there's no way for us to compile a list of potentially affected files. Since this code has been running for 3 months now, purging all generated JPG thumbnails over that period is impractical. Which means that once the fix is deployed, affected files will have to be purged manually when encountered. Furthermore, once they fall out of Varnish cache eventually, they will fix themselves.

Change 379218 had a related patch set uploaded (by Gilles; owner: Gilles):
[operations/debs/python-thumbor-wikimedia@master] Upgrade to 1.5

https://gerrit.wikimedia.org/r/379218

Gilles moved this task from Inbox to Doing on the Performance-Team board.Sep 20 2017, 7:04 PM
Speravir updated the task description. (Show Details)Sep 25 2017, 6:12 PM

Last time I asked in the other task, but now the other way: Could T172556 be a duplicate?

In https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Manche_Thumbs_werden_gespiegelt it was noticed that there are not only unintentional rotations, also mirroring appears to happen.

Thgoiter updated the task description. (Show Details)Sep 25 2017, 8:39 PM

Change 379218 merged by Filippo Giunchedi:
[operations/debs/python-thumbor-wikimedia@master] Upgrade to 1.5

https://gerrit.wikimedia.org/r/379218

Mentioned in SAL (#wikimedia-operations) [2017-09-26T08:24:25Z] <godog> roll-restart thumbor to upgrade to 1.5 - T173804

Gilles closed this task as Resolved.Sep 26 2017, 8:36 AM

The files listed in the task description have now been fixed. If you encounter more, try to purge them and shift-refresh/clear your browser cache.

Speravir removed a subscriber: Speravir.May 20 2019, 9:22 PM