Re: x11 palette inaccuracy?

[Daniel J S. <dan...@ie...>]

On 09/01/2013 01:32 PM, sfeam (Ethan Merritt) wrote:
> 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.

I think I follow what you are saying, i.e., the approximate_palette 
routine does interpolation with the assumption of Cartesian coordinates, 
not cylindrical coordinates.  That very last "jump" looks like a 
significant change and when linear interpolation is used the algorithm 
picks some colors with hue values way in between "red" and "red" in the 
angular color space.  That sort of explains why the sparkling snow 
effect has a fairly fixed number of colors (blue, yellow) and not some 
random colors.


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

Would there be some way to do the arithmetic in greater than 8 bit and 
truncate?  That is, the table is really something like this:

Fraction Hue
---------------------
0.0000   0f
0.9400   ff
0.9410  100
1.0000  10f
1.0000  10f

for which linear interpolation will still work.  I've got a feeling that 
might not be possible though because that approximate_palette() comes 
after the palette definition.  Is that correct?


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

Shouldn't it be effecting all terminals in the same way if the problem 
lies in the core?  Why is the Qt terminal not showing this?

Dan