#554 "Cubehelix" palette
Ingo Thies pointed out a recent article by D A Green that recommends a family of color palettes called "cubehelix". They share a general feature of combining N cycles of a color-wheel with a monotonic increase in overall intensity. This patch implements the specific cubehelix palette shown in Green's paper. It can be selected with the command
set palette rgbformulae 37,38,39
The downside of implementing this via rgbformulae is that only the one family member is described [well actually you can permute the indices to yield 6 variants]. The upside is that this mechanism produces smaller PostScript output files. An alternative approach would be to define a new palette option "cubehelix" taking additional parameters. This would allow more flexible selection of a palette from this family, but would would produce generally larger PostScript files. So far as I know there would be no similar drawback for other terminal drivers.
reference: D A Green (2011) "A colour scheme for the display of astronomical intensity images" http://arxiv.org/abs/1108.5083
palette rgbformulae for a cubehelix scheme
Great, that you picked up this idea!
I would prefer a new palette option, because e.g. my preferred palette is not included in your proposal, and I guess if you would change that, it would not fit for someone else.
Maybe a new palette option "named" can be introduced. It takes the name of the palette and some palette-dependent parameters. So other palettes of this kind can be included easier at later times.
So the syntax would be
set palette named cubehelix 1 -0.5 1.2
I can see if I can come up with a patch in the next time.
Christoph
Here is an alternative patch. It touches many more files, but it's more flexible. The new option in this variant is
set palette cubehelix {start <val>} {cycles <val>} {saturation <val>}
These are the three control parameters used in the Green paper. The gamma correction from `set palette gamma <val>` is also applied.
set palette cubehelix
Hi,
I tested the patch. Basically it works, but not for larger saturation values. The colorboxes are correct in both cases, but the images are not (same result with wxt and postscript) terminals:
set terminal wxt
# this works
set xrange[-10:10]
set yrange[-10:10]
set palette cubehelix sat 1 cycles -0.5 start 1
plot '++' using 1:2:1 with image
pause -1
# this image does not agree with the colorbox, which is correct.
set palette cubehelix sat 2 cycles -0.5 start 1
plot '++' using 1:2:1 with image
I have to admit that I am surprised that this use of "with image" does anything reasonable at all! Why does this work? Should we expect it to, and support it?
If so, then I conclude the problem is with the driver implementation of "with image" rather than a problem with the palette per se. You can see this by comparing:
set palette cubehelix sat 2 cycles -0.5 start 1
plot '++' using 1:2:1 with image # uses the driver-specic image code
pause -1
plot '++' using 1:2:1 with image failsafe # uses the generic image code
Alternatively, one might view it as a case of "don't do that". If you allow setting the saturation greater than 1.0, things are eventually going to go wrong somewhere. If you clip the over-saturated components, then the palette scheme is no longer guaranteed to be monotonic increasing in intensity. If you do not clip the components, then you get color artifacts. The simplest limitation would be to not accept saturation values > 1. But this would rule out schemes where due to gamma correction it is possible to have a saturation [slightly] greater than 1.
A more complicated test would be to calculate the full palette range, check for saturation overflow, then retroactively reset the saturation to the maximum value that does not overflow. Would this be worth doing?
clip RGB components (allows saturation>1, but loses monotonicity)
07 October version clips the RGB components individually. This removes color artifacts for large values of saturation, but loses the property of monotonic increasing intensity.
The patch also adds an intensity graph to "test palette" so you can evaluate the effect of clipping.
This version works fine for me. Of course if the RGB values are clipped, the gray values are not linear anymore. But this is much better than having negative RGB values (like in the version of the 1. oct), which in my opinion should never happen!
For my part I am surprised that my use of 'with image' should not be ok. The '++' generates only a datafile on-the-fly, so I took this for testing instead of generating external data files.
Why should there be any problem with this?
No problem, it's just that my first thought when seeing "with image" is that it will be reading from an image file.
There's a certain amount of processing that the generic image code does (like clipping the components) that is skipped in the term->image() routines, I suppose because it is assumed that it isn't necessary for "real" image data. Your example raises the question of whether we should add more filtering and sanity checks to the individual term->image() routines.
I think there is enough sanity checks in the generic code. This must make sure, that
* the coordval's are always in the range [0, 1]. This is granted with cb2gray().
* the palette maps to [0, 1] for each rgb components. I think this was not the case for your first patch.
Christoph