[css-color-4] Missing info about Premultiplication and Undefined values

[facelessuser]

In this issue (#7253) a change was made :

If the alpha value is none, the premultiplied value is the un-premultiplied value. Otherwise,

I still feel this is a good call, but it is often referred that premultiplication happens before interpolation, which it does. Still, maybe it should be mentioned that at interpolation time, if given two colors (A and B), if one of the colors has an undefined alpha (we'll say A), and the other does not (B), then when A takes on the alpha value of B, it will need to premultiply on the fly before the actual interpolation takes place. This can be inspected and done ahead of time, but I think maybe it should be mentioned.

[svgeesus]

Re-reading the relevant sections Interpolating with Missing Components and Interpolating with Alpha I agree, it would be easy to miss that the handling of missing components happens before the alpha-premultiplication stage.

Which means that the only time alpha=none persists through to the premultiplication stage is when both colors have it; and in that case, the alpha premultiplication and un-premultiplication steps are both unity no-op.

Needs to be mentioned as you say, and ideally more examples added which show the interaction between the different stages.

[svgeesus]

I started working on examples and (once you consider nonsense examples, because none can occur anywhere) find I have an order of operations problem. Here is a dumb example:

--start: color(prophoto-rgb 0.3 none 0.7 /0.5);
--end: lab(100% 0 0 / none);
.foo {
  background: linear-gradient(in oklab to right, var(--start) var(--end));
}

Selected quotes from the spec:

For handling of missing component in color interpolation, see § 12.2 Interpolating with Missing Components

and

For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc.

(both from 4.4 “Missing” Color Components and the none Keyword

Interpolation between values occurs by first converting them to a given color space which will be referred to as the 'interpolation space' below, and then linearly interpolating each component of the computed value of the color separately.

from 12. Color Interpolation

and lastly

If a color with a missing component is interpolated with another color which is not missing that component, the missing component is treated as having the other color’s component value.

from 12.2. Interpolating with Missing Components

So on the one hand, --end needs to get the alpha value from --start, 0.5, which is easy as they both have an alpha component in their source forms; but also, --start needs to get the green value from --end which is problematic because Lab doesn't have a green component.

And this filling in of missing components must necessarily happen before converting them to the interpolation color space, because color space conversion changes missing values to 0.

What I think is reasonable, then is that there is no green component to copy from; and thus --start is unchanged; and when converted to OKLab the missing component will become zero.

--start: color(prophoto-rgb 0.3 0 0.7 /0.5);
--end: lab(100% 0 0 / 0.5);

which is

oklab(38.63% 0.076 -0.27 / 0.5)
oklab(100% 0 0 / 0.5)

and interpolation proceeds as normal (both colors are premultiplied, components are interpolated, results are un-premultiplied).

[svgeesus]

One more gotcha: consider

--one: color(sRGB 0.7 0.4 0.2 / none);
--two: color(display-p3 0.8 0.7 0.4 / none);

both are missing alpha values:

If both colors are missing a given component, the interpolated color will also be missing that component.

Spec is missing some text to clarify that, when these two colors are converted to the interpolation color space, those two none values do not get converted to zero but must be preserved. Otherwise, the interpolated result will be fully transparent (alpha of zero) not alpha of none. And also, that zero alpha would give premultipled color components of zero, thus transparent black.

[svgeesus]

From my earlier comment I think that we need to expand the text slightly, from

If a color with a missing component is interpolated with another color which is not missing that component, the missing component is treated as having the other color’s component value.

to

If a color with a missing component is interpolated with another color which has that component, and the value is not missing, the missing component is treated as having the other color’s component value.

[svgeesus]

This will produce occasionally surprising results, where the two colors have matching components but the scales or offsets are different. For example copying OKLCH hue to an HSL color with missing hue gives you a result, but that color is not the same hue.

rebeccapurple converted to OKLCH oklch(44.03% 0.16 303.4) and converted to HSL is hsl(270 50% 40%)

Now interpolate oklch(44.03% 0.16 303.4) with hsl(none 50% 40%) and the second color becomes hsl(303.4 50% 40%)

rebeccapurple is rgb(40%, 20%, 60%)
hsl(303.4 50% 40%) is rgb(60% 20% 57.73%)

Or copying an OKLCH Lightness (range 0 to 1) to a CIE LCH Lightness (range 0 to 100) will work well if the percentage form was used, but oddly if the number form was used.

[facelessuser]

So, this is starting to get a bit confusing:

If a color with a missing component is interpolated with another color which has that component, and the value is not missing, the missing component is treated as having the other color’s component value.

So, are we comparing these colors before they are converted to the common color space? If I'm comparing an sRGB color with a Rec 2020 color that has different scaling, the sRGB color need to take on the red value from the Rec 2020 color? You seem to mention these surprising results with hues not being compatible and scales, I'm not sure I like this approach very much. Color spaces may share the same components, but they are not exactly the same in meaning. They may have different primaries for example.

I feel if people are trying to use none to their advantage, it would be best that they work with their colors in a consistent color space to take advantage of the none and avoid none to zero translation.

If the intent is to special case alpha specifically, I can more see that as a possibility. It is independent of color conversions and definitions of color spaces. I remember some suggesting the possibility of making alpha resolve to 1 instead of zero for instance. I could see an undefined alpha reasonably being treated specially during a conversion process and not altered, and then only at display time resolved to some sane, viewable value. I'm just not sure I personally see much of a benefit to complicating the conversion process for non-alpha components.

[svgeesus]

So, are we comparing these colors before they are converted to the common color space?

Right, otherwise all the none become 0

I feel if people are trying to use none to their advantage, it would be best that they work with their colors in a consistent color space to take advantage of the none and avoid none to zero translation.

Yes I think we are going to need some authoring guidelines here.

We added none everywhere (for consistency), when the actual motivation was powerless hue; now the spec of course has to say what happens in all cases many of which are far-fetched and are not goig to show up in real-world style sheets.

And yes people can use 'none` deliberately, for effect; but then they should be using a starting color space which is perceptually uniform and has semantically meaningful axes (so LCH or OKLCH, basically).

I'm just not sure I personally see much of a benefit to complicating the conversion process for non-alpha components.

I can certainly see that point of view.

[facelessuser]

Yeah, my two cents is that I'd prefer if color component translations stay with the current assumptions. It keeps things simple. Yeah, there can be weird cases, but if you are working in non-consistent color spaces, that's what you get 🙃. It seems more preferable than creating a more complicated conversion pipeline for interpolation, and there are still different, weird cases that are maybe less intuitive in nature.

If it is viewed that there is benefit in handling alpha differently, then I can maybe see that. I'm honestly kind of indifferent, but since alpha is agnostic to color spaces, you can kind of do whatever you want with it, if it makes more sense and provides a net positive benefit, I'm not sure I could argue.

[LeaVerou]

From a quick skim of the issue, here's what I see, correct me if I'm wrong:

Regardless of which components can have none values, when we're interpolating a color with none components into another color space, we have a problem. How will we handle e.g. hsl(none 0% 50%) when interpolated in srgb or literally any other color space that is not hsl? Are we going to now have entire expressions involving none values? Will we just coerce it to 0 and lose the noneness?

I wonder if it would be better to go back to just handling achromatic colors specially in the interpolation algorithm rather than have undefined components, even though undefined components is a more elegant solution... I mean, an achromatic color is sitll an achromatic color when converted to another color space…

[facelessuser]

I wonder if it would be better to go back to just handling achromatic colors specially in the interpolation algorithm rather than have undefined components, even though undefined components is a more elegant solution... I mean, an achromatic color is still an achromatic color when converted to another color space…

I'd personally hate the pendulum to swing too far in either direction. The heart of the issue had nothing to do with the current discussion. Really, I just thought it would be important to make clear that when two colors are being interpolated that premultiplication needs to come after an undefined resolution.

From the very beginning, it was understood that when a color with undefined components is converted that undefined values would need to be resolved, and it was decided that undefined channels would become zero. The spec already states this. This comes with certain implications that I thought were well understood.

Because none was introduced, some users could exploit this behavior and set channels to undefined values to try and take advantage of the logic, but as long as the spec makes clear what would happen in these cases, I think that is fine. I don't think the solution needs to be more magic or reverted.

I think the current behavior is fairly intuitive. Yes, I'm sure even if spelled out completely, some people may still be surprised at first, but that is true for a lot of things. If needed, I think it could be mentioned that if you are going to set none manually to channels in order to exploit its behavior during interpolation, undefined values will not persist through conversion unless the channel's undefined behavior is dictated by its achromatic nature. If you want the manual insertion of none to be meaningful, you need to work in the same color space, if not, they will be assigned a defined value of 0.

I think going back to only handling achromatic is the lesser of the two evils, but I'm not sure I prefer that over just adding a few more comments to make clear what should happen during premultiplication and will happen if you try to exploit none during interpolation.

[LeaVerou]

Maybe I'm missing something. How would you handle interpolating between e.g. hsl(none 0% 50%) and lch(50% 0% none) in e.g. OKLab?

The spec is very handwavy:

If a color with a missing component is interpolated with another color which is not missing that component, the missing component is treated as having the other color’s component value.

How do you even compute what "the other color's component value" is here, given they both have missing components so none can be converted to each other's color space?