25508 2014-04-29 22:53:04 +0000 <img>: Have an autorotate="" attribute that honours orientation metadata in the image (e.g. EXIF) 2019-03-29 22:27:50 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED MOVED http://code.google.com/p/chromium/issues/detail?id=413272 P3 enhancement Unsorted 1 ian zcorpan adrianba annevk d davve dbaron eoconnor eseidel ian jackalmage marakow mathias mike mjs noel.gordon oriadam roc seth Smylers zcorpan contributor oldest_to_newest 104749 0 ian 2014-04-29 22:53:04 +0000 Instead of the CSS 'image-orientation' property, it would make more sense to have an HTML <img> attribute that honours EXIF. 104752 1 ian 2014-04-29 23:03:15 +0000 cc'ing Tab so that he's aware of this and can drop image-orientation once I've added it, assuming that's workable. I presume this will be a boolean attribute; if present, honour orientation, else do the same as now. Any suggestions for a good name? honor-exif-orientation="" is a bit long. 104754 2 jackalmage 2014-04-29 23:06:14 +0000 You don't want EXIF in the name; while that's the metadata scheme used by most image formats, there's nothing special about it that would make this attribute work any differently if we used some other metadata scheme. Call it "autoorient"? (Dropping image-orientation in favor of an HTML attribute is already planned: http://dev.w3.org/csswg/css-images/#the-image-orientation) 104803 3 Smylers 2014-04-30 11:42:18 +0000 (In reply to Tab Atkins Jr. from comment #2) > Call it "autoorient"? That double “oo” is awkward. How about autorotate? 104828 4 ian 2014-04-30 17:56:38 +0000 autorotate="" is pretty nice. 104864 5 jackalmage 2014-04-30 21:33:21 +0000 Yeah, sounds good to me. 106417 6 zcorpan 2014-05-20 02:48:02 +0000 (File a new bug about the Index when fixing this) 106745 7 seth 2014-05-23 22:55:31 +0000 From my perspective, Tab's proposal at the bottom of this message is the right approach: http://lists.w3.org/Archives/Public/www-style/2014Apr/0186.html We really want some support in CSS for document authors to opt in to displaying images with the correct EXIF orientation. (And most sites would surely choose to do this once the feature is widely implemented.) If backwards compatibility were not a concern, the 'from-image' behavior would surely be the default today, given the proliferation of smartphone pictures with embedded EXIF orientation data. Safari Mobile even honors EXIF orientation by default! 106746 8 seth 2014-05-23 22:56:40 +0000 (To be clear, I'm just saying that we should retain some form of 'image-orientation' in CSS. I support adding the HTML attribute.) 108196 9 zcorpan 2014-06-22 13:37:13 +0000 https://twitter.com/brucel/status/479883882725404672 [[ TIL (thx @zcorpan) that <img autorotate> won't make images spin constantly, but honours orientation data in EXIF ]] rotatebymetadata is possibly a better name? (ack @shwetank) 109606 10 ian 2014-07-30 21:28:32 +0000 Since we're bikeshedding... I think autorotate="" is better than rotatebymetadata="". In particular, I think the more words you have in an an attribute name, the harder they are to read. "Rotate byme tada ta? Or is it rotate by me tadata?" 109613 11 jackalmage 2014-07-30 22:03:23 +0000 (In reply to Ian 'Hixie' Hickson from comment #10) > Since we're bikeshedding... I think autorotate="" is better than > rotatebymetadata="". In particular, I think the more words you have in an an > attribute name, the harder they are to read. "Rotate byme tada ta? Or is it > rotate by me tadata?" autorotate is definitely better, even with the possibility of it being interpreted as "constantly rotate". ^_^ "rotate by me, tada! Ta!" 110023 12 zcorpan 2014-08-07 11:59:22 +0000 It appears that desktop Safari, Chrome/Opera and Firefox honor EXIF when the image is shown in the top-level page, but not in <img>. https://raw.githubusercontent.com/recurser/exif-orientation-examples/master/Landscape_6.jpg http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3109 Mobile Safari honors EXIF also in <img>. Other mobile browsers don't. http://www.browserstack.com/screenshots/5864b36445508e27c01ccb333d17b979c27cdfb7 Are browsers willing to switch to the mobile Safari behavior without opt-in? Is Apple willing to ignore EXIF for <img> in mobile Safari when there's no opt-in? 110029 13 dbaron 2014-08-07 15:45:37 +0000 (In reply to Simon Pieters from comment #12) > It appears that desktop Safari, Chrome/Opera and Firefox honor EXIF when the > image is shown in the top-level page, but not in <img>. > > https://raw.githubusercontent.com/recurser/exif-orientation-examples/master/ > Landscape_6.jpg > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3109 Also note here that I believe this is specifically the *top-level* page, i.e., it doesn't happen with <iframe src="[...].jpg"></iframe>. > Mobile Safari honors EXIF also in <img>. Other mobile browsers don't. > > http://www.browserstack.com/screenshots/ > 5864b36445508e27c01ccb333d17b979c27cdfb7 > > Are browsers willing to switch to the mobile Safari behavior without opt-in? I think Mozilla folks would prefer not to; see the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=298619 110035 14 zcorpan 2014-08-08 05:32:29 +0000 Summarising the Mozilla and WebKit bug discussion: * iOS and Android devices use EXIF when taking a picture and email to someone. * Cameras usually use EXIF. * Some image editing tools rotate the image by changing the pixels and either remove EXIF, leave it as is, or add a duplicate entry saying "no rotation". https://bugs.webkit.org/show_bug.cgi?id=19688#c64 says Windows Photo Viewer can produce duplicates. * WebKit/Blink/Gecko (also Geeqie, Nautilus, Eye of GNOME, Thunar) use the last EXIF value when there are duplicates. (I get confused by https://bugzilla.mozilla.org/show_bug.cgi?id=298619#37 -- is it first or last?) * Windows 7 Photo Viewer, OpenOffice "Insert Picture" and Microsoft Paint ignore EXIF. * There has been no research yet as to whether always honoring EXIF is a net win or a net loss. Eric Seidel says in https://bugs.webkit.org/show_bug.cgi?id=19688#c61 he thinks it's a net win. https://bugzilla.mozilla.org/show_bug.cgi?id=298619#c27 suggests things to research. roc thinks supporting EXIF is a bad idea but is an option if research supports it. (https://bugzilla.mozilla.org/show_bug.cgi?id=298619#33 https://bugzilla.mozilla.org/show_bug.cgi?id=298619#34 ) 110701 15 zcorpan 2014-08-28 09:45:05 +0000 (In reply to Simon Pieters from comment #14) > * Some image editing tools rotate the image by changing the pixels and > either remove EXIF, leave it as is, or add a duplicate entry saying "no > rotation". https://bugs.webkit.org/show_bug.cgi?id=19688#c64 says Windows > Photo Viewer can produce duplicates. It's not clear to what extent this it true. It might just be a misunderstanding of what the tag applies to (the primary image or the thumbnail). https://bugs.webkit.org/show_bug.cgi?id=19688#c124 https://bugzilla.mozilla.org/show_bug.cgi?id=298619#c116 110702 16 zcorpan 2014-08-28 09:55:56 +0000 (In reply to Simon Pieters from comment #14) > * There has been no research yet as to whether always honoring EXIF is a net > win or a net loss. Eric Seidel says in > https://bugs.webkit.org/show_bug.cgi?id=19688#c61 he thinks it's a net win. I've tried to research this a bit. I've collected the following: A) total number of sites. B) total number of <img>s. C) total number of images with IFD0:Orientation tag that is not Horizontal. D) total number of images with IFD0:Orientation tag that is not Horizontal where the <img> had width and height attributes. E) total number of images with duplicate IFD0:Orientation tags where not all are Horizontal. (I have not collected "total number of images that are taller than wide (ignoring EXIF) and have orientation EXIF".) (I also didn't collect the number of images that failed to download or decode etc.) The data set is http://webdevdata.org/ data set 2013-09-01 102,000 pages. Method: $ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -Eio "<img\s[^>]+>" >> ../img.txt $ cd .. $ python fetch-img.py # https://gist.github.com/zcorpan/1848552ed84bc3db4935 Results: A) 2592 B) 43908 C) 0 D) 0 E) 0 No rotated images at all. Not very surprising though, given that the data set is font pages of high-profile sites. Let's look at a different data set: images on lists.w3.org. Method: https://www.google.com/search?q=site:lists.w3.org&tbm=isch load all results copy resulting DOM from devtools filter out imgurl=([^&]+) run similar script as above Results: A) 1 B) 779 C) 3 D) 0 E) 0 The images were: http://lists.w3.org/Archives/Public/www-archive/2012Feb/att-0011/dsc03579.jpg http://lists.w3.org/Archives/Public/www-archive/2013Oct/att-0018/PepysFootnotes.jpeg http://lists.w3.org/Archives/Public/www-archive/2013Feb/att-0010/dsc07902-Whiteboard.jpg relevant HTML pages containing those in <img>: http://lists.w3.org/Archives/Public/www-archive/2012Feb/0011.html http://lists.w3.org/Archives/Public/www-archive/2013Oct/0018.html http://lists.w3.org/Archives/Public/www-archive/2013Feb/0010.html These three would get the correct orientation if Exif was honored in <img> without opt-in, and no other images in the data set would regress. I'm happy to look at other data sets if the above is not convincing enough. So far, the data supports Eric Seidel's belief that honoring Exif without opt-in is a net win. What do people think? 110703 17 zcorpan 2014-08-28 10:15:21 +0000 (In reply to L. David Baron (Mozilla) from comment #13) > Also note here that I believe this is specifically the *top-level* page, > i.e., it doesn't happen with <iframe src="[...].jpg"></iframe>. That is true for Firefox but not for Safari, Chrome and Opera. (IE11 appears to ignore Exif both in iframe and top-level.) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3137 110737 18 marakow 2014-08-28 22:19:43 +0000 We're (IE) interested in honoring orientation for top-level and iframes though. Just hasn't happened yet. For other topics on the thread... I'd prefer to only have this in HTML or CSS, but not both. HTML sounds fine to me. My instinct is that rotating based on metadata by default would cause more layout breakage on long-tail and older sites. The data below is encouraging, though I'm curious if 0 is the right number given the number of users who upload EXIF-oriented images to various sites. It's likely that many top sites do fixup server-side but I'd still expect some images to make it through. For naming, I like autorotate, assuming that this is Boolean as Ian mentioned. If it needs more options then I like the image-orientation syntax. 110764 19 zcorpan 2014-08-29 12:05:36 +0000 Thanks Matt. Yep, I think 0 is right. (First the script collected any image that had the IFD0:Orientation tag, and there were a number that did but had the value Horizontal (normal) which is the default.) I guess it is possible to add a UseCounter in Blink or telemetry for Firefox to get more useful data, but it would take some more weeks to get it (plus impl+review time for adding the counter). Doesn't CSS also need a way to opt-in for things like background images if we don't rotate by default? 110772 20 marakow 2014-08-29 16:56:28 +0000 The rotation of background-images in CSS is covered by the image() function in Images L4 I believe: "If the image has an orientation specified in its metadata, such as EXIF, the UA must rotate or flip the image to correctly orient it as the metadata specifies." http://dev.w3.org/csswg/css-images/#image-notation 112581 21 zcorpan 2014-10-02 13:27:48 +0000 Is anyone interested in implementing images rotated without opt-in and seeing what breaks? I think it could very well be compatible enough (iOS Safari already does it; the research so far only found pages that would be fixed by doing it) and it seems better on the long term, IMHO. 112593 22 dbaron 2014-10-02 15:50:29 +0000 I think it would be worth trying. Does iOS Safari do it for all images (img, object, background-image, list-style-image, content, toplevel document, iframe, svg:image, etc.?) or just some of them? 112638 23 zcorpan 2014-10-03 10:52:32 +0000 In iOS Simulator of Xcode6-Beta5, I see: img, iframe, top-level document: rotated input, object, background-image, content, list-style-image, svg:image, video poster, embed: not rotated http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3226 118662 24 noel.gordon 2015-03-18 02:21:10 +0000 Yes, img, iframe, top-level (Image) document only. <iframe> documents satisfy the isImageDocument() test when the <iframe> source is an image URL [1] [1] http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderObject.cpp?rev=181654#L1771 What happens on iS Safari when the <img> is in a layer, via CSS translateZ(0) for example. 119873 25 zcorpan 2015-04-24 10:14:00 +0000 Also see https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/thread.html#msg14 124577 26 zcorpan 2016-01-13 10:50:26 +0000 It seems like there is not enough interest in trying to rotate all images by default. It's also not clear to me that it's a good idea to drop the CSS property, since one might want to rotate e.g. 'content: url(image)' images etc. I suggest we do this: * Keep the CSS property. * Add autorotate to <img> * Add img[autorotate] { image-orientation: from-image; } to Rendering. * Clarify that image-orientation affects naturalWidth, drawImage(), etc. * Require that https://html.spec.whatwg.org/multipage/browsers.html#read-media has an autorotate attribute set on the <img> (for top-level images *and* images in <iframe>s). 124579 27 noel.gordon 2016-01-13 15:17:16 +0000 I've added stats to chrome to record image orientation. The stats for win dev-channel chrome on Dec 25th 2015 (Christmas Day): not a busy day, but an interesting distribution. Top Left X Billion 100.00% Top Right 36 00.00% Bottom Right 2,474 00.00% Bottom Left 4 00.00% Left Top 2 00.00% Right Top 23,518 00.00% Right Bottom 3 00.00% Left Bottom 9,902 00.00% 124582 28 jackalmage 2016-01-13 23:25:15 +0000 (In reply to Simon Pieters from comment #26) > It seems like there is not enough interest in trying to rotate all images by > default. It's also not clear to me that it's a good idea to drop the CSS > property, since one might want to rotate e.g. 'content: url(image)' images > etc. > > I suggest we do this: > > * Keep the CSS property. > * Add autorotate to <img> > * Add img[autorotate] { image-orientation: from-image; } to Rendering. > * Clarify that image-orientation affects naturalWidth, drawImage(), etc. > * Require that > https://html.spec.whatwg.org/multipage/browsers.html#read-media has an > autorotate attribute set on the <img> (for top-level images *and* images in > <iframe>s). This sounds fine to me. 124641 29 zcorpan 2016-01-20 12:28:32 +0000 Thank you for the data Noel! It seems difficult to say if rotating by default would fix or regress more, though. But good to know it would at most regress 0.00% of images. :-) Is there still interest in changing the default, or should I implement comment 26 in the spec? 128894 30 oriadam 2017-09-13 08:20:12 +0000 I strongly vote for default behavior. Adding this property will make a confusion and inconsistency where it is not needed. For example we wouldn't want to add a property called "buggy-behavior:false" now would we :) There is no use for displaying images up-side down or mirrored. Regarding Noel's statistics - at the moment most websites that encounter this bug added processing of uploaded images to remove the orientation before displaying them image back to the user. This is another incentive to avoid adding 'autorotate' or 'image-orientation'. It would be interesting to see statistics for EXIF of uploaded images vs displayed images. 129683 31 d 2019-03-29 20:46:01 +0000 My understanding is that this work is currently being pursued in the CSSWG as `image-orientation: from-image`. https://drafts.csswg.org/css-images-3/#propdef-image-orientation 129712 32 zcorpan 2019-03-29 22:27:50 +0000 https://github.com/whatwg/html/issues/4495