[css-color] Generic Transform Function for RGB Color Spaces

[Crissov]

All predefined color spaces are RGB. In prose and sample code, their transfer function into linear-light components is described quite differently, although it could be stated in a single formula with up to four parameters specific to the color space (of which only gamma γ is frequently mentioned). Can we use this abstraction – or a similar one – in the spec and leave optimization up to implementers?

c = (C < β × δ)
  ? C ÷ δ
  : ((C − 1) ÷ α + 1) ^ γ
  ;
C = (c > β)
  ? α × c ^ γ⁻¹ − α + 1
  : c × δ
  ;

Color Space	α = a + 1	β = K₀/φ	γ	δ = φ
Rec. 2020	~1.099297	~0.018054	2.4 = 12/5	4.5 = 9/2
sRGB, P3	1.055	0.0031308	2.4 = 12/5	12.92 = 323/25
ProPhoto, ROMM	1	0.001953	1.8 = 9/5	16
Adobe 1998	1	0	563/256 ≈ 2.2	(1)

[Crissov]

These parameters could even become descriptors in @color-profile, but that would be worthy of a dedicated issue.

@color-profile "rec-2020" {
  composition: rgb 0.708 0.292, 0.17 0.797, 0.131 0.046;
  white-point: D65;
  linearization: 2.4 0.018054 1.099297 4.5; /* [γ = 2 [β = 0 [α = 1 [δ = 1]]]] */
}
@color-profile "sRGB" {
  composition: rgb 0.64 0.33, 0.30 0.60, 0.15 0.06;
  white-point: D65;
  linearization: 2.4 0.0031308 1.055 12.92;
}
@color-profile "Pro-Photo" { /* ROMM */
  composition: rgb 0.7347 0.2653, 0.1596 0.8404, 0.0366 0.0001;
  white-point: D50;
  linearization: 1.8 0.001953 1 16;
}
@color-profile "A98-RGB" { /* Adobe 1998 */
  composition: rgb 0.64 0.33, 0.21 0.71, 0.15 0.06;
  white-point: D65;
  linearization: calc(563/256);
}

[faceless2]

Each of these spaces is completely defined by an ICC profile. So conversion to or from any of these spaces is going to be done by the ICC code, rather than by doing the maths by hand. I don't think there's any value in trying to reproduce the ICC profile in CSS.

That said, in the PDF world defining ColorSpaces without reference to an ICC profile is extremely common. It's not used for RGB as you've done here, but to define custom separations - a single separation is often called a "spot color", but they can be combined with other custom separations or the normal process colors (cyan, magenta, yellow and black) to form what PDF call "DeviceN" ColorSpaces.

I attempted to tackle this in #2023.

The ability to define custom separations is absolutely critical for any CSS to PDF engine. It's not a nice-to-have, and it's not something that can be done with ICC profiles. All products I'm aware of (Prince, Antenna House, RealObjects, our existing Report Generator and our new under-development engine all have a method for this, many loosely based on the rgb-icc function defined in https://www.w3.org/TR/xsl11/#expr-color-functions, but personally I don't think that approach is very well thought out. I'd really like to see it standardised.

[svgeesus]

Each of these spaces is completely defined by an ICC profile. So conversion to or from any of these spaces is going to be done by the ICC code, rather than by doing the maths by hand.

That may well be the case for some implementations. For example, Apple stated clearly that they will implement this in Safari by using ICC profiles.

In other cases, and Chrome springs to mind, from what I understand they plan to do the matric math themselves rather than loading profiles. TV and other video-oriented implementations also historically do not use ICC profiles for colorspace conversions.

I don't think there's any value in trying to reproduce the ICC profile in CSS.

I disagree. The specification needs to state these values, because they are normative. Forcing people to dig into ICC profiles to find the values is counter productive and prone to error (for example ICC v.2 profiles typically have unadapted primaries while ICC v.4 profiles with a chad tag will have the primaries adapted to D50.

< That said, in the PDF world defining ColorSpaces without reference to an ICC profile is extremely common. It's not used for RGB as you've done here, but to define custom separations - a single separation is often called a "spot color", but they can be combined with other custom separations or the normal process colors (cyan, magenta, yellow and black) to form what PDF call "DeviceN" ColorSpaces.

Yes, I'm aware of them.

In CSS Color 4, multichannel calibrated spaces are already possible. It would be possible to add a Device-N() alongside Device-CMYK() but both suffer from not being a colorimetric specification and thus, not composable with other colors (opacity, blending, interpolation as a color stop, etc).

The ability to define custom separations is absolutely critical for any CSS to PDF engine. It's not a nice-to-have, and it's not something that can be done with ICC profiles.

I'd like to see a fuller proposal on how that would fit into CSS. For example, would it also require knock-out to be supported?

[faceless2]

Using an ICC profile to do the conversion is an implementation decision, of course. My reply was mainly in reply to Crissov's second post, not his first - I don't think that adding composition, white-point, linearization as property values to @color-profile is useful. I've no issue with including the definitions of those spaces in the spec.

• I believe the concerns about DeviceN not being a colorimetric specification are unfounded. Provided each separation has a "fallback" value defined in a process colorspace such as device-cmyk, sRGB or an RGB/CMYK ICC space, they can be converted to that for blending. That's how they're defined in PDF and PostScript, and any PDF viewer that displays a PDF on screen has to do this already.

I outlined one such algorithm at the bottom of #2023, along with a demonstration showing how it could be defined in CSS and document showing the result. If you think this approach has legs I'm happy to flesh this issue out, or open a new one without the considerable cruft of my earlier comments - as you prefer.

• Regarding opacity, SVG filters etc., these are currently defined in the spec as requiring conversion to RGBA first. I'm not proposing changing this, as I know full well the horrors this would lead to.

• Regarding "knock-out" - I understand this term to describe the current rendering model, where drawing red over blue (or cyan over black) replaces the background color completely. The opposite being "overprint", where inks not present in the current colorspace are unchanged. This only makes sense with additive color and is not supported in CSS, although again Prince, AH and RealObjects all support it via a non-standard property. Is that what you're getting at?

I'm very much aware of the difficulty in rendering overprint on screen - we have a PDF to bitmap converter and don't currently support it when rasterizing, as it requires keeping track of each individual color separation. I certainly don't expect browser engines to support this rendering model. As none of the suggestions so far preclude adding later support for it, I'd be inclined to kick it down the road and deal with it later myself.

[svgeesus]

These parameters could even become descriptors in @color-profile, but that would be worthy of a dedicated issue.

They could, but

1. The examples you give are all predefined colorspaces so don't need (and must not have) an @color-profile
2. The things that actually need an @color-profile in practice (calibrated CMYK or CMYKOGV print) are non-additive and the ICC profile is a large, inverted 4D or 7D lookup table of measured Lab values for a sampling of ink combinations, which does not lend itself to your approach.

In summary yes, we could replace ICC profiles for RGB spaces with your suggested alternate formulation as descriptors, but that would have no advantages and many disadvantages such as incompatibility with existing infrastructure, so we won't.

[Crissov]

What about the example code, though?