[manual] suggested addition to pcolor description

[Ben Abbott]

On Feb 2, 2009, at 6:06 PM, Petr Mikulik wrote:

>>>> | On caveat is that gnuplot's method of interpolation is different
>>>> | than that of Matlab's. As Francesco points out the commercial
>>>> | variant splits rectangles into a pair of triangles and performs a
>>>> | linear interpolation of the color across the triangle. Although  
>>>> I do
>>>> | not know what algorithm is used, gnuplot does not work the same  
>>>> way.
>>>>
>>>> Is this something that Octave should do, rather than relying on
>>>> gnuplot?  If so, where does this code belong?  Maybe we should  
>>>> provide
>>>> a function (accessible from C++ and the scripting language?) that  
>>>> does
>>>> the interpolation, so that all backends can do things consistently.
>>>
>>> In 2007, I noticed that even matlab behaves differently depending on
>>> platform (linux, windows) and renderer (OpenGL, ...) when plotting
>>> polygons. But I have not verified if its still true. Also, OpenGL  
>>> does
>>> this interpolation with hardware acceleration, so we would waste a  
>>> lot
>>> of graphic performance in this case.
>>
>> I studied the situation more closely and noticed that gnuplot  
>> appears (to me)
>> to interpolate colors by increasing the density of the facets by  
>> four. The
>> color of facets appear to snap to the nearest color in the colormap.
>>
>> If anyone is running a copy of gnuplot with the patch for  
>> interpolating color
>> as a 4th dimension, you can examine this by
>>
>> 	[x,y,z] = peaks(10);
>> 	pcolor([x,y,z])
>> 	shading interp
>> 	shading faceted
>
> I think a better comparison would be
> 	shading flat
> 	shading interp
>
>> In any event, I agree with Kai. The backend should handle this.  
>> Regarding
>> Octave's gnuplot backend, I don't see anything that Octave should do
>> differently.
>>
>> I've copied Petr in the event my inference regarding the gnuplot
>> implementation is in error ... or in the event he has some insight  
>> as to the
>> possibility of modifying the behavior of gnuplot.
>
> Gnuplot does interpolation in pm3d by splitting each quadrangle into  
> smaller
> quadrangles. You can try the following example that demonstrates
> "shading flat" and "shading interp":
>
>
> figure(1)
> pcolor([1 2; 3 3])
> shading interp
> drawnow ('x11', '/dev/null', false, '1.gp')
>
> figure(2)
> pcolor([1 2; 3 3])
> shading flat
> drawnow ('x11', '/dev/null', false, '2.gp')
>
> system('sed "s/depthorder /depthorder interpolate 100,100 /" <2.gp  
> >2a.gp');
> system('sed "s/depthorder /           interpolate 100,100 /" <2.gp  
> >2b.gp');
>
> % The two images are identical for the very fresh gnuplot compiled  
> from cvs,
> % otherwise look to results from 2b.gp:
>
> system('gnuplot -persist 2a.gp');
> system('gnuplot -persist 2b.gp');
>
>
> The implementation of "shading interp" requires the backend to smooth
> colours with the resolution comparable with the output device. There  
> was an
> attempt for this functionality (see EXTENDED_COLOR_SPECS in gnuplot  
> sources
> - however, I think it was working only for the vgagl terminal). So  
> this
> feature is currently not working.
>
>
> Therefore, I've written the following patch:
> https://sourceforge.net/tracker/index.php?func=detail&aid=2558565&group_id=2055&atid=302055
> [ 2558565 ] pm3d interpolate 0,0
> The animated demo there shows color surface transformations; Octave  
> would
> use for its "shading interp" the option
> 	set pm3d interpolate 0,0
> Does it look OK?
>
> ---
> Petr Mikulik

Petr,

I think the attached files look good ... but can you describe what has  
been changed.  The results (in your email) look very similar to what  
the current gnuplot sources produce.

Ben