2004.01.15 20:14 "Re: [Tiff] How to determine number of colors in the colormap", by Bill Cassanova
Ah,,,That makes since. I did a little experiment and anded each of the red, green, and blue values with
0xff to wipe out the high order bits...The values are now in the range of 0 to 255.
One curious note though. If the largest number that could ever exist in a Red or Green or Blue component
is 255 why would libtiff have defined the values coming out of a call to TIFFGetField as uint16*?
My only thoughts are maybe libtiff was written with strictly a "C" interface in mind and therefore function overloading would not have been possible. If they coded it for the largest value that would ever be returned from TIFFGetField then I guess uint16 is the right choice.
Thanks for the input.
<joris.at.lebbeke To: "Tiff mailing list" <firstname.lastname@example.org>
Sent by: Subject: Re: [Tiff] How to determine number of colors in the colormap
Thanks for writing.
So to read the colormap am I doing it correctly? For some reason the results I am getting are
non-sensible. I would have expected to see values in the range of 0 to 255.
It's been a while since I build my interface to that stuff. I plan to return to it, that's the reason I'm here again, but when it comes to LibTiff, someone else's advice is no doubt better than my vague memory.
No, you should expect values like the ones you're seeing. The palette entries is 16bits per channel.
You could check your findings by comparing them with the output of my free TIFF Tag Viewer application for windows.
If you want to convert them to the more familiar 8bit per channel range, see a very recent (and ongoing?) other thread on this subject tittled 'Colormap and byte padding'. No disrespect to other posters in that thread (especially no disrespect to myself, grin), but if you want a quick answer without browsing through the whole thread I should suggest that Marti Maria is the author of Little CMS and could be considered the authority on the matter.