Last modified: 2012-03-25 05:52:32 UTC
Mediawiki doesn't take into account the EXIF orientation which permits to rotate automatically the images. Nowadays most softwares handle this correctly and rotate the image accordingly. When an image is uploaded mediawiki doesn't correct the orientation, therefore creating some problems. Mediawiki should handle the EXIF orientation.
Here is a clear example: http://flickr.com/photos/73422480@N00/81593789 - Flickr image http://commons.wikimedia.org/wiki/Image:Tackle.jpg - image transferred to Commons by a bot (so definitely no editing done in between).
ImageMagick has this option: -auto-orient automatically orient (rotate) image from a digital camera. could we simply change $wgImageMagickConvertCommand to add this option? I suppose all the width and height stuff would need to be swapped around...
We'd have to special-case a couple of additional things: * handling of width and height * display of full-size images inline The most consistent width/height handling would likely be to switch the fields at metadata load time. This might have issues with existing files, though.
(In reply to comment #3) > * display of full-size images inline If you mean what happens when the user clicks through to see the fullsize file at upload.wikimedia.org - I suppose we should follow Flickr's lead: if you download one of their photos at "original" it doesn't auto-orient. I would imagine this behaviour for say a 100px image that needed auto-orient: - inline image [[image:foo.jpg]] or [[image:foo.jpg|100px]] - use auto-orient - image on image page 100px wide - use auto-orient and provide file link to original file on upload.wikimedia.org (currently we don't do this if the image fits entirely on the image page thumb) - upload.wikimedia.org - serve file as is, so no auto-orient.
(In reply to comment #4) > If you mean what happens when the user clicks through to see the fullsize file > at upload.wikimedia.org Nope: [[Image:Foo.jpg]] or just plain inline display where it's not big enough to trigger a thumbnailing down to limited size. > - I suppose we should follow Flickr's lead: if you > download one of their photos at "original" it doesn't auto-orient. For download yes, that's same as our current SVG behavior. > I would imagine this behaviour for say a 100px image that needed auto-orient: > - inline image [[image:foo.jpg]] or [[image:foo.jpg|100px]] - use auto-orient > - image on image page 100px wide - use auto-orient and provide file link to > original file on upload.wikimedia.org (currently we don't do this if the image > fits entirely on the image page thumb) > - upload.wikimedia.org - serve file as is, so no auto-orient. Sounds perfect. From an internal perspective, the object would be set as always requiring rendering for view, same with SVG and DjVu files.
A related problem (I'm going to file a separate bug if necessary) is turning those images that have no (or wrong) EXIF data. On Commons, {{rotate}} asks people to "perform a lossless rotation using a tool such as jpegtran". How about a mediawiki button, maybe for admins, to losslessly rotate images in steps of 90 degrees?
Bumping the priority on this and changing it from "enhancement" to regular bug -- many current digital cameras store orientation information this way, and it can be fairly non-obvious how to "fix" an image from this state when common image editing tools also support the EXIF orientation transparently. Accepting the declared orientation automatically on our end will reduce the number of hoops required to get a photo onto Wikimedia Commons.
We should ask imagemagick people to add -auto-orient to the -thumbnail option btw, so we don't have to care about it anymore.
(In reply to comment #8) > We should ask imagemagick people to add -auto-orient to the -thumbnail option > btw, so we don't have to care about it anymore. We do, because in the MediaHandler we still need to swap width and height around.
Fixed in r79845.
Interesting observation of note. The thumbnail in the Upload page (using the new FileAPI) is not an actual thumbnail, but the full image of course, and it seems that both Safari and FF for Mac, don't apply the EXIF rotation when viewing images in the browser. Not sure why that is, but it is rather confusing when you want to upload a file with EXIF rotation.
*poke poke brion* Can we read out exif data using HTML5? If so we can use the <canvas> element to do rotation ourself. Canvas is not supported by some stone-age browsers, but those browsers probably can't show a thumbnail anyway.
http://code.google.com/p/jsjpegmeta/ looks useful.
Added javascript rotation support in r79867.
It seems that this functionality is explicitly disabled in Safari, because it would create further confusion. You would have one browser rotating an included <img>, while all others don't. In that light, perhaps a note with "Your image contains 'orientation' settings that will be automatically applied after upload", is a better idea than actually rotating the image.......
Actually it is still under debate it seems: https://bugs.webkit.org/show_bug.cgi?id=19688
Created attachment 8647 [details] Sample rotated image file This is a sample file I created to ensure we had a handy test case for related bugs & regression checks. Image was drawn in Gimp in portrait, manually rotated sideways, and had appropriate EXIF orientation tag applied via: exif -c --output=portrait-rotated.jpg --ifd=0 --tag=0x0112 --set-value=8 --no-fixup portrait-raw.jpg Correct preview of this file should be in portrait format, showing the arrow pointing up and the word 'UP' legible.
I've noticed a problem with the rotation & scaling on trunk; while the image appears to be getting rotated correctly, it's scaled to the wrong dimensions in the case of a 90-degree rotation (at least for orientation 8 which should rotate 90 degrees left). The thumbnail image gets re-scaled to the proper aspect ratio on the client side, but if loaded directly will be stretched. Test box is on Ubuntu 11.04, $wgUseImageMagick on, version: $ convert --version Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC Features: OpenMP
Marking with need-unittest keyword; there really should be some standard source files in the unit test suite that we can confirm get rendered to correct size and orientation.
Scaler modes tested as of r90009: OK: * gd: correct size & orientation * imext (ImageMagick PHP extension): correct size & orientation Bad: * im (shell-out): orientation ok, size has width/height swapped * client: fails to rotate at all Unknown: * custom It looks like the --auto-orient option on convert might be telling it to swap its width/height, so we may need to swap them back before passing them in. (The ImageMagick extension mode does the rotation explicitly, and explicitly swaps the swapped width/height back first for the scaling.)
Started adding phpunit test cases in r90016. So far just loading in a landscape image (unrotated) and a portrait image (rotated via EXIF orientation number 8) and checking their width/height. The test fails on the rotated image, reporting a width of 1024 pixels instead of the expected 768 pixels; it seems that the 'width' and 'height' are still being reported in pre-rotation form, which isn't very useful since any view or transformation of it will be post-rotation. Still also need to add actual transform tests (can we test multiple backends easily?)
The rotation implementation here is awfully complex; is there a reason to use canvas over CSS transforms? This relies on FileReader, and so far the only browsers that support FileReader all support CSS transforms, at least with prefixes. We'd just have to add the appropriate rule. -moz-transform: rotate(90deg); -o-transform: rotate(90deg); -webkit-transform: rotate(90deg); transform: rotate(90deg);
Well, canvas does two things for you here: 1) by scaling down, you no longer have to keep a 10MP JPEG photo uncompressed in memory 2) by rotating, well it's rotated and now you're done. Copy-pasting the image will work as expected; no idea if it will with a CSS transform. and also 3) Note that EXIF orientation can include flipping as well as rotation -- see http://sylvana.net/jpegcrop/exif_orientation.html
Makes sense. Ok, canvas it is.
r92246
There are some serious breakages -- reopening and setting bug 31024 as a blocker.
Ok, issues recently raised in bug 31024 and bug 31048 are now fixed. Re-resolving.
*** Bug 31290 has been marked as a duplicate of this bug. ***
reopened. Please see here: https://commons.wikimedia.org/wiki/Commons:Village_pump#Autorotation_using_EXIF_tag_with_MW_1.18 Firefox 3.6 and Opera 11.5 do not rotate images based on EXIF tags: totally confusing when you click on the 800px preview to see the image in full that the image is suddenly wrongly rotated by 90° (portrait image). Usability failure in my opinion. Next time: Please ask Commons community before! :-) Solutions(?): *rotate them serverside (lossless!) and offer an additional download link (ugly) for the original image. *Get the browsers to rotate images based on EXIF. EXIF rotation is a confusing idea ;) And: we will get thousands of images being wrongly rotated in our old images! Images have wrong EXIF tags but it didn't matter since MW did not respect them. We probably need a bot deleting the wrong tag to fix them: exiftool -Orientation= filename.jpg
Firefox 7.0.1. apparently respects EXIF rotation. Fine. Although 3.6 is still supported... What about IE?
where is the edit button?.. gnah. Those browsers mentioned all do *not* rotate based on EXIF. Sorry, that EXIF rotation stuff is that confusing that it just did confuse me. Another reason simply not to do it... https://upload.wikimedia.org/wikipedia/commons/archive/7/7e/20111005030352!SagradaFamiliaSanJuan05.jpg is the old version which has an tag: "Orientierung drehen 270° (8)". So the browsers should show a rotated church but they show it all standing. → no browser support for EXIF-based rotation in Firefox 3.6, 6.0.1, 7.0.1 and Opera 11.5.
More test results: * IE9 (on Vista) doesn't rotate based on EXIF. * Safari5 (on Vista) doesn't, too. "In fact, it seems like there shouldn’t even be the option to specify rotation in EXIF!" [http://pleaselistencarefully.com/Why-photo-rotation-is-broken-on-the-iphone-4-and-how-to-fix-it-using-paperclip-on-heroku pleaselistencarefully.com] November 16th, 2010 * "AFAIK Firefox ignores EXIF information, and IMHO it probably should by default because it could potentially lead to undesirable affects." [http://forums.mozillazine.org/viewtopic.php?f=8&t=1352155 Bluefang] July 13th, 2009 Browser bugreport: * [http://code.google.com/p/chromium/issues/detail?id=56845 current chromium bug] At least we know that the EXIF rotation stuff is ugly. Ugly by design since older/basic tools able to decode and display jpeg do not understand EXIF. Then EXIF was added and used to apply a transformation which is really important - but ignored by all older/basic tools. Since today images are pushed directly from cams to browsers we have a problem. A safe approach would be: simply do not use the broken-by-design EXIF rotation. This means: if we display the thumbs rotated by EXIF we also need to rotate the full size server-side to be compatible with browsers (currently: all!).
I really don't like this "feature", this resolution is not proper. Good would be if the software rotate the images directly after upload, but not just the thumbnails. If I open the original file or download it on my computer, it's wrong rotated. It confuses user, because on their computer and with original size it looks right but the thumbnail is rotated if the exif is wrong.
(as I wrote in COM:VP) In case some people did not understand the severity (changed this bug to "major") of our problem: Some discussion/info about popular M$ tools (e.g. "Microsoft Picture manager") which do not care for EXIF rotation and also do not update it after rotating an image. See: [[:en:Windows_Photo_Gallery#Bugs]], [http://www.artslant.com/global/articles/show/11800 artslant.com], [http://www.google.com/support/forum/p/Picasa/thread?tid=76dd86d9b63dfed7&hl=en picasa discusion], [http://social.technet.microsoft.com/Forums/ar/w7itproui/thread/58866b3d-0e14-4db8-b6d4-2ee871303da2 technet.microsoft.com]. A user I spoke with in Commons did use MS photo manager since ever to rotate images. That means: when the thumbnails of his old uploads get purged or a thumb size which wasn't used before is used they all (also the old uploads) will display wrongly rotated and are unusable until fixed. If they are currently in articles the article will contain a rotated image.
I think you are describing a situation like this: - There are files which have EXIF rotation information. - Some desktop tools do not display the file correctly, with EXIF rotation. - So, the user rotates the file "physically" so it looks right in their desktop tool. But the EXIF information is still preserved. - Then they upload it to Commons, which detects the EXIF, and rotates it *again*. - Chaos ensues But, my question is, how do we fix that without also causing a bug if the user has desktop tools which do the *right* thing? Do we supply some sort of button on Commons to rotate the file until it looks right, then nuke the EXIF?
Corrections / comments: * "Some desktop tools" - no - (AFAIK) all(!) current desktop browsers do ignore EXIF rotation. * The chaos is minor currently. The chaos will get worse (I guess) when thumbs needs to be regenerated of all the x thousands of files with incorrect EXIF rotation which we already have from uploads in the past. * I do not know what the "the *right* thing" is: I would say that rotating an image by a meta tag while you know that there are older but even current tools which do not respect this is a stupid idea. This can be done if a file format specifies this right from the beginning... but the old, pure jpeg doesn't. * It would have been nice if the Commons users would have been asked before such a deployment - why isn't this possible? Why do we need chaos first? * I do not understand how you will realize your idea. I.e.: how to get the real orig image if the user wants do download it? Options: * option one is: revert this change and do it like the years before: Ignore EXIF-specified rotation. We have Rotatebot in Commons. Images get tagged and physically bot-rotated. This worked fine for all cases. After physical rotation each and every tool did display correctly - no more hassle. * option onepointfive is: No real server-side rotation but a javascript assisted placement of bot tempates {{rotate|xxx}} or {{reset rotation in EXIF}} (not existent currently) directly on upload. Did I understand it correctly that you can read the EXIF tags by using Javascript? You can show the (exif-rotated) thumb (as it is done now) in the upload form and add rotation arrows and ask the user to bring the image in the right orientation. If the orientation chosen by the user differs from the physical orientation the JS could set one of the templates mentioned above. Those templates could be bot-processed then. Or maybe directly processed by a serverside re-upload of a physically rotated version. Benefit: no problems with full-size view in older tools (browsers). No chaos with old uploads. No manual tagging for rotation needed. * option two is: We keep EXIF-based rotation but it needs improvements. ** The most urgent thing would be that we need to have a possibility to fix files which specify rotation but do not need rotation. Currently, we can only fix this manually. Bot would be a option: https://commons.wikimedia.org/wiki/User_talk:Dcoetzee#EXIF_orientation_reset_bot But even if we have one: it is hard for all users except tech-aware to understand what is going on. A average user will think: huh, my image is rotated, lets order rotatebot to correct rotate it back. The problem is: the first rotatebot attempt will fail since rotatebot doesn't take the current Exif rotation into account. Maybe it should - in some cases... ** The full-size usability: user expects no rotated image when he clicks on a image (with correct exif-based rotation) to see the full view. Serverside rotation of the full resolution image (lossless, via exiftran for example) would be an option. But we also need to provide a option to download the real original image (maybe an additional link below). Of course this will still cause confusion and maybe will break some scripts/tools. I suggest: revert and think. And then maybe try a exif-based rotation again. btw: * just found: [[bugzilla:31366]] describes the full-size view problem, too. Feel free to merge or whatever. Not my world here. * opened [[Bugzilla:31487]] for another problem: "EXIF orientation tag display on bottom of each file page". This leads to more user problems because they have no chance to understand why MW rotates a image.
>I suggest: revert and think. And then maybe try a exif-based rotation again. If we do, we should do so soon, before there are lot of cached rotated thumbnails. Given the problems it seems to be causing, the Exif auto-rotation feature does need more careful consideration imho.
Why is no one complaining about these problems on Flickr ? Because I believe we chose the same approach as Flickr.... Is it just because it's very difficult to download the full version of an image from flickr ? Or does Flickr serverside rotate images before anyone downloads the full version ?
I don't think there would be much of an issue if we did this consistently from the beginning (Some files are broken, but if its broken from the get-go, then its the file's fault). But when things used to work, and then stop, people tend to complain (Especially when they become really broken due to mismatched cached thumbs).
(In reply to comment #38) > Why is no one complaining about these problems on Flickr ? Because I believe we > chose the same approach as Flickr.... > > Is it just because it's very difficult to download the full version of an image > from flickr ? Or does Flickr serverside rotate images before anyone downloads > the full version ? The reason is: in flickr: you click on the image and you get a server-side scaled bigger version of the image but not the real full version like you get at Commons. I really hate flickr therefore, btw. It takes tens of clicks in flickr to get the original version (and this is only available at pro accounts). And: the full version is a forced download (you cannot view it in your browser). That is a completely different UI. Btw: that UI is that bad that often scaled-down versions of flickr images (CC licensed) are uploaded to Commons instead of the biggest available version. And, yes, flickr did the EXIF-based rotation right from the beginning, didn't it?
Some new stats from the rotation by bot (disabled) cat: (currently) 26 pictures in Category:Images requiring rotation by bot (images go there if a user places a template on the file page) * 15 of had wrong EXIF data, were not physically rotated * 4 images had correct EXIF, were physically rotated but a user did apparently intentionally request the correct rotation based on the physical pic. * 9 (incl. 4 left over from yesterday) images had incorrect EXIF, were physically rotated and needed rotation.
Please open separate bugs for new issues so we have a chance of tracking them. :) Bug 31366 covers the 'browser will usually see unrotated file when you click on the main image on the description page' thing. I think there's a couple other bugs around somewhere for manually changing the rotation -- which would let people easily correct images that get uploaded incorrectly.
(In reply to comment #42) With "option one" or "option onepointfive" from comment #36 we wouldn't need to solve Bug 31366. However, reverting seems to be the best solution for now. All was fine until the software change. Let's keep it like this please. This feature wasn't ready to be deployed (to Commons and Wikipedia).
Ok, I've created bug 31504 to track related issues. See the full list here: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=31504&hide_resolved=0
Well, you are all commenting on related issues, but as for Flickr I can speak authoritatively since I used to work there. And anyway, you could have verified its behaviour pretty easily yourself. I think this picture says it all. Here they are with our rotated test image: http://www.flickr.com/photos/brevity/6221434141/meta/in/photostream/ No, they did not do EXIF from day one. In fact, they don't do EXIF rotation at all, and EXIF metadata is entirely stripped from all scaled images. The reason why is that some people stuff ridiculous amounts of data in there, which is then incompressible. So if they preserved EXIF there would be some idiot who would just have to add 1MB of data into there, and then suddenly the 75x75 version is still 1MB, which breaks some other code, etc. etc. At Flickr they will add (some) EXIF info to the metadata of the file, which you can view on the metadata page. So, Flickr doesn't have this problem because they don't do anything with EXIF. But even if they *did* change their system, it would still be mostly okay. At Flickr, when a file is uploaded, it makes several thumbnails at fixed sizes and then that is it. Unless the file is replaced or manually rotated it never makes another thumbnail. Commons is very different; it will generate any thumbnail of any size on demand, and doesn't generate thumbnails until asked. So, on Flickr, if you uploaded some file in 2007, and you got it to the point where you like the rotation of the file or the thumbnails, it will stay that way. However, at Commons, now a file that was manually rotated in 2007 could be thumbnailed with the new code, which tries to EXIF-rotate. So now you have thumbnails that were created with different code all co-existing.
Anyway I'm not arguing whether it was right or wrong to change what we do with EXIF, I'm just correcting misinformation about Flickr.
so what if we make the scaling take into account upload time ? some versioning or something ?
Before this "fix" Commons did not have much problems with rotated images. They were rare and we had a simple system for tagging them for a bot to rotate. Now all the bets are off, since most images in need of rotation only need the deletion of the EXIF tag. I have uploaded yesterday a dozen of images which show just fine on my windows machine and 25% of them show up on Commons rotated. At present I do not have any tools on my PC that follow EXIF tags so it is hard to find such images beforehand. I am uploading images for years and for time being they all look fine, but I expect that large fraction of them will self-rotate if re-rendered. I think this extension is a cure to non-existing illness and the side-effects of the cure messing up much more files than are helping. I think we should revert it.
(In reply to comment #48) > we had a simple system for tagging them for a bot to rotate. Just a tip: Rotatebot was adjusted to MediaWiki's new behaviour since reverting didn't seem to happen. Rotatebot will rotate and adjust EXIF tag if needed. You can use {{rotate|xx}} based on the new(!) thumbnails (there is also one with a unusual size to force a new thumb creation inside the rotation template) like you did before.
(In reply to comment #48) > I think we should revert it. I would go for my suggestion "onepointfive" (see above). This would help users to rotate images. Currently the fully automatic rotation confuses people instead of help them. And: As we see in Bug 31637 it is totally arbitrary which metadata is used to rotate. There is no real standard, every program behaves different. If I create my own metadata standard will it be respected by MediaWiki, too? ;) → Images should be physically in a correct orientation! Nice to have: as many correct metadata tags as possible.
(In reply to comment #45) > Well, you are all commenting on related issues, but as for Flickr (...) they don't do EXIF rotation at all, and EXIF metadata is entirely stripped from all scaled images. There are images in flickr where the file is rotated according to the EXIF. I.e. the thumbs look right, but the original image (as provided by flickr) is rotated with EXIF rotation metadata. A couple of instances: http://www.flickr.com/photos/igorgm/6073292209/ http://www.flickr.com/photos/igorgm/6073985274/
(In reply to comment #51) > (In reply to comment #45) > > Well, you are all commenting on related issues, but as for Flickr (...) they don't do EXIF rotation at all, and EXIF metadata is entirely stripped from all scaled images. > > There are images in flickr where the file is rotated according to the EXIF. > I.e. the thumbs look right, but the original image (as provided by flickr) is > rotated with EXIF rotation metadata. > > A couple of instances: > http://www.flickr.com/photos/igorgm/6073292209/ > http://www.flickr.com/photos/igorgm/6073985274/ That was puzzling -- I tried it myself with the test image Brion was using in the unit tests. Orientation is 270, and yet the image remains unrotated: http://www.flickr.com/photos/brevity/6221434141/meta/in/photostream/ This is a guess, but the other image uses the Canon EXIF Tag "Auto Rotate". http://www.flickr.com/photos/igorgm/6073292209/meta/in/photostream/ ...which my usual EXIF parsing tool (exiv2) can't even read or write, so that's hard to test. Maybe Flickr decided that Orientation was unreliable, but maybe Canon's AutoRotate is. I'll ask.
>...which my usual EXIF parsing tool (exiv2) can't even read or write, so that's >hard to test. btw, exiftool can read Canon maker notes (And possibly write them), so it can be used to test that. As an aside, MediaWiki does not currently extract/do anything with, maker notes.
http://www.flickr.com/photos/iteijeiro/6049541815/ and http://www.flickr.com/photos/iteijeiro/5948070071/ get rotated and were made with a Nikon (NIKON D3100). They don't seem to contain propietary markers. Maybe they have a whitelist for cameras with gravity sensor?
(In reply to comment #54) > http://www.flickr.com/photos/iteijeiro/6049541815/ and > http://www.flickr.com/photos/iteijeiro/5948070071/ get rotated and were made > with a Nikon (NIKON D3100). They don't seem to contain propietary markers. > > Maybe they have a whitelist for cameras with gravity sensor? Maybe. I posted a test image, right out of a camera albeit an older one, and it still didn't work. http://www.flickr.com/photos/brevity/6254100567/meta/in/photostream/ (Test image from here: http://www.kotikone.fi/kuukkeli/antin_exiftran.html, taken with Nikon D50.)
Oh, never mind. I had a setting in my account to not auto-rotate my images. A friend of mine who works there says that, unless the user has turned off auto-rotate, EXIF Orientation is used to "physically" rotate the thumbnails as they are generated (which is a one-time event at Flickr). I do remember this long conversation about stripping EXIF from all thumbnails, which still seems to be the policy.
*** Bug 32507 has been marked as a duplicate of this bug. ***
I should note that it is now possible to disable the automatic rotation via $wgEnableAutoRotation
With http://commons.wikimedia.org/wiki/File:Urbanski_Grave.jpg (a photo of a grave marker taken with a Canon PowerShot SX100 IS uploaded 03:26, 24 March 2012 (UTC) and my version uploaded 34 minutes later) the EXIF contains "Orientation=Rotated 90° CCW", the original size displays fine in IE 9.0.8112.16421 64-bit Edition (reading left to right), and all thumbnails display Rotated 90° CW (reading top to bottom). :(
(In reply to comment #59) > With http://commons.wikimedia.org/wiki/File:Urbanski_Grave.jpg (a photo of a > grave marker taken with a Canon PowerShot SX100 IS uploaded 03:26, 24 March > 2012 (UTC) and my version uploaded 34 minutes later) the EXIF contains > "Orientation=Rotated 90° CCW", the original size displays fine in IE > 9.0.8112.16421 64-bit Edition (reading left to right), and all thumbnails > display Rotated 90° CW (reading top to bottom). :( That is the expected behaviour.
