[css-color] What happens to rgb() etc with Working Color Spaces?

[grorg]

https://drafts.csswg.org/css-color/#working-color-space

The rgb() family of functions are defined to produce sRGB values. If we have Working Color Spaces, we'll have to update them all to say they produce a value in that space.

Same with color(<number> <number> <number>)

[svgeesus]

Yes, we need to update them to say that the sRGB value gets converted to the working colorspace. Because all the working spaces are larger in gamut volume than sRGB, there will be no gamut clipping in that case.
It is more tricky for color() if the working colorspace is smaller; then you will get gamut clipping. We should add authoring advice to set working colorspace appropriately if colors are being specified in a colorspace wider than sRGB. The spec needs to say what happens when people don't do that, though.

[grorg]

Ah, so you're saying that rgb() is always sRGB, and it gets converted to the working space.

I'm not sure that's really helpful to authors. I think they would prefer the defaults for all color values to be in the working space, including rgb() and the named colors.

i.e. "red" should be the most reddish value in the working color space

[frivoal]

Ah, so you're saying that rgb() is always sRGB, and it gets converted to the working space.

I'm not sure that's really helpful to authors. I think they would prefer the defaults for all color values to be in the working space, including rgb() and the named colors.

i.e. "red" should be the most reddish value in the working color space

Doesn't sound great to me.

• "darkolivegreen should be the most darkolivegreenish in the working color space". What's that supposed to mean? I sorta see why you'd want that for red, green, blue and possibly other fully saturated colors, but for the rest, it doesn't make much sense.
• This would be error prone and author hostile. Changing the color space of your previously perfectly working page in order to do some new things that call for a bigger gamut mean that you'd need to redefine all the colors in your page, or they'll end up different.

[grorg]

"darkolivegreen should be the most darkolivegreenish in the working color space". What's that supposed to mean? I sorta see why you'd want that for red, green, blue and possibly other fully saturated colors, but for the rest, it doesn't make much sense.

The wording I used doesn't make sense for darkolivegreen. What I meant is that the values for the R, G and B primaries are taken to operate in the working color space. So it's almost certain that darkolivegreen will produce a different color when the working space is sRGB as opposed to P3.

If we don't do it this way, I'm not sure what the point of the working color space is, because all your #rrggbb, named colors, rgb() values are unchanged.

This would be error prone and author hostile. Changing the color space of your previously perfectly working page in order to do some new things that call for a bigger gamut mean that you'd need to redefine all the colors in your page, or they'll end up different.

Exactly!

The alternative is to manually change all the color rules to be in the working color space.

Note that you don't necessarily have to set the working space to "do some new things that call for a bigger gamut". After all, that's exactly what we're doing today without this working color space feature.

[frivoal]

What I meant is that the values for the R, G and B primaries are taken to operate in the working color space.

For any RGB working color space, this will work, but you might get wacky colors, and I don't know how useful that is. If you pick a working color space with 3 channels that aren't RGB, this is going to be weird. If you pick a working color space in CMYK or some other thing with a number of channels other than 3, I don't know what it means.

Exactly!

The alternative is to manually change all the color rules to be in the working color space.

I don't follow: if your existing colors are specified in sRGB and they're the colors you want, you leave them as is. Even if you pick a different working color space, the math works out right, and they look just like you want them too. If you want to define colors in the working color space, you use color().

Note that you don't necessarily have to set the working space to "do some new things that call for a bigger gamut". After all, that's exactly what we're doing today without this working color space feature.

Can you clarify? If you do a gradient from sRGB's most saturated red to P3's most saturated red (or if you don't care about gradients, put 50% transparent one on top of the other), how is that going to work if your working color space isn't P3 or something large enough for both colors to be in gamut?

[Spacefish]

They are converted to the working colorspace and clipped if necessary. Guess the only thing we need to discuss, is which conversion is used.. absolutely colorimetric, relative or perceptual. The standard should define that. So for photographs for example perceptual is what you want most of the time. But there are cases where relative is more appropriate. If the target space is bigger than the source you can just perfectly match the colors, as long as the bit depth allows it.
It should be possible the override the default conversion model as an author.

[svgeesus]

Yes, the specification will need to offer choices for rendering intent on conversion to working colorspace. For matching colors specified in different colorspaces, media relative colorimetric would be the best choice. (Agreed that photographic images would mostly use perceptual).

[cabanier]

"darkolivegreen should be the most darkolivegreenish in the working color space". What's that supposed to mean? I sorta see why you'd want that for red, green, blue and possibly other fully saturated colors, but for the rest, it doesn't make much sense.

The wording I used doesn't make sense for darkolivegreen. What I meant is that the values for the R, G and B primaries are taken to operate in the working color space. So it's almost certain that darkolivegreen will produce a different color when the working space is sRGB as opposed to P3.

I agree. rgb/rgba colors should be interpreted as being in the working colorspace. (Just like it happens in authoring applications.)

If we don't do it this way, I'm not sure what the point of the working color space is, because all your #rrggbb, named colors, rgb() values are unchanged.

The reason for the working color space is so you can have consistent color across devices.
For instance, if an author sets the working space to sRGB, then the page will display the same everywhere (as long as the device's gamut is at least sRGB)

Compositing always happens in the working color space and the end result is then mapped to the output color space.

[cabanier]

Yes, the specification will need to offer choices for rendering intent on conversion to working colorspace. For matching colors specified in different colorspaces, media relative colorimetric would be the best choice.

I thought we agreed at the SFO meeting to not include those for now and state that "relative colorimetric" should be used.

[Spacefish]

This would be quite bad for images with a high color gamut shown on a output device with lower color gamut, as you get nasty banding artifacts, due to colors out of gamut being clipped!
This blogpost: http://sketchminded.blogspot.de/2011/11/color-space-conversion.html explains the differences!

[svgeesus]

Yeah I think we do need both relative colorimetric and perceptual.

[cabanier]

@Spacefish if an author cares about that, it's possible to trigger different images using a media query.
I don't disagree that we should have those parameters _eventually_. For now I believe we should focus on the more important things. AFAIK, designers have not expressed huge interest in controlling this parameter in their workflows.

[karip]

Currently, untagged images are assumed to be sRGB. If rgb() colors are in the working colorspace, then should untagged images also be in the working colorspace?

If I have a web page with an untagged image and matching rgb() colors, then it would be nice if changing the working colorspace would keep the image and rgb() colors matching.

[svgeesus]

Currently, untagged images are assumed to be sRGB.

Yes.

If rgb() colors are in the working colorspace

They aren't

, then should untagged images also be in the working colorspace?

No, because that would be unintuitive and not backwards compatible (as you point out):

If I have a web page with an untagged image and matching rgb() colors, then it would be nice if changing the working colorspace would keep the image and rgb() colors matching.

[grorg]

Current resolution is that rgb and rgba are always in sRGB, regardless of the Working Color Space.