I guess this is a two-part question: 1) What is the maximum number of colors
representable in an x-monitor/tcltk canvas, and 2) How many colors are
stored in a raster color table from a raster that was gridded within Grass
(i.e., xyz data)
Thanks,
~ Eric.
I guess this is a two-part question: 1) What is the maximum number of
colors representable in an x-monitor/tcltk canvas, and 2) How many
colors are stored in a raster color table from a raster that was
gridded within Grass (i.e., xyz data)
d.info -c
or
d.mon start=x1
should tell you the number of colors used in a x monitor
$MAPSET/colr/$MAP holds the color rules. Usually color is interpolated
from a few set tie points. e.g. 0% black 4 red 100% blue
see the r.colors help page.
Wild guess as to why you are asking this:
your output looks like it has like 256 contoured bands when you think it
should be (perceivably) continuous. try this:
r.mapcalc 'elev_int=int(elev)'
r.colors elev_int rast=elev # maybe redundant
d.rast elev_int
[mult the DCELL map by 10000 before int() if decimal places are significant]
is it now smooth?
For some reason I don't understand, floating point maps don't do smooth
color transitions. On the other hand I have used this "feature" on
occasion to enhance a raster map hardcopy (sometimes you want the subtle
contour lines).
I tried to document this ~1-2 years ago I think. If interested search
through the mailing list archive or the bug tracker for the post.
commonly seen: scale a lat/lon SRTM map to 1:1:1 XYZ for NVIZ by dividing
elev map by 60*1852. set some colors with r.colors and then d.rast both
original CELL and new DCELL maps.
or maybe you are seeing big white splotches? do this:
r.color map rules=rainbow
anything beyond the color rules' range gets turned white; sometimes the
map range is increased but the colors file is taken from a narrower
map.
Hamish
Hamish wrote:
For some reason I don't understand, floating point maps don't do smooth
color transitions.
If you look at G_get_color_range() in lib/gis/color_range.c, for FP
maps, it returns +/- 255^3 for the min/max values.
Moving on to lib/display/raster2.c, D_set_colors() calls
D_check_colormap_size(), which checks whether the number of colours
supported by the driver is sufficient for the range returned by
G_get_color_range().
If there are sufficient colours, it uploads a colour table to the
driver such that each category has its own colour table entry.
For an FP map, it wants 2 * 255^3 + 4 = 33162754 colours, which is
more than the 16777216 colours provided by a 24-bit display. In this
case, it uploads a colour cube which fits within the number of colours
provided by the driver, clamped to a maximum of 32 levels per
component (i.e. 32768 colours, or 15-bpp).
IOW, the colour handling in libdisplay was designed for colour-mapped
displays and integer maps. Support for FP maps and true-colour
hardware has largely been bolted on as an afterthought.
OTOH, it's constrained by the fact that uploading a 16777216-entry
(24-bpp) colour table to the driver isn't particularly practical (for
a start, it will cause the driver to consume an extra 64MB of RAM, as
well as being rather slow).
[If you want to test this case, create an integer map with just under
2^24 categories (e.g. using "r.composite ... levels=256", but ensure
that it doesn't actually use #FFFFFF, as the +4 in
D_check_colormap_size() will take it over the limit), then display it
with d.rast. Note the time taken and the memory used by the driver.]
One solution would be for libdisplay to use D_draw_raster_RGB() if the
driver supports >=32768 colours (i.e. it's using true-color). This
eliminates the need to upload a large colour table; instead, you
upload separate R/G/B translation tables, each of which would have 256
entries (256 * 3 is much smaller than 256 ^ 3), and send the raster as
separate R/G/B components rather than a composite index.
Another option would be to sample the map's colour table rather than
using a colour cube. A colour table is a piecewise-linear curve in a
3-dimensional space. Unless it's a space-filling curve (Sierpinski,
Hilbert etc), and it probably isn't, a colour cube is a very
sub-optimal choice.
The latter is more work, but would also provide improvements on
colour-mapped displays. OTOH, are colour-mapped displays still
relevant nowadays? Removing support for them would make the display
architecture (libdisplay, libraster, monitor drivers) so much simpler.
--
Glynn Clements <glynn@gclements.plus.com>
These are actually related questions...I think.
A TclTk canvas can use a full color RGB image (16 million). I'm not sure
about an x-monitor (but see below).
The PNG driver for GRASS is the one used for the TclTk canvases in the new
GIS Manager. It can be set to a low index color setting or a "true color"
setting (the one used by default for the GIS Manager). I think the latter is
32 bit (please correct me someone if this is wrong). It looks to my eye that
an x-monitor can display the same number of colors.
The color table does not store colors per se. It stores a reference to
colors. For a continuous shade map, like an elevation map, it stores
reference points along a color continuum and GRASS seems to generate the
intermediate gradations. You can look at the color table in a mapset. It is
just an ascii file.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: "Patton, Eric" <epatton@nrcan.gc.ca>
Date: Mon, 27 Mar 2006 10:06:48 -0400
To: "'GRASSLIST@baylor.edu'" <GRASSLIST@baylor.edu>
Subject: [GRASSLIST:416] Maximum number of colors in rastersI guess this is a two-part question: 1) What is the maximum number of colors
representable in an x-monitor/tcltk canvas, and 2) How many colors are
stored in a raster color table from a raster that was gridded within Grass
(i.e., xyz data)Thanks,
~ Eric.