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:


This proposal seems pretty reasonable. I'm tracking this in:

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:

   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 

   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.

   Have createImageBitmap() take options, e.g. to honour EXIF orientation

   This is pending implementation interest outside Chrome.

   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():

   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:

   Have ImageBitmap expose height and width attributes

   This is pending implementation interest outside Chrome.

Regarding <img>:

   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.

   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.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to