Biggest image in the smallest space


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 img elements. 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:

bzr get

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
There’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: gzip to 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.

Related reading:

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 non-compressed blocks in an IDAT chunk. Each non-compressed block with LEN=0 takes up 5 bytes: \x00\x00\x00\xff\xff. Following that strategy, here’s the 100 MB transparent tracking pixel you’ve always dreamed of:

splat.png.bz2 (4,733 bytes)


Anthony Fleming offers a 28-byte lossless WebP image that has the maximum allowable dimensions of 16,384 × 16,384 pixels. Its entire contents:

5249 4646 1400 0000 5745 4250 5650 384c  RIFF....WEBPVP8L
0800 0000 2fff ffff 1f88 8808            ..../.......

Here is a brief overview of the structure:

52 49 46 46 ("RIFF")
Required header.
14 00 00 00 (20)
Little-endian length of the remainder of the file.
57 45 42 50 ("WEBP")
Required header.
56 50 38 4c ("VP8L")
Required header.
08 00 00 00 (8)
Little-endian length of the remainder of the lossless stream.
Required header.
ff ff ff 1f
image_width = 0x3fff + 1, image_height = 0x3fff + 1, alpha_is_used = 1, version_number = 0b000
88 8808
The remaining bytes specify no transforms, no color cache, a meta-prefix of 0, and then 5 1-symbol prefix codes. Because all prefix codes have a length of 0, no bits are required to encode an endless stream of 0 bits that fill in the image data.

More hacks