gnuplot-beta

x11 palette inaccuracy?

[Juhász P. <pet...@gm...>]

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.

Peter

Re: x11 palette inaccuracy?

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

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.

OK, I finally broke out of the hypnotic trance...

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.

Dan

Re: x11 palette inaccuracy?

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

On 08/31/2013 04:52 PM, Daniel J Sebald wrote:

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

I conflated a couple concepts there: RRGGBB wouldn't be a palette lookup 
sort of thing.  This is palette-based so I'm going to guess indexing 
outside the palette, i.e., some rounding effect puts the palette index 
one past the last value and a range check is missing.

The best place to watch is the colorbar.  It is always the same color 
that has the incorrect shade.

Dan

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

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

Re: x11 palette inaccuracy?

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

On 09/01/2013 03:04 PM, Ethan Merritt wrote:
>
>     >  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
>
>
> The demo actually uses a palette of functions, not gradients. Most
> terminals calculate a pixel color directly from the functions.  But
> there is no way to pass the function definitions to gnuplot_x11, so
> instead the code in x11.trm pre-calculates a gradient by sampling the
> functions, and passes the gradient to gnuplot_x11.   I haven't looked to
> see if any other terminals do this also.

Ah...  It appears to be only the gnuplot_x11 terminal requiring the use 
of color function interpolation as:

#ifndef GPLT_X11_MODE
     case SMPAL_COLOR_MODE_FUNCTIONS:
	calculate_color_from_formulae(gray, color);
	break;
#endif /* !GPLT_X11_MODE */

I wonder if in this function:

calculate_color_from_formulae(double gray, rgb_color *color)

where the three components are computed whether the type of 
interpolation, linear or angular, can be controlled.

I'm still not sure that will work (it might).  The functions have to be 
retained post interpolation.  Once the function values are computed, 
doing interpolation has no assurance of selecting the user's desired 
result.  We can only assume that the user wants the interpolation with 
lowest frequency.  That is, perhaps the user gave commands to create the 
snow effect and that was his desired result.

Dan

Re: plasma demo, was: x11 palette inaccuracy?

[Bastian M. <bma...@we...>]

Am 31.08.2013 23:19, schrieb Juhász Péter:
> Dear gnuplot list,
>
> continuing my recent series "exposing possible bugs by fun, useless
> scripts", here is a nice plasma effect:
>

Nice one!  To improve the animation speed, I checked wether using "with 
image" instead of pm3d would help.  Tests were done without the colorbox 
and key using the wxt terminal on Windows 8.  Here are my results:

   pm3d:  28 fps
   with image:  40 fps
   with image + refresh:  162 fps

Using the pseudofile '++', we can actually reuse the plot data with 
"refresh".  You can find the updated script below.

   Bastian


----
reset
set sa 50
set isosa 50
set xrange [-10:10]
set yrange [-10:10]
unset colorbox
unset key

bind "Escape"      "t = 10"

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
start = time(0.)
eval pal(t)
plot '++' using 1:2:(plasma($1,$2)) with image
while(t < 3){
	eval pal(t)
	t = t + 0.01
	pr t
	refresh
}

print sprintf("%.2f frames/second", t/0.01 / (time(0.) - start))
reset bind
----



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