Add perceptual colour functions #40
Conversation
gravitystorm
force-pushed
the
perceptual_color
branch
from
d10bd7a to
fb758e5
Compare
Chroma currently expects all strings to be mutable. Calling this from frozen_string_literal files works fine, but not on ruby 2.7 where things were handled differently. This syntax can be removed when either a) Chroma accepts frozen strings or b) ruby 2.7 support is dropped
|
I've rebased this, since #39 helps highlight that this would not have worked on ruby 2.7. The fix for that edge case has now been included in this PR. |
pnorman
left a comment
pnorman
left a comment
There was a problem hiding this comment.
Color mixing should be done in a perceptual colourspace, probably one of the two supported by css (oklab, oklch, lab, or lch). hsluv is not perceptual.
I'd rather go to CSS to figure out what functions are useful than cartocss. CSS Color 4 and 5 have a decent theoretical foundation that CartoCSS lacks.
We do need to decide what to do with colors that can't be represented in sRGB. We should not clip bounds until writing the color out to RGB hex or rgb(). Out of gamut colors sometimes appear in color calculations They're also necessary for operations like darken and lighten to be inverses of each other.
Lastly, we should have a list of color functions in the docs.
|
My main concern here is to provide an smooth path for people to convert their existing CartoCSS projects to glug. I acknowledge that this is mainly self-interest! But I also think it's worth making it easier for other cartographers to do the same thing, since there are many existing CartoCSS projects and many of them use the "colourp" functions. I think it's more helpful for people in this situation if they have the familiar colour functions that give the same results available in glug. If they need go through every use of colour functions and change all of the percentages used, or keep the percentages but end up with different colours, then this would be a barrier to adoption. It certainly would be for me, which is why I've added these "colourp" functions, rather than reworking every colour function in every stylesheet to use the non-p versions already available in glug. I'm happy to also support more accurate colour spaces, but I think these should lie alongside doing calculations in hsl colour space and hsluv colour spaces. |
2 participants
This PR adds the perceptual colour functions, which are familiar for users of CartoCSS (like me). I've also had to add a "mix" function since that isn't native to Chroma, along with a "mixp" variant that's not found in CartoCSS but seems reasonable to include.
Each function is tested, and for ease of comparison is tested alongside the chroma version. The chroma mixins for Integer were adapted for functions that require 0 and 2 parameters (e.g. greyscale and mix, respectively).
I've made a sense-check of each function against the output from CartoCSS, which indicated the algorithms are the same. There were about 3-4 cases where the output colour was 1-bit different in a particular colour channel. I assume that's a rounding issue and I don't think this is significant.
The only functions not implemented from CartoCSS are the "fadein/fadeout/fadeinp/fadeoutp" group, since they rely on colours having transparency. I'll open a separate issue for that.
Refs #10