QOI: Lossless Image Compression in O(n) Time • Hacker News Board

Re: QOI: Lossless Image Compression in O(n) Time

#301

Post by sam0x17 » Tue, Nov 30, 2021, 6:34 PM UTC

kaetemi wrote: post #163

sam0x17 wrote: post #159

Earlier quoted context omitted.

> We're stuck with images stored in the display profile of old CRTs by default, because that was the most practical option at the time. The analogue in photography is photographs lose color clarity and fade as they age. Why should I care if this is the case in images as display technology evolves when this is already a problem with every physical medium? > For correct editing operations, and correct display. Sadly, i…

I get what you mean, but... the color profile of the image is the profile of the display where the image can be displayed without adjustment. Think of it as the display profile of the guy that sent you the image. The magic math transforms the image to your display profile. That means it will look exactly the same on both displays. If they both have a correct display profile. If your green is going pink, then either y…

Right, so sRGB should really just be the only allowed profile for images. That's my whole argument. There should be some standard profile all images should use, and then displays should deal with the work of converting things to a suitable display profile. Allowing more than one image-level profile just makes things way more complex for no perceivable benefit.

Re: QOI: Lossless Image Compression in O(n) Time

#302

Post by [deleted] » Thu, Dec 02, 2021, 8:39 AM UTC

Animats wrote: post #297

account42 wrote: post #293

Earlier quoted context omitted.

Or you could be wrong.

It checks for running out of input but, at line 460, will read three bytes beyond the end of the buffer for suitably constructed input. This is technically wrong, but hard to exploit. Amusingly, if you run out of input too soon, the last pixel is replicated to fill the buffer. So you don't get random memory contents in the output, which would be more exploitable. [1] https://github.com/phoboslab/qoi/blob/master/qoi.h

[deleted]

Re: QOI: Lossless Image Compression in O(n) Time

#303

Post by account42 » Thu, Dec 02, 2021, 8:51 AM UTC

Animats wrote: post #297

account42 wrote: post #293

Earlier quoted context omitted.

Or you could be wrong.

It checks for running out of input but, at line 460, will read three bytes beyond the end of the buffer for suitably constructed input. This is technically wrong, but hard to exploit. Amusingly, if you run out of input too soon, the last pixel is replicated to fill the buffer. So you don't get random memory contents in the output, which would be more exploitable. [1] https://github.com/phoboslab/qoi/blob/master/qoi.h

I still don't see it. Note that there is 4 bytes of padding at the end of the image data to simplify the bounds check in the decoder. Those 4 bytes are subtracted from the chunks_len that the pixel start bound check compares against. So you could craft an image where the last pixel runs into that padding (which the encoder won't produce since it always pads with the full 4 bytes) but not one where the pixel data is read from outside the image buffer beyond the padding.