3 ms·

I'll throw another idea in to the air. How about least bytes per pixel (or most pixels per byte) PNG. Is this stable system or does it go to the infinity? So n

I'll throw another idea in to the air. How about least bytes per pixel (or most pixels per byte) PNG. Is this stable system or does it go to the infinity? So now we have 2064 pixels in 67 bytes. 30.8 pixels per byte or 3.39 pixels per bit

michaelt 3y ago
You can get 636 pixels per byte with a 256x256 pixel, 103 byte image. For example: https://www.mjt.me.uk/posts/smallest-png/ https://www.mjt.me.uk/posts/smallest-png/ And they're used in real production systems :)
lifthrasiir 3y ago
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 https://stackoverflow.com/a/16794960
- vincnetas 3y ago
  Great answer. And sure enough there is a PNG bomb created by someone on the internet. PNG that renders to 225000 х 225000 pixels (50 gigapixels).

michaelt 3y ago

You can get 636 pixels per byte with a 256x256 pixel, 103 byte image. For example: https://www.mjt.me.uk/posts/smallest-png/ https://www.mjt.me.uk/posts/smallest-png/ And they're used in real production systems :)

lifthrasiir 3y ago

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 https://stackoverflow.com/a/16794960

vincnetas 3y ago
Great answer. And sure enough there is a PNG bomb created by someone on the internet. PNG that renders to 225000 х 225000 pixels (50 gigapixels).