What’s the range of *s* in Cubehelix? about d3-color HOT 13 CLOSED

There isn’t a defined range; it’s dependent on your display characteristics and the other channels h and l, similar to L*a*b* color space. The range [0, 2] is just what looks reasonable (to me) for that color picker. I think the range [0, 1] is guaranteed to be within most displays but you can’t get very saturated colors that way…

from d3-color.

Is there an article or paper or something about Cubehelixas a color space? I could not find anything (except this lib)

from d3-color.

Also is this somehow related to http://www.hsluv.org (like HSL but based on CIELUV)? as I think this space has similar characteristics.

from d3-color.

The only paper I’m aware of is linked from https://www.mrao.cam.ac.uk/~dag/CUBEHELIX/, but it’s described as a color scheme rather than a color space. Jason Davies and I extended it into a three-dimensional space and then implemented the inverse mapping from RGB to Cubehelix.

Also to correct my earlier comment, since the Cubehelix space is defined as a transformation of RGB space, which is typically considered fixed in [0, 255] (or [0, 1] depending on your representation), you can consider the s and l channels to have hard limits because there isn’t a concept of a device profile like there is with the CIE color spaces. But those limits are not constant—they depend on the other channel values.

from d3-color.

so what's this limits? maybe there was some issue in formula because of which i was still getting different colors after i was increasing s. in which case I guess we need to clip s to not allow such cases.

from d3-color.

I made an interesting observation, if you use saturation 1 and enable grayscale mode in osx (Preferences > Accessibility > Display > use Grayscale), then hue part is mostly solid gray, and if you drag hue from 0 to 360 and take a look at lightness gradient then you will see almost no change. but if you set saturation to 2 then hue is not as solid gray as before and some light colors are observable, also if you drag hue from 0 to 360 lightness gradient changes a lot. You can also try to set s to 1, and when you drag hue from 0 to 360 only change in gray appears in s range or [1,2].

So I think the s should be in range [0,1]. and to allow for much saturated colors I guess we need to use higher gamma value in the formula.

So maybe the color space should be parameterized by gamma?
I could not see any place where gamma could be used in current implementation.
(I'm taking about the gamma from here)

from d3-color.

This is discussed in the paper. If s and l are in [0,1], the Cubehelix color space is completely contained in RGB. But it is a subset of RGB, so if you want more saturated colors at a risk of some hues being out of gamut, you need s > 1. So making it a hard limit would constrain the usefulness of the color space, limiting it to more “muddy” colors. Allowing s > 1 lets you reach brighter colors at the risk of sometimes going out of gamut.

from d3-color.

This is more of a discussion than a bug or feature request, so closing this issue. But feel free to keep discussing!

from d3-color.

I understand that.

I was thinking if we introduce gamma as parameter of for cubehelix color space would we get uniform lightness even for saturated colors? or anything above gamma 1 will be non uniform?

from d3-color.

See d3.interpolateCubehelix.gamma.

from d3-color.

hm we can't I played with https://www.mrao.cam.ac.uk/~dag/CUBEHELIX/cubetry.html and if you increase hue param which I guess is gamma here, we do not get uniform lightness.

from d3-color.

The “Hue parameter” on that page is s in d3.cubehelix, and the “γ factor” is gamma in d3.interpolateCubehelix.

from d3-color.

For what it's worth, in my simple computation of "every" sRGB color (r, g, b ∈ ℕ ⋂ [0, 255]), the range for s in Cubehelix ended up being [0, 4.6143].

from d3-color.