More general representation of XYZ spaces, custom colour matching functions (CMFs), and Spectrum type/trait

[marcpabst]

Following the initial discussion at #376, here's some brainstorming on developing a more flexible approach to representing XYZ colors. Feedback appreciated!

• have a Spectrum type or trait that can represent colors, (empirical) CMFs, and cone sensitivity functions (cone fundamentals)
• (re-)specify common XYZ spaces using CMFs¹, _{(i.e., CIE 1931 2-deg, CIE (1964) 10-deg, Judd-modified CIE 2-deg color matching functions, CIE (1964) 10-deg, CIE-170 2-deg & CIE-170 10-deg (based on LMS cone sensitivity functions²))}
• allow arbitrary XYZ spaces based on user-provided CMFs
• possibly define LMS space in a similar way _{(related: there are a number of ways to do the LMS -> XYZ transform, see e.g., Stockman & Sharpe (2000) - both Hunt (2004) and Smith & Pokorny (1975) seem like popular options. However, I'm not sure if this could be generalized to work with different XYZ spaces and cone fundamentals)}
• allow transformation from spectrum to any XYZ space³
• compute transformation matrices to other color spaces⁴ at compile time where possible, and at runtime for user-provided CMFs or cone fundamentals

There are a number of reasons why it would be useful to allow this kind of flexibility:

• commonly used CMF are based on the population average - being able to use data from individual participants might be useful for research applications
• the LMS space is useful for research where photoreceptors need to be stimulated in a highly-controlled way (e.g., silent substitution experiments, where colors are changed in a way that only the activation for one type of cone is varied while the activation of the two other types is constant) and allowing arbitrary CMFs allows modeling of the spectral characteristics of the display device (assuming you have a spectrophotometer at hand).

Footnotes

1. Empirical CMF data can be found here: http://cvrl.ucl.ac.uk/cmfs.htm ↩

2. https://www.sciencedirect.com/science/article/pii/S0042698900000213 ↩

3. http://www.brucelindbloom.com/index.html?Eqn_Spect_to_XYZ.html ↩

4. http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html ↩

[Ogeon]

Thanks for making this thread. Let's see if I understand this correctly. Since we have different definitions of XYZ, for example based on different measurements, it would be useful to parameterize the type by those. So in essence, the current Xyz would rather be Xyz<Cie1931TwoDeg, T> (or whatever we call it), and we could also have marker types for other common options. Each of these would technically still be independent of reference white points, right? So we may want to parameterize them further for convenience: Xyz<Cie1931TwoDeg<D65>, T>. These meta types could also be linked to constant CMF data for spectral conversion.

Runtime data may need some experimentation or a more dynamic fallback, but should be some way to link the values if we want to prevent mix-ups. Perhaps optionally, so there's the dynamic option when the marker types become impractical.