210021 2020-04-05 02:37:45 -0700 EXIF orientation info in PNGs isn't used for image-orientation: from-image 2022-06-20 00:14:34 -0700 1 1 1 Unclassified WebKit Images Safari Technology Preview Mac macOS 10.15 NEW BrowserCompat, InRadar P2 Normal --- 1 e webkit-unassigned bfulgham jonlee karlcow sabouhallawa simon.fraser webkit-bug-importer zalan oldest_to_newest 1637850 0 e 2020-04-05 02:37:45 -0700 `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/ 1637998 1 sabouhallawa 2020-04-05 17:27:33 -0700 <rdar://problem/61323993> 1637999 2 sabouhallawa 2020-04-05 17:28:30 -0700 Either there is a bug in exiftool or in one of the macOS underlying framework. 1638158 3 simon.fraser 2020-04-06 10:26:19 -0700 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. 1638321 4 e 2020-04-06 14:31:51 -0700 @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? 1876744 5 karlcow 2022-06-20 00:14:34 -0700 A similar case has been reported on webcompat.com https://github.com/webcompat/web-bugs/issues/94467