2004.01.14 19:02 "Re: [Tiff] COLORMAP and byte padding", by Andy Cave
What "significant errors"? Please show us. As far as I know there are no significant errors - as I said in my previous post, 0 to 255 -> 0, 256 to 511 -> 1, etc... gives an even spread reduction. How else would one want to map these numbers? For example what do you think 127 should map to, or 128, or 255, 256, or 511,512, etc...?
Your calculation is:
(rgb * 65281) = (rgb * (65536 - 255)) = rgb * 65536 - rgb * 255.
If I understand this correctly, all it does is map 0 to 128 -> 0, 129 to 385 -> 1, etc... which gives a non-even spread (where the end 'bands' are half all the other bands). Why would anyone prefer this (slower method)?
For the perfectionists who are wondering: multiplying by 257 works perfectly. In effect, it makes the least significant byte a copy of the most significant byte of the 16-bit value. In C:
uint16val = ((uint8val << 8) | uint8val);
Note that when reducing the 16-bit value to 8-bit, you could divide by 257 and round, but it's way faster to simply take the upper byte (the same as an integer division by 256, truncating everything after the decimal point). Don't divide by 256 and round, because you will end up 1 too high in 50% of the cases. In C:
uint8val = (uint16val >> 8);
Yep, that is fast, but unfortunately can give significant errors, since that is same than dividing by 256.
Here are a couple of macros that does the trick.
#define RGB_8_TO_16(rgb) (WORD) ((((WORD) (rgb)) << 8)|(rgb))
#define RGB_16_TO_8(rgb) (BYTE) ((((rgb) * 65281 + 8388608) >> 24) & 0xFF)
The little cms project