Color Library Design - What to Model? #201
dragonfly-ai
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
How would you characterize the fundamental requirements of a Color library? What core concepts do you consider? What do you want a color library to do for you?
The Color Science domain makes use of the terms: Working Space, Gamut, Color Space, and Color Model, so perhaps at a minimum, a color library should model these concepts:
A Working Space seems defined by:
a. An Illuminant or White Point expressed as a three dimensional vector with real valued components. This illuminant further decomposes into:
b. Three Chromatic Primaries representing red, green, and blue basis vectors. The sum of these equals the illuminant.
c. An invertable Transfer Function, also called a Companding Function, which non-linearly maps color component intensity values to fixed intervals, e.g. [0-1] or [0-255], in ways meant to apportion more of the interval to intensity ranges correlated with high sensitivity in human vision systems, at the expense of intensity ranges that humans struggle to distinguish. Generally the transfer function plays a role in conversions from XYZ to RGB color models.
A Gamut can take the form of a bounded volume in 3 dimensional space, and represents all colors available to human color perception constrained by the illuminant and the Chromatic Primaries from the Working Space, and often in applied contexts, the Color Model. We refer to unconstrained Gamuts as: Full Gamut.
A Color Space approximates (usually mathematically) a gamut, often as a transformation and/or subspace of the full gamut to model constraints such as lighting conditions or the capabilities of specific physical display devices. Examples of popular color spaces include:CIE Lab* and sRGB.
Color Models, such as RGB, RGB24, HSL, CMYK, etc, specify formats for encoding color values numerically for digital storage, manipulation, and transfer.
Most libraries also provide ways of converting between various color models and color spaces.
Would you add or subtract anything from this list?
Do you use alternative terminology? Should a color library embrace technical jargon from Color Science for the names of types, methods, fields, functions, and data structures, or should it favor computer science vernacular?
For example, because a color model has no meaning without its color space, and a color space derives from a working space, the distinctions between all three can blur. A color model is an element of a color space; a color space is the set of all possible instances of a color model. A color model is defined as the intersection between all possible visible colors from a working space and all possible representations of those colors which can be encoded in a color model. How should a library code these relationships? Which concepts should it consider as types, which as values, and how should they interact?
For example, a working space has a very regular structure, so one class can handily encode all working spaces. However, the meaning of a working space seems more akin to the meaning of types; it makes no immediate sense to compare a color from one working space to a color of another. Should a color space:
Furthermore, a library must decide whether to capture these concepts with types, fields, singletons, convention, or context. However, depending on perspective, mapping these color science ideas to programming language can lead to contradictions. Perhaps most glaringly, the XYZ color model has a circular relationship to color spaces and working spaces in the sense that an XYZ value has no meaning outside of a working space, yet, the working space defines its illuminant and chromatic primaries as XYZ values. How would you address this chicken and egg paradox in code?
Beta Was this translation helpful? Give feedback.
All reactions