Bug 210021 – EXIF orientation info in PNGs isn't used for image-orientation: from-image

• Component: Images
• Status: NEW

[Eric Portis]

`image-orientation: from-image` correctly reads and applies EXIF orientation from JPEGs; however it does not read or apply EXIF orientation info from PNGs.

See a test page/resources here: https://ericportis.com/etc/PNG-EXIF-orientation/

[Said Abou-Hallawa]

<rdar://problem/61323993>

[Said Abou-Hallawa]

Either there is a bug in exiftool or in one of the macOS underlying framework.

[Simon Fraser (smfr)]

This seems to be a quirk of the image.

The image has these chunks:
	IHDR
	PLTE
	IDAT
	eXIf
	IEND
libpng does not recognize the ‘eXIf’ chunk if it’s after the image data (IDAT).
The spec states: “The eXIf chunk may appear anywhere between the IHDR and IEND chunks except between IDAT chunks.”
So in theory it’s allowed, but libpng does not support this.
If the PNG is modified (moved eXIf before IDAT) it displays as expected (90º rotated).
FireFox, Chrome, GraphicConverter don’t handle this either.

[Eric Portis]

@smfr Interesting!

Here's a new test page: https://ericportis.com/etc/PNG-EXIF-orientation/shuffling-chunks/

Looks like (on MacOS 10.15):

Finder, Preview, and Safari respect eXIf-before-IDAT.

Chrome and Firefox do not respect eXIf-before-IDAT.

I'm not sure how any browser can support both eXIF-*after*-IDAT and also progressively render partially-downloaded, progressively-encoded PNGs. In some initial testing both Firefox and Chrome will paint partially-downloaded PNGs, but Safari does not.

Does a note about PNG chunk order and/or progressive rendering belong in the spec?

[Karl Dubost]

A similar case has been reported on webcompat.com
https://github.com/webcompat/web-bugs/issues/94467