My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 56845: EXIF orientation is ignored
60 people starred this issue and may be notified of changes. Back to list
 
Reported by thoc...@gmail.com, Sep 24, 2010
Chrome Version       : 6.0.472.55 (Official Build 58392) beta
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
Firefox 3.x:
IE 7:
IE 8:

What steps will reproduce the problem?
1. Find a JPG with the EXIF Orientation value set to a rotated value
2. View the JPG - it displays rotated, even though other apps know to rotate it based on EXIF data
3.

What is the expected result?  A heads-up picture.

What happens instead?  A head-sideways picture.


Please provide any additional information below. Attach a screenshot if
possible.

Screenshot shows a GMail preview - properly rotated - and a full-size chrome view, not rotated.
Screenshot.png
970 KB   View   Download
Oct 5, 2010
#1 westacu...@gmail.com
Safari 5.0.2 and Firefox 4.0b6 also do not respect the orientation value, but the current mobile version of Safari reportedly does.

The iPhone camera now uses the EXIF orientation value exclusively -- the screenshot above is indicative of what commonly happens with photos emailed from an iPhone.

Is there a technical reason why desktop browsers don't seem to support this, or is it just something that has never been a big enough issue to address? You'd think that now that most browsers support colour management in JPEGs, there wouldn't be much additional overhead for them to read the orientation value and perform the rotation.
Oct 21, 2010
#2 mr.j...@gmail.com
Please fix this issue. Sony Cameras also use this feature.
Oct 30, 2010
#3 lepin...@gmail.com
Chrome Version: 7.0.517.41 (OSX)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4: FAIL
Firefox 3.x: FAIL
IE 7:
IE 8:

Just adding that I'm still seeing this on 7.0.517.41. I've also tested Safari 4 and Firefox 3.6 and confirmed that this happens in those browsers as well.
Nov 16, 2010
#4 jfr...@gmail.com
Safari 5.0.2 (7533.18.5): FAIL
IE 8.0.6001.18702: FAIL
Opera 10.63: FAIL

Picasa photo viewer also knows how to rotate my JPGs (from a Canon XSi DSLR).
Dec 9, 2010
#5 thakis@chromium.org
http://i.min.us/iG4mm.jpeg is another repro case.
Status: Untriaged
Labels: -Area-Undefined Area-WebKit
Dec 10, 2010
#6 ctruta@chromium.org
This work has to go in WebKit. I added my preliminary analysis in the WebKit bug that I opened:
https://bugs.webkit.org/show_bug.cgi?id=50847
Dec 11, 2010
#8 noel.gor...@gmail.com
No browser support at all currently, really needs some standards support rather than
webkit-specific work.  Related items are:

https://bugs.webkit.org/show_bug.cgi?id=19688
  proposed last year, patch at r- and appears to have been dropped.

https://bugs.webkit.org/show_bug.cgi?id=39905
  WHATWG image resizer proposal, adds control for image orientation, dataURL and
  blob extraction, currently under consideration, and may be redesigned.

http://www.w3.org/TR/css3-page/#orienting
  formative section, doesn't address issues such as how would the browser a priori
  know the orientation so the proposed CSS3 could be applied, or what the reported
  values of image.naturalWidth|.naturalHeight would be for an orientated image ...

All up, not much to go on here.  I note it is possible, using javascript, to read
an images' orientation and present the image with the correct viewing orientation
using CSS3 -webkit-transform: matrix(...); transforms.  One downside is that user
javascript must also adjust (compute) CSS margin|padding when presenting multiple
images if uniform image spacing is required.

Dec 19, 2010
#9 fulldec...@gmail.com
Of course all images produced by the iPhone are affected.
Dec 20, 2010
#10 ka...@chromium.org
(No comment was entered for this change.)
Labels: Mstone-X
Dec 29, 2010
#11 linus%chromium.org@gtempaccount.com
This is really annoying. We need to fix this, at least for Gmail. Is there no hope of doing this in WebKit or should we pester the Gmail team?
Cc: jeffr...@chromium.org da...@chromium.org esei...@chromium.org
Labels: -Mstone-X Mstone-10
Dec 29, 2010
#12 thakis@chromium.org
I think there is hope in webkit land. ctruta said he'd like to give this a shot.
Owner: ctr...@chromium.org
Dec 29, 2010
#13 esei...@chromium.org
Oh, I just assigned the WebKit bug to myself, but you're welcome to take it ctruta.  The WebKit patch just needs someone to apply it and respond to Greg's comments.  Then I'd be happy to r+ it.
Status: Assigned
Dec 29, 2010
#14 abarth@chromium.org
> No browser support at all currently, really needs some standards support rather than
> webkit-specific work.

Does that mean that Gmail has this bug in every browser?  If so, they're going to need to fix it on their end no matter what we do in WebKit.

