Summary: | EXIF orientation info in PNGs isn't used for image-orientation: from-image | ||
---|---|---|---|
Product: | WebKit | Reporter: | Eric Portis <e> |
Component: | Images | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | bfulgham, jonlee, karlcow, sabouhallawa, simon.fraser, webkit-bug-importer, zalan |
Priority: | P2 | Keywords: | BrowserCompat, InRadar |
Version: | Safari Technology Preview | ||
Hardware: | Mac | ||
OS: | macOS 10.15 |
Description
Eric Portis
2020-04-05 02:37:45 PDT
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 |