Does QOI support grayscale?

[dmikushin]

Hi, I wonder if the QOI format also covers grayscale? As I understood it is designed mainly for 3 and 4 channels.

[phoboslab]

Support: yes, good at it: no. Of course you can encode grayscale images with qoi, but it will always use 3 channels for it. The resulting file size will be closer to uncompressed than PNG.

A "qoi-like" file format focusing on 1 channel sounds like a fun experiment though. Could probably get good results with storing small chunks as 4bit nibbles.

May I ask: what's your use-case?

[dmikushin]

Hi @phoboslab , thanks ! My usecase is 5 GBytes of grayscale images from a high-speed industrial camera.

[schoebey]

same use-case here. Images from industrial cameras or artificial sources. 8-bit greyscale images of varying dimensions (~1k x 1k up to ~16k x 80k)

[dead-claudia]

I was exploring general data compression similar to QOI for small arbitrary data and I wanted something super simple, fast, and with reasonable compression.

I came up with this general-purpose (untested) compression format idea:

It's a sequence of the following 16-bit aligned words, all N little-endian:

• 00nnnnnn nnnnnnnn: Emit most recent byte N+1 times
• 00111111 nnnnnnnn nnnnnnnn nnnnnnnn: Emit most recent byte N+1 times
• 01xxxxxx nnnnnnnn: Emit X+2-th most recent distinct byte N+1 times
• 10nnnnnn xxxxxxxx: Emit specified byte N+1 times
• 11xxxxxx nnnnnnnn: Emit most recent byte plus 6-bit signed X delta N+1 times

• Max compression ratio: ~2^24 to 1
• Min compression ratio: 0.5 to 1

Internal state: last 65 unique bytes emit, initially set to 0 for the first byte and the sequence 64 to 127 for the remaining bytes (to optimize for small ASCII strings).
There's no implicit end token like QOI has, but you can infer the end from your input, or you could modify one of the above to provide an "end" byte. If you shoved a QOI-like header plus this into a QOI image format, it may do the trick.

Keep in mind, I've not done any experiments, so this is just all words on a page. But I am curious what you all might see with compression ratios using this.

Edit: improve max compression, simplify loading

[API-Beast]

QOI does poorly if the data is anything but 3 channel RGB, this is probably it's biggest weakness.

However this should be easy to fix: In theory you could just apply QOI to encode/decode a bytestream instead of a pixelstream. That means one RGB QOI pixel simply becomes 3 bytes. So 1 pixel of RGB data, 1.5 pixels of RG data or, 3 pixels of Grayscale data.

It would be great if this way of using the QOI format could be standardized somehow. The channels field of the header is a full 8 bit field but only two values are accepted currently. Perhaps make it so that a value of 128+N means that the image is encoded and decoded like a 3 channel image, but should be interpreted like a byte stream with N channels. This would also affect how the width and height parameters are defined.