gnuplot-beta

Re: Explicit rgb colors

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

On Wednesday 17 August 2005 11:16 am, Theo Hopman wrote:
> Theo Hopman wrote:
> 
> Meh...this doesn't work as well as I think it should. The various 
> paletted terminals agree better now, but the colours are still wrong, 

After mulling things over in my head last night, I think Theo's
approach, clever as it is, is the wrong way to go.  Drivers which
are capable of rgb output already support a mechanism for requesting
specific rgb triples.
	t_colorspec *color;
	color->type == TC_RGB;
	color->lt =  24_bit_packed_rgb_triple;
	term->set_color(color);

What we are missing is a way to select this method of color generation
rather than the usual pm3d palette functions.

We should expand the syntax for "with" to provide an alternative
in parallel to "with palette".  Something like
  splot <foo> 1:2:3:4 with palette    # Takes gray value from $4
  splot <foo> 1:2:3:4 with rgb        # Takes packed rgb triple from $4

We already have such a keyword for specifying individual line styles,
text styles, etc.  Extending it to the overall plot style seems both
obvious and easy to do.  The input routine in df_readline() should
handle packed hexadecimal values as is, so data files can look like:

#   X   Y   Z   RGB
#=========================
  255   0 255   0xFF00FF
    0 127   0   0x000f00


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

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

Re: Explicit rgb colors [was Re: historysize]

[Juergen W. <wie...@fr...>]

On Wednesday 17 August 2005 20:08 Ethan Merritt wrote:
> On Wednesday 17 August 2005 10:09 am, Theo Hopman wrote:
> > 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.

This is what I understand:

The "nearest colour" approximation is done with the gray value,
not with the colour itself:  The gray value is first rounded and
then mapped to an rgb value.

This is OK as long as it is used as designed:  Show values of one
continuous range.

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

If I remember the postscript colour handling correctly, the
Postscript terminal does the "nearest colour" approximation itself.
At least for "palette rgbformulae": The needed functions are put as
formulaes into the postscript file and evaluated while
displaying/printing the file.  Reporting an infinite number of
palette entries probably means the terminal does the mapping.

This means that the postscript file generally contains the gray
values and a rule how to map this onto colours.  I'd expect "palette
functions" to save an interpolated table into the output file.


Juergen

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

Re: Explicit rgb colors [was Re: historysize]

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

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

Re: Explicit rgb colors [was Re: historysize]

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

On Wednesday 17 August 2005 12:03 pm, Ethan Merritt wrote:
> 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.

Just to prove the point - 

The small patch below forces the gray->rgb conversion to happen in the
driver, rather than in the PostScript code.  With this patch in place,
the postscript output looks the same as the png truecolor output.

diff -ur gnuplot/term/post.trm gnuplot-cvs/term/post.trm
--- gnuplot/term/post.trm       2005-08-07 18:21:52.000000000 -0700
+++ gnuplot-cvs/term/post.trm   2005-08-17 16:03:53.408922728 -0700
@@ -3371,7 +3371,16 @@
        if (gray >= 1)
            fputs("1 g ", gppsfile);
        else
+#if (0)
            fprintf(gppsfile, "%s g ", save_space(gray));
+#else
+       {
+           rgb_color color;
+           rgb1_from_gray(gray, &color);
+           fprintf(gppsfile, "%5.3f %5.3f %5.3f setrgbcolor ",
+               color.r, color.g, color.b);
+       }
+#endif
     }
     PS_relative_ok = FALSE; /* "M" required because "g" forces stroke (??) */
 }



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

Re: Explicit rgb colors [was Re: historysize]

[<mi...@ph...>]

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

This scheme with 4 digits is enough for continous pm3d maps. It should
stay as is, as for large maps, every byte written to the datafile counts
(nb of points)-times.

An easy fix would be to extend the precision if "set palette maxcolors" is
larger than 1e4.

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

Or some new call like term->set_palette(be truecolor).
Or term->set_trucolor(rgb_or_cmyk_, r, g, b, k) to bypass the current
set_palette+set_color mechanism.

---
PM

Re: Explicit rgb colors [was Re: historysize]

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

On Friday 19 August 2005 07:06 am, mi...@ph... wrote:
>
> Or some new call like term->set_palette(be truecolor).

term->set_color() already handles this.

The trick is to have the core routines set the TC_RGB flag rather
than the pm3d/gray flag TC_FRAC.
See patchset uploaded to SourceForge.