`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/
<rdar://problem/61323993>
Either there is a bug in exiftool or in one of the macOS underlying framework.
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.
@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?
A similar case has been reported on webcompat.com https://github.com/webcompat/web-bugs/issues/94467