Can't load PNG produced by Blender 3.6

[theres1]

Describe the bug

I use Python bindings https://github.com/LeoHsiao1/pyexiv2 though I think the problem is related to exiv2 library itself.
Problem: Can't load PNG file saved by Blender 3.6. I get error: RuntimeError: This does not look like a TIFF image

Exception from Python:

    with pyexiv2.Image(self.prev.filepath) as img:
  File "C:\Users\user\AppData\Roaming\Python\Python310\site-packages\pyexiv2\core.py", line 15, in __init__
    self.img = exiv2api.Image(filename.encode(encoding))
RuntimeError: This does not look like a TIFF image

To Reproduce

Steps to reproduce the behavior:

1. Save render in Blender 3.6 (specifically this version) or use image provided by me
   
2. Load image via pyexiv2.Image(filepath) (Python bindings)

Expected behavior

PNG produced by other programs load without problems.

Desktop (please complete the following information):

• OS and version: Windows 7
• Exiv2 version and source: v0.27.7 https://github.com/LeoHsiao1/pyexiv2/tree/master/pyexiv2/lib

[kmilos]

I can reproduce this w/ 0.27.7 exiv2 CLI, thanks for the sample.

The "This does not look like a TIFF image" is not related to the PNG image itself, but presumably to the eXIf chunk which is supposed to be based on the TIFF spec...

[kmilos]

There are actually 2 (identical!) eXIf chunks in this PNG file, but very short so might not carry any significant metadata:

$ exiv2 -pS 262298280-d31e764a-7898-4ca7-b09c-9766c0dec23f.png
STRUCTURE OF PNG FILE: 262298280-d31e764a-7898-4ca7-b09c-9766c0dec23f.png
 address | chunk |  length | data                           | checksum
       8 | IHDR  |      13 | ...`...6....                   | 0xb72d0b85
      33 | eXIf  |      54 | MM*........H.......H.......... | 0x6c37252a
      99 | oFFs  |       9 | ........                       | 0xda2ab6ce
     120 | pHYs  |       9 | .........                      | 0xd2dd7efc
     141 | tEXt  |      15 | File.<untitled>                | 0x95b3d796
     168 | tEXt  |      24 | Date.2023/08/22 10:54:21       | 0x6c56e2d2
     204 | tEXt  |      16 | Time.00:00:00:01               | 0xecc326c2
     232 | tEXt  |       9 | Frame.001                      | 0xc1511522
     253 | tEXt  |      13 | Camera.Camera                  | 0x68ffefe9
     278 | tEXt  |      11 | Scene.Scene                    | 0xe5215d96
     301 | tEXt  |      19 | RenderTime.00:00.31            | 0xfc1d3d14
     332 | IDAT  |    2784 | h..[]o....(9...#...d..`..-f... | 0x07fa723d
    3128 | eXIf  |      54 | MM*........H.......H.......... | 0x6c37252a
    3194 | IEND  |       0 |                                | 0xae426082

[kmilos]

Btw, exiftool -v3 also warns about overlapping TIFF directories, so at least that should be reported to Blender as well:

PNG eXIf (54 bytes):
      0c40: 4d 4d 2a 00 00 00 00 18 00 00 00 48 00 00 00 01 [MM*........H....]
      0c50: 00 00 00 48 00 00 00 01 00 02 01 1a 00 05 00 00 [...H............]
      0c60: 00 01 00 00 00 08 01 1b 00 05 00 00 00 01 00 00 [................]
      0c70: 00 10 00 00 00 00                               [......]
  + [TIFF directory]
  | ExifByteOrder = MM
  | Warning = IFD0 pointer references previous IFD0 directory
PNG IEND (end of image)

[kmilos]

Ok, so the TIFF signature 4d 4d 2a 00 is invalid for this eXIf chunk. For big-endian encoding, it must be 4d 4d 00 2a.

This is a Blender (or whatever library they use to write PNGs) bug.

The only thing exiv2 can do here is perhaps detect this special byteswap case and tolerate it (like exiftool) w/ a warning instead of erroring out...

[kmilos]

Thanks for addressing this upstream.