MediaWiki and ImageMagick use different methods to determine orientation that don't match up
Closed, ResolvedPublic

Description

Author: saibotrash

Description:
https://commons.wikimedia.org/wiki/File:Solre-sur-Sambre_Station_plant-test.jpg#metadata

ExifTool: "Orientation Rotate 90 CW" http://regex.info/exif.cgi?imgurl=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F3%2F39%2FSolre-sur-Sambre_Station_plant-test.jpg

Sometimes the EXIF rotation if not displayed by MediaWikis EXIF display on bottom of each file page but ExifTool displays it and MediaWiki rotates the image (in that case by mistake [[bugzilla:6672]]), too.


Version: unspecified
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz31487.
bzimport created this task.Via LegacyOct 7 2011, 4:31 AM
Bawolff added a comment.Via ConduitOct 7 2011, 1:54 PM

Hmm, that's quite odd.

Ok, it looks like the exif orientation tag for that file is in IFD1 instead of IFD0 (IFD1 is supposed to contain exif information pertaining to the embedded thumbnail, instead of the actual image)

So (I think anyways) MediaWiki is being correct, and image magick is being wrong.

We should probably be specifying rotation to ImageMagick explicitly so the same determination is always used for both programs.

bzimport added a comment.Via ConduitOct 7 2011, 3:58 PM

saibotrash wrote:

btw: That example image is not the only one where I've seen this.

Yes, something is really broken in those files' EXIF. I cannot remove the Orientation tag with ExifTool by "-Orientation=" command. It just does nothing.

I did the following now:
-Orientation=180 → "1 image files updated"
-Orientation=90 → "Can't convert IFD0:Orientation (matches more than one PrintConv)"

The wrong orientation tag is only removable by ($1 = filename):
exiftool $1 -exif:all=
exiftool -tagsfromfile $1_original --Orientation $1
And the second command reports "Warning: Missing stream for FPXR object 2 - Solre-sur-Sambre_Station_plant-test.jpg_original" - but at least all EXIF data is back but without the Orientation tag.

However, apparently - however - there are many/few files with broken EXIF. As said, this is not the only file I have seen with this behaviour.
Maybe the file isn't broken but some other tools like ExifTool are. -- What do you expect from a tiff in a jpeg file mechanism? ;)

brion added a comment.Via ConduitOct 7 2011, 5:49 PM

Please add URLs for any others you see -- test materials are very handy!

Adding need-unittest keyword as this seems like a nice thing to have in the regression tests...

bzimport added a comment.Via ConduitOct 7 2011, 6:48 PM

saibotrash wrote:

(In reply to comment #3)

Please add URLs for any others you see -- test materials are very handy!

All files which were fixed by me are listed here:
https://commons.wikimedia.org/w/index.php?title=Special%3ALog&type=upload&user=Saibo&page=&year=&month=-1&tagfilter=&hide_patrol_log=1
But only some had the rotation not displayed by MediaWiki. As the current version is corrected I cannot see mediaWiki's assessment anymore.

Rotated by MediaWiki based on wrong EXIF rotation information but not displayed by MediaWiki:

bzimport added a comment.Via ConduitOct 7 2011, 7:03 PM

Bryan.TongMinh wrote:

Using ImageMagick's -rotate in r99230.

bzimport added a comment.Via ConduitOct 7 2011, 7:42 PM

saibotrash wrote:

@Bryan: what does this change? When is it live?

brion added a comment.Via ConduitOct 7 2011, 7:44 PM

(In reply to comment #6)

@Bryan: what does this change? When is it live?

This should correct the rotation (will need to do an ?action=purge to force re-rendering of existing thumbs) once it is reviewed and goes live. Probably to be batched up with a few other things later today.

Bawolff added a comment.Via ConduitOct 7 2011, 8:03 PM

(In reply to comment #2)

btw: That example image is not the only one where I've seen this.

Yes, something is really broken in those files' EXIF. I cannot remove the
Orientation tag with ExifTool by "-Orientation=" command. It just does nothing.

Probably need to use a command like -IFD1:Orientation= (exiftool probably assumes you mean the main file exif info, not the thumb. This is just an untested guess though, so could be stupid/wrong) Also when viewing the exif data using exiftool, use the -g1 command line switch to see which ifd the tags are for

... What do
you expect from a tiff in a jpeg file mechanism? ;)

Don't get me started ;)

brion added a comment.Via ConduitOct 7 2011, 9:54 PM

Confirmed r99230 fixes the test cases in comment 4 (I took the old versions since Saibo was kind enough to reupload fixed versions in place already! you commons people work fast ;))

Merging to 1.18...

brion added a comment.Via ConduitOct 7 2011, 11:05 PM

Ok this got pushed out a little bit ago, fix is now live. Another action=purge will clean up affected images (or wait until they get batch-fixed).

I'll make a note to do a full bot run and check for remaining issues...

TheDJ added a comment.Via ConduitOct 8 2011, 2:14 PM

We should probably report this upstream to imagemagick.

Peachey88 added a comment.Via ConduitNov 16 2011, 1:56 PM

(In reply to comment #11)

We should probably report this upstream to imagemagick.

Was this ever reported upstream? anyone have bug links?

Gilles added a project: Multimedia.Via WebDec 4 2014, 9:34 AM
Gilles triaged this task as "Unbreak Now!" priority.Via WebDec 4 2014, 10:10 AM
Gilles moved this task to Closed on the Multimedia workboard.
Gilles lowered the priority of this task from "Unbreak Now!" to "Needs Triage".Via ConduitDec 4 2014, 11:22 AM

Add Comment