News for hackers. Stuff that matters.
Re:The Biggest Smallest PNG by lifthrasiir on Tuesday January 09, 2024 @09:58PM (#38935592)
EDIT: I read the original article in the opposite way and described the largest PNG file with single pixel, oops. It's still a good tidbit so here is the original comment.

There is a much easier way. You can put an arbitrary number of empty uncompressed blocks, which are normally used for the sync flush (Z_SYNC_FLUSH in zlib). Such blocks do not affect any other block or zlib checksum (but do affect PNG checksum). For example a DEFLATE stream `7801 (00 0000 ffff)* 01 0100 feff xx yyyy yyyy` is always valid and decompresses into a single byte `xx` where `yyyy` is a big-endian representation of `xx + 1`. Also PNG IDAT chunks have to be implicitly concatenated, so you can technically have an arbitrary large PNG file of single pixel if you really want.

Re:The Biggest Smallest PNG by Retr0id on Tuesday January 09, 2024 @11:07PM (#38936016)
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

Re:The Biggest Smallest PNG by MByte on Tuesday January 09, 2024 @10:44PM (#38935862)
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.