What’s the biggest pixel size of a PNG image in the smallest number of bytes? I wanted to try to create an image that could be downloaded but whose pixel buffer would be too big to store in the RAM of a PC. Here is a PNG image of 6,132,534 bytes (5.8 MB) and 225,000 × 225,000 pixels (50.625 gigapixels), which, if uncompressed and represented as a pixel buffer of 3 bytes per pixel, takes about 141.4 GB.
The PNG file is further bzip2-compressed to avoid abuse by people
hot-linking it in
The bzip2 compression doesn’t have anything to do with the high compression ratio in the PNG.
spark.png.bz2 (420 bytes)
The program used to make it: deflate.py.
bzr get https://www.bamsoftware.com/bzr/deflate
PNG uses DEFLATE compression in a zlib wrapper. DEFLATE can asymptotically approach a compression ratio of 1032:1: each pair of bits can represent 258 zero bytes, and then there’s some constant overhead for headers and such.
The image is almost entirely zeroes, with a secret message in the center. We gain an extra factor of 8 pixels by using a 1-bit colorspace. Even with this maximum compression, the PNG file is basically a long string of zero bytes. bzip2 has a run-length preprocessing step that crunches these megabytes into a few hundred bytes.
Things to try:
Unfortunately the ratio of 1032:1 is really the best you can do. If you want an image with ten times the pixels, the PNG file has to be ten times the size. The above image is already close to the theoretical maximum (the extra divisor of 8 is because there are 8 pixels per uncompressed byte in the 1-bit colorspace):
>>> 225000.*225000/8/6132534 1031.893993575902There’s a constant cost of 109/1032/8 ≈ 121124 bytes per gigapixel. But if you are serving (or uploading) the image over HTTP, there’s another trick you can apply. Precompress the file and send it with
Content-Encoding: gzipto gain another factor of 1032 (gzip also uses DEFLATE) and a communication cost approaching ≈118 bytes per gigapixel. This is like a two-layer recursive zip bomb, except that both decompression steps are side effects of normal processing. Going one step further, you could embed the PNG as an image in an ODF or OOXML document, both of which use a zip container (i.e., DEFLATE). You could get a compression ratio of about 1 billion: 1000× from PNG, 1000× from the document container, and 1000× from HTTP.
What about the opposite question, the largest encoding of a 1 × 1 image?
It’s not very interesting, because there are various ways
of increasing the file size without affecting the image.
For one thing, you can just
stuff in a lot of text
or other ancillary (non-image) chunks.
But keeping in the spirit of DEFLATE, you can also use an unlimited number of empty
Each non-compressed block with
LEN=0 takes up 5 bytes:
Following that strategy, here’s the 100 MB
transparent tracking pixel you’ve always dreamed of:
splat.png.bz2 (4,733 bytes)