CIE Lab color conversion, for the L component

[artscoop]

Hi,
Would adding CIELab conversion in order to benefit from the L channel be out of scope for Less ? HSL or HSV are convenient and simple, but perceptually, changing L/S ot V/S is often far less efficient than moving the L channel.
I happen to rely on the Lab color space very often in web design and digital painting.
I'm considering adding such a feature to Less but won't if you believe it has no practical use.
Thanks.

[lukeapage]

we already have alot of colour functions... it really depends if it will be useful for lots of people. If it is a minority I would suggest it should be a plugin - though our support for plugins is limited ;(

[thorn0]

The argument about a minority is irrelevant. This function would be much more valuable than the existing lightness(@color) function.

[Synchro]

While Lab is more accurate, it's definitely less valuable in that it's not specifically needed by anything. Lightness and toHSL are used in a lot of places. L in Lab isn't the same thing as L in HSL (your point), but it's not a meaningful replacement either.

[thorn0]

There exists the luma function which is better than lightness and looks similar to the L component of Lab, but why is HSL used for the lighten and darken functions?

[thorn0]

And the same issue with the spin function. Equidistant colors obtained with it have different perceived brightness.
See the really great article on this: http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/

[artscoop]

Luma only gets the perceptual lightness of a color, by using simple math on the RGB components.
But going from a color and changing the L (from CIELab) component has a complex effect on saturation, hue and brightness.
@Synchro Marcus, I'm not talking about replacing the existing color conversion modes, since they're valuable and used so often. I was thinking about adding CIELab color space conversions to the existing ones.
This is perceptually one of the best color spaces I know, and very natural results could be achieved simply with this (may I remind that HSL/HSV to change lightness of a color seems quite unnatural compared to the Lab results).
But I agree that my proposal is not a vital feature.
@thorn0 Very good article that illustrates the issue well.

[thorn0]

"going from a color and changing the L (from CIELab) component has a complex effect on saturation, hue and brightness"

Yes, it has, and this effect is much more nice-looking than the effect of changing Lightness in HSL.

[Synchro]

@thorn0 actually I agree with you about lighten/darken and spin. There's no particular reason to use HSL for them other than convenience since the HSL implementation was already there. One other factor is that there is no browser support for Lab, whereas all the other spaces are supported, so no matter what you do in Lab, you'll need to convert back to some other space.

[artscoop]

I was thinking about doing different math : let's suppose we start with @col : #f30. We could then have a function named, for example, shift_CIEL(percent), which would return a RGB(A) value. Indeed, it would need a conversion from RGB to XYZ to CIELab, and a conversion back from CIELab to XYZ to RGB. The result would be transparent for any browser. Only a javascript function would be used to manipulate the perceptual brightness of a color.

[thorn0]

Actually all the maths is already implemented in chroma.js, and I don't think it's worth reimplementing it. It would rather be cool if Less just used chroma.js to do color maths. Also would be great to have color scales as first-class citizens.

[seven-phases-max]

Implement as a plugin (first). See #1853 for more on the current "new color functions" approach.

[thorn0]

For reference, Lab and LCH colors in the CSS spec draft:
https://www.w3.org/TR/css-color-4/#lab-colors