[gdal-dev] [GRASS-user] r.out.gdal export with color table for floating-point values

Even Rouault even.rouault at mines-paris.org
Tue Aug 2 07:21:36 EDT 2011


> Thanks a lot Even for your help,
>
> the workaround with gdaldem worked fine for me. I can use the integer output
> for nice looking visualisation in the background and the floating ERDAS Img
> for further processing.
>
> Are there any plans to be able to translate GRASS color tables of a floating
> point band into a matching GDAL object? Would it make sense to write an
> enhancement report to the GDAL bug tracker?

One big question is : who (=which drivers) would make use of this new enhanced
"color table" object ? Apparently GRASS, but the only other driver I have in
mind would be the EHdr driver for which negative values for the entries are also
possible. See http://trac.osgeo.org/gdal/ticket/3253 . Perhaps I am missing
other use cases, but that seems to be a quite uncommon notion to justify
extending the abstraction GDAL model to accomodate for it.

The notion of "color table" does not even seem to be appropriate when talking
about floating point values. Floating point values are by essence continuous
(*), in contrary to integer values which are discrete. So why put an entry in
the table for 11.1, but not for 11.11, 11.111... ? The values that you would put
in such a table would be similar to the text file used by gdaldem, that is to
say thresholds used by the linear interpolation for a float->RGB conversion.

The use case for Byte raster bands is different. For a paletted Byte raster
band, the value of the byte has generally no meaning by itself : it is just an
arbitrary index that is mapped to a RGB triplet in the table. The color table
acts in fact as a compression method and you can generally not use other values
for the table(**).

For a Float32 raster band, the value of the pixel means something (physical
phenomenon). The table can be used as an additionnal way of displaying the
value. But you could use different tables depending on how you want to display
the data (for a DEM, you have different DEM color tables depending on the nature
of the terrain, its global elevation, etc...). So such a color table is used for
styling, and you can imagine having different styles for the same raster band,
contrary to byte raster band where the palette is generally unique.

Even

(*) Not completely though. For a 32bit float, you have at maximum 2^32 values,
and even a bit less considering that several byte combinations map to NaN.
(**) Of course, for each principle, you can find its exception. The BSB driver
enables the user to select an alternate color table to use. See
http://gdal.org/frmt_various.html#BSB

>
> Regards,
>  Otto
>
>
>
>
>
>




More information about the gdal-dev mailing list