Re: [compositing] Incorrect recommended implemntation of mix-blend-mode: saturation

This implementation and naming has shipped for over 20 years in Adobe
products and their specifications.
Also, it is part of every single browser (except Safari) and operating
system (except MacOS/iOS) in their CSS, SVG and Canvas 2D implementations.

If you want to file an issue for a real saturation mode, you can try filing
an issue here: https://github.com/w3c/fxtf-drafts/issues


On Fri, Apr 2, 2021 at 5:01 AM Callum Morrisson <morrisson.callum@gmail.com>
wrote:

> RE: https://www.w3.org/TR/compositing-1/#valdef-blend-mode-saturation
>
> The math used in the functions:
>
> Lum(C) = 0.3 x Cred + 0.59 x Cgreen + 0.11 x Cblue
>
> and
>
> Sat(C) = max(Cred, Cgreen, Cblue) - min(Cred, Cgreen, Cblue)
>
> seems to be taken from the calculations for Luma and Chroma (respectively)
> in the LCH color space (as seen here
> <https://en.wikipedia.org/wiki/HSL_and_HSV#Hue_and_chroma> and here
> <https://en.wikipedia.org/wiki/HSL_and_HSV#Luma,_chroma_and_hue_to_RGB>).
> However, the expectation would be that it's derived from
> lightness/luminance and saturation from the HSL or HSV/HSB color spaces.
> This expectation stems from the fact that the word chosen to describe the
> blend mode is "saturation", not "chroma" or "chrominance". This has lead to
> entirely too much confusion with people thinking there's a bug in the
> implementation of mix-blend-mode: saturation.
>
> My plea is that either the saturation blend-mode gets renamed to "chroma"
> or "chrominance" or the implementation gets fixed to match a colorspace
> that actually has saturation as one of its channels (ideally HSL as that
> colorspace exists in the svg/css world already).
>
> Cheers,
> Callum Morrisson
>

Received on Friday, 2 April 2021 15:33:46 UTC