Closed rivitoz closed 2 years ago
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?QOI_OP_INDEX
with any index position for transparent black at the beginning.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
@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.
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.
- 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.
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.