Out of curiosity, I modified the benchmark program to simply toss the pixel data into lz4/lz4hc for comparison (patch file:
https://paste.debian.net/1220663/).
I'm actually quite impressed how the resulting size is a little bit smaller than lz4hc (actually not even that far away from libpng), while the encoding speed is quite close to lz4, despite seemingly not having as many hacks and tweaks under the hood to get there. So the encoder is IMO doing amazingly well actually.
However, the decoding speed of liblz4 is off by roughly an order of magnitude. But again, liblz4 probably benefits from decades of tweaking & tuning to get there. It would be interesting how much performance could be gotten out of the qoi decoder.
Here are the totals I get for the "textures" benchmark samples:
decode ms encode ms decode mpps encode mpps size kb
libpng: 2.2 32.4 58.67 3.94 160
stbi: 2.1 17.0 61.50 7.49 228
qoi: 0.7 0.7 191.50 170.54 181
lz4: 0.1 0.6 1226.06 206.40 258
lz4hc: 0.1 70.9 1029.26 1.80 200
And for the "wallpaper" samples. The spreads seem to be a bit more in favor of qoi here:
decode ms encode ms decode mpps encode mpps size kb
libpng: 131.9 2287.1 66.63 3.84 8648
stbi: 147.5 1177.1 59.55 7.46 12468
qoi: 56.3 56.5 156.13 155.60 9981
lz4: 14.3 53.1 614.53 165.50 18019
lz4hc: 13.9 1901.7 630.94 4.62 12699
I'm actually quite impressed how the resulting size is a little bit smaller than lz4hc (actually not even that far away from libpng), while the encoding speed is quite close to lz4, despite seemingly not having as many hacks and tweaks under the hood to get there. So the encoder is IMO doing amazingly well actually.
However, the decoding speed of liblz4 is off by roughly an order of magnitude. But again, liblz4 probably benefits from decades of tweaking & tuning to get there. It would be interesting how much performance could be gotten out of the qoi decoder.
Here are the totals I get for the "textures" benchmark samples:
And for the "wallpaper" samples. The spreads seem to be a bit more in favor of qoi here: