AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2003.12.26 16:00 "[Tiff] [ANNOUNCE]: Libtiff 3.6.1 released", by Andrey Kiselev
[...]
2004.01.14 16:43 "Re: [Tiff] COLORMAP and byte padding", by Joris
2004.01.14 17:13 "Re: [Tiff] COLORMAP and byte padding", by Gerben Vos
2004.01.14 17:24 "Re: [Tiff] COLORMAP and byte padding", by Phillip Crews
[...]

2004.01.14 17:24 "Re: [Tiff] COLORMAP and byte padding", by Phillip Crews

> For the perfectionists who are wondering: multiplying by 257 works perfectly.

Agreed on the multiplying by 257. I dissagree on the 'for the perfectionists' part, though, because multiplying by 257 is simply the only correct thing to do and that's all there is to it.

The general rule if 0 maps to 0: divide by the max in the scale you're leaving, and multiply by the max in the scale you're entering. Thus, going from 8bit to 16bit becomes:

uint16val = uint8val/255*65535

              = uint8val*257
              = uint8val*256+uint8val*1
              = ((uint8val << 8) | uint8val)

I agree here.

Converting 4-bit to 8-bit is a multiply by 17 as well, since

   x^2 -1 = (x-1) * (x+1), so 255 = 15*17.

Going from 16bit to 8bit becomes:

uint8val = uint16val/65535*255

= uint16val/257

I disagree. Using integer division, the only 16-bit pixel value that will result in white (255) is 0xffff, and 0x0100 will incorrectly be black.

I've considered (uint16val+128)/257, but prefer uintval/256 because it is significantly faster and evenly spills the range of valid 16-bit values into 8-bit buckets.

- Phillip