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 12:01 "[Tiff] COLORMAP and byte padding", by Stephan Assmus
2004.01.14 15:07 "Re: [Tiff] COLORMAP and byte padding", by Frank Warmerdam
2004.01.14 16:18 "Re: [Tiff] COLORMAP and byte padding", by Gerben Vos
2004.01.14 17:26 "Re: [Tiff] COLORMAP and byte padding", by Andy Cave
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:36 "Re: [Tiff] COLORMAP and byte padding", by Joris
2004.01.14 18:18 "Re: [Tiff] COLORMAP and byte padding", by Marti Maria
2004.01.14 19:02 "Re: [Tiff] COLORMAP and byte padding", by Andy Cave
2004.01.14 19:36 "Re: [Tiff] COLORMAP and byte padding", by Marti Maria
2004.01.14 19:48 "Re: [Tiff] COLORMAP and byte padding", by Andy Cave
2004.01.15 17:24 "Re: [Tiff] COLORMAP and byte padding", by
2004.01.15 17:37 "Re: [Tiff] COLORMAP and byte padding", by Andy Cave
2004.01.15 00:05 "Re: [Tiff] COLORMAP and byte padding", by Chris Cox
2004.01.14 17:17 "Re: [Tiff] COLORMAP and byte padding", by Joris

2004.01.14 17:26 "Re: [Tiff] COLORMAP and byte padding", by Andy Cave

I really wouldn't do that. The 'solution' of dividing by 256 is far more accurate.

With 256:

0 to 255 -> 0,
256 to 511 -> 1,
...
65280 to 65535 ->255.

This gives an even map of 256 values down to each resultant value.

With 257:

0 to 256 -> 0,
257 to 513 -> 2,
...
65278 to 65534 -> 254
65535 ->255.

NOT an even spread.

_andy.

Cc: "Joris" <joris.at.lebbeke@skynet.be> Sent: Wednesday, January 14, 2004 5:13 PM Subject: Re: [Tiff] COLORMAP and byte padding

> > uint8val = uint16val/65535*255
> > = uint16val/257
>
> > Are you sure that boils down to >>8? I'd have to check...
>

> Oops, no. That's wrong in 16256 cases, roughly 24.8%. Should have checked before I spoke. My deepest apologies.

>

> Guess downconverting has to be slow, unless you know you've taken Frank's not quite precise shortcut when upconverting. (Well, if you feel the need for speed you could always sacrifice 65536 bytes to a lookup table.)