search

phoboslab / qoi

The “Quite OK Image Format” for fast, lossless image compression
MIT License
6.92k stars 330 forks source link

Comments on spec.pdf #186

Closed rivitoz closed 2 years ago

rivitoz commented 2 years ago

A couple of comments rather than issues as such

1) as its possible for awkward images to end up with a compressed size larger than the original (potentially 5 for every 4 ARGB) the encoder should quit when it's become obvious that further compression activity is pointless.

2) In the spec.pdf - if RUN length is stored with a -1 bias then it can take values 0..61 in that byte which corresponds to run length 1..62. This is because the code values 62 x3E and 63 x3F are reserved in that 11........ byte corresponding to the RGB and RGBA codes. To call them run lengths of 63 and 64 is a little confusing.

uis246 commented 2 years ago
  1. How palette is initialized? All zeros or all undefined? So can I use index != 0 for black at the beginning?
phoboslab commented 2 years ago
  1. I disagree, as that would be surprising behavior. If you ask for a QOI file, you'll get a QOI file no matter what.
  2. 0x3E and 0x3F would correspond to run lengths 63 and 64 if they were allowed. But I agree it's a bit hard to parse. Do you have a suggestion for the exact wording?
  3. "A running array[64] (zero-initialized)…". So yes, you could use QOI_OP_INDEX with any index position for transparent black at the beginning.
rivitoz commented 2 years ago

Dominic re 1 no problem - callers responsibility. Users should be aware a longer file might result. re 2 Simplest solution is to not mention runlengths other than the ones represented. That should be enough as you already define the OP_RGB and OP_RGBA codes earlier. Ron

ePaul commented 2 years ago

@rivitoz Every compression format will have some inputs where the output is larger than the input. There is no way around this (pidgeon hole principle). For QOI in the extreme case you'll get 125% of the uncompressed size (when the alpha channel is changing on every pixel and they are not found in the index either). This is the price of the simplicity.

uis246 commented 2 years ago

RUN length is stored with a -1 bias then it can take values 0..61 in that byte which corresponds to run length 1..62.

  1. Why not -2 bias? When only next pixel is same as prev, maybe use index? Or this is for some sort of optimization?
phoboslab commented 2 years ago
  1. Why not -2 bias? When only next pixel is same as prev, maybe use index? Or this is for some sort of optimization?

Yeah, there's multiple ways to encode a single unchanged pixel in one byte: QOI_OP_INDEX, QOI_OP_DIFF and QOI_OP_RUN. There could be a bit more efficiency squeezed out for this case, but I opted against it, for an easier to understand spec.