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.
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.
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.
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.
Some tests: https://mcc.id.au/2020/image-orientation/
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. 鈽猴笍
Most helpful comment
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 thoughimage-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. 鈽猴笍