You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could you share pointers on how you obtained that result? I notice that the main website claims only "similar size of PNG" which feels both more defensible and more concrete (stb_image supports many different formats; which of them are you comparing to? All of them?!). So if the claim in the repo is more correct I'd love to see details on methodology and so on.
(I just found this project, and it looks very interesting. But I want to have a clear sense of benefits and limitations. I think the 20x encoding/decoding speedups and 20x shorter implementation seem compelling even if the compression is 20% worse. But not if it's 10x worse.)
The text was updated successfully, but these errors were encountered:
I believe that is incorrect. According to #166 (comment), it looks like QOI is 22% larger than PNG. QOI+ZSTD is about 5% smaller while still being about 5x faster compression and decompression.
I was comparing to stb_image_write's PNG encoder. The idea was to provide an alternative to the use case "quickly write out lossless images of your program". The PNG encoder in stb_image_write is not well optimized for compression (see this comment in stb_image_write.h).
I agree that this whole claim is a bit misleading. I'll update the readme.
Detailed benchmarks can be found here: https://qoiformat.org/benchmark/
QOI usually lands somewhere between libpng and stbi's PNG encoder for the compression rate.
Could you share pointers on how you obtained that result? I notice that the main website claims only "similar size of PNG" which feels both more defensible and more concrete (
stb_image
supports many different formats; which of them are you comparing to? All of them?!). So if the claim in the repo is more correct I'd love to see details on methodology and so on.(I just found this project, and it looks very interesting. But I want to have a clear sense of benefits and limitations. I think the 20x encoding/decoding speedups and 20x shorter implementation seem compelling even if the compression is 20% worse. But not if it's 10x worse.)
The text was updated successfully, but these errors were encountered: