Clarify the createImageBitmap orientation metadata handling #11234
Conversation
Based on whatwg#8118 (comment), we apply a rotation to the image from the metadata like EXIF contains orientation first. Then we determine the image orientation according to the imageOrientation value. fixes whatwg#7210
| <li><p>If <var>image</var> is an <code>img</code> element or a <code>Blob</code> object that | ||
| contains orientation metadata of the source such as <ref>EXIF</ref> metadata, | ||
| apply the orientation.</p> | ||
| </li> |
There was a problem hiding this comment.
This is applicable regardless of whether the imageOrientation member is given.
There was a problem hiding this comment.
Got it, I changed to reflect the orientation at first.
| data-x="dom-ImageOrientation-flipY">flipY</code></dfn>", <var>output</var> must be flipped | ||
| vertically, disregarding any image orientation metadata of the source (such as EXIF metadata), | ||
| if any. <ref>EXIF</ref></p> | ||
| vertically.</p> |
There was a problem hiding this comment.
You want these to be separate steps.
I also worry a bit that this isn't the right place to do it, but perhaps that can later be more properly abstracted. As we should really decode images in a single place after they come from the network and there we should apply the orientation metadata.
There was a problem hiding this comment.
I also worry a bit that this isn't the right place to do it, but perhaps that can later be more properly abstracted. As we should really decode images in a single place after they come from the network and there we should apply the orientation metadata.
There has been no agreement and this is merely a suggestion and implementation-oriented, but there was a conversation about making createImageBitmap a no-op to make it more tolerant of performance and reference from external specifications such as WebGPU.
As a result, I think it is best to just write down how EXIF is handled for now, so as not to restrict implementation-oriented behavior such as the timing of decoding or storing byte sequences including EXIF as internal variables in the API implementation.
closes #7210
I came across this issue recently when I was working on enhancement of createImageBitmap in Deno.
It seems that the relevant test cases are:
https://github.com/web-platform-tests/wpt/blob/0c27c59458/html/canvas/element/manual/imagebitmap/createImageBitmap-exif-orientation_none.html
https://github.com/web-platform-tests/wpt/blob/0c27c59458/html/canvas/element/manual/imagebitmap/createImageBitmap-exif-orientation.html
https://github.com/web-platform-tests/wpt/blob/0c27c59458/html/canvas/element/manual/imagebitmap/imagebitmap-replication-exif-orientation.html
/acknowledgements.html ( diff )
/imagebitmap-and-animations.html ( diff )