←back to thread

A new PNG spec

(www.programmax.net)
616 points bluedel | 2 comments | | HN request time: 0.403s | source
Show context
qwertfisch ◴[] No.44376468[source]
Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy and lossless compression, animated pictures, HDR, EXIF etc.

There is just no need for a PNG update, just adopt JPEG XL.

replies(5): >>44376756 #>>44377176 #>>44378892 #>>44379025 #>>44384951 #
Aachen ◴[] No.44376756[source]
> advanced compression (finite-state entropy, like ZStandard)

I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate

Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will never be a clean i++ like it is here, but more noise surely isn't going to help the algorithm compared to this clean example

replies(3): >>44376987 #>>44377519 #>>44380331 #
1. wongarsu ◴[] No.44380331[source]
PNG's basic idea is to store the difference between the current pixel and the pixel above it, left of it or to the top-left (chosen once per row), then apply standard deflate compression to that. The first step basically turns gradients into repeating patterns of small numbers, which compress great. You can get decent improvements by just switching deflate for zstd
replies(1): >>44389908 #
2. Aachen ◴[] No.44389908[source]
> You can get decent improvements by just switching deflate for zstd

Maybe I sounded too critical of zstd. To be clear: I use it for general-purpose compression where available, the only exception would be where eeking out the last % gain is important and slow decompression is acceptable and it has one of these patterns that Bzip2 does better in the first place

That it's better than deflate (afaik aka gzip and zlib, just with different header fields) is not surprising since that was iirc the defined goal of Zstandard project