[GRASS5] i.composite problems verified

[Glynn Clements]

Eric G. Miller wrote:

> > I have verified that there is a problem on Linux with i.composite.
> > 
> > I can run i.composite on an image group, and it will run forever, LONG
> > after the output has been generated.
> > 
> > Every thing _seems_ to be ok after you force the software to exit.
> > 
> > Problems: i.composite will not exit after completeing output.
> > 	: continues to consume processesor time after output has been
> > completed.
> > 
> > Any ideas on why this might be?
> > 
> > I have looked at the generated output in every way I can think of, and
> > have seen no errors. It does not seem to be incomplete in anyway.
> 
> 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?

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.

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.

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.

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)?

Multi-channel data can already be displayed on the monitor with d.rgb;
Is there any equivalent for the "paint" driver?

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