If all the browsers behave the same way today, why woud we want to start diverging now?  It's entirely likely that a bunch of random images on the web are tagged with this metadata today and would start displaying incorrectly.  If we do make this change, that means some images will randomly appear flipped in some browsers for a decade until every browser has learned how to process this metadata the same way again.
Dec 29, 2010
#15 esei...@chromium.org
I think it's interesting to investigate adding EXIF orientation support to WebKit.  I don't think its outside the realm of reasonable things for a browser to support.

However, I agree with Adam, this should be fixed on Gmail's end regardless.

We should probably close this as won't fix.  Until someone specs otherwise, all browsers agree: this is how the web works.
Dec 29, 2010
#16 thakis@google.com
Some browsers (e.g. Mobile Safari) process EXIF data correctly. Currently, the situation is that EXIF jpegs show up correctly everywhere except in browsers. I think the proposed fix in the webkit bug is to only do this when the browser displays an image/jpeg and not if the image is inline in a src. This is also (afaiu) where gmail has problems, as it shows a correct thumbnail (probably because it processes the EXIF data on the large image and then writes a rotated thumb without EXIF data?) but when you click it stuff looks broken.
Dec 29, 2010
#17 esei...@chromium.org
I suspect that the patch posted on https://bugs.webkit.org/show_bug.cgi?id=19688 came directly from Mobile Safari's port.  (David Carson is, or at least was, an iPhone WebKit engineer.)

I'm currently cleaning up David's patch and will post it on the WebKit bug shortly.

As I stated above, it's not outside the realm of possibility for a browser.  Maybe we only want to respect it when viewing images as an "ImageDocument" which sounds like what you're proposing.
Dec 29, 2010
#18 esei...@chromium.org
The gmail "view" link case can be solved by proposal 3, listed in:
https://bugs.webkit.org/show_bug.cgi?id=19688#c20

aka, auto-rotating images only when they are stand-alone image documents.

Are there other cases from Gmail where this applies?  I dont' think we can change any other image display cases w/o breaking the web.
Dec 29, 2010
#19 esei...@chromium.org
The gmail "preview" link which this bug references to, no longer exists.  That case (using an iframe/div within gmail to show the image) is not one browsers could easily solve for gmail w/o breaking sites.  Gmail however can easily read the EXIF data from the images either client or server side and fix them.

Closure could even do auto-rotation for them. :)
http://www.nihilogic.dk/labs/exif/
Cc: jpar...@chromium.org
Jan 4, 2011
#20 ctruta@chromium.org
> I think there is hope in webkit land. ctruta said he'd like to give this a shot.

I didn't feel so well in the last days, so I took it more slowly. I'm glad that Eric went ahead and did this though, because I had a lot to learn just by looking at his change.

I posted my thoughts in the WebKit bug. Essentially, I liked option 1, not option 3, because I would prefer implementing the proper solution, even though it might break some of the present-day workarounds.

In fact, a proper workaround for a website that delivers already-rotated images is to either reset or remove the rotation flag. This is good both conceptually (as the communication is clear: "don't bother rotating this because I did it") and practically (all www browsers will work properly).

Workarounds that break at the time when the problem gets fixed are bad workarounds.
Jan 21, 2011
#21 ctruta@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-10 Mstone-11
Feb 28, 2011
#22 ctruta@chromium.org
There is a need for consensus among the WebKit developers on what should be done. Eric suggested looking at the web index, in order to find out how many web sites auto-rotate EXIF-rotated images, and how many of those would break.

Assigning to Mstone-X.
Labels: -Mstone-11 Mstone-X
May 20, 2011
#23 mark@chromium.org
Can we get a decision one way or the other on this?

