Re: Explicit rgb colors [was Re: historysize]

[Theo H. <th...@ph...>]

Ethan Merritt wrote:
> I would need to see what you tried in more detail, but I would guess
> another issue may arise here - that of "nearest color" approximations
> done by the output devices or libraries themselves, and hence not really
> under our control.
> 
> 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. 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. As `set term png` says, it's only using 157 palette 
positions for the colourbox. The green channel goes through 256 
oscillations over the cbrange, so the palette sampling is almost certain 
  not to give the desired results. Blue doesn't even bear thinking 
about. Other paletted terminals (postscript, x11) give similar 
undesirable results.

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.

THeo