Re: Explicit rgb colors [was Re: historysize]

[Juergen W. <wie...@fr...>]

On Wednesday 17 August 2005 20:08 Ethan Merritt wrote:
> On Wednesday 17 August 2005 10:09 am, Theo Hopman wrote:
> > The non-truecolor option gives erroneous results, which I
> > don't think are related to "nearest colour" approximations: for small
> > values of (x,y,z) = (r,g,b) we should be getting dark dots, not
> > relatively bright green and blue ones, even if a nearest colour was
> > being used.

This is what I understand:

The "nearest colour" approximation is done with the gray value,
not with the colour itself:  The gray value is first rounded and
then mapped to an rgb value.

This is OK as long as it is used as designed:  Show values of one
continuous range.

> The "nearest colour" calculation produces very strange results. I ran
> into this problem before. But never mind that. Clearly if you want to
> specify arbitrary rgb triples, the terminal should be in full rgb mode
> (TrueColor).
>
> > Other paletted terminals (postscript, x11) give similar
> > undesirable results.
>
> This puzzles me, however.  PostScript is paletted in a sense,
> but it reports back to the core that it has an infinite number of
> palette entries. I would have expected "set term post color" to
> produce essentially the same result as "set term png truecolor".

If I remember the postscript colour handling correctly, the
Postscript terminal does the "nearest colour" approximation itself.
At least for "palette rgbformulae": The needed functions are put as
formulaes into the postscript file and evaluated while
displaying/printing the file.  Reporting an infinite number of
palette entries probably means the terminal does the mapping.

This means that the postscript file generally contains the gray
values and a rule how to map this onto colours.  I'd expect "palette
functions" to save an interpolated table into the output file.


Juergen