[GRASS5] Re: 5.3 vs 5.7 disparity

[Glynn Clements]

Hamish wrote:

> > > > > > > d.erase is now updated, including support for color=R:G:B.
> > > > > > Should Derase() be changing the driver's colour table?
> ...
> > Also, I've just noticed that it is reset to match the standard colour
> > table by R_color_table_fixed(). Similarly, the hardware palette is
> > similarly reset by R_color_table_float(). These two functions are used
> > by d.colormode.
> [...]
> > comment in the d.colormode manpage:
> > BUGS
> >        It  is strongly recommended that the user erase the graph­
> >        ics monitor screen (e.g., by running d.erase)  immediately
> >        after changing the mode between fixed and float.
> 
> Shall we change d.colormode to do this automatically?

No; that would mean that there was no way to change the mode without
erasing the screen.

> Or at least have it issue a warning?

Probably not. Most users won't ever use d.colormode; presumably those
who do will know what they're doing.

In any case, I'm not sure how relevant d.colormode really is nowadays. 
Have you tried using a 256-colour display recently? Anything more
fanciful than an xterm will probably start by popping up a pretty
splash screen which consumes the entire colourmap on the spot.

I'm not even sure that floating colour mode still works correctly; I
did as much testing as I could when I re-wrote XDRIVER's colour
handling (back in May 2001), but there may well be cases which have
been overlooked. I doubt that it gets much "real-world" testing these
days.

> > > > However, the entries may be changed using R_reset_color() and
> > > > R_reset_colors(). R_color() selects colours from this table, as do
> > > > the R_raster* functions.
> > > 
> > > What I am concerned with is instead of resetting the 14th of 13
> > > colors, as intended,
> > 
> > Actually, the standard colour table has 15 entries (0 to 14); I have
> > no idea why, as only entries 1 to 13 are used, and there is no way for
> > clients to modify entries.
> > 
> > > I've actually reset color 14 of say 256 or 65536,
> > 
> > Yep; although, that is better than resetting any of colours 1 to 13,
> > given the behaviour of R_color_table_{fixed,float}, and the comment in
> > the d.colormode manpage
> 
> So for picking an arbitrary number, maybe 14 and 15 aren't so bad after
> all, as it may not be a good idea to assume the color table will be >256,
> e.g. for use on a 4-bit display. Better not to use 255 anyway.

Well, XDRIVER itself should actually work on a 1-bit display, although
I'm not sure that you would be able to do anything useful with it.

BTW, in fixed colour mode, the number of colours in the ("other", as
opposed to "standard") colour table isn't limited by the display
depth. You could still define 1000 colours on a 1-bit display, but
they would all be either black or white (whichever is closest to the
specified R/G/B triple).

> (15 is used when there are both custom foreground and background colors)
> 
> ... I've got a 1-bit NCD X-terminal here (ncolors=2), and d.erase works 
> correctly there: color=127:127:127 -> black, color=128:128:128 -> white.
> 
> Is the color table always going to be 256*256*256 long, or is it created 
> at run-time based on the color depth with colors pulled from 0-1,0-1,0-1 
> and translated on the fly?

The standard colour table always has 15 entries, of which 1-13 are
explicitly set (0 and 14 will always be black).

The fixed colour table is unlimited[1] in both directions (negative
numbers are allowed).

The floating colour table is limited by the hardware palette (and is
only applicable on displays which actually have a hardware palette,
i.e. PseudoColor and GrayScale visuals).

BTW, there is also another level of colour translation within XDRIVER,
but that shouldn't be at all visible to clients.

[1] Well, it's limited by memory: drawing 24-bit rasters by setting a
16-million-entry palette definitely works; after I extended XDRIVER to
correctly report 2^24 colours on a 24-bit display, I had to change
D_set_colors() not to try to actually define that many colours, as
doing so results in XDRIVER using >64Mb of memory.

> shrug
> I guess we should check for color blips on a smooth color transition
> with d.legend or a map made with r.cost, but otherwise I guess I'll leave 
> it as is.

On the subject of smooth colour transitions:

For integer rasters, if there are fewer categories than the number of
monitor colours (as reported by R_get_num_colors()), that number of
colours will be defined (using R_reset_colors()).

If there are more categories than the monitor has colours,
D_set_colors() allocates the largest colour cube which will fit within
the reported number of colours (up to a maximum of 32^3 (32768
colors), to limit the driver's memory usage).

For floating-point maps, G_color_range() reports a range of -255^3 to
255^3, which will always exceed the value reported by
R_get_num_colors(), and so will again result in the use of a colour
cube.

Given the nature of raster colour tables, a colour cube isn't really
an appropriate mechanism. It will typically result in colours being
allocated to regions of the colour cube which are never used, at the
expense of regions which are used. [Ironically, this means that
floating-point rasters will usually have worse colour resolution than
integer rasters.]

E.g. most of the standard colour tables (in the sense of "r.colors
color=...") only use highly saturated colours, which form a path along
the edges around the middle of the colour cube. Distributing the
available colours along the path corresponding to the colour table
(whether evenly, or biased according to the map's histogram) would
provide a much better fit.

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