There are three variants of option 2: - 2a: Use a new ancillary chunk (the OP's solution, here atCh) - 2b: Use officially dedicated PNG chunks (tEXt, zTXt, iT

There are three variants of option 2: - 2a: Use a new ancillary chunk (the OP's solution, here atCh) - 2b: Use officially dedicated PNG chunks (tEXt, zTXt, iTXt; draw.io/diagrams.net approach) - 2c: Put extra data to IDAT after the last DEFLATE block (most famously used by HTML-PNG polyglots, common in size-limited JavaScript demos) I think 2c is most robust among those options, because to my knowledge implementations that recompress IDAT without actual transcoding are rare. 2c does result in some libpng warnings [1] but doesn't seem to cause real-world issues. Also, special tooling requirement of option 2 can be slightly reduced by adopting ZIP approach: you can put magic bytes that are long enough and unlikely to appear by chance, so the reader can simply look for those bytes instead of parsing PNG chunks. This approach is most appropriate for options 2a and 2b (IDAT can be splitted, so there is no real guarantee that magic bytes remain intact) and it is recommended to reuse the existing PNG chunk structure, so that first 4 bytes of magic bytes are also PNG chunk types. It wouldn't fix the writer complexity though. [1] For example, https://github.com/glennrp/libpng/blob/a37d483/pngpread.c#L730-L735 https://github.com/glennrp/libpng/blob/a37d483/pngpread.c#L7...