#[non_exhaustive]pub enum Color {
Rgb {
primary: Primaries,
transfer: Transfer,
whitepoint: Whitepoint,
luminance: Luminance,
},
Luma {
transfer: Transfer,
whitepoint: Whitepoint,
luminance: Luminance,
},
Yuv {
primary: Primaries,
whitepoint: Whitepoint,
transfer: Transfer,
luminance: Luminance,
differencing: Differencing,
},
Oklab,
Scalars {
transfer: Transfer,
},
SrLab2 {
whitepoint: Whitepoint,
},
}Expand description
Identifies a color representation.
This names the model by which the numbers in the channels relate to a physical model. How exactly depends on the variant as presented below. Some of them can be customized further with parameters.
Notably, there are NOT the numbers which we will use in image operations. Generally, we will use an associated linear representation of those colors instead. The choice here depends on the color and is documented for each variants. It is chosen to provide models for faithful linear operations on these colors such as mixing etc.
TODO: colors describe paths to linear display, so we should somehow implement direction conversions such as “BT.2087 : Colour conversion from Recommendation ITU-R BT.709 to Recommendation ITU-R BT.2020” in a separate manner.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Rgb
An rgb-ish, additive model based on the CIE 1931 XYZ observers.
The linear representation is the screen space linear RGB, which depends on primaries, whitepoint and reference luminance. It is derived from the encoded form through the transfer function.
Luma
A pure lightness color based on linear stimulus interpolation.
This is a Yuv without reference to any particular differencing scheme for the two chroma
channels.
Yuv
A lightness, chroma difference scheme.
For the L component, this is equivalent to either a Luma or LumaDigital model
depending on the Differencing scheme used.
This library does not reliably implement all conversion optimizations that are possible. Please refer to test and benchmark coverage.
Oklab
The simple but perceptual space Oklab by Björn Ottoson.
The linear representation of this color is Lab but its quantized components are may be either Lab or LCh.
It’s based on a combination of two linear transforms and one non-linear power-function between them. Coefficients of these transforms are based on optimization against matching pairs in the detailed CAM16 model, trying to predict the parameters in those pairs as precisely as possible. For details see the post’s derivation.
Reference: https://bottosson.github.io/posts/oklab/
Scalars
A group of scalar values, with no assigned relation to physical quantities.
The purpose of this color is to simplify the process of creating color ramps and sampling functions, which do not have any interpretation themselves but are just coefficients to be used somewhere else.
The only SampleParts that are allowed to be paired with this are XYZ.
Additionally, you might use the images created with this color as an input or an
intermediate step of a transmute to create images with chosen values in the linear
representation without the need to manually calculate their texel encoding.
Fields
SrLab2
A LAB space based on contemporary perceptual understanding.
The newly defined SRLAB2 color model is a compromise between the simplicity of CIELAB and the correctness of CIECAM02.
By combining whitepoint adaption in the (more) precise model of CIECAM02 while performing the transfer function in the cone response space, this achieves a good uniformity by simply modelling the human perception properly. It just leaves out the surround luminance model in the vastly more complex CIECAM02.
This is lacking for HDR. This is because its based on L*ab which is inherently optimized for the small gamut of SDR. It’s not constant luminance at exceedingly bright colors where ICtCp might provide a better estimate (compare ΔEITP, ITU-R Rec. BT.2124).
Reference: https://www.magnetkern.de/srlab2.html
Fields
whitepoint: Whitepoint