#992 colorbox bug with palette defined and maxcolors
Hello,
I recently updated my CVS gnuplot and had a strange colorbox behaviour (see comparison in picture).
System: Windows 7, 64 bit; gnuplot 32 bit
CVS checkout: May 21 2011.
Compiler: VC 2008
Commands in gnuplot:
gnuplot> set pm3d
gnuplot> set palette defined ( 0. "magenta", 1. "dark-blue", 2. "blue", 3. "cyan", 4. "green", 5. "yellow", 6. "orange", 7. "red", 8. "dark-red") maxcol 10
gnuplot> splot sin(x)*cos(y)
smooth palette in windows: using 4096 of 4096 available color positions
In the picture I've plotted these commands with different versions of gnuplot:
from left to right:
1. Gnuplot 4.5 with libgd in terminal windows; one year old: CVS May 2010
2. Gnuplot 4.5 with terminal windows from CVS May 2011 (today)
3. Gnuplot 4.5 with libgd in terminal windows from CVS May 2011 (today)
4. Gnuplot 4.5 with terminal postscript eps from CVS May 2011 (today). The eps is viewed with GhostView.
As one can clearly see the colorbar 1 and 4 is different from 2 and 3. In my eyes, 1 and 4 is working properly, i.e. it is showing magenta as lowest in the colorbox and each color range in the colorbox is equal in size. In 2 and 3 the last color is never the one as defined but some mixture. In 2 and 3, there are more than 10 color ranges and they are of different size.
So far I test some things but could find the bug. I guess the bug might be in draw_inside_color_smooth_box_bitmap in color.c. The bug happens also with the libgd outputs.
Best regards.
Colorbox bug
I cannot explain why different terminals produce different color bars on this input.
However, I can point out that your expectation of the resulting palette doesn't match mine. My understanding is that the custom palette you provided means the following:
( 0. "magenta", 1. "dark-blue", 2. "blue", 3. "cyan", 4. "green", 5. "yellow", 6. "orange", 7. "red", 8. "dark-red")
in the interval 0-1 interpolate between magenta and dark-blue
in the interval 1-2 interpolate between dark-blue and blue
in the interval 2-3 interpolate between blue and cyan
etc.
I think the effect you actually want is described instead by
set palette defined ( \ 0 magenta, 1 magenta, \ 1 dark-blue, 2 dark-blue, \ 2 blue, 3 blue, \ 3 cyan, 4 cyan, \ ... and so on.
In other words, if you want a solid color over a particular numeric range then you need to specify that range as having the same color at both ends.
First of all, thank you very much. Your tip did the trick. At least for the moment.
Anyhow, I think the previous behaviour, which was common to all terminals I have used, is much nicer:
- one doesn't need to give each color twice (from and to value) because it is assumable that the previous color ends where the next starts
- the palette maxcolor value is not used anymore. The old behaviour took the defined colors as "supporting values" in the palette of true colors (or at least much more colors than given in set palette defined), while the maxcolor gave the possibility to quickly reduce/change this number as needed. Now, with from to ranges for each color, no interpolation of colors is done, such that it is very limited in use as compared to the old version.
- common to all terminals (bitmap and postscript based)
When searching around I found this entry in the NEWS:
* FIX accurate placement of color boundaries in the colorbar
Is this maybe causing the difference? If so, maybe someone knows when it was changed, such that I can compare the source codes and hopefully restore the old behaviour.
Thanks again.
There was extensive discussion on the mailing list about problems with discrete palettes. You can find a copy here:
http://comments.gmane.org/gmane.comp.graphics.gnuplot.devel/9634
A major issue turned out to be that the old code could only map a discrete palette of N colors onto a colorbox with N segments if the seqments were of equal size.
I finally found the bug in getcolor.c in function quantize_gray. The old behaviour is restored by just returning the degray value as calculated in the first line:
double
quantize_gray( double gray )
{
double degray = floor(gray * sm_palette.use_maxcolors)
/ (sm_palette.use_maxcolors-1);
return degray;
}
Is it a general bug, i.e. is there a general solution or is it just affecting this special combinatoin of commands? If so, maybe it is necessary to have a switch or condition for both variants of finding proper return values.
Your proposed change would restore the previous major problem - it assumes that the N color ranges are all of equal size. If you want to explore possible changes, please also test with non-uniform spacing. E.g.:
set palette defined ( 0. "magenta", 1. "dark-blue", 2. "blue", 4. "cyan", 8. "green", 16. "yellow", 32. "orange", 64. "red", 128. "dark-red")
Hi. I recently added bug report #3532747 which was flagged "duplicate with this thread".
> Your proposed change would restore the previous major problem - it assumes
> that the N color ranges are all of equal size.
If each behaviors are trade-off things, I think that the issue pointed out by Andreas is more problematic behavior.
With quantize_gray( double gray ) suggested by Andreas, by setting maxcolors 128,
set palette defined ( 0. "magenta", 1. "dark-blue", 2. "blue", 4. "cyan", \ 8. "green", 16. "yellow", 32. "orange", 64. "red", 128. "dark-red")
set palette maxcolors 128
gnuplot could generates same plot with the current CVS version.