Re: Explicit rgb colors [was Re: historysize]

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

On Wednesday 17 August 2005 07:04 am, Theo Hopman wrote:
> > 
> >   rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
> >   r(gray)=int(2.**24*gray)/65536/256.
> >   g(gray)=int(2.**24*gray)%65536/256/256.
> >   b(gray)=int(2.**24*gray)%256/256.
> >   set palette color model RGB functions r(gray),g(gray),b(gray)
> >   set cbrange [0:2.**24-1]
> >   unset colorbox
> >   splot 'colour-data.txt' using 1:2:3:(log($4)) \
> >       with points pointtype 6 pointsize variable lc("black"), \
> >     '' using 1:2:3:(rgb($1,$2,$3)) \
> >       with points pointtype 7 palette
> 
> Grr. This works in theory, but not in practise, and the (wrong) results 
> are different on different terminals. I suspect that the rapidly varying 
> rgb() function is being sampled at a relatively low frequency to get a 
> limited set of grey values. The binning of the rgb() values causes wrong 
> (encoded) gravy values to be given to the r(), g() and b() functions, 
> resulting in incorrect colours -- red is almost right, but green is 
> wrong, and is useless.

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?



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