Last modified: 2011-11-16 13:56:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 31487 - MediaWiki and ImageMagick use different methods to determine orientation that don't match up
MediaWiki and ImageMagick use different methods to determine orientation that...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Unprioritized normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: need-unittest
Depends on:
Blocks: 31504 6672
  Show dependency treegraph
 
Reported: 2011-10-07 04:31 UTC by Saibo
Modified: 2011-11-16 13:56 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Saibo 2011-10-07 04:31:51 UTC
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.
Comment 1 Bawolff (Brian Wolff) 2011-10-07 13:54:45 UTC
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.
Comment 2 Saibo 2011-10-07 15:58:46 UTC
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? ;)
Comment 3 Brion Vibber 2011-10-07 17:49:34 UTC
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...
Comment 4 Saibo 2011-10-07 18:48:45 UTC
(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.
Comment 5 Bryan Tong Minh 2011-10-07 19:03:19 UTC
Using ImageMagick's -rotate in r99230.
Comment 6 Saibo 2011-10-07 19:42:53 UTC
@Bryan: what does this change? When is it live?
Comment 7 Brion Vibber 2011-10-07 19:44:37 UTC
(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.
Comment 8 Bawolff (Brian Wolff) 2011-10-07 20:03:59 UTC
(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 ;)
Comment 9 Brion Vibber 2011-10-07 21:54:41 UTC
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...
Comment 10 Brion Vibber 2011-10-07 23:05:07 UTC
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...
Comment 11 Derk-Jan Hartman 2011-10-08 14:14:08 UTC
We should probably report this upstream to imagemagick.
Comment 12 p858snake 2011-11-16 13:56:28 UTC
(In reply to comment #11)
> We should probably report this upstream to imagemagick.

Was this ever reported upstream? anyone have bug links?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links