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.

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? ;)

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...

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:

• https://commons.wikimedia.org/wiki/File:Nieuwezijds_Voorburgwal_53h_RM5918.jpg
• https://commons.wikimedia.org/wiki/File:Grote_Houtstraat_9-11_Haarlem_RM19200.jpg#filehistory (fixed)
• https://commons.wikimedia.org/wiki/File:Nieuwezijds_Voorburgwal_161_RM5945.jpg#filehistory (fixed)
• Probably more uploads from this user.

Bryan.TongMinh wrote:

Using ImageMagick's -rotate in r99230.

saibotrash wrote:

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

(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.

(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 ;)

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...

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...

We should probably report this upstream to imagemagick.

(In reply to comment #11)

We should probably report this upstream to imagemagick.

Was this ever reported upstream? anyone have bug links?