New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 56845 link

Starred by 70 users

Issue metadata

Status: Fixed
Owner:
ooo
Closed: Oct 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

EXIF orientation is ignored

Reported by thoc...@gmail.com, Sep 24 2010

Issue description

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

Comment 2 by mr.j...@gmail.com, Oct 22 2010

Please fix this issue. Sony Cameras also use this feature.

Comment 3 by lepin...@gmail.com, Oct 30 2010

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.

Comment 4 by jfr...@gmail.com, Nov 17 2010

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

Comment 5 by thakis@chromium.org, Dec 10 2010

Labels: -Area-Undefined Area-WebKit
Status: Untriaged
http://i.min.us/iG4mm.jpeg is another repro case.

Comment 6 by ctruta@chromium.org, Dec 10 2010

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

Comment 7 Deleted

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.

Of course all images produced by the iPhone are affected.

Comment 10 by karen@chromium.org, Dec 20 2010

Labels: Mstone-X
Labels: -Mstone-X Mstone-10
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?
I think there is hope in webkit land. ctruta said he'd like to give this a shot.
Status: Assigned
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.
> 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.
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.

Comment 16 by thakis@google.com, Dec 30 2010

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.
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.
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.
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/
> 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.
Labels: -Mstone-10 Mstone-11
Labels: -Mstone-11 Mstone-X
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.

Comment 23 by mark@chromium.org, May 20 2011

Cc: ctruta@chromium.org
Labels: -Mstone-X Mstone-14
Owner: karen@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.

Comment 24 by k...@google.com, Jul 28 2011

Labels: -Mstone-14 Mstone-15 MovedFrom-14
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.
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..

Comment 26 by kareng@google.com, Sep 8 2011

Labels: Mstone-16 bulkmove MovedFrom15
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.

Comment 27 Deleted

Comment 28 by audv...@gmail.com, Sep 23 2011

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.
 Issue 98172  has been merged into this issue.

Comment 30 by laforge@google.com, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17
Cc: dharani@chromium.org
Labels: Hotlist-Fixit

Comment 32 by youp...@gmail.com, Dec 5 2011

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.
Karen, were you holding onto this for a reason, or is there someone we can assign this to?

Comment 34 by kareng@google.com, Dec 13 2011

Owner: eseidel@chromium.org
eric any chance i can ask you to look at this?

Comment 35 by kareng@google.com, Dec 13 2011

eric any chance i can ask you to look at this?

Comment 36 by k...@google.com, Dec 19 2011

Labels: -Mstone-17 Mstone-18 MovedFrom-17
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.

Comment 37 by dhw@chromium.org, Jan 16 2012

 Issue 110348  has been merged into this issue.
"Option 3" sounds like a simple fix, but this bug has persisted for over a year.... what gives? Someone want to fix it tonight?

Comment 39 by wong...@gmail.com, Jan 28 2012

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.

Comment 40 by troc...@gmail.com, Feb 6 2012

To anyone fed up with this bug, just install this extension, which does the job : 
http://code.google.com/p/img-rotate-extension

Comment 41 by wong...@gmail.com, Feb 6 2012

If this extension rotates automatically would be great
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?

Comment 43 by troc...@gmail.com, Feb 6 2012

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.

Comment 44 by kareng@google.com, Feb 7 2012

Labels: MovedFrom18 Mstone-19

Comment 45 by laforge@google.com, Mar 27 2012

Labels: -Mstone-19 Mstone-20 MovedFrom-19

Comment 46 by noel@chromium.org, Apr 12 2012

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

Comment 47 by noel@chromium.org, Apr 12 2012

Cc: -eseidel@chromium.org -ctruta@chromium.org
Owner: ----
Status:

Comment 48 by noel@chromium.org, Apr 12 2012

Status: Untriaged
Untriaged on standards trac.

Comment 49 by cana...@gmail.com, Apr 12 2012

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
Hiring at this time is not necessary. Please fix the bug and submit your patch. Then we can discuss further. 

Comment 51 by noel@chromium.org, Apr 12 2012

Status: Fixed
Ahem "http://wkb.ug/19688 is closed (resolved fixed)" aka Option 3. The rest is on standards trac.

Comment 52 by noel@chromium.org, Apr 12 2012

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

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?

Comment 54 by Deleted ...@, Jun 25 2012

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.

Comment 55 by cana...@gmail.com, Jun 26 2012

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?
This issue still exists for me.

Comment 57 Deleted

There is an extension that fixes that! https://chrome.google.com/webstore/detail/jlfhmpjdhloepjcmfhacbdlcgcibcbod
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).
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).

Status: Available
Reopening as the described bug is not fixed (although a related one is).

Here's a testcase: http://www.xanthir.com/etc/exif/
Labels: Non-WebStore

Comment 63 by jlege...@gmail.com, Sep 15 2012

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
Chrome team, you are very very slowness!!! Bug not fixed for 2 years !!!!
Owner: thakis@chromium.org
Status: Started
Labels: -Mstone-20 Mstone-24
Status: Fixed
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.

Comment 67 Deleted

Comment 68 by noel@chromium.org, Nov 5 2012

All done on https://bugs.webkit.org/show_bug.cgi?id=100191 for reference.

Comment 69 Deleted

Project Member

Comment 70 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Mstone-24 Cr-Content M-24
Project Member

Comment 71 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Comment 72 by laforge@google.com, Jul 24 2013

Cc: -jeffreyc@chromium.org
Note to self: Adding support for css image-orientation: from-image is tracked in issue 158753.
Is this fixed yet? I'm having hell with a webpage of mine, the photos showing correct orientation in IOS and in internet explorer, but turned all sorts of ways in google chrome. Its driving me crazy, can't seem to fix it.
@fireei...: I think your best bet is to process your images so they get the rotation applied. Jpegtran can do this lossless. After all, even if this gets fixed, there will be people using a browser that doesn't have the fix.

More on-topic: I noticed that background-image ignores the EXIF rotation, but the image tag works fine…

Sign in to add a comment