- From: Marc Edwards via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Jun 2022 09:05:50 +0000
- To: public-design-tokens-log@w3.org
> * sRGB color space (or is that color _profile_?) Essentially the same thing. A color profile usually refers to the file that describes a color space. > Safari, soon Chrome and perhaps other browsers, platforms and tools support wider gamuts (i.e. _more_ colors that don't exist in the sRGB space) and/or higher color depths (the _precision_ with which colors within a given color space can be specified). Design systems wanting to use such wide gamut and/or higher depth colors therefore cannot accurately represent them using the DTCG format. It’s complicated. Support for wide gamut images has been pretty good across the board for ages, but support for wide gamut colors in CSS is newer and not as well supported. It’s absolutely the future though, and a new spec now should take it into consideration. The great news is that it’s not really wide gamut support we’re discussing, it’s just for the spec to be color space aware. If you’re taking colors seriously, you have to be aware of the color space they’re in. For native apps, wide gamut support for colors has existed on iOS, macOS, and Android for many, many years. > The syntax for color values proposed by @romainmenke could resolve these issues because: > > * The floating point numbers for each channel offer a much higher color depth than the 8bits afforded by the hex format the spec currently specifies Yep, floats are good idea. If only one format is supported, it should be floats. If supporting HEX can _also_ be done, that’s great. > * Explicitly stating the color space lets folks use different color spaces. Though, I'd imagine the spec would need to define a finite set of color spaces that can be used in order to enable interoprability. A finite set of spaces would be totally fine. If no color space is specified, sRGB should be assumed (I think this should be explicitly stated in the spec). Essential: - sRGB space - Display P3 Bonus points: - Rec.2020 - DCI-P3 - Adobe RGB - sRGB-linear (AKA scRGB) > 1. Is it possible to do a lossy conversion from a higher color depth to a lower one? It’s possible to do lossy conversions between color space and color depths. > 2. Is it possible to do a lossless conversion from one color space to another for colors where their gamuts overlap? There’s almost always a loss in precision, but if the color depth is enough and if the space you’re converting to is contained inside the color space you’re converting from, it’ll be fine. >* I'm assuming if a color in space A does not exist in space B's gamut, the conversion would necessarily be lossy. Right? That will typically result in colors being clipped/clamped. It would mean a color outside the destination color space will look different (often duller). > Assuming the answer to 1. is "yes", then any tools that only support 8bits per channel could simply do the lossy conversion from the token's "raw" floating point value. Depending on their needs, this could be done at the point at which they load a tokens file or at the point at which the value is displayed in the UI. Yep, definitely. FWIW, color depth conversions are super easy. Color space conversions are non-trivial, and a library will often be needed. > The use-case that requires some further thought would be a tool that can import, manipulate and then export token files. Ideally any tokens in the original file that were imported, not modified and then included in the exported file would be perfectly preserved. However, if the import process inluded a lossy conversion, then the corresponding exported token would no longer be the same. I think that's a broader topic as it applies to other kinds of tokens too. For example dimension tokens with `rem` values. If they were to travel through a tool that internally only supports `px` values, there's the same kind of challenge. I think I'll therefore open a separate Github issue for this specific topic. I think your assumptions are correct and imported colors could be clipped or have rounding errors. That’s on the tool though — if the spec defines a color space and colors are floats, best practices are being covered. > The question therefore becomes, if we were to go down this route with the spec, which other color spaces should we support? Please see my list above. :) It’s a pretty non-controversial list! > Question: Is there a color space that has a gamut wide enough to encompass all other color spaces? If so - and assuming you can convert in gamut colors losslessly between spaces - then would it not suffice to only add that? There’s a few answers to this. Rec.2020 is pretty huge, and that will cover quite a lot of future advancements. ACES is way better again. sRGB Extended allows for values beyond 1.0, which means it can also cover anything. But, in all honesty, it makes sense to support Display P3 before other spaces. -- GitHub Notification of comment by marcedwards Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/137#issuecomment-1167085285 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 27 June 2022 09:05:53 UTC