[GRASS5] r.in.gdal updates?

Frank Warmerdam warmerdam at pobox.com
Mon Mar 10 10:01:18 EST 2003

Markus Neteler wrote:
> On Sun, Mar 02, 2003 at 06:53:56PM +0000, Glynn Clements wrote:
>>Glynn Clements wrote:
>>>>I would like to ask if a developer is willing to update r.in.gdal
>>>>(Frank Warmerdam told me that he won't do that at time):
>>>> - fix the grey color tables issue for RGB maps
>>>The main problem here is determining the overall range of the data,
>>>i.e. which values correspond to black and white. Black is almost
>>>certain to be 0, but determining white is more difficult. Usually it's
>>>((1<<bit_depth)-1), but you need to know what bit_depth is.
>>The upshot of a private conversation with Frank is that GDAL doesn't
>>make this information available. Consequently, you would need to use
>>heuristics to determine the bit depth (and hope that the image isn't
>>too dark).
> We may start to implement it only for RGB images at time. Usually
> they should be 8 bit. GDAL cannot deliver the bit depth of the
> read format (maybe GetRasterDataType())?


I think Glynn is referring to the fact that GDAL doesn't return the
real dynamic range of the original sensor.  For instance, an 11bit sensor
would be represented via GDAL as 16 bit (depending on the format it is
stored in of course), not 11.  So, of course GDAL returns information on
the data type but GDAL can't transport the meaningful dynamic range of
the original sensor since that isn't even available in most formats.

In short, if it is GDB_Byte assume a dynamic range of 0-255 otherwise the
data should be sampled.


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

More information about the grass-dev mailing list