[css-images] image-orientation and canvas drawImage

[schenney-chromium]

More questions on https://drafts.csswg.org/css-images/#the-image-orientation

As of Canary version 81.0.4017.0 chromium supports the image-orientation property for all images in all locations, defaulting to the "from-image" value but also supporting "none" to turn off exif image-orientation.

In numerous cases where there is not yet a code path to access the CSS property, chromium will use "from-image". Right now that means that canvas drawImage calls will always respect the exif orientation.

1. Assuming we support image-orientation: none for drawImage, which element's image-orientation property should take priority when there is a conflict between the source element and the canvas element? I argue for the source but welcome feedback.

2. Given Safari does not support "none", should chromium just always use image-orientation: from-image in this situation?

There are some other similar cases: when an image is dragged and maybe when WebGL binds an image as texture. In all cases I argue that we respect the source's preferred orientation as that will avoid the image appearing to rotate when dragged or copied.

[heycam]

Right now that means that canvas drawImage calls will always respect the exif orientation.

From my testing in Chrome Canary yesterday, it looks like the image-orientation value on the canvas element itself affected a drawImage() call.

Testing a recent WebKit build, it's looking at the img element for image-orientation: none, but it's doing something buggy since I don't see all of the un-reoriented image in the canvas.

I think it makes more sense to look at the img element, if anything, although I realize that means it's possible to call drawImage() with some non-element image source, with no way to ignore the EXIF orientation.

[heycam]

Some tests: https://mcc.id.au/2020/image-orientation/

[blueimp]

Hi, I'm the author of a JavaScript Image Loading/Manipulation library (see also the previously referenced issue) and I noticed that there's another variable in image-orientation browser behavior that's not detailed out in the spec:

If the image and canvas elements are constructed outside of the DOM and the canvas only added to the DOM after the drawImage() call, results in browsers will differ even though image-orientation support might be the same.

For browser-based image manipulation libraries, it's important to be able to change the image-orientation behavior for out-of-DOM constructed elements or at least to be able to consistently detect their behavior based on browser support.

One use case for this is to be able to auto-rotate (based on EXIF data) and save the resulting image without keeping the meta data.
Another use case is to provide users the ability to provide an arbitrary rotation parameter.
In both cases, if the image has already been rotated by the browser, the library needs to detect this so it doesn't apply an incorrect rotation.

Currently, the situation looks like the following:

Browser	Version	initial value	default behavior	Out-of-DOM result
Chrome	81.0	from-image	from-image	from-image
Safari	13.1	from-image	from-image	from-image
Firefox	75.0	none	none	none
Firefox	76.0b2	from-image	none	none

To illustrate this better, I took the liberty to extend your test example @heycam with the out-of-DOM behaviors (hot-linking your example image) - hope that is acceptable:
https://image-orientation-test.now.sh/

At the moment, the only way I see to properly detect if an out-of-DOM created canvas element has been rotated by the browser is to use a (minimal) test image, which is less than ideal.

I hope this provides some context from the JS library author view. ☺️