PNG File Chunk Inspector

> The main reason to have multiple IDATs is if the encoder software wants to keep memory usage low and not need to buffer the entire IDAT, which is required just to know the final length of the chunk before starting to write the chunk.

It should be noted that this is only true for streaming applications where they have no chance to fix the length field already written.

> For example, outputting every DEFLATE symbol, every pixel value, or even every palette value, would be very verbose and probably not helpful.

I have some idea for the visualization, but one possibility is to show a list of DEFLATE blocks. zlib tries to break blocks when applicable as a sort of adaptive compression so it might be interesting to see overall changes in the image triggering new blocks. I've written a function to list blocks and their overheads (to encode Huffman trees), which is now a part of the Roadroller packer [1].

[1] https://github.com/lifthrasiir/roadroller/blob/main/deflate....

I realize you mentioned you decided not to parse any metadata found in the file. However, metadata can be such a window into the file, I’d really encourage you to extend the site to accommodate it.

This is one of those awkward parts of the standard, the samples always take up 16 bits and decoders are expected to mask off the extra high bits, any 16-bit value was supposed to be considered valid. In the real world trash values are often written for transparency (tRNS) chunks that inadvertently match samples in the image when the extra bits are masked off, which leads to random holes in the image. In practice those chunks have to be ignored when the values are out-of-range for the given bit depth.

I must say that I am impressed withe quality of Nayuki’s code.