[Gdal-dev] Inaccuracy concerning PseudoColor-Tables

[Frank Warmerdam]

On 7/7/05, Schmitz, Uwe <uwe.schmitz at lverma.nrw.de> wrote:
> Hi,
> 
> I've detected a slight inaccuracy during translation
> of a Gtiff formatted file.
> 
> I have a file f2.tif on which "tiffinfo -c" gives me:
...
>   Color Map:
>        0: 65535 65535 65535
>        1: 65535     0     0
>        2: 57054 65021 65535
>        3: 13107 26214 65535
>        4: 61166 53713 49858
>        5: 57825 50629 43947
>        6: 63736 52428 43176
> <<snip>>
> 
> After doing
> 
> gdal_translate -co COMPRESS=PACKBITS f2.tif f3.tif
...
>   Color Map:
>        0: 65280 65280 65280
>        1: 65280     0     0
>        2: 56832 64768 65280
>        3: 13056 26112 65280
>        4: 60928 53504 49664
>        5: 57600 50432 43776
>        6: 63488 52224 43008

Uwe, 

I was somewhat shocked to see this, since I thought I had been
very careful about retaining the full dynamic range when converting
to 16bit for tiff colormaps.  What I discovered in the code is that there
are two sets of logic for writing colormaps in TIFF.  One for "immediate
writes" and one used in the CreateCopy() case (as used by gdal_translate). 
The immediate mode (SetColorTable()) was done right, but the 
CreateCopy() was not.  

I have committed a correction for this to CVS. 

Thanks for the careful report. 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent