Another case of combinatorial dilemma

A project log for 3RGB image lossless compression format

Tiled CODEC for still and moving pictures based on the 3R compaction algorithm

yann-guidon-ygdesYann Guidon / YGDES 05/30/2017 at 23:370 Comments

As one block of 64 number is scanned, the min and max values are computed. The min value is subtracted from all the sample, as well as from max.

This implies that

Wouldn't it be cool if we could use these informations to save more space ?

Let's take the example of max, which in our case can be anywhere from 0 to 765 (up to 10 bits for luma). We have 64 values, so the index fits in 6 bits. The gain can be negative or positive:

The same goes with min, though min usually encodes in less bits than max.

In our case, the special values can not be represented in an efficient way. We have to count on using 3R for increased compaction and there is some inherent redundancy that can't be removed. And the above case only addresses the assumption that there is only one value equal to min and one that is equal to max. How do you manage the case where more than one value is used ?

Note for later:

With fewer values of higher amplitude (like, chunks of 16× 16-bits numbers for example), the "min/max index" uses 8 bits and can save up to 24 bits so this is a valuable trick for sound compression.

Part of the answer is the use of recursive σα transforms because the very high values are reduced to few bits, like the very low values.

Another approach is to encode the max value with a different code, such as 1 (0 is reserved for min). The other values are incremented: 1 becomes 2 etc. However this might not be as beneficial because