rgb 24 bit

[Markus Neteler]

> I've been testing the new 24bit display.
> 
> First at all, thanks to Roberto Flor 
> as this is a mjor concern for 
> integrating rs imagery in GIS analysis.
> 
> My conclusion is that there is a very significant improvement, but
> the results would be much better if we could use a d.rgb able
> to generate at least 32^3=32768 colors instead of the
> 10^3=1000 colors that d.rgb or i.composite generate.
> I might be wrong, but it seems to me that this improvement would
> be much simpler that the XDRIVER-24bit development, would'nt it?
> 
Dear Agus, dear Community,

sorry for talking so much in this forum, but an important
information you should know related to this problem:

GRASS becomes incredible slow when having more than
about 2500 categories (colors). The reason might be
(I am not an X11 programmer) that the color association
to categories takes so much time as it has to be done
iteratively.

To overcome this problem only "color optimization" could
help. Stefano Merler already did like this when updating
r.in.ppm to 24bit (GRASS 5beta3). As far as I know the "xv" 
image viewer uses such color optimization as well to speed 
up displaying images.
So we would need a mechanism comparing to this: 
Reducing the color table on the fly while *displaying* an image 
(here equal to raster map) if having more than 2500 categories
in the raster map. 
In new r.in.ppm it is already coded that huge number of the 
colors will be reduced to a smaller color table using the 
closest colors (in our 24bit test images the reduction was 
from 10 minutes down to 4 seconds).

Suggestion: Perhaps there should be a change in the GRASS 
library to quantize the colors on the fly in all d.* commands.
That might be better than reducing the colors (categories)
when importing an image.

So far my knowledge related to this 24bit problem,

cheers

  Markus Neteler