3 ms·

I experimented with adding this to the embedded system Toit. I wrote up the experience here https://medium.com/@erik_68861/trying-out-the-quite-ok-image-format

I experimented with adding this to the embedded system Toit. I wrote up the experience here https://medium.com/@erik_68861/trying-out-the-quite-ok-image-format-in-toit-98e8db914573 https://medium.com/@erik_68861/trying-out-the-quite-ok-image... and also used it for this little demo on a 2 inch screen: https://twitter.com/erikcorry/status/1470023885026467848 https://twitter.com/erikcorry/status/1470023885026467848 It was pretty good, but in the end I don't think I'll be making it part of the graphics system. I would really like a bit of random access into the image without having to divide it up into multiple tiles. And the spec took a direction that didn't really suit me - i wanted to use it for Gui-like textures which have slabs of colours and anti-aliased edges with varying alpha. In the final version of the spec there's no way to code "the alpha changed, but the color is the same". without spending 5 bytes on a single pixel. Previously that took 2 bytes. So I'm still looking for a format with: * Very small amount of decode state (GIF's 16k is probably too much - PNG's 32k is certainly too much). * Fast decode (these embedded chips are not as fast as desktops). * Alpha channel (not just on-off like GIF) * A bit of random access like the parallel PNG, but hopefully less bolted-on.

FullyFunctional 5y ago
All these points are spot on, but I want to reorder the priority. I cannot believe that a format is introduced in this millennium that doesn't have a single thought to aiding parallel access/decode. The single-thread focus will not age well; even low-end µProcessors are going multicore today, and going forward that will only accellerate.
- kevingadd 5y ago
  Even ignoring parallelism, images increasingly need to go straight to the GPU, so improving the performance of access on-GPU (I.E. using a GPU compressed texture format) can have a bigger positive impact on the user experience than making the file on disk smaller. Adopting Basis to compress your images could in practice be much better than adopting QOI, and it should be benchmarked against options like that along with PNG or JPEG.
modeless 5y ago
Have you considered compressed texture formats, perhaps DXT5? Fixed compression ratio (1 byte per pixel for DXT5), arbitrary random access, decompress the pixels you need on the fly. Can be further compressed for efficient storage to about 1-2 bits per pixel with https://github.com/BinomialLLC/crunch https://github.com/BinomialLLC/crunch.
- ErikCorry 5y ago
  This is pretty neat. Simple enough to decode, and very simple to do random access. And if we ever port to something with a GPU it's might even be supported. But I worry it might be too visibly lossy, especially for GUI-ish textures.
  - modeless 5y ago
    It's certainly not going to be perceptually lossless for every image, but good compressors can do pretty well. There's a big difference in quality between good compressors and bad ones. Newer formats like ASTC have better quality but are more complex. ASTC has the advantage of selectable compression ratio from 8 bits per pixel down to 0.89 bits per pixel.

FullyFunctional 5y ago

All these points are spot on, but I want to reorder the priority. I cannot believe that a format is introduced in this millennium that doesn't have a single thought to aiding parallel access/decode. The single-thread focus will not age well; even low-end µProcessors are going multicore today, and going forward that will only accellerate.

kevingadd 5y ago
Even ignoring parallelism, images increasingly need to go straight to the GPU, so improving the performance of access on-GPU (I.E. using a GPU compressed texture format) can have a bigger positive impact on the user experience than making the file on disk smaller. Adopting Basis to compress your images could in practice be much better than adopting QOI, and it should be benchmarked against options like that along with PNG or JPEG.

modeless 5y ago

Have you considered compressed texture formats, perhaps DXT5? Fixed compression ratio (1 byte per pixel for DXT5), arbitrary random access, decompress the pixels you need on the fly. Can be further compressed for efficient storage to about 1-2 bits per pixel with https://github.com/BinomialLLC/crunch https://github.com/BinomialLLC/crunch.

ErikCorry 5y ago
This is pretty neat. Simple enough to decode, and very simple to do random access. And if we ever port to something with a GPU it's might even be supported. But I worry it might be too visibly lossy, especially for GUI-ish textures.
- modeless 5y ago
  It's certainly not going to be perceptually lossless for every image, but good compressors can do pretty well. There's a big difference in quality between good compressors and bad ones. Newer formats like ASTC have better quality but are more complex. ASTC has the advantage of selectable compression ratio from 8 bits per pixel down to 0.89 bits per pixel.