Re: [community-group] Loosen up the color type (#79)

@NateBaldwinDesign I agree that the "channels" value should not be labeled, storing them in an array makes sense to me and allows for an extensible system of arbitrary channels and data types where we can define the encoding model, the colourspace (how software should interpret these values), and finally the values themselves in the array.  I'd also like to ammed my previous comment about skipping the encoding model, it would be useful to specify both in the case of normal map channels where there are two different common encodings (OpenGL & DirectX) but both should be interpreted as data.  I'm sure this isn't the only use case where it's useful to seperate the two.

Perhaps something along these lines...
```json
{
"color": {
  "encoding": "rgb",
  "colorspace": "srgb",
  "channels": [0, 0.54321, 1]
},
  
"alpha": {
  "encoding": "data",
  "colorspace": "data",
  "channels": [0.5]
},

"normals": {
  "encoding": "directx",
  "colorspace": "data",
  "channels": [0, 0.54321, 1]
}
}
```

I don't know why I had it in my mind that different numerical data types should be supported, maybe becuase I wrote that late at night. 😅   Storing all values as floats all the time is a good idea.

As for enforcing _integer floats_ however, it is worth letting users and programs write values in a design token that are open-domain.  RGB values "higher than 1" are often required when doing photoreal compositing tasks.  Software like Nuke and After Effects allows users to blow their pixel values past their set gamut boundary and will not clip values until they get sent through the EOTF either on-write or in the viewport.  For most design software today of course this isn't the case (as much as I'd like it to be) and I don't think it's unreasonable for those open-domain values to be clipped according to their encoded `colorspace` tag when the token is used (though perhaps with a warning) in less colour aware programs.  I would expect software to handle things similarly when shifting out of gamut colours into the destination space in the case of using P3 encoded design token values in an sRGB document for example.

Similairly, if we want design tokens to fully accomidate the intricacies of digital colour, they should be able to store _negative values_ as well.  CIE XYZ tristimulus values will plot to negative values if they are outside the destination gamut and the same will occur when reprojecting P3 values onto sRGB.  As such, despite the fact that they may be outside of the current working space gamut (which we've already defined as a feature of some image manipulation software) users should be able to encode these as they are not actually invalid values.  I imagine this will rarely be used in practice, but in cases where negative values are present in a design token but once again unsupported by software they should clip to 0 and again, show a warning.  In any case, I'd just once again make the case that we shouldn't limit ourselves to what most software _can_ do and instead strive to properly implement the transfer of digital colour values while giving software developers a path to implementing digital colour correctly.

-- 
GitHub Notification of comment by Shrinks99
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1332867911 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 30 November 2022 23:24:53 UTC