Re: x11 palette inaccuracy?

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 31 August 2013, Daniel J Sebald wrote:
> On 08/31/2013 04:19 PM, Juhász Péter wrote:
> > Dear gnuplot list,
> >
> > continuing my recent series "exposing possible bugs by fun, useless
> > scripts", here is a nice plasma effect:
> >
> >
> > set term x11
> > set sa 50
> > set isosa 50
> > set pm3d
> > unset surface
> > set view map
> >
> > plasma(x,y) = sin(x/.8)+sin(y/1.6)+sin((x+y)/1.9)
> > pal(t) = sprintf("set pal model HSV functions frac(gray+%f),0.5,1", t)
> > frac(x)= x-int(x)
> > t = 0
> > while(t<10){eval pal(t); t= t+0.01; pr t; splot plasma(x,y)}
> >
> >
> > With the x11 terminal I notice that there is "snowing" on the picture,
> > that is, some of the pm3d rectangles have incorrect color in certain
> > frames. Rounding or accuracy effect?
> >
> > I don't know if this is significant at all, but it doesn't show with the
> > wxt or qt terminals.
> 
> The snow effect appears to happen when the color of the "pixel" is 
> predominantly red.  Assuming the order of the triplet is RGB with red 
> being most significant, it could be that the upper-most palette is 
> incorrect, the index is pointing outside the palatte, or there is some 
> time of sign/unsigned issue unaccounted for, or all of the above.  I'd 
> have to guess it is an end-of-palette issue because otherwise I suspect 
> we'd have seen this issue show up in some other way.

The x11 terminal approximates the color functions by constructing 
a gradient palette and passing that to gnuplot_x11.  
It is screwing up because this palette is in HSV space rather than RGB.
Here is a typical palette gradient that it sends:

 frac      HSV    frac      HSV    ...
 0.0000 0f80ff 0.9400 ff80ff 0.9410 0080ff 1.0000 0f80ff 1.0000 0f80ff

S is always 80, V is always ff.   H varies from 00 to ff.
Extracting only the Hue from that gradent we get:

Fraction Hue
---------------------
0.0000  0f 
0.9400  ff 
0.9410  00 
1.0000  0f 
1.0000  0f

The problem is that between 0.940 and 0.941 it tries to interpolate
from Hue = FF to Hue = 00.   Now in HSV space these represent the same hue,
but the interpolated values between them are very definitely different hues.

The problem lies in the routine getcolor.c (approximate_palette).
It wasn't designed to handle HSV color space.

For the palettes that are generated by this demo, it is obvious to the
eye that gradient break-point at the wrap-around point to be identically
the same rather than  frac - (frac+0.001) would fix the problem.
But it's not obvious to me what that means in terms of changing the
code in approximate_palette().   

Maybe it would be possible to add a post-processing step that is only
called if we are working in HSV space?

I don't know which terminals other than x11 are affected by this.

	Ethan