[GRASSLIST:1832] Re: inverse r.composite?

[Glynn Clements]

Ian Macmillan wrote:

> Now I have a color orthorectified air photo in a UTM projection. I
> would like to project this color raster into a lat-long location. 
> Problem is that r.proj seems to mess with the colors, and the newly
> projected air photo in the lat long location has screwy colors (like
> a color ramp). I can't figure out how to get around this.

Odd. r.proj is supposed to copy the colour table. You could try
copying it manually; the file in question has the same name as the
map, and lives in the "colr" subdirectory of the mapset directory.

> When I
> imported the original photo into my xy location, it came in as a
> single rgb raster (both with r.in.tiff, and r.in.gdal). Going
> through i.ortho.photo kept the colors the same in the UTM location. 
> However now the colors are scewball in the lat-long location. I
> figured a fix would be to separate the color orthophoto into 3 bands
> (ortho_photo.r, ortho_photo.g, ortho_photo.b), sort of like
> r.composite, but in reverse. I could then r.proj each of those into
> the lat-long location, and composite them later. I can't figure out
> how to do this though. Any ideas? Is there another approach? A
> search through the archives unfortunately didn't help too much.

There isn't a dedicated command, but it's easy enough to do with
r.mapcalc:

	r.mapcalc 'map.r = r#map ; map.g = g#map ; map.b = b#map'

The above will split a map named "map" into three maps named "map.r",
"map.g" and "map.b".

Depending upon what you will subsequently do with the map, you may
need to set appropriate grey-scale colour tables, e.g.:

	GRASS:~ > r.colors map.r color=rules
	Enter rules, "end" when done, "help" if you need it.
	Data range is 0 to 255
	> 0 black
	> 255 white
	> end
	GRASS:~ > r.colors map.g rast=map.r
	GRASS:~ > r.colors map.b rast=map.r

For this purpose, using color=rules is safer than color=grey, as the
latter will produce the wrong result if the map only uses a subset of
the range 0-255.

However: splitting a map into components then re-constructing it with
r.composite will normally lose data, primarily because using
levels=256 is impractical; that generates massive colour tables,
meaning that not only does r.composite itself take a long time to run,
but so does anything which uses the colour table (e.g. d.rast).

If at all possible, it would be better to figure out why r.proj failed
to preserve the colour table.

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