[GRASS5] Driver Update

[Markus Neteler]

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