25642 2014-05-09 21:18:19 +0000 createImageBitmap() options: image data orientation 2016-03-16 14:15:58 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED P3 enhancement Needs Impl Interest 25639 1 ian ian annevk ian junov kbr mike contributor oldest_to_newest 105583 0 ian 2014-05-09 21:18:19 +0000 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 105588 1 ian 2014-05-09 21:21:58 +0000 *** Bug 25507 has been marked as a duplicate of this bug. *** 105624 2 annevk 2014-05-10 14:45:07 +0000 I think you want to align with bug 25508 here in some way. 106016 3 kbr 2014-05-15 06:36:32 +0000 For the record, the WebGL working group would like to see this option in the spec. 106062 4 ian 2014-05-15 18:06:26 +0000 If we're going to align with bug 25508, I guess the values would be: unchanged flipY autorotate autorotate-flipY 106085 5 kbr 2014-05-15 20:18:09 +0000 Additionally, there is desire to implement this feature on the Google Chrome team. Having it specified would make it easier to motivate adding it. 106160 6 junov 2014-05-16 13:22:38 +0000 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. 106162 7 annevk 2014-05-16 13:31:23 +0000 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. 106169 8 junov 2014-05-16 14:25:53 +0000 (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. 106179 9 ian 2014-05-16 16:58:52 +0000 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.) 125527 10 annevk 2016-03-16 14:15:58 +0000 https://github.com/whatwg/html/pull/741