3 ms·
Comparison of "zpng" (PNG wth zstd) and WebP lossless, with current PNG. From https://github.com/WangXuan95/Image-Compression-Benchmark https://github.com/WangX
by arp242 1y ago
Comparison of "zpng" (PNG wth zstd) and WebP lossless, with current PNG. From https://github.com/WangXuan95/Image-Compression-Benchmark https://github.com/WangXuan95/Image-Compression-Benchmark :
Compressed format Compressed size (bytes) Compress Time Decompress Time
WEBP (lossless m5) 1,475,908,700 1,112 49
WEBP (lossless m1) 1,496,478,650 720 37
ZPNG (-19) 1,703,197,687 1,529 20
ZPNG 1,755,786,378 26 24
PNG (optipng -o5) 1,899,273,578 27,680 26
PNG (optipng -o2) 1,905,215,734 4,395 27
PNG (optimize=True) 1,935,713,540 1,120 29
PNG (optimize=False) 2,003,016,524 335 34
Doesn't really seem worth it? It doesn't compress better, and only slightly faster in decompression time.
- bobmcnamara 1y agoAm I reading those numbers right? That's like 25x faster compression than WEBP-M1, there's probably a use case for that.
- arp242 1y agoThe numbers seem small enough that it will rarely matter, but I suppose there might be a use case somewhere? But lets be real here: this is basically just a new image format. With more code to maintain, fresh new exciting zero-days, and all of that. You need a strong use case to justify that, and "already fast encode is now faster" is probably not it.
- scott_w 1y agoI don’t think it’s quite as bad, though? It’s using a known compression library that (from reading other comments) has seen use and testing. The rest of PNG would remain unchanged, as the decompression format is a plugin. I know it needs to be battle tested as a single entity but it’s not the same as writing a new image format from scratch.
- realityking 1y agoConsidering both zstandard and PNG are already web facing technologies, would the combination of both really increase the attack surface?
- phire 1y agoAnd compresses significantly faster than regular png too. That’s the major advantage of zstd, fast compression. Not particularly relevant in web use cases, but would be great for saving screenshots.
- stephencanon 1y ago"Only slightly faster in decompression time." m5 vs -19 is nearly 2.5x faster to decompress; given that most data is decompressed many many more times (often thousands or millions of times more, often by devices running on small batteries) than it is compressed, that's an enormous win, not "only slightly faster". The way in which it might not be worth it is the larger size, which is a real drawback.
- arp242 1y agoThe difference is barely noticeable in real-world cases, in terms of performance or battery. Decoding images is a small part of loading an entire webpage from the internet. And transferring data isn't free either, so any benefits need to be offset against the larger file size and increased network usage.
- fhcbix 1y agoWhen you talk about images over HTTP, you need to consider most web servers and browsers already support zstd compression on the transport, so the potential bandwidth win provided by zstd is already being made use of today.
- arp242 1y agoI'm not sure how that's relevant for a new "ZPNG" format vs. lossless WebP?
- fmbb 1y agoWin how? More efficiency will inevitably only lead to increased usage of the CPU and in turn batteries draining faster. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
- hcs 1y agoSo someone is going to load 2.5x as many images because it can be decoded 2.5x faster? The paradox isn't a law of physics, it's an interesting observation about markets. (If this was a joke it was too subtle for me)
- out_of_protocol 1y agoIs webp really losses here? As far as i remember its capped at 4:2:0 and can't do 4:4:4 files without loosing some of the color data
- IshKebab 1y agoI looked it up and lossy mode only supports 4:2:0 but the lossless mode uses RGBA.