PNG File Chunk Inspector(nayuki.io)

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

19 comments

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

MontagFTB5 anni fa

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.

nayuki5 anni fa

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.

MontagFTB5 anni fa

I was thinking specifically of Exif and XMP.

randy4085 anni fa

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

nayuki5 anni fa

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

randy4085 anni fa

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/

geoduck145 anni fa

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

nayuki5 anni fa

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

ChrisMarshallNY5 anni fa

Very nice.

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

throwaway8899005 anni fa

So how does this compare to TweakPNG?

nayuki5 anni fa

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.

[deleted]5 anni fa

mkoryak5 anni fa

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

cxr5 anni fa

For anyone who wants to implement this, please _don't_ implement it like the GIF. <https://github.com/mkoryak/floatThead/blob/master/README.md> Instead, do what mobile web browsers do, where the header is automatically revealed and overlaid onto the content when scrolling up. On desktop, you can make it so the headers are also revealed when mousing around over the relevant data. But indiscriminately reducing the size of the viewport by going sticky is incredibly annoying.

mkoryak5 anni fa

To be fair, the thing you linked to was never made for mobile. On desktop reducing the size of the viewport isn't generally a huge problem.

cxr5 anni fa

It is a problem[1][2]. Desktop is the only use case I even had in mind. I only threw in the mobile/desktop mention in order to reference what mobile browsers do with the address bar and a last minute thought about how the availability of a mouse pointer presents the opportunity to add a little polish. Sticky headers, whether on mobile or desktop, are worse than animated banners.

1. https://alisdair.mcdiarmid.org/kill-sticky-headers/

2. https://news.ycombinator.com/item?id=21699871

mkoryak5 anni fa

You said you dont respond to comments, but you lied.

As an author of a sticky table header plugin, I disagree with you about sticky headers being bad :)

I do like your idea about scrolling them away, I'll make that be a thing in mine.

cxr5 anni fa

"Scrolling them away" is the default behavior. (Just never make them sticky.)