[GRASS5] Driver Update

GRASS GRASS developer
1

Markus Neteler wrote:

I have found a display/color problem in d.his:

Today I have done some calculation in northern Italy DEM (GLOBE DEM) and
created an aspect map using r.slope.aspect. Unfortunately moire appears at
Garda lake: all pixels have 0.0 aspect as the lake is flat in DEM, but
appear in different gray values in GRASS monitor.

This appears to be intentional; G_HIS() (src/display/d.his/cmd/his.c)
implements a simple dithering technique.

Any help would be welcome to fix d.his,

I'll fix this in a similar manner to d.rgb, i.e. scrap the misguided
attempt to generate a composite "RGB" output layer and just display
the result of HIS->RGB conversion using R_RGB_raster().

I'll also look into producing a separate r.his program which reads H,
I and S layers and outputs R, G and B layers.

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

2

Glynn Clements wrote:

> Any help would be welcome to fix d.his,

I'll fix this in a similar manner to d.rgb, i.e. scrap the misguided
attempt to generate a composite "RGB" output layer and just display
the result of HIS->RGB conversion using R_RGB_raster().

Having looked into this, the name is somewhat misleading:

1. The "hue" map is only really a hue map if used with a colour table
such as "rainbow" where all entries have 100% intensity and
saturation. Otherwise the intensity and saturation values are used to
scale those provided by the i_map and s_map parameters.

2. The "saturation" map isn't. An all-black saturation map would
result in grey-scale output, but specifying an all-black for the
"s_map" parameter will actually output solid 50% grey. "haze map"
would be more accurate.

From reading the d.his manpage, I'm assuming that the behaviour is
correct and the name isn't, so I'll maintain the existing behaviour.

Would there be any value in a program which displays (or converts)
actual HIS layers? Is HIS ever used for geographical raster data?

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

From neteler Tue Jun 26 09:38:24 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id JAA23389; Tue, 26 Jun 2001 09:38:24 +0100
Date: Tue, 26 Jun 2001 09:38:24 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: Glynn Clements <glynn.clements@virgin.net>
Cc: grass5 developers list <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Driver Update
Message-ID: <20010626093823.I19099@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Glynn Clements <glynn.clements@virgin.net>,
  grass5 developers list <grass5@geog.uni-hannover.de>
References: <15121.14708.979191.289876@cerise.nosuchdomain.co.uk> <20010613171316.K10125@hgeo02.geog.uni-hannover.de> <15143.56498.53250.288145@cerise.nosuchdomain.co.uk> <20010614114747.C11308@hgeo02.geog.uni-hannover.de> <15144.45297.673435.379639@cerise.nosuchdomain.co.uk> <20010614161829.B18856@hgeo02.geog.uni-hannover.de> <15145.8392.320239.598657@cerise.nosuchdomain.co.uk> <20010625171204.G18370@hgeo02.geog.uni-hannover.de> <15159.51431.130059.539081@cerise.nosuchdomain.co.uk> <15159.60464.129470.381175@cerise.nosuchdomain.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15159.60464.129470.381175@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Tue, Jun 26, 2001 at 02:58:08AM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 2564
Lines: 63

On Tue, Jun 26, 2001 at 02:58:08AM +0100, Glynn Clements wrote:

Glynn Clements wrote:

> > Any help would be welcome to fix d.his,
>
> I'll fix this in a similar manner to d.rgb, i.e. scrap the misguided
> attempt to generate a composite "RGB" output layer and just display
> the result of HIS->RGB conversion using R_RGB_raster().

Having looked into this, the name is somewhat misleading:

1. The "hue" map is only really a hue map if used with a colour table
such as "rainbow" where all entries have 100% intensity and
saturation. Otherwise the intensity and saturation values are used to
scale those provided by the i_map and s_map parameters.

2. The "saturation" map isn't. An all-black saturation map would
result in grey-scale output, but specifying an all-black for the
"s_map" parameter will actually output solid 50% grey. "haze map"
would be more accurate.

