[GRASS5] i.composite problems verified

[Glynn Clements]

Eric G. Miller wrote:

> > What kind of operations might be performed upon the resulting layer? 
> > >From what I can tell, GRASS seems to be oriented towards handling
> > either scalar quantities or discrete categories. The cell values
> > resulting from i.composite certainly aren't scalars, and as categories
> > they don't really have much meaning.
> 
> Purpose would mostly be for display and map making.

For display, there's already d.rgb; I don't know about paint drivers.

> > AFAICT, GRASS would be much happier if the data was just kept as three
> > separate channels. For the future, it might be worth considering a
> > mechanism whereby all applicable GRASS operations would be able to
> > handle "groups" of layers, so you wouldn't need to triplicate
> > commands.
> 
> Yes.  I think GRASS needs a generic method for handling image types
> where the cell values denote the colors rather than having a separate
> lookup.  I looked around the color table functions in libgis, and if
> there was a way to squeeze in a color rule of type RGBENCODED (for
> instance) and a way to associate a function for "parsing" a cell value
> into red, blue, and green parts, then I think most modules could go
> unchanged after a recompilation.  It'd take some reorganizing of the
> color rule functions though...

Again, this sounds like the square-peg-round-hole scenario. The
existing "colour table" stuff seems oriented towards enabling visual
interpretation of categories or scalar values (d.legend and stuff).

If the notion of a "cell" is to be extended to vector data, it strikes
me that it may as well be aimed at the arbitrary N-channel case
(i.tape.tm implies that LANDSAT data may have 7 bands).

That leads on to the question of whether it would be better to have
"vector cells", or "layer groups" (i.e. whether the bands are separate
or interleaved pixel-by-pixel).

> > Is this a just a kludge for getting around the fact that the r.out.*
> > commands which generate image formats can't read multiple channels
> > (similar, well opposite, to r.in.ppm's "-b" switch)?
> 
> Problem is to use color imagery in everyday GRASS display and map
> making.  Say I want to use a color composite for a back drop to
> v.digit.  I don't want some crappy 8-bit color, but 24-bit color.

Can't d.rgb handle that? [OK; d.rgb appears to have been omitted from
the release; but the manual page is still there. I will look into this
ASAP].

> As an aside, I had previously looked at how the XDRIVER handles
> TrueColor visuals and its colormap.  It seems to me there should be a
> way to bypass the allocation of a colormap if a TrueColor visual is
> present (the red, green, blue components passed for pixel values should
> map directly to the TrueColor visual).  Having the XDRIVER allocate a
> colormap of 256*256*256 colors is an extreme use of memory.  I couldn't
> quite figure out how to get the color functions to do this in the
> XDRIVER...

I suspect that the problem is that certain programs assume that the
monitor has a limited set of colours. It would appear that this was a
safe assumption until recently. The only real problem with writing a
driver which supports 24-bit RGB is that it might break existing
clients.

Any fix would needs to start with a decision that a driver does not
have a limited set of colours, and that any client which assumes
otherwise is broken. Once that's done, writing a true RGB driver is
simple.

[Note: I don't know this for a fact; the colour model is one thing
that I've steered clear of so far; but, from what I can tell, it looks
that way.]

> > Multi-channel data can already be displayed on the monitor with d.rgb;
> > Is there any equivalent for the "paint" driver?
> 
> d.rgb does something similar to i.composite,

When I wrote that, I hadn't noticed that d.rgb can also output a
composite layer. I was referring to it purely in the context of
actually displaying the data. (I hadn't noticed it had been removed,
either ;) ).

> though it builds in a limit
> on the number of color levels (10 per band, I think).

Which presumably derives from having explicit colour tables. 

> I believe
> i.composite also uses a histogram for each band individually, which I
> think produces crummy color images in addition to the colormap limits.

IMHO, any actual solution to these limitations has to avoid colour
tables altogether. Even if you can afford to use a colour table with
2^24 entries, that isn't necessarily enough. 256 levels may be enough
to satisfy the human eye, but it seems quite conceivable that raster
data could have more levels.

My take is this: right now, GRASS has no real support for
multi-channel data; all that it does have are:

a) some hacks which create a large number of discrete categories and
an equally large colour table, and

b) the ability store and process each channel separately.

In terms of adding multi-channel support, b) looks like a better
foundation on which to build. 

The raster library does have an R_RGB_raster() operation, although
presently this is implemented (in the generic driver code) by
converting to colour indices.

I will look into:

a) Having XDRIVER implement R_RGB_raster() natively on a TrueColor
display.

b) Getting d.rgb back into the release, and supporting a).

c) Getting r.out.ppm to support writing three layers as an RGB image,
analogous to 'r.in.ppm -b' (maybe some other formats as well, but PPM
is the easiest case).

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

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'