Percentage number coords: why do the percentage value ranges of the sRGB Space coords differ from seemingly all others? #643
Replies: 2 comments 3 replies
-
|
Color.js is aligned with the new color syntax for RGB spaces: https://www.w3.org/TR/css-color-4/#color-function. The original use of 0-255 is based on the usage of colors in UINT8 storage types, 0-1 is a more convenient range in floating point. It's pretty trivial to multiply your values by 255 if you must consume them in the 0-255 range. You can also go the route of creating a custom color space class that automatically outputs the color in this range. More info on such an approach can be found in this discussion: #593. |
Beta Was this translation helpful? Give feedback.
-
|
Don't get me wrong, sRGB using [0, 1] is just as fine to me as it using [0, 255] (and if one has advantages with regards to mathematical operations, precision, etc., perfect). And the conversion to whatever range I might need is trivial. My point is rather that this is (at least as far as I can tell) inconsistent between color spaces: Why is HSL's s and l channel not using [0, 1] but [0, 100]? Again, either seems just fine to me, but it being different between spaces is what I'm wondering about. Both use
|
Beta Was this translation helpful? Give feedback.
-
|
Well, some spaces are spec'd very specifically. For instance, Lab is always used with 100 for max lightness whereas Oklab uses 1 for max lightness as that is how it was designed and spec'd. sRGB is a little funny as the 255 range is an artifact of the storage type it was often stored in and also relates to the hex output. With the new RGB CSS syntax, it made sense to move to 0 - 1 as that is what the new So, generally, Color.js has tried to match CSS conventions, but CSS has conventions that are a bit different depending on the space. |
Beta Was this translation helpful? Give feedback.
-
If you want to format an individual channel I would look into the Format and Type classes I would be nice if there was a higher level interface to the |
Beta Was this translation helpful? Give feedback.
-
This is quite useful; I didn't know this existed. I can get to serialize a good format using something like this: const color = new Color('oklab(88% 0.145 -0.392)')
// I store a tuple like this per space I deal with
const channels = [
['l', '<percentage>'], ['a', '<number>'], ['b', '<number>'],
]
const formatByCoords = color.space.getFormat('default')?.coords ?? []
channels
.map(([channel, preferredType], index) => {
const internalValue = color.coords[index] ?? 0
const type = formatByCoords[index].find(({ type }) => type === preferredType) ?? formatByCoords[index][0]
return type.serialize(internalValue, 5)
})However, I can't figure out how I can access the On the other side, these classes don't seem to help me deserialize a string back to the internal representation that I would use to construct a |
Beta Was this translation helpful? Give feedback.
-
TL;DR: why does the sRGB space store its coords in
<percentage>s in the range [0, 1] when seemingly all other spaces use the<number>ranges of their<percentage> | <number> | noneCSS value types (e.g. [0, 100] for HSL's s and l channels)?For the s and l channels of an HSL color, the internal values on the
coordsproperty are relative to the value 100 (e.g. 50 = 50%). For the r, g, and b channels of an RGB color, the internal values on thecoordsproperty are relative to the value 1 (e.g. 0.5 = 50%). Seemingly for all other spaces (I checked HWB, Lab, LCH, Oklab, and OkLCH), the coords behave like HSL. Why that difference?I want to output coords formatted such that they're valid values in a CSS color (and vice-versa: read exactly this output and turn into coords for a
new Color(). I want to do so by channel so I can't just format the whole number. I want to format an individual channel.It should only take knowing what CSS specifies as a valid type for that channel to do so. For example, I can look up https://www.w3.org/TR/css-color-4/#funcdef-rgb and find out that RGB channels are relative to the value 255 for
<number>and relative to the value 100 for<percentage>. Similarly for HSL (https://www.w3.org/TR/css-color-4/#funcdef-hsl), I find that both<number>and<percentage>on the s and l channels are relative to the value 100. For my purposes, I'm fine with outputting the<number>representation so for the colors in the example above, I want to show50for the HSL color's s channel and 127.5 for the RGB color's g channel.This is difficult to do with the colorjs.io coords using different ranges like that because I can't rely on the fact that a channel that is
<percentage> | <number> | nonein CSS is stored as a value in one knowable range in colorjs.io. I also have to know which space I'm dealing with and I have to know that per space I'm interacting with. I do always know the space, but it makes the logic for outputting the right things needlessly complex. Ifhsl.coordswere[ 270, 0.5, 0.25 ](andrgb.coordsunchanged) orrgb.coordswere[ 255, 127.5, 63.75 ](andhsl.coordsunchanged), I could remove the knowledge of which color space I'm dealing with from this process; I'd just need to know the CSS type definition of the channel itself and the formatting would be easy.Looking further into this, it almost looks like an oversight that RGB coords are stored/represented this way in colorjs.io
Beta Was this translation helpful? Give feedback.
All reactions