4 ms·

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 QO

by rsp1984 4y ago

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/ https://libspng.org/ [2] https://github.com/richgel999/fpng https://github.com/richgel999/fpng

IvanK_net 4y ago
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).
p0nce 4y ago
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 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 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 https://github.com/AuburnSounds/gamut
phoboslab 4y ago
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/ https://qoiformat.org/benchmark/
- rsp1984 4y ago
  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.
  - MacsHeadroom 4y ago
    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.
    - brookst 4y ago
      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”

IvanK_net 4y ago

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

p0nce 4y ago

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 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 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 https://github.com/AuburnSounds/gamut

phoboslab 4y ago

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/ https://qoiformat.org/benchmark/

rsp1984 4y ago
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.
- MacsHeadroom 4y ago
  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.
  - brookst 4y ago
    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”