This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This bug proposes the following new option for createImageBitmap()'s configuration dictionary (as proposed in bug 25639): OrientationKind orientation = 'unchanged' // how to orient the image // OrientationKind: // 'unchanged' - pass the image through unmodified // 'flipY' - vertically invert the image data // 'upright' - place the top left of the image according to the metadata // at the top left of the bitmap data; acts as 'unchanged' in the // absence of image orientation metadata // 'inverted' - place the top left of the image according to the metadata // at the bottom left of the bitmap data; acts as 'flipY' in the // absence of image orientation metadata See also: http://wiki.whatwg.org/wiki/ImageBitmap_Options http://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0067.html
*** Bug 25507 has been marked as a duplicate of this bug. ***
I think you want to align with bug 25508 here in some way.
For the record, the WebGL working group would like to see this option in the spec.
If we're going to align with bug 25508, I guess the values would be: unchanged flipY autorotate autorotate-flipY
Additionally, there is desire to implement this feature on the Google Chrome team. Having it specified would make it easier to motivate adding it.
FWIW, having options that respect orientation meta data here is not redundant with bug 25508 because we need a path to support orientation meta data when not going through an <img>. For example, when loading from a blob. However, in cases where we are loading through an <img>, the behavior has to be smart and take into account any upstream orientation tweaking that may have been performed by the <img> decoding steps. For example, if the image element already autorotated that data, createImageBitmap with orientation='autorotate' must detect this and not "autorotate" a second time. Issue: How do we handle the case where 'unchanged' or 'flipY' are used with an <img> that is autorotated? Is the image to be 'unchanged' with respect to the pre- or post-autorotated orientation? I can't think of any use cases that would strongly require one or the other, but the behavior still need to be clearly defined. I think using the post-autorotated image would be more predictable behavior (what devs would expect), but I don't have any strong arguments to support that claim.
Align != redundant ;-) I would expect that the parameter overrides the <img> attribute (acting as if the attribute was not specified). If the parameter is not given, the <img> attribute would be used. That would make specifying the same a no-op and still give full control relative to the source image. I don't see a reason for stacking.
(In reply to Anne from comment #7) > Align != redundant ;-) Yes, I was clarifying not correcting ;-) > I would expect that the parameter overrides the <img> attribute (acting as > if the attribute was not specified). If the parameter is not given, the > <img> attribute would be used. > > That would make specifying the same a no-op and still give full control > relative to the source image. I don't see a reason for stacking. Overriding sounds good to me. Easy to spec in a concise and non-confusing way. Will make sense to devs.
Yeah, I was imagining that this would go back to the original data and override anything specified on <img>. But we can make this clearer by adding another value: use-source-orientation - honours <img autorotate> raw - takes original raw pixel data raw-flipY - takes original raw pixel data, flips it vertically autorotate - honours EXIF autorotate-flipY - honours EXIF, then flips vertically The default would be 'use-source-orientation'. (I'm not a fan of these exact names, if anyone has a better suggestion for these names, let me know.)
https://github.com/whatwg/html/pull/741