[css-images-3] Allow impls to not respect exif data if it's after the image data

[tabatkins]

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.

[chrishtr]

FYI Chromium supports this now also.

[tabatkins]

Do you just mean "supports image-orientation: from-image;"? What version? Just jpeg, or png also?

In the test files linked from the Firefox bug, I don't see either image rotated in Chrome.

[chrishtr]

Yes, it should be supported... let me check on this.

[chrishtr]

@schenney-chromium

[schenney-chromium]

Loading the "test files linked form the Firefox bug" correctly renders in Chrome Canary. i.e. the dog is right-way-up in both images.

[tabatkins]

...are you sure that's what it's supposed to do? I'm pretty sure the dog image as originally right side up, and if exif is supported, it should be rotated 90deg.

However, that testfile is super unclear, and I've pinged @eeeps to put a "no EXIF" version up so we can tell if things are broken or working correctly.

[schenney-chromium]

Tab, you're right. In Chrome-80, without image-orientation support, the dog is right way up in both images, so that mean Chrome 81+ is not displaying it with expected results.

[schenney-chromium]

If the bug is common everywhere, maybe it's in libjpeg-turbo.

[eeeps]

I'm pretty sure the dog image as originally right side up, and if exif is supported, it should be rotated 90deg.

Correct. Added an EXIF-less PNG to both pages for clarity.

As for the JPEG -- in Canary (83) it's correctly rotated 90°CW; in Stable (80) it is not. Given that image-orientation support was added in 81, this meets my expectations; I don't think there's anything weird going on with the JPEG in any browser.

[schenney-chromium]

Ahh, I thought this was jpeg. If we're talking PNG that's known, https://bugs.chromium.org/p/chromium/issues/detail?id=1067846, but I guess you're the one who reported it. I'm sorry for causing so much confusion - brain mangled after a day of small kids.

[tabatkins]

I've hidden the diversion due to confusion. ^_^

So bringing us back:

Chrome, Safari, and Firefox all now respect image-orientation: from-image on 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]

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.