Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-color] Working Color Space #300

Closed
svgeesus opened this issue Jul 10, 2016 · 9 comments
Closed

[css-color] Working Color Space #300

svgeesus opened this issue Jul 10, 2016 · 9 comments
Assignees

Comments

@svgeesus
Copy link
Contributor

@svgeesus svgeesus commented Jul 10, 2016

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

Resolved at San Francisco to add a working-color-space at-rule, which affects the entire document. Compositing, interpolation, blending use this. Initial value is sRGB. linear-sRGB, p3, rec2020, and lab were also discussed as values. Chris to read the canvas spec to see what it does there, particularly for the "optimal" value.

@svgeesus svgeesus self-assigned this Jul 10, 2016
@karip
Copy link

@karip karip commented Jan 10, 2017

Should the initial value be "auto"? Safari 10 seems to implement something like that. It means that on sRGB monitors, the working colorspace is sRGB. On P3 monitors, the working colorspace is P3.

Edit: actually, I'm not sure what Safari does. But, it is able to show P3 images correctly on P3 monitors without a working colorspace at-rule.

@svgeesus
Copy link
Contributor Author

@svgeesus svgeesus commented Jan 24, 2017

Edit: actually, I'm not sure what Safari does. But, it is able to show P3 images correctly on P3 monitors without a working colorspace at-rule.

That doesn't require a working colorspace. Things like interpolation and compositing of colors from different spaces are where this is needed.

The initial value, for Web-compat reasons, will be sRGB (because that is what is currently used).

@frivoal
Copy link
Collaborator

@frivoal frivoal commented Jan 25, 2017

That doesn't require a working colorspace

Is that because when no interpolation / composition is needed, we can just do:
input space ---- (via CIE-lab)----> output space (which is a no-op when input=output)
instead of
input space ---- (via CIE-lab)----> working-space ----(via CIE-lab)----> output space
?

Presuming that's the case, it means that converting from the input to the output space is something that can happen late in the pipeline, well after computed or even used values. In which case the resolved value (result of getComputedStyle()) would presumably be the same as the specified value. This also seems fine when it comes to compositing.

However, when it comes to interpolation (gradients, animations...), this looks like something that you should be able to resolve at computed value time, as it does not depend on layout, much less painting or compositing. And that means it should affect the computed value and the result of getComputedStyle() somehow.

So how do we spec that? do we say that the computed and used values are the specified values, even in the cases where they will be used as inputs for an interpolation, but that when a property is set to a color that is the result of an interpolation (e.g. because of an animation / transition), then it is set to the right color in the working color space at computed value time?


Note: this relates to #871, #741, #480, #867, #883 (at least)

@css-meeting-bot
Copy link
Member

@css-meeting-bot css-meeting-bot commented Apr 21, 2017

The CSS Working Group just discussed Color properties, and agreed to the following resolutions:

  • RESOLVED: Interesting idea, dino will experiment and come back with results.
The full IRC log of that discussion
<flackr> Topic: Color properties
<dino> Github Topic: https://github.com/w3c/csswg-drafts/issues/300
<flackr> dino: idea is that document will have working color space, some kind of css syntax to say what it is, default is srgb
<flackr> dino: there was some discussion as to what does the value if you specify background-color: rgb(255, 0, 0) what space are they in?
<flackr> ChrisL_: this is in sRGB
<flackr> dino: this didn't matter because everything was in sRGB. we think older style colors should be in working color space
<flackr> ChrisL_: downside is if you view source and copy some of their style and document the colors become different
<flackr> ChrisL_: also, one reason to change working color space is because you've got some bit of content you want in a different color space, like a video
<flackr> ChrisL_: you don't want your existing colors to change because you have a new element needing a wider gamut
<flackr> dino: adding the new element doesn't necessarily change colors
<flackr> ChrisL_: if you then want to have a gradient you need to change working color space
<flackr> dino: i propose we change default working color space away from srgb but to be the same as it
<dbaron> s/the same as it/extended sRGB/
<flackr> ChrisL_: in SRGB you've got 0-255 and we used to say you could theoretically go below 0 or above 255 but it was undefined what the transfer code was
<flackr> ChrisL_: there was defined a transfer space called ?? which was a linear mapping which was tried in HTML context for a while but it didn't work well
<dbaron> s/??/scRGB/
<flackr> ChrisL_: you need a wider gamut. going for an older model which isn't compatible with color management systems isn't going to work well
<flackr> dino: concern that ChrisL_ is bringing up is that you would end up with a band as you clamped at the edge of your color space
<flackr> ChrisL_: what is complete gamut range?
<flackr> dino: goes on forever
<flackr> dino: it covers at least P3
<flackr> dino: and should cover ?? (2020?)
<flackr> dino: should we distinguish between linear, SRGB, etc
<flackr> dino: we don't have any way to handle blending in linear space yet
<flackr> dino: designers don't understand what it is, are very used to non-linear blending
<jihye> s/??(2020?)/rec2020
<Rossen> q?
<flackr> ChrisL_: once we're finished with this easy stuff we need to get linear for when we get onto HDR
<flackr> dino: definitely do not want to block out linear, we could definitely add it now
<flackr> ChrisL_: i'd like to see more details about your proposal
<flackr> dino: I was hoping to implement it, do everything in extended SRGB and see what happens. and whenever doing an interpolation convert to the working color space and see how well this works
<flackr> dino: we could make the default working color space extended SRGB, which should be lossless, not out of gamut
<flackr> dino: I can do some experimentation and see if that's okay
<flackr> RESOLVED: Interesting idea, dino will experiment and come back with results.

