[GRASS5] r.in.gdal and colors

[Glynn Clements]

Russell Nelson wrote:

>  > Thanks that did it. Don't understand why I have to go through grey to get
>  > colors, but oh well...

The code needs a way to translate category values to intensities. It
does this by using the intensities from the map's colour table. If the
colour table is wrong, everything which tries to use it will produce
the wrong result.

> Makes no sense to me either.  If r.in.gdal splits an image up into R,
> G, and B, then it ought to set the colormap for those rasters to
> grey.  When would you ever want it otherwise??

AFAICT, the problem is that r.in.gdal (maybe others) don't set *any*
colour table, so you get the default colour table ("rainbow").

For importing most image formats, I suggest converting to PPM (e.g. 
via "djpeg"), then using "r.in.ppm -b" (r.in.ppm *does* set the colour
table correctly).

The main exceptions are PNG (r.in.png will preserve some information
which could be lost by going via PPM) and TIFF (r.in.tiff and
r.in.gdal can extract geographic data from .tfw files or GeoTIFF
images respectively).

However, the problem with using "r.colors ... color=grey" is that it
will map black and white to the lowest and highest categories which
are actually used, rather than to the logical range of the data.

A better approach is to use color=rules, and explicitly map
black/white to 0/255 (or 0.0/1.0 for FP), e.g.

	r.colors map=... color=rules
	0 black
	255 white
	end

> > > The thing I'd like to know is how to get them back into one map again.
> > 
> > r.composite
> 
> Thanks!

First, you should be asking yourself whether you want to get them back
into one map again. For most purposes (considering that GRASS is an
analysis package, not a paint program), it's best to leave them as
three separate maps, where the cell values are meaningful.

If you generate a composite map with r.composite, the resulting
categories are basically meaningless; about the *only* thing you can
actually do with the image is to display it. Furthermore, unless you
use "r.composite ... levels=256" (which is slow in itself, and also
makes some other operations slow), a composite map will usually have
lower colour resolution than separate bands.

To date, I've only discovered one scenario which requires the use of a
composite map, and that is for use as a colour layer in NVIZ. The
other common operations upon a composite map all have equivalents
which operate upon separate R/G/B layers:

	Composite	Separate Bands

	d.rast		d.rgb
	r.out.ppm	r.out.ppm3
	r.in.ppm -c	r.in.ppm -b
	ps.map/raster	ps.map/rgb

-- 
Glynn Clements <glynn.clements at virgin.net>