PNG File Chunk Inspector

https://www.nayuki.io/page/png-file-chunk-inspector

by nayuki • 5 years ago

48 18 5 years ago

So how does this compare to TweakPNG?

nayuki4• 5 years ago

Mine is web-based, written in a memory-safe language, no need to download and run a local executable, supports OSes other than Windows, thousands less lines of code, but read-only. Thanks for mentioning TweakPNG though; I think I'll link to it as another resource.

mkoryak3• 5 years ago

I looked at your code and it's written in typescript, but I have a thing written in jQuery whitch floats the table headers that your website really needs. You can probably use position:fixed too.

https://github.com/mkoryak/floatThead

MontagFTB2• 5 years ago

I’m always a fan of anything that helps people understand the contents of the binary files that are slung about the Internet.

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.

nayuki4• 5 years ago

Thanks, I agree with having accessible tools to dissect binary file formats. I'm not sure what you mean by "decided not to parse any metadata", care to elaborate? I implemented the parsing of almost all native PNG metadata chunks because they're concisely described in the official specification. I currently don't parse iCCP or eXIf because they will require reading more long external specifications. I don't parse IDAT (but might soon) because decompressing all the image data could use enough CPU time to have a perceptible lag.

MontagFTB2• 5 years ago

I was thinking specifically of Exif and XMP.

ChrisMarshallNY• 5 years ago

Very nice.

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

randy4082• 5 years ago

bKGD overflow, tRNS overflow

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.

nayuki4• 5 years ago

Nope. I rechecked the PNG specification, and it explicitly states that the high bits must be zero:

"If the image bit depth is less than 16, the least significant bits are used and the others are 0." -- Year 2003, https://www.w3.org/TR/2003/REC-PNG-20031110/#11bKGD

"Gray: 2 bytes, range 0 .. (2^bitdepth)-1" -- Year 1996, version 1.0, http://www.libpng.org/pub/png/spec/1.0/PNG-Chunks.html#C.bKG...

randy4082• 5 years ago

It makes sense to treat it as an error but the ISO standard is too vague on this and the libpng developers never "fixed" this[1], it issues a warning but otherwise just masks off the high bits. Firefox has a workaround[2][3], Chrome doesn't.

FWIW I do the same in my library[4], handling it as an error is problematic because it would mean the chunk gets discarded and then you can't even retrieve the values.

[1] https://sourceforge.net/p/png-mng/mailman/png-mng-implement/...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=428045

[3] https://searchfox.org/mozilla-central/source/image/decoders/...

[4] https://libspng.org/

lifthrasiir• 5 years ago

Good page. If I can I would also add a filtered image (or a set of them, if interlaced) to illustrate how PNG filters work.

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....

geoduck14• 5 years ago

I'm going to favorite this because I REALLY want to understand it, bit I think I'm too tired right now to really appreciate it

nayuki4• 5 years ago

Hope you feel refreshed in the morning. The core idea is that a PNG file contains an 8-byte signature followed by any number of chunks.

The outside of every chunk has a regular layout: https://www.w3.org/TR/2003/REC-PNG-20031110/#5Chunk-layout . But the inside of each type of chunk is different.

There are many types of chunks, like: https://www.w3.org/TR/2003/REC-PNG-20031110/#5ChunkOrdering

PNG File Chunk Inspector

Related Stories