[css-color-4] Should lab() colors which are outside the sRGB gamut be rendered on capable displays?

[smfr]

Lab and LCH colors can be outside the sRGB gamut. https://www.w3.org/TR/css-color-4/#specifying-lab-lch says nothing about how to render those colors, other than not clamping lightness.

There is text about how to convert lab/lch to sRGB, so implementors may take this to mean that lab/lch should be converted to sRGB for rendering, but UAs that wish to support extended color rendering may choose to map lab/lch into some other working colorspace. I think the spec should make this clearer. Maybe #300 needs to be resolved before that happens.

[smfr]

@svgeesus

[svgeesus]

There are two cases:

1. The color is used as-is. In that case, it will be converted to the display (or other output device) gamut in the usual way (for ICC-based implementations, the source profile will be Lab and the destination profile will be the 'full gamut' or 'native' display or printer ICC profile
2. The color is manipulated first. The color manipulation functions in CSS Color 5 are defined to use lch() by default. Gradient interpolation and compositing are currently defined to use sRGB; working colorspace allows that to be changed (including display-p3, or laborlch`). The resulting color is then converted to the display (or other output device) gamut .

I agree that this needs to be stated explicitly, otherwise implementers could easily guess wrong.

For case 1. it is independent of #300

This probably needs a new section in the spec.

[css-meeting-bot]

The CSS Working Group just discussed Should lab() colors which are outside the sRGB gamut be rendered on capable displays?.

The full IRC log of that discussion

<dael> Topic: Should lab() colors which are outside the sRGB gamut be rendered on capable displays?
<dael> github: https://github.com//issues/4646
<dael> smfr: Apple display supports P3 which is wider. Makes sense to allow an author to get brighter colors. An author working on a lower gamut display may spec colors outside srgb and thye don't know it.
<dael> leaverou: That can happen. Thre are monitors smaller than srgb. Current colors have this problem
<dael> chris: smfr I assumed question was retorical and you're saying chris please document this
<dael> smfr: I wanted to it be clear we're not using lab as a way to spec things immediately converted to srgb
<dael> chris: Yes. Thank you
<dael> AmeliaBR: Suggestion is that the default behavior is use max gamut available on device and if you want clamping you need to use workin color space
<dael> leaverou: Could wrap in rgb funt
<dael> chris: Mainly needs to say use widest gamut possible and therefore clamp as late as possible
<Rossen_> s/funt/func/
<dael> dbaron: Should space say how to deal with displays with narrower gamuts?
<dael> dbaron: Rendering intent in SVG
<dael> chris: Yes, exactly. I plan to use that b/c currently have horrible per component clamping. As you say there's this metrec that's much more internded
<dael> myles: Is this tested?
<dael> chris: Reference modes, yeah
<dael> florian: Follow up. When you say gamut is smaller I suspect displays less then srgb we pretend is srgb?
<dael> chris: Yes. Highly sub srgb probably don't have color profiles so you get what you get.
<TabAtkins> Hm, testing is interesting here. Does the output's gamut affect computed values?
<dael> Rossen_: Anything else on this?
<TabAtkins> I don't think it does, so this would be purely visual.

[jrus]

IMO document color space should be explicit (or should default to sRGB if not specified), and out-of-gamut CIELAB colors should be brought into document gamut (e.g. by clamping chroma along a ray of constant hue/lightness) before display.

If someone wants to take advantage of a P3 display (or whatever) then that should be explicitly opted into by the document.

Then authors will be able to reliably target sRGB vs. P3 (etc.) displays, and an author who sets the document to sRGB mode will see the same output as an sRGB display, even if the display they are looking at has a wider gamut.

Otherwise it becomes very difficult for an author to simulate on their own wide-gamut display what typical viewers on an sRGB display will see.

AmeliaBR: Suggestion is that the default behavior is use max gamut available on device and if you want clamping you need to use workin color space

Please don’t do this.

dbaron: Rendering intent in SVG

Many kinds of color gamut mapping lead to quite bad results. Often the gamut mapping done by software following “rendering intent” is horrific (in general authors do not understand what “rendering intent” means, and most of the rendering intents are inappropriate for most use cases; in the context of the web pretty much only “relative colorimetric” makes sense).

If you don’t like clamping to max-gamut-chroma along a constant hue–lightness ray, then there are other possible choices (for ideas, perhaps read Morovič (2008) Color Gamut Mapping), but some kind of decent default should be explicitly specified or implementers will end up with an inconsistent mix of bad implementations.

[svgeesus]

There is text about how to convert lab/lch to sRGB, so implementors may take this to mean that lab/lch should be converted to sRGB for rendering, but UAs that wish to support extended color rendering may choose to map lab/lch into some other working colorspace. I think the spec should make this clearer.

I agree that this could have been misunderstood. I have:

• made sRGB be an example for RGB to Lab, and clarified that the sample JavaScript code has conversions from several RGB spaces
• clarified that the a reason to do Lab to RGB conversion is on-screen display
• clarified that the display profile should be used for this
• changed the example to use Lab to display-p3
• added brief CMYK to Lab and Lab to CMYK overview, indicating the ICC profile should be used for the conversion

The part about gamut mapping is still to be added

[svgeesus]

Gamut mapping section added d51a437