Closed Bug 298619 (exif) Opened 19 years ago Closed 11 years ago

should consider using exif orientation flag when displaying JPEG images

Categories

(Core :: Layout: Images, Video, and HTML Frames, enhancement)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla26
Tracking Flags:
Tracking Status
relnote-firefox --- 26+

People

(Reporter: g.hueller, Assigned: seth)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: dev-doc-needed, Whiteboard: [GS])

Attachments

(6 files)

landscape photo
792.95 KB, image/jpeg
Details
unrotated portrait photo
700.51 KB, image/jpeg
Details
portrait photo manually rotated by Photo Editor
122.02 KB, image/jpeg
Details
portrait photo manually rotated by Photo Studio
541.68 KB, image/jpeg
Details
Use EXIF image orientation in top-level image documents.
624 bytes, patch
Dolske
: review+
Details | Diff | Splinter Review
Screenshots of browsers on Windows
163.54 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

just a thought to keep firefox on the bleeding edge:
modern digital cameras store the orientation of the camera when the picture was
taken inside the jpeg file.
ie when displayed with current browsers (MSIE, firefox), the picture is
displayed in landscape as is every picture. But the exif orientation flag tells
the true orientation when the picture was taken.
Only IrfanView and consorts display it correctly.

OK modern HTML gallery programs also consider that flag when writing images, and
the probability that a camera-written JPEG appears on the WWW is still small.

just a thought....

Reproducible: Always

Steps to Reproduce:
1.buy a modern digital camera
2.take a portrait picture
3.view that picture in your browser

Actual Results:  
picture is displayed in landscape

