[GRASSLIST:1829] inverse r.composite?

GRASS GRASS user
,
1

Hi all, sorry to pester the list recently, but the more I try new things (I love
GRASS), the more questions I have (not a bad thing). I have been working on
using i.ortho.photo lately. Got all the bugs worked out with that (see earlier
posts).

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. 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.

Thanks a million, Ian

2

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@virgin.net>

3

On Thu, 20 Nov 2003, Glynn Clements wrote:

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

I think Ian said in another e-mail he was using 5.0.0? The colour table
support for r.proj is only recently added (in 5.3/CVS HEAD only)

4

Paul Kelly wrote:

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

I think Ian said in another e-mail he was using 5.0.0? The colour table
support for r.proj is only recently added (in 5.3/CVS HEAD only)

Right. Well, not really that recent (2003/04/28), but it is still only
in 5.3 (not 5.0.3).

That particular feature should go into the release branch. I guess
that it will have been overlooked amongst the datum-related changes.

In general, a program which preserves cell values should replicate the
colour table. However, it's particularly important for r.proj, as you
can't use a map from a different location with "r.colors rast=...".

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