@css-meeting-bot
Copy link
Member

@css-meeting-bot css-meeting-bot commented Nov 7, 2017

The Working Group just discussed Color, and agreed to the following resolutions:

  • RESOLVED: Chris to do more work :)
The full IRC log of that discussion <eae> Topic: Color
<Chris_> github: https://github.com//issues/300
<eae> Chris_: This issue is about making computations on color boundaries.
<eae> Chris_: If used in a gradient, transitions, animations, etc.
<eae> Chris_: Right now, by default, given that we've never had anything outside of srgb, is that it happens in srgb which is unfortunate. You'll end up with the wrong color due to the gamma curve.
<eae> Chris_: We've had several resolutions where we don't have the right color space.
<eae> Chris_: In April we discussed this and someone suggested a linear 16 bit color space.
<eae> Chris_: That would allow colors outisde of the srgb gamma to be expressed. Another option would be to have it be unbounded.
<leaverou> s/outisde of the srgb gamma/outisde of the srgb gamut/
<eae> Chris_: I'd like to push this forward to have spec text about this.
<eae> Chris_: There will be people here at 3:30 that are exerts in this and will have an in-depth dicussion about it.
<eae> Chris_: One of the reasons I started this community group is to get expert input - should help the spec move forward.
<eae> I don't have a better proposal yet. Does anyone have any thoughts on this?
<dbaron> q+
<eae> pkerr: You need to do you calculations in a linear space. Whether it is sRGB or float-16 that gives you the same flexibility but with better math
<eae> pkerr: Gives an infine space between 0 and 1
<eae> Chris_: The movie industry likes having absolute values defined.
<eae> pkerr: Linear pixels is the way to go.
<astearns> ack bkardell_
<astearns> ack dbaron
<smfr> q+
<eae> dbaron: One comment: I'm fine with putting stuff in spec that isn't quite sure yet but please stick a note on it to explain that/
<dbaron> ack next
<eae> smfr: You can't change the color space to be linear without breaking stuff. A lot of pages have assumptions that would break. Authors needs to opt in.
<Rossen> q?
<eae> pkerr: When I said use linear I meant use it for the math and then convert back, not necessarily switching everything to linear.
<eae> RESOLVED: Chris to do more work :)

svgeesus added a commit that referenced this issue Apr 22, 2019
@george-steel
Copy link
Contributor

@george-steel george-steel commented Jul 30, 2019

Has this gone anywhere? I made a demo of color blending issues to demonstrate the need for this as well as the filter version of this property. Forefox renders to-spec while Chrome uses sRGB even for SVG filters (which should use RGB by default).

@george-steel
Copy link
Contributor

@george-steel george-steel commented Jul 30, 2019

The choice of which representation of linear space to use should probably be left unspecified (probably to be implemented as whatever's native on the platform in question) as all the operations currently used on colors are isomorphic over conversion between different linear spaces. The only caveat should be that tests should allow for enough imprecision for platforms that use float16.

@svgeesus
Copy link
Contributor Author

@svgeesus svgeesus commented Dec 9, 2020

RESOLVED: Chris to do more work :)

OK, more work done. To catch up on this long-standing issue:

There cannot be a per-document or even per-element working colorspace because different options require calculations to be done in different colorspaces:

Also the need for a working colorspace for serialization was removed, serialized value is in the colorspace it was declared.

@svgeesus
Copy link
Contributor Author

@svgeesus svgeesus commented Dec 9, 2020

In consequence, related issues are being or have been raised on other specs. Color 4 says how to specify, resolve, and serialize the colors. Combining them is handled on the appropriate spec as mentioned above, and does not affect Color 4. Thus, this issue can finally be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants