[css-color-4] Expose Linear-light sRGB as CSS syntax?

[samweinig]

Edit 11 Oct 2021 by @svgeesus : much of this issue is now solved, see here for the remaining question. Issue title updated.

---

CSS Color 4 currently defines the following "RGB-ish" (meaning, using rgb channels, a transfer function to linear, and linear transform to XYZ) color spaces: 'srgb', 'display-p3', 'a98-rgb', 'prophoto-rgb', 'rec2020'.

In some use cases, it can be useful to have variants of these that are "linear" (meaning, the transfer function is unapplied), "extended" (meaning they are not bounded from 0.0 - 1.0, but rather can extended to Inf in either the positive or negative direction) or "linear and extended" (meaning a combination of the both).

While we certainly could specify the full matrix of all combinations of color spaces with these characteristics, for instance:

srgb
linear-srgb
extended-srgb
linear-extended-srgb

display-p3
linear-display-p3
extended-display-p3
linear-extended-display-p3

(etc, etc...)

An alternate formulation might be to offer CSS functions to transform the color spaces, offering linearize(), extended() functions, so the above could be described as:

srgb -> srgb
linear-srgb -> linearize(srgb)
extended-srgb -> extended(srgb)
linear-extended-srgb -> linearize(extended(srgb)) or extended(linearize(srgb))

display-p3 -> display-p3
linear-display-p3 -> linearize(display-p3)
extended-display-p3 -> extended(display-p3)
linear-extended-display-p3 -> linearize(extended(display-p3)) or extended(linearize(display-p3))

(etc, etc...)

As existing precedent, CoreGraphics, the library used on Apple's platforms for graphics, exposes functions to transform these RGB-ish colorspaces to their "linear", "extended", and "linear and extended" variants via the following functions:

/* Create a linearized copy of the color space if the color space is matrix based.
   Return NULL if otherwise */
CG_EXTERN CGColorSpaceRef  __nullable CGColorSpaceCreateLinearized(CGColorSpaceRef space)
CG_AVAILABLE_STARTING(11.0, 14.0);

/* Create a copy of the color space which uses extended range [-Inf, +Inf] if the color space is
   matrix based. Return NULL if otherwise */
CG_EXTERN CGColorSpaceRef  __nullable CGColorSpaceCreateExtended(CGColorSpaceRef space)
CG_AVAILABLE_STARTING(11.0, 14.0);

/* Create a linearized copy of the color space which uses extended range [-Inf, +Inf]
   if the color space is matrix based. Return NULL if otherwise */
CG_EXTERN CGColorSpaceRef  __nullable CGColorSpaceCreateExtendedLinearized(CGColorSpaceRef space)
CG_AVAILABLE_STARTING(11.0, 14.0);

[svgeesus]

I'm aware of this requirement, Canvas for example wants to have this as they reference Color 4 for predefined colorspaces.

SVG also needed a stable reference for linear-light sRGB because this is what SVG Filters use by default (and the rest of SVG can also optionally use this). Which is why linear-light sRGB is in the list of defined and exported terms.

What wasn't clear to me though was whether to

1. Expose this to CSS syntax, so you could use something like color(srgb-linear 0.2 0.5 0.9), or
2. Expose the defined terms for other specifications to link to, but not make them available from CS syntax

In terms of extended vs. not, I think that is a separate issue and I am in process of changing all the transfer functions (EOTFs) to cover the full range, for non-linear-light ("gamma encoded", although that term is problematic spaces. It simply involves extending any linear portion near the origin, for the same distance in the negative; and then mirroring the curved portion.

The sample code has that change, I need to check all of them have been done. The transfer function part of the predefined colorspaces has not been done yet, but I will do so.

Specifications which reference these spaces and require clamped values are unaffected, because the clamping means they don't exercise that part of the EOTF; and everyone else gets it "for free" and it just works.

Linear-light versions get extended for free, because the EOTF is a straight line and extended it is still a straight line.

So I don't think there is a need to expose special -extended versions in CSS. Just make the regular ones extended.

On naming: I see the Canvas and WebGPU folks using things like srgb-linear while @samweinig used linear-srgb as an example. I have a slight preference for putting the colorspace first so that they group together in indexes of terms.

[svgeesus]

linear-extended-srgb -> linearize(extended(srgb)) or extended(linearize(srgb))

Note btw that the second of those does not produce the expected result. If sRGB values that are clamped to [0..1] are linearized, then extended, the results are still in [0..1].

[weinig]

linear-extended-srgb -> linearize(extended(srgb)) or extended(linearize(srgb))

Note btw that the second of those does not produce the expected result. If sRGB values that are clamped to [0..1] are linearized, then extended, the results are still in [0..1].

I meant that pseudo syntax to be transformations of the type, not transformations of a value, but yes, if doing that to a value, they would have different results.

[svgeesus]

@weinig my key question is

So I don't think there is a need to expose special -extended versions in CSS. Just make the regular ones extended.

So the proposal would be to expose explicit *-linear versions to CSS syntax, but to make both the linear and the gamma-encoded versions extended by default and if you don't want extended, don't specify negative values.

Thoughts?

[weinig]

I am always a bit weary of compatibility when changing existing behavior, which this would be since we currently clamp, but sometimes that is the right call, as it is pretty unlikely people are using values greater than 1 or less than 0.

The more I think about it, the more reasonable that proposal seems to me, but I would be interested in hearing other voices on the matter.

(From an implementation perspective, this is very straightforward (it actually would allow us to remove some complexity if we could remove our bounded variants of the matrix-style RGB-ish colors (your, srgb, display-p3, a98rgb, prophoto, etc.)).

[LeaVerou]

What about an extra linear keyword, that could go either before, or after the color space name? linear srgb is far easier to read than srgb-linear for example, and authors won't have to remember whether it precedes or follows.

[svgeesus]

The sample code has that change, I need to check all of them have been done. The transfer function part of the predefined colorspaces has not been done yet, but I will do so.

That is all done now; all the transfer functions are defined over the extended range.

[svgeesus]

a) Linear-light versions

Currently, the term linear-light sRGB is defined in CSS Color 4, primarily to allow reference from other specifications such as SVG filters or Canvas. However, it isn't exposed as a color() colorspace. Should it be?

b) Extended versions

Currently, all the predefined RGB colorspaces are defined over the extended range by default. Also, color interpolation says not to clamp intermediate results that are extended. as @weinig says, taht removes some needless complexity from the implementation as well. Is that sufficient?

[Smilebags]

However, it isn't exposed as a color() colorspace. Should it be?

Just chiming in to say I think it would be nice to have this as an option, definitely.