An X11 palette issue, approximate_palette

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

Here is a small issue with the palette in X11.

In the pm3dcolors.dem demo, as in the most recent CVS version is an example of using functions for the palette.  By the definition of the functions for each color component, this demo is supposed to have three regions with two sharp transitions between the regions.

The pm3d plot itself has good sharp transitions in X11 and other terminals I've looked at.  As an example, look at the attached PNG "palfunc.png".

Likewise, one would think that the color box should have a similar sharp transition.  This is the case for PNG (see "palfunc.png") and for PDF.  Notice the sharp boundaries right at -5 and 0.

However, the X11 terminal produces a color box with an artifact at -5 and 0.  See the attached PNG "Screenshot-Gnuplot-4-palfunc.png".

I've done a little investigation and concluded parts of the palette method work as they should.  For example, the software produce component values

a=0.984000 b=0.000000 c=0.246000
a=0.992000 b=0.000000 c=0.248000
a=0.000000 b=0.500000 c=0.250000
a=0.000000 b=0.500000 c=0.254000
a=0.000000 b=0.500000 c=0.258000

and

a=0.000000 b=0.500000 c=0.496000
a=0.000000 b=0.500000 c=0.498000
a=0.000000 b=0.000000 c=0.500000
a=0.000000 b=0.000000 c=0.504000
a=0.000000 b=0.000000 c=0.508000

at the boundaries.

To anyone familiar with the x11 palette method (and that includes *any* code in the color.c, getcolor.c, etc. files) is what I'm seeing simply an artifact of the "approximate_palette()" routine?

I think what x11 does is not keep track of functions, but has a palette sent to it that is an approximation of the functions.  (The routine gnuplot_x11 doesn't have the foundation for functions and so on.)

This routine "approximate_palette()" is an interesting one.  (And I've a feeling it might be slow because of what it does.   More later...)  If I understand correctly, it first oversamples the palette and then attempts to find a smaller palette that fits within an allowable tolerance of approximation the original palette.  So it seems to be an embedded loop kind of thing.  (Hence its slow speed.  I wonder if we could devise a mathematical formula that would tell us immediately what the size of the palette should be rather than by trial and error.)

So, is it the case that in the color box we are seeing the effect of approximate_palette() doing linear interpolation on the colors on each side of the discontinuity for the RGB formulae?  This is what I'm guessing.  So that is the issue I'm raising--this idea of first sampling the palette and then using linear interpolation to construct a smaller palette.  In the case of discontinuities (and in image processing and pattern recognition, discontinuities do not seem in any way a far stretch), which are not band limited, this is not a good thing.  Perhaps there are some applications where interpolating is desired.

What is the difference with PNG/PDF?  I'm guessing in that case, the term->make_palette(NULL) indicates there are, say 157, colors.  Then the software decides, OK, I'll sample the palette in 157 locations, no interpolation.

If what I've described is the case and there is no desire to address the issue because people feel it is fine the way it is, there should probably be mention of this in the palette documentation.  Otherwise it might seem peculiar to the end user and cause a lot of question.

Dan