From reading the d.his manpage, I'm assuming that the behaviour is
correct and the name isn't, so I'll maintain the existing behaviour.

Would there be any value in a program which displays (or converts)
actual HIS layers? Is HIS ever used for geographical raster data?

Glynn,

thanks for your fixes. Now color quality is as expected (no more odd
dithering). However, unfortunately the "output" option is gone which
is needed - or do you know a different way to store such images?

An example, where this is needed: If you want to create shaded maps
(as done in my example from yesterday), you need the "output" parameter
to store the result. This feature is also implemented in "tcltkgrass"
(Display -> shaded map).

Another example, where the RGB/IHS transform is used (i.rgb.his, i.his.rgb)
is resolution improvement of satellite images:

low.res Image I2: high res. pan image high res. image
    
  red ---| |-- I replace |- I2 --| |--- R
           | | | |
  green ---| RGB/IHS |-- H ---------------------| IHS/RGB |--- G
           | | | |
  blue ---| |-- S ---------------------| |--- B
                                     g.region
                                     res change
                                     here

This approach needs low.res multispectral and outputs "high res"
multispectral using the high res. geometrical information and
low res. multispectral color information.

But for above (shaded maps), the d.his approach was much more convenient.

Regards

Markus

3

Markus Neteler wrote:

> > > Any help would be welcome to fix d.his,
> >
> > I'll fix this in a similar manner to d.rgb, i.e. scrap the misguided
> > attempt to generate a composite "RGB" output layer and just display
> > the result of HIS->RGB conversion using R_RGB_raster().
>
> Having looked into this, the name is somewhat misleading:
>
> 1. The "hue" map is only really a hue map if used with a colour table
> such as "rainbow" where all entries have 100% intensity and
> saturation. Otherwise the intensity and saturation values are used to
> scale those provided by the i_map and s_map parameters.
>
> 2. The "saturation" map isn't. An all-black saturation map would
> result in grey-scale output, but specifying an all-black for the
> "s_map" parameter will actually output solid 50% grey. "haze map"
> would be more accurate.
>
> From reading the d.his manpage, I'm assuming that the behaviour is
> correct and the name isn't, so I'll maintain the existing behaviour.
>
> Would there be any value in a program which displays (or converts)
> actual HIS layers? Is HIS ever used for geographical raster data?

thanks for your fixes. Now color quality is as expected (no more odd
dithering). However, unfortunately the "output" option is gone which
is needed - or do you know a different way to store such images?

An example, where this is needed: If you want to create shaded maps
(as done in my example from yesterday), you need the "output" parameter
to store the result. This feature is also implemented in "tcltkgrass"
(Display -> shaded map).

In a previous message I did say that I'd look into producing an r.his
program (there's no reason why generating raster layers should require
a monitor to be running).

Realistically you need three parameters: r_map, g_map, b_map (as per
the i.* programs discussed below).

Generating "colour images" by quantising the colour space into R*G*B
discrete categories is a kludge. Particularly when you have to choose
between substantially truncating the number of levels or ending up
with a 16777216-entry colour table.

It probably didn't matter when the display drivers were limited to
8-bpp, as the process was bound to occur at some point. These days
24-bpp output is common; even 15/16-bpp seems to be limited to
real-time 3D where bandwidth starts to become an issue when 30fps
refresh rates are commonplace.

If this "colour image" kludge is deemed sufficiently important, there
should be a single r.rgb.to.cell (or whatever) program which takes
separate R,G,B layers and produces a CELL map according to
user-specified settings, rather than lots of different programs all
performing their own kludge with their own options while not providing
any way to get 24-bpp (or better; there's no reason to impose a
256-level ceiling apart from during the final display stage where the
human eye becomes the limiting factor).

Actually, if it's that important, it might be worth extending both
"struct Colors" and the functions which operate upon it to support a
quantised RGB colour cube as a special case, so that you wouldn't need
to store 16777216 distinct entries for 24-bpp quantised data (although
you probably don't really need that now; you should be able to use
65536 ranges of 256 colours each).

