I'd like to view this as proof of concept and base for discussion.
Fixes #354.
Builds upon #418.
Basically this PR adds support for HUSL (http://www.husl-colors.org/) perceptual colours. I have chosen that over Lch or Lab, because it doesn't allow the definition of colours that cannot be represented in the RGB colour space. This and its similarity to HSL make its use convenient and avoids trial-and-error colour definitions (see https://github.com/mapbox/carto/issues/354#issuecomment-165576590 for an expanded explanation why I think this is beneficial).
The implementation has the following characteristics:
the colour object knows if it is a perceptual colour or not
internally colours are no longer represented in rgb but in hsl (or husl) values
colour functions like lighten, darken operate on the respective colour space (internally they only manipulate hsl or husl values)
there are lightenp, darkenp, ... functions to force a colour into perceptual colour space
hue, saturation, ... always return the value of the (converted) non-perceptual colour
huep, saturationp, ... always return the value of the (converted) perceptual colour
the mix function operates on perceptual colours if there is at least one perceptual colour in its parameters
chained colour functions operate on the HSL or HUSL space as long as possible, the conversion to rgb or rgba is done at the end
The similarity of hsl and husl in terms of values keeps the representation simple. The perceptual colour space is kind of sticky. Once you are in it is difficult to get out again, but I thought this would be no problem.
I have extended test coverage, which @pnorman started in #418, further to all new colour functions.
I'd like to view this as proof of concept and base for discussion. Fixes #354. Builds upon #418.
Basically this PR adds support for HUSL (http://www.husl-colors.org/) perceptual colours. I have chosen that over Lch or Lab, because it doesn't allow the definition of colours that cannot be represented in the RGB colour space. This and its similarity to HSL make its use convenient and avoids trial-and-error colour definitions (see https://github.com/mapbox/carto/issues/354#issuecomment-165576590 for an expanded explanation why I think this is beneficial).
The implementation has the following characteristics:
The similarity of hsl and husl in terms of values keeps the representation simple. The perceptual colour space is kind of sticky. Once you are in it is difficult to get out again, but I thought this would be no problem.
I have extended test coverage, which @pnorman started in #418, further to all new colour functions.