Repository navigation
[css-images-3] Allow impls to not respect exif data if it's after the image data #4929
Description
In #3799 (comment), @eeeps brings up the fact that none of the browsers currently supporting image-orientation: from-image; respect the orientation if it comes after the image data. (firefox bug, webkit bug, chrome bug)
This is fairly reasonable, as it would be incompatible with streaming display of the image; it would progressively render in one orientation, and then flip around once it's finished. This is not only somewhat jarring, it seems to be incompatible with current browser image loading architectures, without some refactoring of uncertain complexity.
I suggest that we explicitly allow impls to not respect orientation if it comes after the image data; possibly we should restrict them from doing so, tho I'm not sure if this unnecessarily constrains their future usage of image libraries.
Activity
chrishtr commentedon Apr 9, 2020
tabatkins commentedon Apr 9, 2020
chrishtr commentedon Apr 9, 2020
chrishtr commentedon Apr 9, 2020
schenney-chromium commentedon Apr 9, 2020
tabatkins commentedon Apr 9, 2020
schenney-chromium commentedon Apr 9, 2020
schenney-chromium commentedon Apr 9, 2020
eeeps commentedon Apr 10, 2020
schenney-chromium commentedon Apr 10, 2020
tabatkins commentedon Apr 10, 2020
I've hidden the diversion due to confusion. ^_^
So bringing us back:
Chrome, Safari, and Firefox all now respect
image-orientation: from-imageon JPGs (in their latest versions, make sure you're updated), as shown in https://ericportis.com/etc/PNG-EXIF-orientation/.Chrome and Firefox don't currently support it on PNGs at all (but plan to fix that). Safari does support EXIF on PNGs, but only if it comes before the image data (the PNG spec technically allows it to show up before or after). (The test linked above has the EXIF after the image data.)
Orientation data showing up after the image data is hostile to streaming display of the image: it'll progressively render one way, then flip at the very end, and that's assuming your rendering pipeline even allows changing orientation after-the-fact (apparently Safari's doesn't currently).
So! Given that, should the spec allow (or mandate) ignoring image-derived orientation if it comes after the image data?
svgeesus commentedon Apr 10, 2020
It would be reasonable for the relatively recent (2017) specification for EXIF in PNG to add a recommendation to put EXIF data before the IDAT (image data) chunk, in section 3.7.3 eXIf Recommendations for Encoders.
annevk commentedon Jun 5, 2020
I think it should be mandated (and tested), otherwise you get a race to the bottom.
8 remaining items
annevk commentedon Oct 23, 2020
I'm not happy with @smfr's example and using that as justification for "should" rather than "must". Perhaps it is out of place for CSS to say something about images, but I think for the web we should have a consistent image model across implementations and it definitely shouldn't depend on the size of the image what ends up happening. That will lead to confusion for web developers.
If the concern is really about CSS defining it, perhaps image fetching and decoding should be in its own document?
tabatkins commentedon Oct 23, 2020
Can you clarify what makes you unhappy? His justification is that the image decoder in use may simply not have the ability to report that data; as such, making it a MUST requirement would effectively require a switch or rewrite of the image decoder, which seems like a pretty big request to make.
His second reason, about small images, I agree is bad; the size of the image shouldn't have an effect here.
The owner of the requirement won't make any difference to the issues raised here.
annevk commentedon Oct 26, 2020
Having standardized image decoders across the web platform does not seem like a big request? Why would we accept non-interoperability there?
tabatkins commentedon Oct 26, 2020
Because the browser vendors in the room expressed their discomfort at that sort of requirement.
jonsneyers commentedon Oct 29, 2020
In the JPEG XL file format, you can put the Exif data where you want, but for web use cases, we define an abbreviated 'file format' that is just a 'naked' JPEG XL codestream without any metadata.
All render-impacting metadata is defined in the JXL codestream, and if the optional Exif (or XMP) metadata says something that conflicts with what the codestream says, then a decoder has to ignore the Exif/XMP. The codestream is the single source of truth. This includes image dimensions, bit depth, number of channels, image orientation, intrinsic dimensions, and color space. In the codestream these things are part of the header, and are always put before the actual image data in the bitstream. Otherwise you cannot do meaningful progressive decoding.
tabatkins commentedon Nov 9, 2020
Fixed in a426128
@smfr Could you review?
zcorpan commentedon May 26, 2021
@tabatkins should this issue be closed?
It looks like web-platform-tests/wpt#26915 tests this. Correct?
svgeesus commentedon Mar 6, 2023
It looks like the spec edits are done and WPT in place. @fantasai Close?
tabatkins commentedon Mar 6, 2023
I'd just asked for a review before closing, but after a year and a half of waiting (and WPT enforcing it) I think it's safe to close as completed. ^_^