Expected Results:  
picture should be displayed portrait
Assignee: nobody → pavlov
Status: UNCONFIRMED → NEW
Component: General → ImageLib
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general
Hardware: PC → All
Summary: should consider exif orientation flag when displaying JPEG → should consider using exif orientation flag when displaying JPEG images
Version: unspecified → Trunk
EXIF is considered a global standard now. See www.exif.org. Firefox doesn't seem to support it yet.
Assignee: pavlov → nobody
QA Contact: imagelib
(In reply to comment #1)
> EXIF is considered a global standard now. See www.exif.org. Firefox doesn't
> seem to support it yet.
> 

See bug 232806 - but that's kinda different, I think this is more basic.
Many KDE 3 programs seem to support the EXIF orientation settings, which means that Firefox is the odd program out: everything else displays rotated images just fine, but when one views them in Firefox...

Feel free to bring this bug to the attention of the usability people for their consideration.
Man, this would have been a great GSOC project.
I imagine this as a student project to implement bug 232806 and this bug.
Keywords: student-project
This bug is a real issue for Thunderbird even if it isn't a big deal for Firefox. 

Users are increasingly likely to email photos directly from iPhones etc, most of which will set the Orientation flag but not actually rotate the image.  

Doing the right thing is also unlikely to impact in non-obvious ways when dealing with image attachments.
https://bugs.webkit.org/show_bug.cgi?id=19688 is WebKit's bug on the subject.
https://crbug.com/56845 is a chromium bug on the subject.
Bah, turns out crbug.com doesn't support https.  Use http://crbug.com/56845 instead.
I don't understand why a camera would output a JPEG oriented according to the sensor and include an EXIF orientation annotation with the correct orientation. Wouldn't it be simpler and more compatible with the rest of the world to just rotate the JPEG itself?
Presumably it is more expensive to rotate the image than to add a flag... This could be embedded hardware we're talking about - with real time requirements to clear the buffer ready to take another photo. 

Anyway, whether the camera could or should do something different isn't really important. The point is that image files contain information about how they should be displayed and Thunderbird/Firefox aren't acting on this information appropriately.
(In reply to comment #10)
> I don't understand why a camera would output a JPEG oriented according to
> the sensor and include an EXIF orientation annotation with the correct
> orientation. Wouldn't it be simpler and more compatible with the rest of the
> world to just rotate the JPEG itself?

One use case is an already-compressed image that needs to be rotated, and somebody sets the flag to avoid recompression. (I assume you're aware that JPEGs can only be rotated losslessly if their dimensions are a multiple of their block size, and even then only with software written specifically to do so.)
The problem is that no browser other than apparently iPhone Safari interprets these tags, and that rotating photos based on this metadata breaks Web pages.
(In reply to comment #12)
> One use case is an already-compressed image that needs to be rotated, and
> somebody sets the flag to avoid recompression. (I assume you're aware that
> JPEGs can only be rotated losslessly if their dimensions are a multiple of
> their block size, and even then only with software written specifically to
> do so.)

Do any cameras use sensors whose dimensions aren't a multiple of 8? Surely not.
(In reply to comment #13)
> The problem is that no browser other than apparently iPhone Safari
> interprets these tags, and that rotating photos based on this metadata
> breaks Web pages.

Yeah. As I said in Comment 7, I think this is a much bigger problem in Thunderbird than in Firefox - and a fix in Thunderbird is less likely to cause collateral damage than it would in Firefox. 

Is it possible to fix it in one, but not the other?
(In reply to comment #13)
> The problem is that no browser other than apparently iPhone Safari
> interprets these tags, and that rotating photos based on this metadata
> breaks Web pages.

I'd make this an opt-in thing on the part of the image element - some -moz-rotate-image: auto CSS attribute, or whatever, and opt in by default for image documents and Thunderbird.
Server-side opt-in would completely defeat the purpose; if the server knew or cared it would just rotate the images.  

Has anyone done a survey to find out if there are actually a significant number of images on the web that have the orientation flag set non-normal and Should Not?  I am having trouble imagining how that would happen - it would take software that (a) Rotates images, (b) Preserves EXIF (rare), and (c) Ignores the orientation flag, not rare in itself, but in combination with (a) and (b)?  If there are not a significant number of such broken images on the web (as I suspect there are not) then this feature should also be the default in Firefox.
I don't know of such a survey -- is there one indicating that there are a lot of images that would be helped by this? (probably a lot of protected images on facebook and elsewhere that would be hard to survey)
(In reply to comment #10)
> Wouldn't it be simpler and more compatible with the rest of the
> world to just rotate the JPEG itself?

if cameras would rotate images into portraint mode, can you imagine how broken the result of print outs of image printers would be? Most of them expect to get plain images in landscape orientation.

I think it would NOT be a good idea to mess with rotating images on the web. There are lots of images with orientation in EXIF AND there are JPEG manipulation tools that roatate images without flipping the orientation EXIF flag. So if you try to be smart for photos in the web in Firefox you will mess up things completely. People putting images on the web *will* rotate them for real.

A real advantage would be there if Thunderbird would display simple attached JPEG images rotated if the EXIF flag says so.

Just my 2 cent ...
My feeling - completely unbacked by hard data - also is that breakage of webpages would be minimal: non-EXIF-aware software usually discards metadata on any kind of manipulation. But I also understand the reluctance to go ahead without that hard data.

How about a compromise: Leave images embedded in webpages alone, but *do* EXIF-rotate "naked" images, i.e. non-embedded ones. We already scale those down to fit the browser window for users' convenience, rotating images to their (very likely) intended orientation will only improve on that.
(In reply to comment #21)
> How about a compromise: Leave images embedded in webpages alone, but *do*
> EXIF-rotate "naked" images, i.e. non-embedded ones.

I fear that would confuse web developers. "bug: this image looks right when I view it directly, but when I embed it in my webpage it's rotated!"  It's less confusing if we're internally consistent.

I agree with comment 15 & comment 20 that a thunderbird-specific fix seems most reasonable. (perhaps controlled by an about:config pref)
(In reply to comment #20)
> (In reply to comment #10)
> > Wouldn't it be simpler and more compatible with the rest of the
> > world to just rotate the JPEG itself?
> 
> if cameras would rotate images into portraint mode, can you imagine how
> broken the result of print outs of image printers would be? Most of them
> expect to get plain images in landscape orientation.

If I was writing image printing software, I would automatically place the longer axis of the image along the longer edge of the paper, so I can print photos that have been rotated.

> I think it would NOT be a good idea to mess with rotating images on the web.
> There are lots of images with orientation in EXIF AND there are JPEG
> manipulation tools that roatate images without flipping the orientation EXIF
> flag.

If people are rotating the image and not removing the EXIF annotation, won't honouring the EXIF annotation break those photos by rotating them again? 

According to the Chrome and Webkit bugs, the major practical issue here is people emailing images from their iOS devices which use the EXIF annotation, and then Webmail clients (and other clients I guess) not displaying those images correctly. For that case, there is absolutely no reason why Apple can't fix their iOS apps to rotate the JPEG properly. Apple should fix their apps instead of pushing their problem out to the entire Web.
To be precise, Apple should fix their iOS apps to properly rotate images before emailing or uploading them. That approach has less recoding, less coordination, less developer confusion, a faster migration path, and zero risk.
(In reply to comment #22)
> I fear that would confuse web developers. "bug: this image looks right when
> I view it directly, but when I embed it in my webpage it's rotated!"  It's
> less confusing if we're internally consistent.

By that standard it's hopeless to do anything right.  If I view a vertical picture taken with my camera via previews in the file browser in Fedora, or doubtless on any other OS, or of course in photo viewers in such, it'll appear properly oriented.  Now I upload it to a web site.  Now, "this image looks right when I view it locally, but when I view it on my website it's rotated!"  It's just as confusing to anyone taking pictures and uploading them, I think.

Stated more briefly, I think internal consistency doesn't mean much compared to the cross-application consistency beef here.

(In reply to comment #24)
> To be precise, Apple should fix their iOS apps to properly rotate images
> before emailing or uploading them. That approach has less recoding, less
> coordination, less developer confusion, a faster migration path, and zero
> risk.

My camera takes vertical pictures which are mis-oriented when I view them in the browser, more precisely when I upload them to my site.  That's certainly not Apple's fault, just a camera taking advantage of standard JPEG features that work in photo viewers, file explorers, &c.  And I don't think Sony's going to fix my camera to avoid that.
I was arguing on a usability basis and for consistency with other software. When I use a program like digiKam (0.9.3 on KDE 3.5.10) with images from my camera which doesn't have any orientation detection, the EXIF orientation reads "top, left" and after a clockwise rotation (which is a "real" rotation) it remains as "top, left". Such images, since they have been actually rotated, appear as anticipated in Firefox.

However, images which have orientation as "top, right", which appear as anticipated in digiKam (and Gwenview), appear rotated anti-clockwise in Firefox: that is, the actual top right corner of the image appears in the top left corner. Although I can't find the tool which apparently performed the EXIF rotation on my example images (changing "top, left" to "top, right") - it wasn't done by me, but was most likely done by some KDE software - it is clear that the effect of the rotation is supported widely in KDE and the images would appear correct right up until being viewed in Firefox.

As for whether supporting EXIF rotation would cause images to be incorrectly rotated, I would imagine that many images have "top, left" orientation by default unless an orientation sensor (or an image editor) has decided to override this. Such images probably have the intended orientation as they are, however this was achieved. Certainly, image editors that don't support EXIF orientation will maintain the metadata while actually rotating images, but people with orientation-aware cameras should already know that something is wrong if they load their images into such editors and see an incorrect orientation. Performing an actual rotation in such EXIF-unaware tools would compound an already present problem, but Firefox would be doing the right thing by observing the EXIF metadata.
(In reply to comment #25)
> (In reply to comment #22)
> > I fear that would confuse web developers. "bug: this image looks right when
> > I view it directly, but when I embed it in my webpage it's rotated!"  It's
> > less confusing if we're internally consistent.
> 
> By that standard it's hopeless to do anything right.  If I view a vertical
> picture taken with my camera via previews in the file browser in Fedora, or
> doubtless on any other OS, or of course in photo viewers in such, it'll
> appear properly oriented. 

FWIW the Windows 7 Photo Viewer and the Windows shell preview do not honor the EXIF orientation. So if you depend on the EXIF orientation, your photo is going to display incorrectly in any current Web browser, and some significant subset of other image viewers. Any device or image manipulation software would be much better off rotating the image for real.

> My camera takes vertical pictures which are mis-oriented when I view them in
> the browser, more precisely when I upload them to my site.  That's certainly
> not Apple's fault, just a camera taking advantage of standard JPEG features
> that work in photo viewers, file explorers, &c.  And I don't think Sony's
> going to fix my camera to avoid that.

My experiments show that Android does the same thing, at least when sending photos using GMail :-(.

However, I share the worry of paragraph 2 of comment #20.

I think someone could get some useful data here. Assuming that most/all sensors are wider than they are tall (even though there's no "natural" orientation for a phone, my Android phone always produces wide images), one could sample photos on the Web and count the photos that
1) have an EXIF orientation annotation that is wrong because the image has been manually rotated
2) have an EXIF orientation annotation and have their size in the page set using <img width="..." height="...">, hence would break if we automatically rotated the image
I think we should have that data before we try to change the behavior of JPEG for the Web.

If we take a short-term fix specific to Thunderbird or full-page image display, I wouldn't object to that. Especially if we extend the full-page image UI with rotation control so that users can fix it manually.
(In reply to comment #27)
> FWIW the Windows 7 Photo Viewer and the Windows shell preview do not honor
> the EXIF orientation.

Interesting.  OS X 10.5(.8) does honor it in shell and in Preview, just to complete the survey of the major desktops (well, sorta, I'm assuming KDE acts as GNOME does based on the digikam comment).
I just tried rotating the image in Windows Photo Viewer to see what it would do with the EXIF data.

It rotates the image data as expected. Fortunately, it adds an EXIF orientation tag to indicate that the photo doesn't need further rotation. Unfortunately, it leaves the old orientation tag in place as well!!!

Does EXIF specify which orientation tag to use when there's more than one? Do EXIF-aware photo viewers get that right?
(In reply to comment #29)
> Does EXIF specify which orientation tag to use when there's more than one?

As far as I can tell, it does not.

Anyone want to have fun testing EXIF-aware image viewers to see which ones use the first EXIF orientation tag and render this incorrectly?
http://people.mozilla.org/~roc/IMG_20110526_110158.jpg
Gwenview 1.4.2 (on KDE 3.5.10) shows the image correctly in portrait mode both when directly fetching and also locally viewing the image, although it will only report the "meta info" when accessing the image locally. The helpful orientation value in that case is "6" which would appear to correspond to "top, right":

http://www.impulseadventure.com/photo/exif-orientation.html

Gimp 2.4.6 also shows the image in portrait mode but doesn't seem to give any orientation information in the image properties.
On Mac, Picasa and Preview render the image correctly.
OpenOffice "Insert Picture" and Microsoft Paint also don't respect the EXIF tag.

I really think producing JPEGs that use the EXIF orientation is a bad idea. And I worry that importing EXIF orientation as a Web feature adds complexity and will create more problems.
(but I still think it's an option if we get data like in comment #27)
According to the comments, the reason that this exif flag exists is to speed up the saving of photos on the cameras, but there's no extra benefit once that step has been performed.

So if something is gonna be changed in Thunderbird to obey this flag, I would suggest that it should modify the image: If you compose a new mail and insert such an image then it can correctly rotate it, and then send an image with that correct orientation and the exif orientation flag removed. Likewise, upon getting a mail with such image show it as expected and if the user saves it to disk, save it with the correct orientation and no exif flag.

That shouldn't create any compatibility problems because Thunderbird would send a correctly oriented image and no matter if other programs are exif-aware or not, they'll show the image the same way.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #30)
> Anyone want to have fun testing EXIF-aware image viewers to see which ones use the first EXIF orientation tag and render this incorrectly?
> http://people.mozilla.org/~roc/IMG_20110526_110158.jpg

Do you mean the first orientation tag as opposed to the zeroth orientation tag?

Exiftool shows:
[EXIF:IFD0:Image] Orientation                   : Horizontal (normal)
[EXIF:IFD1:Image] Orientation                   : Rotate 90 CW

It shows correctly in Geeqie, Nautilus, Eye of GNOME, Thunar.
Concerning comment #36, in no way should Thunderbird be changing the images that are attached to emails. Attachments should be faithfully delivered as sent without any massaging to conform to your world view. Thunderbird is an email program and not some arbiter of what makes a good jpeg file.
I have to agree with the concerns cited in comment #23 and others.  

When I place a photo in a Web page, I always do some form of editing (e.g., resizing, cropping).  If the photo appears rotated in my editor, I rotate it to the proper orientation as part of that editing.  Since I have a real digital camera but do not have a photo-capable phone, I do the same editing before sending a photo via E-mail.  

I have searched and cannot find a format specification for JPEG files that indicates where the EXIF flag is located.  Thus, I cannot edit out such a flag when I have manually rotated an image.  I cannot even tell if my JPEG photos have EXIF flags.
Regarding comment #27 and concern if the EXIF tag doesn't match the image orientation e.g. in case the image was already rotated but the EXIF tag wasn't fixed.

My suggestion is to have checkbox in the status bar of the preview area called "Autorotate" which is by default checked. If checked it respects the information in EXIF and autorotates the pictures to proper orientation according to EXIF. If unchecked, it display them as they arrived.
Images in a Web page should be edited before the page is completed.  After completion, the page should be reviewed.  Thus, any such checkbox as proposed in comment #40 should have the default to ignore the exif flag for browsers.  

For E-mail, images are often sent without the sender even reviewing them.  Thus, any such checkbox should have the default to use exif flag for Thunderbird.
(In reply to David E. Ross from comment #41)
> Images in a Web page should be edited before the page is completed.  After
> completion, the page should be reviewed.  Thus, any such checkbox as
> proposed in comment #40 should have the default to ignore the exif flag for
> browsers.  
> 
> For E-mail, images are often sent without the sender even reviewing them. 
> Thus, any such checkbox should have the default to use exif flag for
> Thunderbird.

not  good idea without validation as there are image editors that retain exif settings even if the user chooses to rotate the image. if you decided to rotate an image based on exif you would also have to check for its longest side. But how do you detect if the image is cropped from portrait to landscape? As you see, there are tons of edge cases here, and I would guess that it is near to impossible to come up with a 100% foolproof  algorithm. you will inadvertently end up rotating some images wrongly, and thus end up with a broken feature.

better add a manual rotation tool and a way to remember this rotation.
Blocks: 717810
As an added twist -- it would appear that laying an iPhone or iPod over on its side to capture a landscape photograph will either encode as 0-degrees rotation or 180-degrees rotation, depending on whether the user turns it clockwise or counterclockwise (both seem natural when using the device).

This means that about half of all landscape photos I get from Apple mobile devices are upside-down.

It also means that 100% of all portrait photos (which people tend to send quite a few of when "portrait" is the default device orientation) are rotated 90 degrees.

We've come a long way since 2005, and this problem has gone from niche to pervasive. Collection of data to determine whether this breaks Firefox is all well and good, but I think we know enough about Thunderbird at this point to green-light a solution.
If at least we applied this to standalone images, I think this would be a great win already.
Comment 46 is fine for Firefox but doesn't help with Thunderbird where it generates the HTML to show the images. Thunderbird is seriously broken in this regard.
Would this RFE make Thunderbird not compliant with HTML specifications?  If so, is that a path that should be chosen?
I'm not talking about how you show HTML email with embedded images within Thunderbird, the issue is with image attachments. These attachments are currently shown with no regard for EXIF flags. This means that items emailed from smartphones, tablets and even desktops display incorrectly on Thunderbird. This makes Thunderbird look really bad, especially when, if you save the image and view it it looks perfect.

In this case there is no HTML to control use of EXIF info, the choice is simply one for Thunderbird. It needs to get it right. Currently, on the Mac, I see the images correctly in Finders quickview, Photoshop, Aperture, iPhoto, and any thing else I try and view the photo with. The *only* thing that gets it wrong is Thunderbird and Firefox.

As others have said it's no good trying to say that each device should 'correctly orient' the picture, there are too many devices out there that don't have the power to do that or where it would be a waist of resources (such as digital cameras). These devices are starting to get the ability to email directly, just as smartphones can. This cannot be the direction chosen for Thunderbird. Trying to do so will result in a disaster on the scale of ignoring h.264 support.

I've just checked on other web browsers and they all suffer the same issue as Firefox.
Obviously I meant waste not waist... :(
I'm just a user of Thunderbird and I don't know how easy it is to fix this, but this issue props up more and more with smartphone use.  I second comment #40, but suggest that an option be added to manually rotate the image if the user has not enabled the autorotate option.
WebKit respects EXIF orientation data in images when viewed standalone (as ImageDocuments), per <http://trac.webkit.org/changeset/113486> (linked in the see-also bug).  It seems to me that we should make at least that much change for consistency, although I think I'd do it in a new bug, this one now having fifty-plus varyingly irrelevant comments to wade through (including this one!).
Alias: exif
(In reply to Adam Roach from comment #43)
> As an added twist -- it would appear that laying an iPhone or iPod over on
> its side to capture a landscape photograph will either encode as 0-degrees
> rotation or 180-degrees rotation, depending on whether the user turns it
> clockwise or counterclockwise (both seem natural when using the device).
> 
> This means that about half of all landscape photos I get from Apple mobile
> devices are upside-down.
> 
> It also means that 100% of all portrait photos (which people tend to send
> quite a few of when "portrait" is the default device orientation) are
> rotated 90 degrees.
> 
> We've come a long way since 2005, and this problem has gone from niche to
> pervasive. Collection of data to determine whether this breaks Firefox is
> all well and good, but I think we know enough about Thunderbird at this
> point to green-light a solution.

I agree with this issue. I am getting more and more of these iOS' photographs/photos. these days to find the orientations incorrect. :(
Flags: in-testsuite+
Flags: in-testsuite+
This is not just an iOS problem.  My Canon SD850 point and shoot camera (a 2007 model) does the same thing.
This is a really vexing problem.
Unfortunately, there is no consistency between programs for honoring this JPEG orientation flag.

Most photo editing programs honor it and display the pictures correctly out of the camera. But many viewers, most notably the Windows 7 photo viewer, ignore it, and thus display the photos wrong.

Web browsers ignore it as well, sadly. I understand the problems of legacy images that once displayed one way, and which we don't want to change.

Still, I am perplexed that I cannot upload my pictures right out of the camera and display them right. If I want to share them with friends with my google drive for example, they will display wrong. I am required to manually rotate the image and remove the flag. This is a cumbersome process as well as lossy to image quality. 

If we can't unconditionally honor this flag, then we should at least consider some methods for honoring it under a defined set of circumstances.
I would really like to be able to set it for a given site or page. I am not sure how the server could communicate that to the client. If the images are embedded in an HTML file, perhaps there should be a flag somewhere in the HTML to tell the client to honor JPEG EXIF orientation for all the images on the entire page.

Or perhaps do something simpler but more drastic, and honor the orientation flag for all images shot after a specified date, based on the EXIF shooting date. This would be best enabled in coordination between all browser vendors.
Re comment #55:  

If I put an image into an HTML page, I first review the image.  Often, I crop or resize it.  Of course, I rotated it to its proper orientation.  This is all part of editing HTML (along with checking spelling, punctuation, grammar, etc) to ensure users see what I want them to see.  

If I manually rotate an image to its proper orientation, I surely do not want browsers to use the EXIF flag to rotate it again.  And I don't want to use a hex editor to find and tweak the EXIF flag to prevent such extra rotation.
@David Ross
The problem is that Thunderbird does not allow you to do this in an email. Attachments to emails do not come with HTML and are displayed raw. They are often sent directly from a device that does not support image rotation, like a camera or smart phone. Most smart phones support image rotation by simply adding information to the EXIF data to tell other applications to rotate the image on display. If you have edited the image and saved it again, and your image editing software is not brain dead, then it will add the correct EXIF image rotation information so this will not be an issue for your images.
@Julien Pierre: unless you have a really messed-up image editor, the EXIF rotation tag should be correct or not present at all (in which case it is the same as 0° rotation) which avoids the isue of backwards compatibility entirely

@David Ross: As a website designer, you would pay attention to that and pretty much all image editing software will edit the EXIF fields to match the real orientation (or strip it out entirely).

The real issue here is that cameras and especially phones now use the EXIF tag instead of physically rotating the image. While this in itself poses no issues, with the increased number of file syncing cloud services like Dropbox that automatically upload your photos in the background, photos rotated through the EXIF tags are becoming increasingly more widespread as people simply link already uploaded, EXIF-rotated images instead. I have done it myself (imagine my surprise) and is why I subscribed to this bug.

For this reason, I favor honoring the EXIF tag across all Gecko/Mozilla programs across ALL images rather than just Thunderbird or certain images.
Attached image landscape photo — 
Attachment IMG_0001.JPG was taken with a Canon A550 in normal (landscape) orientation.  This attachment and the three following may be used for testing.
Again with a Canon A550, this photo was taken in the portrait orientation and was not manually rotated.
Attachment IMG_0003.JPG is the same as attachment IMG_0002.JPG (#628802) manually rotated to proper orientation by Windows Photo Editor.
Attachment IMG_0004.JPG is the same as attachment IMG_0002.JPG (#628802) manually rotated to proper orientation by ArcSoft Photo Studio.
(In reply to David E. Ross from comment #56)
> If I put an image into an HTML page, I first review the image.  Often, I
> crop or resize it.

I certainly don't always crop or resize the picture. I sometimes take the picture at low resolution on camera on purpose, so that it doesn't have to be resized.

I'm glad you "often" crop or resize your picture. My problem is that the current implementation of JPEG in Firefox requires it, and it just shouldn't be necessary. I strongly feel that Firefox should be able to correctly display an image straight out of the camera. Not all JPEG images are embedded in HTML pages also. Firefox can open JPEG files that are not part of HTML pages. It should display them correctly, honoring the EXIF orientation flag, if present.

> Of course, I rotated it to its proper orientation.  This
> is all part of editing HTML (along with checking spelling, punctuation,
> grammar, etc) to ensure users see what I want them to see.  

And it is not part of a photographic process. I like to make my photo edits before I shoot the picture, composing and exposing properly, at the right resolution. Cameras allow you to do that. It is a tremendous waste of time to require every other photo to be edited in order to orient it properly.

> If I manually rotate an image to its proper orientation, I surely do not
> want browsers to use the EXIF flag to rotate it again.  And I don't want to
> use a hex editor to find and tweak the EXIF flag to prevent such extra
> rotation.

I think that would be an issue for your picture editor to deal with.

However, when no editor is used, and JPEGs are right out of the camera, Firefox should honor the orientation flag. It doesn't, and this is my main problem with the status quo.
(In reply to ZeDestructor from comment #58)
> @Julien Pierre: unless you have a really messed-up image editor, the EXIF
> rotation tag should be correct or not present at all (in which case it is
> the same as 0° rotation) which avoids the isue of backwards compatibility
> entirely

You are assuming that an image editor is always used. That is just not the case.
I shoot pictures with my camera, and the JPEGs always contain the EXIF orientation tag. That is what the "auto orient" function does in my camera. If I disable it, then the output JPEG files have no orientation flag, but unfortunately they are all landscape, thus requiring an editor to manually rotate them. The use of an editor solely for rotation purpose is what I want to avoid. Requiring each image to be edited just for the purpose of removing the EXIF orientation flag defeats the point. Removal of the EXIF flag, and actual rotation of the image, also involves degrading the image quality.
(In reply to Julien Pierre from comment #64)
> (In reply to ZeDestructor from comment #58)
> > @Julien Pierre: unless you have a really messed-up image editor, the EXIF
> > rotation tag should be correct or not present at all (in which case it is
> > the same as 0° rotation) which avoids the isue of backwards compatibility
> > entirely
> 
> You are assuming that an image editor is always used. That is just not the
> case.
> I shoot pictures with my camera, and the JPEGs always contain the EXIF
> orientation tag. That is what the "auto orient" function does in my camera.
> If I disable it, then the output JPEG files have no orientation flag, but
> unfortunately they are all landscape, thus requiring an editor to manually
> rotate them. The use of an editor solely for rotation purpose is what I want
> to avoid. Requiring each image to be edited just for the purpose of removing
> the EXIF orientation flag defeats the point. Removal of the EXIF flag, and
> actual rotation of the image, also involves degrading the image quality.

I was referring to you worrying about backwards compatibility, not whether you used an image editor or not. Sorry you missed my point.

Here's an image of mine: http://www.armedcats.net/image/view/1mzJqrdvFqP7wvVR

Opens fine in Gwenview (Linux) and my Nexus S (Android 4.0.x). Upside-down in FF.
(In reply to Julien Pierre from comment #63)
> However, when no editor is used, and JPEGs are right out of the camera,
> Firefox should honor the orientation flag. It doesn't, and this is my main
> problem with the status quo.

If we could tell that no editor was used, then that would be a fine solution. Unfortunately I don't know how to do that.
And, to be clear, we know that many editors leave the EXIF data untouched.  So if you use an editor to rotate the image, and that editor just leaves the exif data, then if we honored the EXIF data we'd just end up rotating it again.

Given that compatibility problem that means the only solution for Web content is to have a way of letting authors opt in to honoring the EXIF orientation.  (For email attachments it's probably better to just honor it, though, but that should be easy enough for thunderbird to implement if we implement a CSS property that lets authors opt in to honoring the EXIF orientation.)
(In reply to David Baron [:dbaron] from comment #67)
> Given that compatibility problem that means the only solution for Web
> content is to have a way of letting authors opt in to honoring the EXIF
> orientation.  (For email attachments it's probably better to just honor it,
> though, but that should be easy enough for thunderbird to implement if we
> implement a CSS property that lets authors opt in to honoring the EXIF
> orientation.)

Orientation isn't a presentation issue in most cases, so shouldn't this be handled in HTML? Perhaps with an attribute. 

Next gen image elements (eg. <pic>) could have this set by default.
ZeDestructor,

(In reply to ZeDestructor from comment #65)
> I was referring to you worrying about backwards compatibility, not whether
> you used an image editor or not. Sorry you missed my point.

Ah, I misunderstood indeed.

I don't know if my backwards compatibility fears are warranted. I did some google historical searches . This is the oldest dated reference I found : http://www.dpreview.com/news/2003/2/27/acdseereview . The flag was probably in use at least a year before.

I think it's fair to say that web publishers in the last 10 years have been testing their content with browsers that didn't honor EXIF orientation. Picture editors today might be fine, but they most certainly didn't deal with the flag correctly ten years ago.

Statistics would be useful to figure out what ratio of existing pictures have the EXIF flag out there at all on the web. That would give us an idea of the maximum ratio of pictures that would change orientation if we start honoring the flag. It would be good to know whether most of those pictures also contain the EXIF shooting date and time. If so, my suggestion to start honoring the flag only after a given shooting date might be the most painless as far as content breakage. However, it may be confusing to web developers.

During my google searches, I found that many programs over the last 3 years have been fixed to honor the flags. They didn't put any conditional logic to it, as far as I can tell.

Just doing this might be the simplest way, but I think we would want to make sure the rest of the industry does the same. Someone has to be first obviously. That is obviously not Firefox.

An HTML tag definitely would help, but some pictures are downloaded via ftp or http directly without corresponding HTML tag, and need to be handled too.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #66)
> If we could tell that no editor was used, then that would be a fine
> solution. Unfortunately I don't know how to do that.

I'm certainly not an expert in JPEG/EXIF .
I suspect that there are ways to detect that some pictures have been edited.

I found the specs at :
http://www.exif.org/Exif2-2.PDF

Looks like the orientation flag was there at least since 1998 .
There are many other date fields :
DateTime which is for the file change date.
DateTimeOriginal which is for the time the picture was taken .
DateTimeDigitized which is for the time the picture was converted to digital.

I think if these date/times differ, we could safely conclude that some processing was involved.
By exclusion, we could assume that all the other pictures are straight out of the camera :) I don't know how reliable this would be.

We would need data on how many pictures include both those various DateTime flags, and the Orientation flag.

There are probably many other methods to detect edits.  One EXIF flag is "Software". One might be able to figure out a lot from that. Even possibly specific versions of broken software which left EXIF flags alone during picture rotation. This is probably a lot of work.
My guess is there is way more (probably several fold more) people taking pictures by digital cameras and phones and sending them by email then editing them in image editors. 

My opinion is that by not fixing this bug to display the images correctly based on the EXIF flag we penalize way more people than those that would be affected by incorrectly displaying the images when edited by editor which doesn't correctly follow and/or modify the EXIF flag. By fixing it we would also allow these people to properly follow up with the image editor to correct any incorrect behavior.
This bug is now more than seven years old. in the interests of moving it along:

- all modern cameras with orientation sensors set EXIF tags rather than rotating the image data. That's the way it's going to stay, and it's pointless to complain about it.

- the issue of what to do about this in Firefox is complicated, and now is not the time for Mozilla to take the lead on changing it. Apple has already taken the first step by doing this in mobile Safari. Until we see it in desktop Safari, Chrome, Explorer, etc., nothing further should be done.

- on the other hand, the issue of what to do about it in Thunderbird is a no-brainer. For example, virtually all of the *billions* of photos mailed from the iPhone, will appear incorrectly oriented in Thunderbird. Portrait photos appear sideways, and when people use the popular "volume button as shutter release" feature, landscape photos appear upside down. But they appear correctly oriented in the native Mail app, on both mobile and the desktop. I can't think of any reason not to fix that. The argument that some people may use image-editing software that rotates the image data while leaving the EXIF rotation tag unchanged, is not a valid reason in my opinion, since that's not a sensible way for that software to operate, and should be fixed in said software...

Do we need to separate this into two bugs, one for Firefox and one for Thunderbird?
(In reply to Sum Yung Guy from comment #73)
> This bug is now more than seven years old. in the interests of moving it
> along:
> 
> - all modern cameras with orientation sensors set EXIF tags rather than
> rotating the image data. That's the way it's going to stay, and it's
> pointless to complain about it.

Agreed

> - the issue of what to do about this in Firefox is complicated, and now is
> not the time for Mozilla to take the lead on changing it. Apple has already
> taken the first step by doing this in mobile Safari. Until we see it in
> desktop Safari, Chrome, Explorer, etc., nothing further should be done.

I disagree. I think the choice is obvious and Firefox should take the lead and implement it as a core function of the rendering engine and not do some **** "safe" decision. The tag has been around since 1998, and massively widespread usage started at the very latest around 2007 with the success of the iPhone. This means that it has been five years since EXIF rotation has taken off in what can be approximated to an exponential growth following the growth of the smartphone market.

> - on the other hand, the issue of what to do about it in Thunderbird is a
> no-brainer. For example, virtually all of the *billions* of photos mailed
> from the iPhone, will appear incorrectly oriented in Thunderbird. Portrait
> photos appear sideways, and when people use the popular "volume button as
> shutter release" feature, landscape photos appear upside down. But they
> appear correctly oriented in the native Mail app, on both mobile and the
> desktop. I can't think of any reason not to fix that. The argument that some
> people may use image-editing software that rotates the image data while
> leaving the EXIF rotation tag unchanged, is not a valid reason in my
> opinion, since that's not a sensible way for that software to operate, and
> should be fixed in said software...

If your image editing software is ignoring the metadata, then it is either buggy, in early development or abandonded and you really shouldn't be using it eitherways. This is consequently a moot point: Mozilla should NOT be covering for other developers' failures.

> Do we need to separate this into two bugs, one for Firefox and one for
> Thunderbird?

No. This is a core rendering bug, not an application bug.

It's about time Mozilla started supporting the standard instead of ignoring it, especially since many, many people access the net via webmail services like GMail. Those of using Thunderbird are few in number and generally don't even directly attach pictures to our mails as we prefer online imagehosts like imgur/imageshack/photobucket/flickr/Google Pictures etc.
Gentlemen and ladies,

Unless your comment is specifically about the implementation of this feature, I'd like to ask you to restrict your advocacy to bugzilla "Votes", which were invented for such advocacy. As it is, you're hurting more than you're helping, I'm afraid.
Very recently, I observed that AOL Mail viewed on the Web via SeaMonkey 2.12 (the latest version) had a number of photos sideways.  Would proper orientation be the responsibility of AOL Mail or of SeaMonkey's Gecko core?
When receiving such an image from an iPhone by mail (in Seamonkey, probably also in Thunderbird) is it displayed rotated now. I have to save the image and open it in another viewer to see it correctly.
Note there is a Chrome extension that allows the user to rotate images via a context menu.

https://chrome.google.com/webstore/detail/img-rotate/jcoonajankpbolkgbipphpmbhefkengn

If this functionality was built into browsers, or the extension was better known, this would solve the user problem.
I understand the angst.  I wrote a photo gallery application & dealt with this issue there.

I decided that:
 * If there's no EXIF Orientation, I display as provided
 * If there's an EXIF Orientation tag, I rotate per the tag - if it says to rotate 270 degrees, that's what I do.  And I update the tag so that if the image is saved from the viewer, it indicates 'no rotation'.  If some other software rotated but didn't update the tag, that's not my problem.  
  * I provide a link for downloading the original image (that is, the bits I received; unmodified image, unmodified EXIF data).  So if some other software is available to deal with incorrectly tagged images, it can have them without any modifications.  (I also may resize by default - makes those 5MB snapshots display a LOT faster on typical browser windows...)

My answers for this environment are a tad more complex:
 Thunderbird - attach an image - just attach the image.  TB is a transport mechanism; it has no business modifying bits.
 Thunderbird - insert image - attach unmodified file.  But display per the EXIF orientation tag.  (It's the receiver's responsibility to display per the tag.)
 Thunderbird - display - Obey the EXIF orientation tag.  Provide a context menu option to rotate for the cases where the image is not displayed to the user's liking.  For 'save image', save the original bits/tags (same as save attachment).
 Firefox - same as TB display, unless major websites break.

This approach 'does the right thing' in that it obeys what the image provider declares.  If the image says 'rotate me', that's what we do.  The context menu 'rotate' provides a means for the person who looks at a picture to easily view any image that is incorrectly tagged in a 'better' orientation.  And all forms of save/send store what was received.  Any reorientation of the saved bits is the responsiblity of whatever software accesses them.

With respect to the discussion on multiple Orientation tags:  This is not supposed to happen.  The standard isn't explict, though it does specify that tags are supposed to be stored in (ascending) numerical order.  Most software I've seen extracts all the tags before doing any processing, doesn't care about order, and simply takes the last value that it sees for each tag.

For reference: EXIF is specified at http://www.exif.org/Exif2-2.PDF
I was looking at existing solutions for parsing EXIF this evening.  One C++ library that might be promising is:

http://code.google.com/p/easyexif/

Its BSD licensed, actively maintained, no dependencies, and looks to have a straightforward API.

I also noticed that pdf.js has a TODO for EXIF, so perhaps a JavaScript solution could be useful as well.  The only implementation I could find was the script for 2008:

http://www.nihilogic.dk/labs/exif/exif.js

MPL licensed, but seems like its not really maintained as a library.

Of course, we could also re-implement the parsing from the spec.  I couldn't find any guidance on whether 3rd party libs are ok in moz-central or not.  Any pointers would be helpful.

Personally, the easyexif C++ lib looks like a reasonable solution to pursue.
Also, asutherland pointed out to me that Gaia already parses some EXIF data:

https://github.com/mozilla-b2g/gaia/blob/master/shared/js/media/jpeg_metadata_parser.js
@Ben Kelly, maybe this can help?
https://github.com/jseidelin/exif-js

It is being used with
https://github.com/gokercebeci/canvasResize
Thanks for the link Pablo!  I'll check it out.  Looks like we have plenty of
options.
Hello everyone! I made an add-on that fixes this issue:

https://addons.mozilla.org/en-US/firefox/addon/imagetwist/

It auto-rotates images in "view image" mode according to their EXIF data. Everywhere else, you can choose to rotate them from a right-click menu.

I licensed it under the MIT license, the source code is here:
https://github.com/fwenzel/imagetwist

Comments, contributions, feature requests, etc. welcome! (On github please, not in this bug).
Is a work-around like an extension for thunderbird availible, too?
See Also: → 875181
Wow, it's a pleasure to finally fix this after 8 years.

This patch makes Firefox display images according to the correct EXIF orientation in top-level image documents. (For the <img> tag, web developers must opt in using the image-orientation CSS property; see bug 825771.)
Attachment #784597 - Flags: review?(dholbert)
Assignee: nobody → seth
Component: ImageLib → Layout: Images
Keywords: student-project
Keywords: dev-doc-needed
Comment on attachment 784597 [details] [diff] [review]
Use EXIF image orientation in top-level image documents.

TopLevelImageDocument is a bit of an oddball as it's basically a front-end feature living in layout, but I'll r+ it from the FE perspective. :)

At the very least we should land this, and watch for feedback. If it turns out to be surprising or there are gobs of mislabeled images, then it's a trivial thing to backout and consider further.

In particular, it might turn out that we want a pref (and/or some UI in the top-level image viewer) to control this. I think it's unlikely (and was even rejected in the past when we switched to dark backgrounds), but it's one path forward if needed.

I'll note that testing with http://farm4.staticflickr.com/3826/9028972457_6fa76877df_o.jpg, Chrome and Safari both display a portrait image (i.e., respect EXIF), while IE and Firefox do not. Presumably if this is a huge problem for Chrome, there's a bug in their tracker about it. Anyone want to go look for it?
Attachment #784597 - Flags: review+
Thanks for the review, Justin!

(In reply to Justin Dolske [:Dolske] from comment #90)
> I'll note that testing with
> http://farm4.staticflickr.com/3826/9028972457_6fa76877df_o.jpg, Chrome and
> Safari both display a portrait image (i.e., respect EXIF), while IE and
> Firefox do not. Presumably if this is a huge problem for Chrome, there's a
> bug in their tracker about it. Anyone want to go look for it?

I looked around and couldn't any bug like this. My hunch is that there's not much of a problem here and we probably don't need a pref, though I will happily add one if concerns arise.

I'll try to get this patch stack landed ASAP so we can start getting feedback from the community.
Comment on attachment 784597 [details] [diff] [review]
Use EXIF image orientation in top-level image documents.

Clearing the review request for Daniel since he has a lot of review requests from me already and I think this patch aligns more perfectly with Justin as a reviewer anyway.
Attachment #784597 - Flags: review?(dholbert)
Blocks: 833511
Seth, can you land this? :)
Flags: needinfo?(seth)
Sure. Just making sure 825771 stuck. =)

https://hg.mozilla.org/integration/mozilla-inbound/rev/54fa4456a4bb
Flags: needinfo?(seth)
relnote-firefox: --- → ?
https://hg.mozilla.org/mozilla-central/rev/54fa4456a4bb
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Release note something like "When displaying a standalone image, Firefox sets the image orientation to match the EXIF orientation information contained within the image."
relnote-firefox: ? → +
Maybe more specific "for JPEG images if provided" at the end?
Two features - the developer one in bug 825771 and this one is the user feature
Depends on: 917595
Is this not fixed for Thunderbird? I keep seeing wrongly orientated attached jpeg images.
Flags: needinfo?(seth)
This bug didn't make us respect the exif orientation flag *everywhere* (since doing so would break web content). It only fixed it in top-level image documents -- i.e., the UI you see when you view an image directly in Firefox.

If Thunderbird is displaying wrongly oriented jpeg images, that should be easy enough to fix (in Thunderbird code), though -- they just need to add "image-orientation: from-image" somewhere, like Seth did in this bug for image documents.

That should be tracked in its own bug, though.
Flags: needinfo?(seth)
Al, some pointers for you: Bug 877520 added support for /attached/ images with EXIF orientation flags to Thunderbird (for SeaMonkey that's bug 915909). Recently, bug 534083 added rotation and resizing support for images included into the message content (SM bug 939540). Those are all definitions for the default themes. Thus, if you use a 3rd-party theme, it will have to make respective adjustments.

Bug 916104 requests adding the ability to add the image-orientation attribute to composed messages, so that's covered as well, though without gaining any traction yet.
testing with Firefox 26.0 on Linux (but also tested on Win7), also in a fresh profile: firefox rotates http://farm4.staticflickr.com/3826/9028972457_6fa76877df_o.jpg as expected but gets the *aspect ratio wrong*! It is still shown in landscape format (and scaled to 25 %). A click on the image to zoom in to 100% shows it correctly. A zoom out to fit to screen makes the aspect ratio wrong again.  Interestingly something similar happens with Chromium 31.0: wrong aspect ratio, zoom in: correct, zoom out: correct aspect ratio (so only the inital load is wrong in Chromium).

I could not find many other images which behave similarly.   http://www.kotikone.fi/kuukkeli/Antin_kuvakalleria/anti_clock_wise_90_web.jpg and http://www.kotikone.fi/kuukkeli/Antin_kuvakalleria/clock_wise_90_web.jpg get fat/wrong if the window is made small enough to trigger Firefox zoom feature.

After searching a bit in bugzilla it seems that this problem was known (bug 917595) and is fixed for Firefox 28. Hmmm, a bit unfortunate that the rotation by EXIF is already switched on in Firefox 26, isn't it? Can someone test this with a nightly build?
(In reply to GreenRep from comment #107)
> Can someone test this with a nightly build?

All 3 WFM
(In reply to GreenRep from comment #107)
> After searching a bit in bugzilla it seems that this problem was known (bug 917595)
> and is fixed for Firefox 28. Hmmm, a bit unfortunate that the rotation by EXIF is
> already switched on in Firefox 26, isn't it?

The patch for bug 917595 landed on trunk but not the branches. I've added a comment there with your post quoted.
(In reply to GreenRep from comment #107)
> testing with Firefox 26.0 on Linux (but also tested on Win7), also in a
> fresh profile: firefox rotates
> http://farm4.staticflickr.com/3826/9028972457_6fa76877df_o.jpg as expected
> but gets the *aspect ratio wrong*! It is still shown in landscape format

Interestingly, Google Chrome 31 also gets the aspect ratio wrong and the image is rendered with correct aspect ratio after clicking the image to zoom in and clicking again to zoom out. Resizing the window also fixes the aspect ratio.

Firefox 26 always renders the image with incorrect aspect ratio. Firefox 29.0a1 nightly build (2013-12-16) renders the image with correct aspect ratio after the image has been fully loaded. However, the image is rendered with incorrect aspect ratio during the time the file is being downloaded.
(In reply to Mikko Rantalainen from comment #110)
> Interestingly, Google Chrome 31 also gets the aspect ratio wrong and the
> image is rendered with correct aspect ratio after clicking the image to zoom
> in and clicking again to zoom out. Resizing the window also fixes the aspect
> ratio.

The Chrome thing is (nearly) exactly what I wrote, isn't it?! Seems you quoted the wrong part of my comment.

Note that the aspect ratio issue is covered by (and discussed in) bug 917595 . I think here is the wrong place to continue.
The case with (not rotated) Canon photos: I also experienced that. After touching the JPG file with MS Office Picture Manager, picture is then rotated in FF (also stretched in mistmateched coords...). I've noticed the endianness of the two files is different. JPG file from Canon camera uses "II" (Intel - little endian), MS OPM saves metadata in "MM" (Motorola - big endian).

Looking into sources of 26 final and 27 beta2, the problem is with the magic number 42 (2A hex). In the file, this magic number is stored with respect of the endianness indicated (see http://en.wikipedia.org/wiki/Tagged_Image_File_Format#Byte_order), so 00 2A for MM and 2A 00 for II. But FF matches always 00 2A (image/decoders/EXIF.cpp, EXIFParser::ParseTIFFHeader).

The block:

==
  if (MatchString("MM", 2))
    mByteOrder = ByteOrder::BigEndian;
  else if (MatchString("II", 2))
    mByteOrder = ByteOrder::LittleEndian;
  else
    return false;

  if (!MatchString("\0*", 2))
    return false;
==

Should look like this:

==
  if (MatchString("MM", 2))
  {
    if (!MatchString("\0*", 2))
      return false;
    mByteOrder = ByteOrder::BigEndian;
  }
  else if (MatchString("II", 2))
  {
    if (!MatchString("*\0", 2))
      return false;
    mByteOrder = ByteOrder::LittleEndian;
  }
  else
    return false;
==
That issue is now fixed in nightly, see bug 950293.
There needs to be an option to disable image auto-rotation.
(In reply to Jef Poskanzer from comment #114)
> There needs to be an option to disable image auto-rotation.

This is not an issue of this closed bug. If you'd like to see this new feature added, please file a new bug (and try to ensure it's not a duplicate, by searching beforehand). Also ensure to give a short explanation what your use case is, beyond an assertion that something is needed. Thanks for your contribution!
(In reply to [:Aleksej] from comment #37)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #30)
> > Anyone want to have fun testing EXIF-aware image viewers to see which ones use the first EXIF orientation tag and render this incorrectly?
> > http://people.mozilla.org/~roc/IMG_20110526_110158.jpg
> 
> Do you mean the first orientation tag as opposed to the zeroth orientation
> tag?
> 
> Exiftool shows:
> [EXIF:IFD0:Image] Orientation                   : Horizontal (normal)
> [EXIF:IFD1:Image] Orientation                   : Rotate 90 CW

From what I understand, IFD0 is for the primary image and IFD1 is for the thumbnail. So this file doesn't have duplicate Orientation tags for the primary image.
I vote for re-opening the issue because:

1. Correct image orientation should also be supported by CSS background images and Canvas.

2. Correct image display is not a matter of web standards but a matter of file formats.
So I suggest either removing `image-orientation: from-image` or setting it to 'from-image' by default.
Similar to supporting animated GIFs, there is no property called 'animate-image: from-image'.
The image should be displayed as it was meant to be displayed, end of story.
Also, no other browser supports `image-orientation` so I assume it is safe for deprecation.

Backward compatibility is irrelevant because there is no workaround for solving image EXIF orientation issue, other than re-rendering the image on server side.

Here is an example page for displaying the problem:
http://softov.org/oria/image-orientation/index.html
Product: Core → Core Graveyard
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: