Inaccuracy concerning PseudoColor-Tables

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Inaccuracy concerning PseudoColor-Tables

Uwe Schmitz-2
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:

TIFF Directory at offset 0xf4691e
  Image Width: 4000 Image Length: 4000
  Bits/Sample: 8
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: palette color (RGB from colormap)
  Samples/Pixel: 1
  Rows/Strip: 2
  Planar Configuration: single image plane
  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

a "tiffinfo -c" for f3.tif results in:

TIFF Directory at offset 0x4080a
  Image Width: 4000 Image Length: 4000
  Bits/Sample: 8
  Sample Format: unsigned integer
  Compression Scheme: PackBits
  Photometric Interpretation: palette color (RGB from colormap)
  Samples/Pixel: 1
  Rows/Strip: 2
  Planar Configuration: single image plane
  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
<<snip>>

Please note that every color value
(except 0) has slightly changed. Well, gdalinfo produces
the same Output for both files, but it works with 8 bit
resolution.

Also using the identify command line tool from
ImageMagick (which also uses 8 bit channel resolution),
I get the following output:


File f2.tif:

f2.tif TIFF 4000x4000 PseudoClass 256c 15.3mb 0.656u 0:01
Image: f2.tif
  Format: TIFF (Tagged Image File Format)
  Geometry: 4000x4000
  Class: PseudoClass
  Type: Palette
  Endianess: LSB
  Colorspace: RGB
  Channel depth:
    Red: 8-bits
    Green: 8-bits
    Blue: 8-bits
  Channel statistics:
    <<channel stats snipped>>
  Colors: 256
         0: (255,255,255) white
         1: (255,  0,  0) red
         2: (222,253,255) #DEFDFF
         3: ( 51,102,255) #3366FF
         4: (238,209,194) #EED1C2
         5: (225,197,171) #E1C5AB
         6: (248,204,168) #F8CCA8
<<snip>>

File f3.tif:

__3.tif TIFF 4000x4000 PseudoClass 256c 276kb 0.672u 0:01
Image: __3.tif
  Format: TIFF (Tagged Image File Format)
  Geometry: 4000x4000
  Class: PseudoClass
  Type: Palette
  Endianess: LSB
  Colorspace: RGB
  Channel depth:
    Red: 9-bits
    Green: 9-bits
    Blue: 9-bits
  Channel statistics:
    <<channel stats snipped>>
  Colors: 256
         0: (254,254,254) #FEFEFE
         1: (254,  0,  0) #FE0000
         2: (221,252,254) #DDFCFE
         3: ( 50,101,254) #3265FE
         4: (237,208,193) #EDD0C1
         5: (224,196,170) #E0C4AA
         6: (247,203,167) #F7CBA7
<<snip>>

(Please recognize the unusual channel depth)

I've tested these with FWTools0.9.8 under Windows
and with gdal1.2.6 under Unix. I think this is a bug,
but may be I'm  missing something.

Best wishes
Uwe

---------------------------------------------------------
... Uwe Schmitz  Landesvermessungsamt Nordrhein-Westfalen
... Muffendorfer Str. 19 - 21              D - 53177 Bonn
... E-mail:       [hidden email]
... Internet:     http://www.lverma.nrw.de
 
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Inaccuracy concerning PseudoColor-Tables

Frank Warmerdam-2
On 7/7/05, Schmitz, Uwe <[hidden email]> 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, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev