4 ms·

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 origin

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.

MByte 3y ago
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.
Retr0id 3y ago
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 https://github.com/davidBuchanan314/unpng