3 ms·
The QOI benchmarks shows it only lagging a small bit behind PNG in compression ratio, while performing much faster (multiples) in both encoding and decoding. Do
by jchw 4y ago
The QOI benchmarks shows it only lagging a small bit behind PNG in compression ratio, while performing much faster (multiples) in both encoding and decoding. Doesn't seem like an awful trade-off. Surely you'd expect a much larger, slower and more sophisticated encoder and decoder would at least net 25-50% improvements to compression ratio, but it seems to net much less.
If you are artificially or truly constrained in either CPU usage, or maybe just static code size, it seems like it would have some appeal, even if niche.
- duskwuff 4y ago> The QOI benchmarks shows it only lagging a small bit behind PNG in compression ratio The benchmarks are misleading. By size, they mostly consist of photographs and other true-color images, which neither compressor handles well. This has the effect of hiding QOI's lackluster performance on synthetic images which PNG does compress well. In particular, QOI performs dramatically worse than PNG on synthetic images containing any sort of vertical pattern. As a worst-case example, an image consisting of a single line of noise repeated vertically will compress down to basically nothing in PNG, but QOI will fail to compress it at all.
- jchw 4y agoYes, but the point is that it's not really that far off. PNG will outperform in screenshots with a lot of empty space, so if you were dealing with that situation, obviously PNG is better. OTOH, QOI still performs relatively well: while the difference is multiples in some cases, to me it seems that those cases are mostly ones where PNG's compression ratio is obscenely good, and therefore QOI is actually still producing reasonably small image files, too. I can see that QOI performs well for what you might use as texture maps for 3D rasterization, for example. Definitely seems to have some applicability to me.
- mananaysiempre 4y ago> The QOI benchmarks shows it only lagging a small bit behind PNG in compression ratio, while performing much faster (multiples) in both encoding and decoding. Presumably that’s with stock libpng, which uses zlib. I wonder if anyone tried patching it to use the substantially faster (on x86) libdeflate[1] instead? It doesn’t do streaming, but you shouldn’t really need that for PNG textures. [1] https://github.com/ebiggers/libdeflate https://github.com/ebiggers/libdeflate