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