2004.01.15 18:59 "Re: [Tiff] How to determine number of colors in the colormap", by Bill Cassanova
Thanks for writing.
I wondered about the -1 as well but I saw it in an example and thought I was missing something.
The original example was at: http://remotesensing.org/pipermail/tiff/2003-November/000230.html
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.
Instead I am seeing results like from the execution of the code below:
0 0 0
26214 26214 26214
39321 39321 39321
52428 52428 52428
65535 65535 65535
39321 52428 65535
26214 52428 65535
13107 52428 65535
The code from the original is posted below for convenience.
int num_entries = (1 << bitspersample) - 1;
cout << "num_entries: " << num_entries << endl;
// get the photmetric interpretation
if ((result =
TIFFGetField(image_in, TIFFTAG_COLORMAP, &red, &green, &blue)) != 1)
for (int i = 0; i < num_entries; i++)
cout << red[i] << "\t" << green[i] << "\t" << blue[i] << endl;
<joris.at.lebbeke To: "Tiff mailing list" <email@example.com>
Sent by: Subject: Re: [Tiff] How to determine number of colors in the colormap
I have an 8-bit tiff image which I have been able to confirm has only 18 colors. Is there some tag within the tiff itself that says how many colors are actually present?
No, there isn't. That is only possible to deduct with code that actually counts the colors used. This counting is not a codec's responsability, either, it is an imaging operation instead of an encoding/decoding operation.
An extreme example of how these two are different and complement each other: a codec is and should be perfectly happy to encode a black and white image in 16bits per channel full color RGB. But of course the imaging library on top of the codec is either completely braindead, or provides the application level with a way to easily detect and improve encoder options that produce such garbadge, which may internally result in transcoding the image library's image object into another object that is 1bit per pixel.
Or at least, that's how I see it.
The value that is being returned when I have ( 2**bits_per_sample ) or from another example I saw (( 1 << bitspersample ) -1 ) is 255 which is the number of colors that I would expect are possible although not necessarily present.
Why the -1? (2**bits_per_sample) = (1<< bits_per_sample) = maximum number of entries in palette. The -1 can be used to derive the index of the last entry in the palette.