The Biggest Smallest PNG

With a bit of math, it should be possible to devise a sequence of zlib flush blocks (and other tricks) that don't affect the PNG checksum, either.

As for the "other tricks", you can get 10 bits of do-nothing padding by starting and immediately ending a fixed-huffman block, and various other lengths by starting and immediately ending dynamic huffman blocks. I use the former in unPNG[1] to pad things out to word boundaries, for alignment.

[1] https://github.com/davidBuchanan314/unpng

I think you missed the point of trying to make the largest image dimensions within the smallest file size. It looks like you're describing the opposite.

You can indeed, if you slice off everything after and including the zlib adler32 checksum. In some situations you might need to add some extra (compressed) padding bytes to flush the pixel data you care about through the parser state machine. This works in every browser I tested (as a consequence of their ability to preview partially-downloaded files) but not in many standalone image viewers (since they usually expect whole files).

You can get 636 pixels per byte with a 256x256 pixel, 103 byte image. For example: https://www.mjt.me.uk/posts/smallest-png/

And they're used in real production systems :)

It's bounded, because the underlying DEFLATE algorithm has the maximum compression ratio of 1032:1 [1]. You still need at least one literal code and end-of-block code, but the former can be encoded in a separate block so you can indeed use only two bits per each run of 258 bytes.

At one point you will be also bounded by the maximum size of IDAT chunk, which is 2^31 - 1 bytes with a 4-byte-long chunk name included, and after that point you will constantly need 12 bytes of overhead for each additional 2^31 - 5 bytes. And we will eventually hit the maximum permitted dimension of (2^31 - 1) by (2^31 - 1) pixels. Since the long-term overhead (12 bytes) is much smaller than the one-time overhead (>50 bytes), the biggest image will result in the best ratio. Such biggest image needs at least N = (2^31 - 1) * (2^28 + 1) uncompressed bytes of IDAT, as each scanline needs one filter byte and 2^31 - 1 bits pack into 2^28 bytes.

We can now compress them down to ceil(N / 1032) compressed bytes plus small overhead, which should be divided into ceil((ceil(N / 1032) + eps) / (2^31 - 5)) = 260,112 IDAT chunks. Each chunk of 2^31 - 5 bytes contains at most ceil((2^31 - 5) * 1032 / (2^28 + 1)) + 1 = 8256 scanline boundary, which consists of one filter byte and one unused padding bit. Therefore we should have (2^31 - 5) * 1032 * 8 - 8256 * 9 uncompressed bytes (i.e. pixels) per each chunk, giving the upper bound of ~4127.99997308 pixels per byte. The actual value will be very slightly lower than that due to the one-time overhead---aforementioned significant digits did account for this.

[1] https://stackoverflow.com/a/16794960