[GRASSLIST:2265] Re: r.patch -- problem solved

[Glynn Clements]

Rich Shepard wrote:

>   I'll have to read r.colors again until I fully understand this. Looking at
> one of the files in colr/, I see this:
> 
> [rshepard at salmo colr]$ less temp_dem
> % 1200 2721.300048828125
> 1200:255:85:85 1453.550008138:170:170:0
> 1453.550008138:170:170:0 1707.100016276:85:255:85
> 1707.100016276:85:255:85 1960.6500244141:0:170:170
> 1960.6500244141:0:170:170 2214.2000325521:85:85:255
> 2214.2000325521:85:85:255 2467.7500406901:170:0:170
> 2467.7500406901:170:0:170 2721.300048828125:255:85:85
> 
>   It looks to me that there are 12 colors and each is assigned to a range of
> values, the lower bound of which is specified? The range of elevation values
> here (I believe in meters) is on the first line.

The above describes a piecewise continuous mapping from elevation to
RGB. Each line describes a range, with any elevation within that range
being used to linearly interpolate between the start and end colours.

> FWIW, I had nlev=256 set for this display.

Is this with 5.0pre1? That should ignore nlev, and use the full range
of the display. Older versions of XDRIVER clamp nlev to 32.

Shortly after 5.0pre1 was released, I modified D_set_colors() to clamp
the number of colours used for an RGB colour cube to 2^15 (i.e. 32
levels per component). Otherwise, FP maps would attempt to define 2^24
discrete colours; this caused a significant delay before anything was
rendered, and increased XDRIVER's memory consumption by about 60Mb.

If you are:

a) rendering an FP map, and
b) using 5.0pre1, and
c) using a 24-bpp display,

then you should experience the delay and the memory consumption. 
Otherwise, one of the above conditions doesn't hold (it may be that
there's more than one "5.0pre1" version).

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