zopfli VS qoi

This project uses HTMLMinifier, optipng, and zopfli to create a custom production Elm build pipeline. You can see how I make use of these tools in this build script. Here are the results in case you're interested. I used the same ideas from this project to build and deploy dwayne/elm-conduit, which you can learn more about in my article Yet Another Tour of an Open-Source Elm SPA.

I'm making a 2D game with lots of PNG assets. I recently found that ZopfliPNG regularly reduces the sizes of my assets by ~3x compared to Asesprite's output. I've tried a few other PNG compression tools, but ZopfliPNG consistently outperforms the others.

I mean something better than Google's best engineers trying to optimize LZ77's compression as much as humanly possible, while remaining compatible with the DEFLATE/zlib bitstream.

zopflipng typically beats pngcrus and optipng (on Linux at least) but by default it drops auxillary PNG chunks [0] which can result in browsers (and other applications) using a different color space, causing the resulting images to look more washed out than the original. To prevent this you need to explicitly pass --keepchunks=cHRM,gAMA,pHYs,iCCP,sRGB,oFFs,sTER to zopflipng.

Unfortunately it (and most other tools) don't have APNG support, keeping only the first frame.

[0] https://github.com/google/zopfli/issues/113

I tried going with a lot of different compression algorithms, in the end a lot of iterations of Zopfli delivers the best result. With that, I got the image down to 591 kB.

I tried zopflipng [1] with the very expensive option suggested from the usage and got 2,493 bytes (original 2,740 bytes, nowhere practical as it took 3 minutes) so you don't have to sacrifice the palette, though I'm not sure if 16 or even 4 color palette will significantly alter the visual.

[1] https://github.com/google/zopfli

Her request is politely-phrased and reasonable. I don't think there's a legal or ethical issue, but respecting the wishes of others when it costs nothing is just kindness.

However, the way that some have seized on it, and then interacted with others in their communities is ... neither polite nor reasonable.

e.g. https://github.com/phoboslab/qoi/issues/35

How do you know it's not a problem for the people who work with computer vision? Let's take this for example - sure, the request itself was presented very unprofessionally, but this is still an example of someone in a computer vision-adjacent field stating in no uncertain terms that they have a problem with the image.

Yes. Without a supporting statement, it's ad hominem. But I provided a supporting statement.

This is the issue I'm taking about: https://mobile.twitter.com/richgel999/status/146443578680850...

Which links to here: https://github.com/phoboslab/qoi/issues/35

Where everyone agrees, yes, the image should be removed. They didn't know about its history. Would he please stop being a gigantic asshole about it.

So if that's not blowing things out of proportion, I don't know what is.

I don't know about CUDA, however I've made an AVX2 based encoder a few months ago : https://github.com/phoboslab/qoi/pull/143

I intend to create an AVX2 based decoder but I had absolutely no time to work on side projects in the past three months.

You might also want to take a look at this streaming encoder if you want to encode large files with a tiny memory footprint : https://github.com/MKCG/php-qoi/blob/main/src/FFI/lib/qoi.c

Not only does compression improve this situation today, but using QOI means improvements may continue to come over time. QOI is a very new, open source image format, and that's already proving to be an advantage. By itself, QOI compression is pretty weak, but YoYoGames have forked it and worked in BZ2 compression to surpass the old PNG format. As QOI itself improves and as YoYoGames continues to work on it, it's almost guaranteed that we'll see the compression ratio in GameMaker get better over time.