[GRASS-user] Raster analysis

[Glynn Clements]

Brad Douglas wrote:

> > > > Please react to the statement below. This is from one shifting from
> > > > Idrisi to GRASS
> > > >
> > > > "I have found that colour manipulation by contrast stretching is not
> > > > possible in GRASS or am I wrong."
> > > 
> > > Sadly, it is correct.  Only 8-bit (integer) color is supported at this
> > > time.  Adding it to grass/TODO.
> > 
> > Can you elaborate?
> > 
> > Are you referring to the fact that GRASS' colour tables only use 8
> > bits per component? Or the use of 8 bits per component in the display
> > architecture? Or something else?
> 
> The first one: color tables = 8 bits per component.  I'm sure the 2nd
> will eventually come into play, but is much less significant.
> 
> Well, technically, it is possible to do contract stretching
> (normalization), but there is no module to accomplish it and virtually
> all data you would want to use this technique with are 16-bit or better
> resolution.  For instance, the ASTER satellite data I use is 16-bit,
> making it virtually useless in GRASS.
> 
> The module would be fairly simple to accomplish.  Modifying GRASS is a
> bit more work.  GRASS also seems to limited to 1000 categories, too.

There's no reason why you can't import data with more than 8 bits per
component, although some import modules may have their own
limitations.

GRASS itself definitely does not have a limit of 1000 categories. The
only limit is the range of a 32-bit integer.

A colour table isn't necessary for most processing operations; it's
only required for visualisation and export to image files (PNG etc).

Visualising data with more than 8 bits per component will result in
the final output being limited to 8 bits per component (i.e. 24-bpp
RGB), but very few systems support more than that anyhow. However, the
truncation is applied to the result of the colour table lookup, not
the input.

The 8-bit limitation is most significant for export. As it stands, you
can't easily generate image files with more than 8 bits per component.

Unfortunately, fixing that isn't straightforward. We would need to:

1. Extend the format used for colour tables, in such a way that existing
colour tables continue to work.

2. Modify the functions which read colour tables to support the new
format.

3. Add new functions to provide access to the more precise intensity
values.

4. Modify the export modules to make use of the new functions. 
(Modifying visualisation modules is probably pointless, as so little
graphics hardware supports more than 8 bits per component).

-- 
Glynn Clements <glynn at gclements.plus.com>