Comment by phoboslab | Hacker News Reader

Comment by phoboslab | Hacker News Reader

Parent Full thread

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 :-)

Reply on news.ycombinator.com