[GRASS5] i.composite problems verified

[Eric G. Miller]

On Sat, Apr 28, 2001 at 11:12:42PM +0100, Glynn Clements wrote:
> 
> Eric G. Miller wrote:
> 
[snip]
> > Looking at a running version of i.composite, I see the gen_colors()
> > routine near the end calls G_set_color() for the number of color levels
> > set. This eventually results in a call to add_color_rule() in libgis
> > (color_rule.c).  Within add_color_rule, there's a loop that iterates
> > through all of the color rules in order to remove duplicates.  So, as
> > the number of color levels is increased for i.composite, running time
> > increases by n^3 or some such.  I suppose it eventually will finish even
> > for large color rule sets, but there should be no need for the pruning
> > to begin with.  However, I don't see any color rule function in
> > color_rule.c that doesn't end up calling add_color_rule().  Maybe we
> > need some color rule functions that don't check for duplicates?
> 
> What purpose does i.composite serve?

It tries to make a color composite image...

> Trying to merge multi-channel raster data into a single channel by
> creating a colour table with N^3 entries seems, to me, to be a classic
> case of square-peg-round-hole syndrome.

Agreed.

> 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.

> 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...

> 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.

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...

> 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, though it builds in a limit
on the number of color levels (10 per band, I think). 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.

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

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