Comment by rsp1984 | Hacker News Reader

Comment by rsp1984 | Hacker News Reader

There are a lot of dimensions on which QOI could be improved, but most cases involve trade-offs, e.g. more complexity for better compression. The areas where QOI could have been strictly better, the dimensions on which it is not on the Pareto frontier, are more meaningful criticisms — missed opportunities.

This summer I spent a lot of time researching lossless compression formats as a streaming format for our 3D capture and reconstruction engine. QOI was on our list too.

My biggest criticism about QOI is that in many cases it doesn't compress at all, or even increases size. It works well on the demo images that come with the package but these are carefully selected. It also works well on high-res, high-quality images with lots of single-color background and/or smooth gradients. But give it grainy, noisy, smaller-format images and it completely breaks down.

We ended up sticking with PNG, which btw. has fast open source implementations too [1][2].

[1] https://libspng.org/ [2] https://github.com/richgel999/fpng

All of these QOI derivatives improves upon the coding efficiency AFAIK.

In QOIP, opcodes themselves are stored in the format, LZ4 or zstd compression

https://github.com/chocolate42/qoipond

QOIR adds: color profile, EXIF, premultiplied alpha, lossy mode, tile support, LZ4 compression, AFAIK it does this while beating the original QOI in terms of speed AND efficiency.

Lots of benchmarks in: https://github.com/nigeltao/qoir

QOIX is my very own version that adds: Greyscale [+alpha] 8-bit image support, lossy 10-bit support (16-bit encoded as 10-bit, intended for elevation maps), so it's really 3 codecs , optional LZ4. https://github.com/AuburnSounds/gamut

While what you're saying is true - QOI performs badly with some types of images - I want to push back on the notion that the demo images have been "carefully selected" to tell a narrative. TFA alleges the same. This is absolutely not the case!

The benchmark suite[1] I compiled contains many different types of images. The "industry standard" sets like the Kodak and Tecnick Photos, texture packs and icons are complete. No images have been removed from these sets. Some of the other collections (photos and game screenshots from Wikipedia and those from pngimg.com) are a random sample. I did not remove any images just because they compressed badly.

Also, the fact that some images compress badly is a non issue, if the whole set of assets that you need for your game/app combined have an acceptable compression ratio. If that's not the case, by all means, chose another image format.

On average, for a lot of assets types, QOI usually performs quite ok.

[1] https://qoiformat.org/benchmark/

Fair enough. In our testing we couldn't get it to compression ratios lower than ~90% on the kind of images we tested (low quality webcam-type sensors, sub-VGA resolution), while it achieved very impressive compression ratios on the demo images, so I assumed a selection was made. Perhaps it's just works really well for certain kinds of images and doesn't for others.

Low quality sensor photographs are all but impossible to compress because they're filled with compressions worst nightmare: random noise.

Lossless compression of random noise isn't possible and lossy compression of it requires content aware algorithms (e.g. AI) to get results.

Even if you don't readily see the random noise, it's there. Subtly changing the hues of pixels just slightly enough to be incompressible.

And the frustrating thing is that the “noise” is actually information; it tells you something about the capture device and encoding toolchain. It’s just an incredibly inefficient way to encode “this was captured on a cheap image sensor on a severely memory constrained device”

They might be impossible to compress using RLE-based mechanisms, but the theoretical possibility is there. The noise range for the pixels is not 0-255, so the image has less entropy than a fuly random one and thus should be compressable.

I am imagining something like a "base layer" with averaged brightness + arithmetic coding for differences might do it.

These sorts of images do compress quite ok though (pun intended) with PNG.

While you can't compress the random noise itself, it's often easy to still get decent compression of the whole image, depending on how serious the noise is.

Imagine an image with large blocks of constant colour in 8-bit colour depth has 2 bits of random noise on every pixel. We indeed can't ever compress to less than 2 bits per pixel, but we can still get down to that.

QOI will be pretty bad with exceptionally noisy images. that said, if you denoise first, you aren't degrading image quality.

> QOI usually performs quite ok

Nice :-)

I guess you are taking photographs. One should never try to store photographs with no loss. With a lossy format, like JPG or WebP, you can get 5x smaller file size, while giving up 0.000001% of the original information (which usually corresponds to specific values of noise, that are not important in practice).

Reply on news.ycombinator.com