[GRASS5] i.composite problems verified
Eric G. Miller
egm2 at jps.net
Sun Apr 29 01:55:44 EDT 2001
On Sat, Apr 28, 2001 at 11:12:42PM +0100, Glynn Clements wrote:
> Eric G. Miller wrote:
> > 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.
> 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
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
> 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'
More information about the grass-dev