[GRASSLIST:5570] Re: i.composite problem: gives minmax 1:1, grass5

[Glynn Clements]

Philipp Molzer wrote:

> > > Thanks. Unfortunately, d.rgb gives me an image with quite bizarre 
> > > colors.
> > 
> > Then you probably need to do:
> > 
> > for i in 1 2 3 ; do
> >   ( echo 0 black ; echo 255 white ) | r.colors map=294.JPG.$i color=rules
> > done
> > 
> > r.in.gdal really ought to set a colour table, but it doesn't.
> 
> That did the trick!
> Now with
>     IMG=294.JPG
>     d.rgb red=${IMG}.3 green=${IMG}.2 blue=${IMG}.1
> g.rgb now produces a very nice looking image.  Just what I wanted.
> 
> i.composite now also works, so the d.rgb must have been a prerequisite 
> for that.  
> 
> However, the image
> quality of the composite as displayed with d.rast, is not as good as 
> that from d.rgb.  I tried color levels
> between 10 and 40 for i.composite, none of which produces an image with 
> the subtle gradation of colors
> displayed by d.rgb.  My computer really bogs down at 40 color levels.
> 
> Is it possible to produce a composite raster file with visual quality 
> the same as that from d.rgb?

Not really. First you would have to construct a composite raster with
256 levels per component; while this is possible, it is normally
impractical. Second, even if you do that, d.rast won't actually use
that many colours, as the underlying display library imposes a limit
of 32 levels.

The only practical ways to process colour imagery in GRASS are:

1. Quantise the data to at most 32 levels (5 bits) per component (i.e.
15-bpp, 32768 colours), and accept the loss of colour resolution, or

2. Keep the data as separate red/green/blue layers.

I did a fair amount of work to make option 2 practical; there are
modules to import ("r.in.ppm -b", r.in.png, r.in.tiff), export
(r.out.ppm3), display (d.rgb) and print (ps.map, "rgb" command) data
which is in this format. AFAIK, the only situation where you have to
generate a composite layer is for use as a colour layer in NVIZ.

I looked into making option 1 practical; the main problem was the way
in which the monitors (e.g. XDRIVER) handle raster data. Without the
32-level ceiling, the monitors would have to allocate a lookup table
with 16 million entries, which consumes 64Mb of memory, and adds a
substantial delay (~20 seconds on a PIII/800) to d.rast etc.

BTW, if you do need to generate a composite layer, r.composite might
do a better job than i.composite. r.composite creates the colour table
using range rules (e.g. N*N rules of N colours each), whereas
i.composite uses individual colours (e.g. N*N*N colours), which will
result in massive colour tables if the number of levels is large.

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