Re: Explicit rgb colors [was Re: historysize]

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

Ethan Merritt wrote:
> 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.

You are correct. The red dot in the png truecolour terminal disappears 
with these functions definitions. That said, the png truecolour terminal 
does not work correctly under all circumstances. Consider the following:

   set term png truecolor
   set out 'test1.png'
   load 'colour-data.gp'
   set out
   set term png notruecolor
   set out 'test2.png'
   load 'colour-data.gp'
   set out
   set term png truecolor
   set out 'test3.png'
   load 'colour-data.gp'
   set out

One would expect the first and third PNG files to be the same, but 
they're not. The colours are incorrect in the third.

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

But at some point, the Postscript terminal has to decide for itself how 
many palette entries it wants. From my reading of the output file, the 
colours of the dots are determined by a single "gray" value, which has 
only four digits of precision -- clearly not enough to handle 24 bit colour.

[...]

THeo