[GRASS5] Re: d.his r.his question

GRASS GRASS developer
1

Bob,

(I'm on travel at time)
(I cc to grass5 as this might be of interest)

On Tue, Dec 11, 2001 at 10:41:09AM -0400, Bob Covill wrote:

Markus;

[...]

I am actaully writing with a question about d.his (and r.his). In the
past I used a modified version of d.his to create color shaded relief
maps. In other words I fused a color raster (h_map) with a grey
sun-illuminated raster (i_map). The new r.his seems to be (correctly)
designed for imagery.

yes, d.his and r.his I also use for this purpose. Don't you like the
result?

The question I have is there another program that I have overlooked for
combining a color classified raster with a grey shaded raster to create
a single fused raster?

For this r.composite is nice. However, due to the speed limitations
in the current GRASS color model, you may avoid to use more than 8000
colors.

BTW: Does anyone know the reason for the color limitations? We
shall put this into the bugtracker. I can't recall the reason.

Best regards

Markus

2

Markus Neteler wrote:

> I am actaully writing with a question about d.his (and r.his). In the
> past I used a modified version of d.his to create color shaded relief
> maps. In other words I fused a color raster (h_map) with a grey
> sun-illuminated raster (i_map). The new r.his seems to be (correctly)
> designed for imagery.

Treating colour images as a single raster layer with R*G*B distinct
categories is something of a kludge. In the absence of vector-valued
cell maps (i.e. band-interleaved-by-pixel), the next best thing (IMHO)
is separate R,G,B maps (effectively band-sequential).

I'm having second thoughts about whether r.his and r.composite should
have separate arguments for each channel, though. It might be better
to just have input=/output= and require that the bands are called
foo.r, foo.g and foo.b.

yes, d.his and r.his I also use for this purpose. Don't you like the
result?

> The question I have is there another program that I have overlooked for
> combining a color classified raster with a grey shaded raster to create
> a single fused raster?
For this r.composite is nice. However, due to the speed limitations
in the current GRASS color model, you may avoid to use more than 8000
colors.

BTW: Does anyone know the reason for the color limitations? We
shall put this into the bugtracker. I can't recall the reason.

Partly memory consumption (for the colour table), but mainly speed.
Adding a new colour rule (with e.g. G_add_c_raster_color_rule())
checks for overlaps against each of the existing colour rules. As the
number of existing rules increases, the time taken to add each new
rule increases.

Intuition suggests that the time complexity should be O(n^2), but
quick tests suggests that it may even be O(n^3). Try running
r.composite with different values for the "levels=" option. If you try
with "levels=256", you'll see why this isn't the default :wink:

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

3

On Wed, Dec 12, 2001 at 03:04:19PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> > I am actaully writing with a question about d.his (and r.his). In the
> > past I used a modified version of d.his to create color shaded relief
> > maps. In other words I fused a color raster (h_map) with a grey
> > sun-illuminated raster (i_map). The new r.his seems to be (correctly)
> > designed for imagery.

Treating colour images as a single raster layer with R*G*B distinct
categories is something of a kludge. In the absence of vector-valued
cell maps (i.e. band-interleaved-by-pixel), the next best thing (IMHO)
is separate R,G,B maps (effectively band-sequential).

I'm having second thoughts about whether r.his and r.composite should
have separate arguments for each channel, though. It might be better
to just have input=/output= and require that the bands are called
foo.r, foo.g and foo.b.

... that's a good suggestions which reduces typing efforts.
eventually just:

input=name [prefix=name]

if !prefix
prefix=input

[...]

Markus

4

On Wed, 12 Dec 2001 16:24:54 +0100, Markus Neteler <neteler@itc.it> wrote:

On Wed, Dec 12, 2001 at 03:04:19PM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > > I am actaully writing with a question about d.his (and r.his). In the
> > > past I used a modified version of d.his to create color shaded relief
> > > maps. In other words I fused a color raster (h_map) with a grey
> > > sun-illuminated raster (i_map). The new r.his seems to be (correctly)
> > > designed for imagery.
>
> Treating colour images as a single raster layer with R*G*B distinct
> categories is something of a kludge. In the absence of vector-valued
> cell maps (i.e. band-interleaved-by-pixel), the next best thing (IMHO)
> is separate R,G,B maps (effectively band-sequential).
>
> I'm having second thoughts about whether r.his and r.composite should
> have separate arguments for each channel, though. It might be better
> to just have input=/output= and require that the bands are called
> foo.r, foo.g and foo.b.

... that's a good suggestions which reduces typing efforts.
eventually just:

input=name [prefix=name]

if !prefix
prefix=input

[...]

Umm, wouldn't imagery groups work? Already set-up for specifying the
RGB bands...

--
Eric G. Miller <egm2@jps.net>

5

Eric G. Miller wrote:

> > > > I am actaully writing with a question about d.his (and r.his). In the
> > > > past I used a modified version of d.his to create color shaded relief
> > > > maps. In other words I fused a color raster (h_map) with a grey
> > > > sun-illuminated raster (i_map). The new r.his seems to be (correctly)
> > > > designed for imagery.
> >
> > Treating colour images as a single raster layer with R*G*B distinct
> > categories is something of a kludge. In the absence of vector-valued
> > cell maps (i.e. band-interleaved-by-pixel), the next best thing (IMHO)
> > is separate R,G,B maps (effectively band-sequential).
> >
> > I'm having second thoughts about whether r.his and r.composite should
> > have separate arguments for each channel, though. It might be better
> > to just have input=/output= and require that the bands are called
> > foo.r, foo.g and foo.b.
>
> ... that's a good suggestions which reduces typing efforts.
> eventually just:
>
> input=name [prefix=name]
>
> if !prefix
> prefix=input
>
> [...]

Umm, wouldn't imagery groups work? Already set-up for specifying the
RGB bands...

Probably. I wasn't familiar with imagery groups when I wrote this
stuff. Actually, I'm still not familiar with them. If that's deemed to
be the right way to go, I'll look into it.

However: should r.composite be retained? E.g. for the benefit of users
who aren't familiar with imagery groups, and are looking for an
r.<something> command to process their raster maps.

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

6

Glynn;

I have been trying the new r.his to generate RGB files, followed by
r.composite to assemble the files into a single combined image. I have
compared the results to the results from my old d.his method.

What I found is that the new r,his is written only for CELL type data.
If the data is floating point only the integer values are used and
consequently the integer color is used. The end rsult of this is a final
image with distinct color breaks as opposed to a smooth color range from
the original hue map. In my case the original hue map is a floating
point DEM with a custom color table. The intensity map is an integer
shaded relief map generated from the DEM.

I guess the question is, should r.his be only used for imagery (CELL)
data or should it be expanded to include FCELL type data? Would it be
better to come up with a new program to combine a hue map with a
intensity map? Starting to sound like the same questions asked over.

--
Bob Covill

7

Bob Covill wrote:

I have been trying the new r.his to generate RGB files, followed by
r.composite to assemble the files into a single combined image. I have
compared the results to the results from my old d.his method.

What I found is that the new r,his is written only for CELL type data.
If the data is floating point only the integer values are used and
consequently the integer color is used. The end rsult of this is a final
image with distinct color breaks as opposed to a smooth color range from
the original hue map. In my case the original hue map is a floating
point DEM with a custom color table. The intensity map is an integer
shaded relief map generated from the DEM.

I guess the question is, should r.his be only used for imagery (CELL)
data or should it be expanded to include FCELL type data? Would it be
better to come up with a new program to combine a hue map with a
intensity map? Starting to sound like the same questions asked over.

Note: r.his was closely based upon d.his, which has only ever
supported CELL data (at least, as long as it's been in CVS).

If your original composite layers look smoother, I would guess that
it's because d.his used to perform dithering. I originally planned to
add this to r.composite as an option, but had forgotten about it until
now.

I'll add some dithering options to r.composite (at least the basic
dithering previously implemented in d.his, maybe Floyd-Steinberg as
well).

Having said that, I'm not personally aware of any situation where
composite layers are a good idea.

AFAICT, it's always preferable to leave the data as separate R/G/B
bands. These can be exported as a 24-bit PPM image with r.out.ppm3
(PPM can be converted to ~20 different formats with the pbmplus/netpbm
tools), displayed with d.rgb, and printed using ps.map's "rgb"
command.

However, I would appreciate any examples where there is a good reason
for merging separate R/G/B layers into a composite layer.

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

8

Bob Covill wrote:

I have attached 3 smaller sections of the earlier files. Again the first
image dem1.png is the the original color classified dem. The second
image his1.png is the file created with the modified d.his. The third
file, his2.png, was created from r.his->r.combine->r.out.ppm3.

OK; I've re-read the whole thread, and see what you're getting at. I
had been thinking that this was regarding something which used to work
with the original d.his before I changed it. Sorry for the confusion.

To get back to your actual question:

I guess the question is, should r.his be only used for imagery (CELL)
data or should it be expanded to include FCELL type data? Would it be
better to come up with a new program to combine a hue map with a
intensity map? Starting to sound like the same questions asked over.

I think that r.his should probably be expanded to handle FCELL/DCELL
data, as should d.his and r.composite.

Both of these programs operate on 8-bit unsigned integer values. I.e.
they read cell values, convert these to RGB colours, then operate upon
the colours. And both programs use CELL (integer) values for the
intermediate stage, which (as your image shows) loses information when
used on FP data with a relatively small range (i.e. where coercion to
integer introduces a large relative error).

Given that the problem exists in at least three programs, and maybe
more, it might be better to write a utility function to read the
CELL/FCELL/DCELL values and perform the colour lookups. That would
mean that programs which don't care about the actual values, but only
the associated colours, wouldn't each need to handle each of the
different data formats.

BTW, if you need a solution right now, it wouldn't be that hard to do
it with r.mapcalc; this is the approach taken by rgb.hsv.sh and
hsv.rgb.sh. Actually, I'm wondering if this wouldn't be a better
approach for r.his.

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