Another example, where the RGB/IHS transform is used (i.rgb.his, i.his.rgb)
is resolution improvement of satellite images:

[snip]

Presumably this is real HIS (aka HSV, HSB) rather than the "colour,
brightness, haze" fudge which d.his provides? Also, I note that these
programs do use a separate layer for each channel.

Incidentally, this is one area where I could imagine a 256-level
ceiling being a real issue. Can someone with experience of satellite
(or similar) imagery confirm or deny whether data with more than 256
levels exists?

Also, the core RGB<->HSV functionality already seems to be well
handled by the hsv.rgb.sh and rgb.hsv.sh scripts. These use floating
point, so there's no loss of intensity resolution due to quantisation.

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

4

Glynn Clements wrote:

> thanks for your fixes. Now color quality is as expected (no more odd
> dithering). However, unfortunately the "output" option is gone which
> is needed - or do you know a different way to store such images?
>
> An example, where this is needed: If you want to create shaded maps
> (as done in my example from yesterday), you need the "output" parameter
> to store the result. This feature is also implemented in "tcltkgrass"
> (Display -> shaded map).

In a previous message I did say that I'd look into producing an r.his
program (there's no reason why generating raster layers should require
a monitor to be running).

OK; I've committed "r.his". In short:

  r.his h=... i=... s=... r=R g=G b=B
  d.rgb r=R g=G b=B

produces the same results as

  d.his h=... i=... s=...

If this "colour image" kludge is deemed sufficiently important, there
should be a single r.rgb.to.cell (or whatever) program which takes
separate R,G,B layers and produces a CELL map according to
user-specified settings

I'll do this next.

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

From neteler Tue Jun 26 23:13:06 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id XAA27810; Tue, 26 Jun 2001 23:13:06 +0100
Date: Tue, 26 Jun 2001 23:13:05 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Driver Update
Message-ID: <20010626231305.A27722@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
References: <15143.56498.53250.288145@cerise.nosuchdomain.co.uk> <20010614114747.C11308@hgeo02.geog.uni-hannover.de> <15144.45297.673435.379639@cerise.nosuchdomain.co.uk> <20010614161829.B18856@hgeo02.geog.uni-hannover.de> <15145.8392.320239.598657@cerise.nosuchdomain.co.uk> <20010625171204.G18370@hgeo02.geog.uni-hannover.de> <15159.51431.130059.539081@cerise.nosuchdomain.co.uk> <15159.60464.129470.381175@cerise.nosuchdomain.co.uk> <20010626093823.I19099@hgeo02.geog.uni-hannover.de> <15160.51173.144087.254495@cerise.nosuchdomain.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15160.51173.144087.254495@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Tue, Jun 26, 2001 at 06:35:33PM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 3253
Lines: 71

On Tue, Jun 26, 2001 at 06:35:33PM +0100, Glynn Clements wrote:
[...]

In a previous message I did say that I'd look into producing an r.his
program (there's no reason why generating raster layers should require
a monitor to be running).

Sorry, I must have overseen that. Now it is already there, great!

Realistically you need three parameters: r_map, g_map, b_map (as per
the i.* programs discussed below).

Generating "colour images" by quantising the colour space into R*G*B
discrete categories is a kludge. Particularly when you have to choose
between substantially truncating the number of levels or ending up
with a 16777216-entry colour table.

It probably didn't matter when the display drivers were limited to
8-bpp, as the process was bound to occur at some point. These days
24-bpp output is common; even 15/16-bpp seems to be limited to
real-time 3D where bandwidth starts to become an issue when 30fps
refresh rates are commonplace.

If this "colour image" kludge is deemed sufficiently important, there
should be a single r.rgb.to.cell (or whatever) program which takes
separate R,G,B layers and produces a CELL map according to
user-specified settings, rather than lots of different programs all
performing their own kludge with their own options while not providing
any way to get 24-bpp (or better; there's no reason to impose a
256-level ceiling apart from during the final display stage where the
human eye becomes the limiting factor).

