Re: Explicit rgb colors [was Re: historysize]

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 17 August 2005 10:09 am, Theo Hopman wrote:
> Ethan Merritt wrote:
> > Could you try your test case for these two output settings:
> > 
> > 	set term png
> > 	set term png truecolor
> > 
> > and see if it makes a difference?
> 
> Done. See the attached files. Notice the truecolor option gives almost 
> correct results, except for the glaringly obvious red dot which should 
> be white. 

I think your color functions are not quite right.  The color encoding for
each channel runs from 0->255, not 1->256.  I think you end up with red
because the green and blue components wrap around to 0 since they 
cannot be 256.

Try:
r(gray)=int(2.**24*gray-1)/65536/256.
g(gray)=int(2.**24*gray-1)%65536/256/256.
b(gray)=int(2.**24*gray-1)%256/256.


> 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.

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".

 
> I can conceive of a possible workaround: rather than encoding colours as 
> rrrrrrrrggggggggbbbbbbbb, they could be encoded as something like 
> grbgrbgrbgrbgrbgrbgrbgrb, so that the MSBs of the green and blue 
> channels are not lost in palette sampling. I'll give this a shot sometime.

Since (I think) truecolor png does work, I think this demonstrates that
your approach is valid.  We may have to tweak the palette code in other
drivers, but since we have a working one to guide us that should be
possible.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195