Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, 16 Apr 2014, Boris Zbarsky wrote: Right now canvas drawImage ignores EXIF orientation metadata. Could we add a version that doesn't do that? Especially with CSS growing things like the image-orientation property, it would be good to support drawing the image in its correct orientation. On Wed, 16 Apr 2014, Justin Novosad wrote: But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? The default value for image-orientation is 0deg, which corresponds to the current drawImage behavior. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. On Wed, 16 Apr 2014, Anne van Kesteren wrote: Why is image-orientation in CSS for img? For background-image that makes sense, but if you are actually affecting the semantics of the image that is displayed, it seems like it should be in HTML or a hint in the image format. On Wed, 16 Apr 2014, Justin Novosad wrote: Yes, that makes a lot of sense IMHO. I just posted feedback to www-style The feedback seemed positive: http://lists.w3.org/Archives/Public/www-style/2014Apr/thread.html#msg179 This proposal seems pretty reasonable. I'm tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 On Wed, 16 Apr 2014, Justin Novosad wrote: Another use case to think about is: XHR-Blob-ImageBitmap-Canvas(2D or WebGL) With that data flow, there is no opportunity to use a CSS property to tweak image orientation. There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 If other vendors want to do this, please comment on the bug (or here). Here is a summary of related bugs: Regarding EXIF: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23510 Allow EXIF data to be passed to toBlob() This is pending implementation interest from browsers outside Mozilla, and someone coming up with a way to map EXIF to JSON in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23511 Expose EXIF data of images in img elements This is pending implementation interest and would also benefit from a way to map EXIF to an API in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 Have createImageBitmap() take options, e.g. to honour EXIF orientation This is pending implementation interest outside Chrome. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Have an attribute that honours EXIF orientation This seems to have implementation interest from everyone, and I'll hopefully be adding it soon. Need a good name; if you have a suggestion, add it to the bug. Regarding drawImage(): https://www.w3.org/Bugs/Public/show_bug.cgi?id=17427 drawImage() should accept SVGImageElement (svg:image) This is blocked on the SVG spec being updated to define image loading in a suitable level of detail. It could also do with interest from browser vendors other than Mozilla. Regarding ImageBitmap: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21346 Have ImageBitmap expose height and width attributes This is pending implementation interest outside Chrome. Regarding img: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842 Feature to make img elements not load their images until needed This is something I plan to deal with at the same time as script preloading, object preloading, et al. Right now I'm waiting to see if public-web-perf (the W3C WG) is going to move on this topic. No ETA. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24711 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24958 Refactor the image loading model; When exactly should update the image data run? The current img loading model doesn't match browsers well enough and I need to work on that. If you have thoughts on how image loading should work, please comment on bug 24711 soon. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, Apr 16, 2014 at 8:09 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad ju...@google.com wrote: I was wondering the same thing. From the image-orientation spec: It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as background-image). So this property apparently has a considerably larger scope than just correcting the orientation of images from files, which I guess explains why it is in CSS. I don't really follow the reasoning. But I guess if this has been shipping in Firefox for a while we might be out of luck changing this. The problem here stemms from that orientation data lives as metadata in the EXIF data of image formats. This means that many tools has simply ignored that metadata. The result seems to have been that people open their images in tools that ignore the EXIF metadata. Then rotates the pixel data using that tool. Then saves the image again while keeping the EXIF metadata unchanged. This now means the pixels have been rotated (say) 90 degrees, but the EXIF metadata still says rotate image 90 degrees. So any tool that now honors the EXIF renders the picture *wrong*. So effectively the EXIF metadata has to be ignored in order to keep webcompat. That was the case even before image-orientation was implemented. FWIW I believe that WebP is remaking this same mistake. Would be cool if someone tried to prevent this from happening. / Jonas
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Thu, Apr 17, 2014 at 2:46 AM, Jonas Sicking jo...@sicking.cc wrote: The problem here stemms from that orientation data lives as metadata in the EXIF data of image formats. This means that many tools has simply ignored that metadata. The result seems to have been that people open their images in tools that ignore the EXIF metadata. Then rotates the pixel data using that tool. Then saves the image again while keeping the EXIF metadata unchanged. This now means the pixels have been rotated (say) 90 degrees, but the EXIF metadata still says rotate image 90 degrees. So any tool that now honors the EXIF renders the picture *wrong*. So effectively the EXIF metadata has to be ignored in order to keep webcompat. That was the case even before image-orientation was implemented. FWIW I believe that WebP is remaking this same mistake. Would be cool if someone tried to prevent this from happening. The question was why is this a CSS style instead of a property on img, not why isn't this just the default. -- Glenn Maynard
Re: [whatwg] canvas drawImage and EXIF orientation metadata
+1 But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? The default value for image-orientation is 0deg, which corresponds to the current drawImage behavior. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. On Tue, Apr 15, 2014 at 10:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: Right now canvas drawImage ignores EXIF orientation metadata. Could we add a version that doesn't do that? Especially with CSS growing things like the image-orientation property, it would be good to support drawing the image in its correct orientation. -Boris
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, Apr 16, 2014 at 3:22 PM, Justin Novosad ju...@google.com wrote: But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? The default value for image-orientation is 0deg, which corresponds to the current drawImage behavior. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. Why is image-orientation in CSS for img? For background-image that makes sense, but if you are actually affecting the semantics of the image that is displayed, it seems like it should be in HTML or a hint in the image format. (My reply to Boris was going to be that drawImage() should follow whatever flag we introduce for img to have this behavior, seems weird for that flag to be in CSS though.) -- http://annevankesteren.nl/
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, Apr 16, 2014 at 7:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 16, 2014 at 3:22 PM, Justin Novosad ju...@google.com wrote: But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? The default value for image-orientation is 0deg, which corresponds to the current drawImage behavior. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. Why is image-orientation in CSS for img? For background-image that makes sense, but if you are actually affecting the semantics of the image that is displayed, it seems like it should be in HTML or a hint in the image format. I was wondering the same thing. From the image-orientation spec: It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as background-image). So this property apparently has a considerably larger scope than just correcting the orientation of images from files, which I guess explains why it is in CSS. (My reply to Boris was going to be that drawImage() should follow whatever flag we introduce for img to have this behavior, seems weird for that flag to be in CSS though.) -- http://annevankesteren.nl/
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On 4/16/14 10:22 AM, Justin Novosad wrote: But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? We could do that, though it introduces a dependency of drawImage on style computation that isn't there right now. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. Note that image-orientation has been shipping in Firefox for several releases now. -Boris
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad ju...@google.com wrote: I was wondering the same thing. From the image-orientation spec: It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as background-image). So this property apparently has a considerably larger scope than just correcting the orientation of images from files, which I guess explains why it is in CSS. I don't really follow the reasoning. But I guess if this has been shipping in Firefox for a while we might be out of luck changing this. -- http://annevankesteren.nl/
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On 4/16/14 11:09 AM, Anne van Kesteren wrote: I don't really follow the reasoning. But I guess if this has been shipping in Firefox for a while we might be out of luck changing this. I doubt image-orientation is widely used, esp. in combination with drawImage. But if we want to use it here, we should coordinate with the CSS WG at least. -Boris
Re: [whatwg] canvas drawImage and EXIF orientation metadata
Another use case to think about is: XHR-Blob-ImageBitmap-Canvas(2D or WebGL) With that data flow, there is no opportunity to use a CSS property to tweak image orientation. There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Boris' point about adding a dependency on style computation is concerning. This could potentially seriously regress performance of existing apps that (inadvertently?) invalidate style of image elements at each animation frame. From an implementation standpoint though, it would make sense for image elements to to store decoded images with the corrected orientation baked-in, and to be able to use that cached decoded image buffer directly in drawImage, without having to re-apply (or even verify) orientation correction at that time. But of course, that implies resolving style at image decode time. What to do? On Wed, Apr 16, 2014 at 8:15 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/16/14 11:09 AM, Anne van Kesteren wrote: I don't really follow the reasoning. But I guess if this has been shipping in Firefox for a while we might be out of luck changing this. I doubt image-orientation is widely used, esp. in combination with drawImage. But if we want to use it here, we should coordinate with the CSS WG at least. -Boris
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, Apr 16, 2014 at 5:54 PM, Justin Novosad ju...@google.com wrote: From an implementation standpoint though, it would make sense for image elements to to store decoded images with the corrected orientation baked-in, and to be able to use that cached decoded image buffer directly in drawImage, without having to re-apply (or even verify) orientation correction at that time. But of course, that implies resolving style at image decode time. What to do? We could consider moving this property into markup. It seems somewhat more semantic than stylistic too. Image orientation affects the content. -- http://annevankesteren.nl/
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, Apr 16, 2014 at 10:57 AM, Anne van Kesteren ann...@annevk.nlwrote: On Wed, Apr 16, 2014 at 5:54 PM, Justin Novosad ju...@google.com wrote: From an implementation standpoint though, it would make sense for image elements to to store decoded images with the corrected orientation baked-in, and to be able to use that cached decoded image buffer directly in drawImage, without having to re-apply (or even verify) orientation correction at that time. But of course, that implies resolving style at image decode time. What to do? We could consider moving this property into markup. It seems somewhat more semantic than stylistic too. Image orientation affects the content. Yes, that makes a lot of sense IMHO. I just posted feedback to www-style -- http://annevankesteren.nl/