Actually, if it's that important, it might be worth extending both
"struct Colors" and the functions which operate upon it to support a
quantised RGB colour cube as a special case, so that you wouldn't need
to store 16777216 distinct entries for 24-bpp quantised data (although
you probably don't really need that now; you should be able to use
65536 ranges of 256 colours each).

> Another example, where the RGB/IHS transform is used (i.rgb.his, i.his.rgb)
> is resolution improvement of satellite images:

[snip]

Presumably this is real HIS (aka HSV, HSB) rather than the "colour,
brightness, haze" fudge which d.his provides? Also, I note that these
programs do use a separate layer for each channel.

Incidentally, this is one area where I could imagine a 256-level
ceiling being a real issue. Can someone with experience of satellite
(or similar) imagery confirm or deny whether data with more than 256
levels exists?

Yes, they do exist: For example the rather new ASTER satellite
(better than LANDSAT-TM from the multispectral view, I think, data
freely available, 15m/30m/90m resolution) provides several
12bit TIR (thermal infrared) bands:
http://asterweb.jpl.nasa.gov/instrument/character.htm

Another: POLDER
http://www.eoc.nasda.go.jp/guide/satellite/sendata/polder_1_e.html

There should be some more and more to be expected in near future.

Also, the core RGB<->HSV functionality already seems to be well
handled by the hsv.rgb.sh and rgb.hsv.sh scripts. These use floating
point, so there's no loss of intensity resolution due to quantisation.

Thanks for pointing this out. The general problem in GRASS is
the odd mixture of old and new code... as we all know already.

Markus

5

Glynn Clements wrote:

> If this "colour image" kludge is deemed sufficiently important, there
> should be a single r.rgb.to.cell (or whatever) program which takes
> separate R,G,B layers and produces a CELL map according to
> user-specified settings

I'll do this next.

I've done this, but can't commit it as the CVS server is currently
either down or unreachable.

I still need to write manpages for r.his and r.composite (less verbose
than r.rgb.to.cell, and mirrors i.composite).

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

6

Markus Neteler wrote:

> Incidentally, this is one area where I could imagine a 256-level
> ceiling being a real issue. Can someone with experience of satellite
> (or similar) imagery confirm or deny whether data with more than 256
> levels exists?

Yes, they do exist: For example the rather new ASTER satellite
(better than LANDSAT-TM from the multispectral view, I think, data
freely available, 15m/30m/90m resolution) provides several
12bit TIR (thermal infrared) bands:
http://asterweb.jpl.nasa.gov/instrument/character.htm

One issue with handling this type of data at present is that raster
layers don't appear to have an associated "full intensity" value.

Consequently, programs which need to coerce the inputs to a unit
(zero-to-one) range (e.g. d.rgb, r.his, r.composite; probably others),
typically use the associated colour table. Unfortunately this only
gives 8 bits of resolution, even if the layer has more than that.

Might it be worthwhile adding a property similar to the range
(G_read_range etc) but which represents the conceptual "zero" and
"one" values?

Another: POLDER
http://www.eoc.nasda.go.jp/guide/satellite/sendata/polder_1_e.html

There should be some more and more to be expected in near future.

> Also, the core RGB<->HSV functionality already seems to be well
> handled by the hsv.rgb.sh and rgb.hsv.sh scripts. These use floating
> point, so there's no loss of intensity resolution due to quantisation.

Thanks for pointing this out. The general problem in GRASS is
the odd mixture of old and new code... as we all know already.

Having said that, all scripts suffer from the drawback that they don't
generally behave like other GRASS programs. I've recently been
thinking about creating a utility specifically for running scripts.

One possibility would be a modified tclsh which includes key libgis
functions (e.g. G_parser) as tcl commands. However, I don't know
whether tcl is sufficiently widely available to be able to justify
using it in place of the Bourne shell.

Another possibility would be a simple utility which could be invoked
by shell scripts to handle the G_parser() stuff before re-invoking the
script with a full argument list (unless "help" or "--int*-desc*" were
used). However, this could still leave incompatibilities between C
programs and scripts in other areas.

Comments?

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