EXIF orientation (rotation information from digital cameras) should be used in images
Closed, ResolvedPublic

Description

Author: med.wiki

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


Version: 1.13.x
Severity: major
Platform: Other

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz6672.
bzimport created this task.Via LegacyJul 13 2006, 5:57 PM
bzimport added a comment.Via ConduitJul 2 2007, 3:15 AM

brianna.laugher wrote:

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

bzimport added a comment.Via ConduitJul 2 2007, 3:47 AM

brianna.laugher wrote:

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

brion added a comment.Via ConduitJul 2 2007, 7:48 PM

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.

bzimport added a comment.Via ConduitJul 3 2007, 2:34 AM

brianna.laugher wrote:

(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.
brion added a comment.Via ConduitJul 3 2007, 6:05 PM

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

bzimport added a comment.Via ConduitSep 17 2007, 9:27 AM

rl wrote:

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?

brion added a comment.Via ConduitMay 4 2008, 11:08 PM

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.

TheDJ added a comment.Via ConduitAug 18 2010, 1:43 PM

We should ask imagemagick people to add -auto-orient to the -thumbnail option btw, so we don't have to care about it anymore.

bzimport added a comment.Via ConduitJan 7 2011, 8:36 AM

Bryan.TongMinh wrote:

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

bzimport added a comment.Via ConduitJan 7 2011, 10:14 PM

Bryan.TongMinh wrote:

Fixed in r79845.

TheDJ added a comment.Via ConduitJan 8 2011, 12:40 AM

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.

bzimport added a comment.Via ConduitJan 8 2011, 11:42 AM

Bryan.TongMinh wrote:

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

bzimport added a comment.Via ConduitJan 8 2011, 2:04 PM

Bryan.TongMinh wrote:

http://code.google.com/p/jsjpegmeta/ looks useful.

bzimport added a comment.Via ConduitJan 8 2011, 4:25 PM

Bryan.TongMinh wrote:

Added javascript rotation support in r79867.

TheDJ added a comment.Via ConduitJan 9 2011, 2:31 PM

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

TheDJ added a comment.Via ConduitJan 9 2011, 2:33 PM

Actually it is still under debate it seems:

https://bugs.webkit.org/show_bug.cgi?id=19688

brion added a comment.Via ConduitJun 13 2011, 6:56 PM

Created attachment 8647
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.

Attached:

brion added a comment.Via ConduitJun 13 2011, 8:53 PM

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

brion added a comment.Via ConduitJun 13 2011, 8:54 PM

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.

brion added a comment.Via ConduitJun 13 2011, 9:10 PM

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

brion added a comment.Via ConduitJun 13 2011, 10:15 PM

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

bzimport added a comment.Via ConduitJun 13 2011, 11:20 PM

neilk wrote:

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);
brion added a comment.Via ConduitJun 13 2011, 11:23 PM

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

  1. Note that EXIF orientation can include flipping as well as rotation -- see http://sylvana.net/jpegcrop/exif_orientation.html
bzimport added a comment.Via ConduitJun 13 2011, 11:25 PM

neilk wrote:

Makes sense. Ok, canvas it is.

bzimport added a comment.Via ConduitJul 15 2011, 4:31 PM

Bryan.TongMinh wrote:

r92246

brion added a comment.Via ConduitSep 20 2011, 6:25 PM

There are some serious breakages -- reopening and setting bug 31024 as a blocker.

brion added a comment.Via ConduitSep 20 2011, 10:26 PM

Ok, issues recently raised in bug 31024 and bug 31048 are now fixed. Re-resolving.

brion added a comment.Via ConduitOct 3 2011, 4:26 PM
  • Bug 31290 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitOct 5 2011, 3:23 AM

saibotrash wrote:

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

bzimport added a comment.Via ConduitOct 5 2011, 3:25 AM

saibotrash wrote:

Firefox 7.0.1. apparently respects EXIF rotation. Fine. Although 3.6 is still supported... What about IE?

bzimport added a comment.Via ConduitOct 5 2011, 3:32 AM

saibotrash wrote:

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.

bzimport added a comment.Via ConduitOct 5 2011, 1:45 PM

saibotrash wrote:

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

Browser bugreport:

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

bzimport added a comment.Via ConduitOct 6 2011, 3:23 PM

luxo.wp+bugzilla wrote:

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.

bzimport added a comment.Via ConduitOct 7 2011, 2:13 AM

saibotrash wrote:

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

bzimport added a comment.Via ConduitOct 7 2011, 2:32 AM

neilk wrote:

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?

bzimport added a comment.Via ConduitOct 7 2011, 4:33 AM

saibotrash wrote:

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.
Bawolff added a comment.Via ConduitOct 7 2011, 2:06 PM

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.

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

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 ?

Bawolff added a comment.Via ConduitOct 7 2011, 2:18 PM

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

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

saibotrash wrote:

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

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

saibotrash wrote:

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.
brion added a comment.Via ConduitOct 7 2011, 7:48 PM

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.

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

saibotrash wrote:

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

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

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

bzimport added a comment.Via ConduitOct 8 2011, 2:19 AM

neilk wrote:

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.

bzimport added a comment.Via ConduitOct 8 2011, 2:20 AM

neilk wrote:

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.

TheDJ added a comment.Via ConduitOct 8 2011, 10:52 AM

so what if we make the scaling take into account upload time ? some versioning or something ?

Jarekt added a comment.Via ConduitOct 12 2011, 12:58 PM

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.

bzimport added a comment.Via ConduitOct 12 2011, 1:15 PM

saibotrash wrote:

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

bzimport added a comment.Via ConduitOct 12 2011, 1:48 PM

saibotrash wrote:

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

Platonides added a comment.Via ConduitOct 16 2011, 8:41 PM

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

bzimport added a comment.Via ConduitOct 16 2011, 10:55 PM

neilk wrote:

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

Bawolff added a comment.Via ConduitOct 16 2011, 11:54 PM

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

Platonides added a comment.Via ConduitOct 17 2011, 4:18 PM

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?

bzimport added a comment.Via ConduitOct 17 2011, 5:38 PM

neilk wrote:

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

bzimport added a comment.Via ConduitOct 17 2011, 5:50 PM

neilk wrote:

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.

Bawolff added a comment.Via ConduitNov 20 2011, 12:31 AM
  • Bug 32507 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitNov 20 2011, 7:21 PM

Bryan.TongMinh wrote:

I should note that it is now possible to disable the automatic rotation via $wgEnableAutoRotation

bzimport added a comment.Via ConduitMar 24 2012, 6:24 PM

RSYQFIOJGWZA wrote:

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

Bawolff added a comment.Via ConduitMar 25 2012, 5:52 AM

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

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:17 AM
Gilles raised the priority of this task from "High" to "Unbreak Now!".Via WebDec 4 2014, 10:21 AM
Gilles moved this task to Closed on the Multimedia workboard.
Gilles lowered the priority of this task from "Unbreak Now!" to "High".Via ConduitDec 4 2014, 11:21 AM

Add Comment