|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-18 20:31:27
|
On Wednesday 17 August 2005 11:43 am, Theo Hopman wrote: > 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. For me the 1st and 3rd plots are indeed identical. Possibly I have a newer version of libgd than you do (2.0.33), but other than that I cannot think why you would see something different. > 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. Ah. You may be right about that. The postscript driver tries to offload the gray->rgb calculation into print-time PostScript code; this makes for a shorter output file but slower evaluation by the postscript device, and apparently introduces an opportunity for substantial roundoff error. So maybe we need to consider one or both of the following changes to post.trm 1) Only some plot styles should use this "optimization". Color assignment for points, say, could be done by post.trm itself just as it is done by gd.trm 2) The run-time/print-time optimization choice could be toggled by a suboption to "set term post", but would continue to apply equally to all plot elements. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |