[GRASS5] Driver Update

[Glynn Clements]

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