The system won’t take ctruta@chromium.org as an owner anymore.
Owner: ka...@chromium.org
Cc: ctruta@chromium.org
Labels: -Mstone-X Mstone-14
Jul 27, 2011
#24 kerz@google.com
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.
Labels: -Mstone-14 Mstone-15 MovedFrom-14
Jul 28, 2011
#25 timo.witte
Would be nice to have this feature implemented for direct hits on a jpge http://something/pic.jpg ... Sites rotating the picture while leaving exifdata inside it that says the picture should be rotated, just doing it wrong..
Sep 8, 2011
#26 kar...@google.com
moving all non-essential bugs from 15 to 16. please feel free to move back if this was an error and your bug is a release blocker.
Labels: Mstone-16 bulkmove MovedFrom15
Sep 23, 2011
#28 audvare
I currently deal with the situation on my web site manually by rotating based on EXIF data, but every now and then there could definitely be a mistake (there's no way to know if the EXIF data is correct).

In such a case, I really can't help but think how useful it would be that the context menu that appears when right-clicking an image could say 'Rotate left' and 'Rotate right'. Don't store what the user did (because there would be way too much overhead if you ask me), it's just temporary.
Sep 27, 2011
#29 erik...@chromium.org
 Issue 98172  has been merged into this issue.
Oct 24, 2011
#30 lafo...@google.com
(No comment was entered for this change.)
Labels: -Mstone-16 MovedFrom-16 Mstone-17
Nov 8, 2011
#31 jeffr...@google.com
(No comment was entered for this change.)
Cc: dhar...@chromium.org
Labels: Hotlist-Fixit
Dec 5, 2011
#32 youp...@gmail.com
This is bothering me many times a week for more one year now. I vote for "Option 3" as it's the only case I see the problem occurring, mainly iPhone pictures in Gmail attachments.
Dec 5, 2011
#33 jeffr...@google.com
Karen, were you holding onto this for a reason, or is there someone we can assign this to?
Dec 13, 2011
#34 kar...@google.com
eric any chance i can ask you to look at this?
Owner: esei...@chromium.org
Dec 13, 2011
#35 kar...@google.com
eric any chance i can ask you to look at this?
Dec 19, 2011
#36 kerz@google.com
Moving bugs marked as Assigned but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.
Labels: -Mstone-17 Mstone-18 MovedFrom-17
Jan 15, 2012
#37 dhw@chromium.org
 Issue 110348  has been merged into this issue.
Jan 15, 2012
#38 epnich...@gmail.com
"Option 3" sounds like a simple fix, but this bug has persisted for over a year.... what gives? Someone want to fix it tonight?
Jan 27, 2012
#39 wonghow
All image programs displays correctly except Google Chrome
Just spent hours thinking its the wrong EXIF data or buggy image software. Along its been Google bug.
Feb 6, 2012
#40 troc...@gmail.com
To anyone fed up with this bug, just install this extension, which does the job : 
https://code.google.com/p/img-rotate-extension
Feb 6, 2012
#41 wonghow
If this extension rotates automatically would be great
Feb 6, 2012
#42 epnich...@gmail.com
The extension doesn't solve the problem -- the average user (i.e. my parents, or my clients) will see the rotated-image as a bug, and won't know how to install an extension to fix the bug.  It should be fixed by default.

I'm always seeing people in cafes picking up their laptops and awkwardly rotating them to try to see a photo.... seriously, someone should just fix this. Can't the plug-in functionality be merged with the code base (and rotating made automatic, as wonghow suggested?

Feb 6, 2012
#43 troc...@gmail.com
As anyone in position to fix this bug is (rightfully) afraid of "breaking the web" or refuse to consider an intermediate solution (Option 3), I just thought "time to look for a workaround", and found it !

The original Webkit bug (almost 4 years old) : https://bugs.webkit.org/show_bug.cgi?id=19688

Lately it looks like Option 3 has a consensus  (auto-rotate only for ImageDocument, only when the main document.)

With Option 3 I suggest that, prior to rotate the image, some UI indicator suggesting that the rotation would be a good choice, by using the same type of overlay you see in Chrome when opening a PDF file (http://img.clubic.com/03803436-photo-chrome-pdf-viewer.jpg)

Last thing : it used to be an iPhone-related issue as it was only this type of device creating images with EXIF-specified rotation. Now Android phones behaves in a similar way, so maybe Google might be interested in fixing this.
Feb 7, 2012
#44 kar...@google.com
(No comment was entered for this change.)
Labels: MovedFrom18 Mstone-19
Mar 27, 2012
#45 lafo...@google.com
(No comment was entered for this change.)
Labels: -Mstone-19 Mstone-20 MovedFrom-19
Apr 11, 2012
#46 noel@chromium.org
http://wkb.ug/19688 is closed (resolved fixed).  Discussion of this feature has advanced to the CSS working group [1][2].  If you have concerns or something to add, please mail www-style.

[1] http://lists.w3.org/Archives/Public/www-style/2011Dec/0001.html
[2] http://lists.w3.org/Archives/Public/www-style/2012Feb/0316.html
Apr 12, 2012
#47 noel@chromium.org
(No comment was entered for this change.)
Status:
Owner: ---
Cc: -esei...@chromium.org -ctruta@chromium.org
Apr 12, 2012
#48 noel@chromium.org
Untriaged on standards trac.
Status: Untriaged
Apr 12, 2012
#49 cana...@gmail.com
Hello. Did you guys fix the damn thing or not? Want to hire me? I can do
it. I always wanted to work for Google.

-Canaan M. Johnson
Apr 12, 2012
#50 fulldec...@gmail.com
Hiring at this time is not necessary. Please fix the bug and submit your patch. Then we can discuss further. 
Apr 12, 2012
#51 noel@chromium.org
Ahem "http://wkb.ug/19688 is closed (resolved fixed)" aka Option 3. The rest is on standards trac.
Status: Fixed
Apr 12, 2012
#52 noel@chromium.org
... the rest being auto-rotation of web content images.

Per comment #14  "It's entirely likely that a bunch of random images on the web are tagged with this metadata today and would start displaying incorrectly.  If we do make this change, that means some images will randomly appear flipped in some browsers for a decade until every browser has learned how to process this metadata the same way again."

Exactly, and something browser vendors want to avoid. Incorrectly tagged images exist as discussed in http://wkb.ug/19688, and if we auto-rotate them, users will see and report those as bugs. My proposal is to extend CSS4 image-orientation with rotation controls

  img {
    image-orientation: from-image | [<angle>] [horizontal] [vertical]
  }

and second, to report the naturalOrientation of images in an img attribute, similar to img naturalWidth and naturalHeight.  www-style has the ball now, we'll see how it goes.

May 1, 2012
#53 erikwright@chromium.org
The webkit bug seems to indicate that this is turned on for Mac only. I'm using dev channel and it certainly doesn't seem to be fixed for me nearly a month after landing in WK.

Having skimmed the discussion on the webkit bug, it would seem that we still have work to do to get this (correctly rotating full-page images) working across all platforms:

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

Is my understanding correct? Do we have a bug tracking the remaining work or shall I create one/re-open this one?
Jun 25, 2012
#54 d...@darkened.net
I think this issue should be reopened as it has not been fixed. The original report was for full-page images, not images embedded within web pages. The whole webkit discussion appears to be around embedded images -- essentially the opposite of the desired outcome.
Jun 26, 2012
#55 cana...@gmail.com
Thank you. Microsoft < Google > Macintosh ... Look who got caught in the
middle. Wait, there's a new contender... FACEBOOK. What are they going to
do?
Aug 7, 2012
#56 dcopest...@gmail.com
This issue still exists for me.
Aug 7, 2012
#59 epnich...@gmail.com
Can someone verify if the single-image display EXIF issue has been fixed? I don't know how to tell if a fix has been applied to the latest release version of Chrome itself.

As for the extension -- thanks, but that's not a good-enough fix because I see this as an overall usability issue that affects the general public (people like my grandma) who won't be applying extensions to fix issues in the software. Every week I still see people at coffee shops picking up laptops and rotating them 90 degrees in the air to see a photo.... I hope this will quickly become a thing of the past. If it's really been fixed via option 3 -- great! But people are still reporting the issue so I suspect something has gone wrong. (sorry I don't have a file on hand to test at the moment).
Aug 20, 2012
#60 epnich...@gmail.com
Re: comments 54, 56 and 59, yes, the issue should be reopened.

It has not been fixed in the latest stable release of Chrome (21.0.1180.79).

Aug 21, 2012
#61 komoro...@chromium.org
Reopening as the described bug is not fixed (although a related one is).

Here's a testcase: http://www.xanthir.com/etc/exif/
Status: Available
Aug 21, 2012
#62 prashan...@chromium.org
(No comment was entered for this change.)
Labels: Non-WebStore
Sep 15, 2012
#63 jlege...@gmail.com
Will someone please fix this?   Here's my use case:

0) Take picture w/ iPhone in *portrait* camera orientation (!important).  Send via Gmail.
1) Receive Gmail message in desktop Mac Chrome (21.0.1180.89 m) with iPhone picture as attachment.  
2) Open message.. Gmail correctly displays 'preview' of picture in proper 'portrait' orientation (i.e. seems to observe EXIF info).  Available options are 'view', 'share', or 'download' picture
3) Select 'view' option on picture.   Gmail opens new browser tab containing only single picture (see attached html) in *landscape* orientation
4) Observe image is not properly rotate in Chrome!!  

Such an inconsistent experience: Gmail handles EXIF correctly, yet Chrome doesn't!  Makes Chrome look broken...
HTML.txt
445 bytes   View   Download
Oct 22, 2012
#64 djonl...@djonline.ru
Chrome team, you are very very slowness!!! Bug not fixed for 2 years !!!!
Oct 23, 2012
#65 thakis@chromium.org
(No comment was entered for this change.)
Status: Started
Owner: thakis@chromium.org
Oct 26, 2012
#66 thakis@chromium.org
As of webkit r132525, this is done when viewing image files directly. That change missed today's canary by 15 revisions, but it should be intomorrow's.

Images referenced from html files in <img> elements are not affected, intentionally for web compat -- this might be addressed through an explicit opt-in via css as suggested by noel in comment 8, but that's not done at the moment.
Status: Fixed
Labels: -Mstone-20 Mstone-24
Mar 10, 2013
#70 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-WebKit -Mstone-24 Cr-Content M-24
Apr 5, 2013
#71 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Jul 24, 2013
#72 lafo...@google.com
(No comment was entered for this change.)
Cc: -jeffr...@chromium.org
Sign in to add a comment

Powered by Google Project Hosting