Derrington-Krauskopf-Lennie (DKL) color space support

[marcpabst]

Conversion for these colour spaces depend on the spectral properties of the display, so I'm not entirely sure how to represent them in the current type system? It would either add another layer of complexity in that RGB spaces would need to be tagged with their emission spectra, or it would be a lossy conversion. Still, would be nice to be able convert them to RGB using a given conversion matrix.

I think this will need some discussion before persuing this, but see: #352

[Ogeon]

The idea I had for LMS was to make the type aware of its own conversion matrix, but I haven't really been digging into that subject yet. I'm thinking that if there's a well known matrix from XYZ, it could be encoded as a type parameter of LMS so it remembers how to convert back.

[marcpabst]

As far as I understand, the problem with converting from LMS to CIE 1931 XYZ is that the cone response functions (or derived colour matching functions) differ. So, you would actually need to know the precise spectral make-up of the colour in question.

Also, while we're at it, there are a few other things I would really like to see:

• I think it might be worth implementing CIE-170 as well, which is a CIE 1931 alternative based on the cone spectral sensitivity estimates of Stockman and Sharpe (incidentally, I just realised that most of the measurements for these functions were taken in a lab just above my current office).
• It would be really cool if you could define your own XYZ space with your own colour matching functions!
• It would be nice to support different (standard) observers. I don't think they would necessarily need to be part of the type system but could just be represented as different XYZ colour types.
• A spectrum type would be great (I think there is an issue about that somewhere already) that allows converting from a raw spectrum to any colour space (this would be a one-way conversion).

Some of the points would require computing the conversion matrices that are currently taken from Bruce Lindbloom's website ourselves (but that should be doable at compile time without any performance implications), and functions like rgb_to_xyz_matrix() would potentially need to be deprecated (which XYZ space?) or maybe just parameterised?

I realise that some of these things are quite specific to colour sciences/vision sciences/psychophysics and might not fit your vision of this crate. Let me know what you think! If you think this would be a good fit, I think I could afford putting some time into this and maybe help with maintenance a bit. I'm short on time (as always) but I will try to meet with someone from Andrew Stockman's lab next week to get a better understanding of these thing and maybe avoid some potential pitfalls.

[Ogeon]

It's great that you bring this up, because I would surely have missed it. Let me just put on the moderator hat for a moment and ask that we keep the LMS (and DKL?) discussion in #352, so we can follow it more easily. I will respond there. The same goes for any a potential spectrum type. It would be better to have that discussion in #64. As for the rest, I'm happy to discuss possible extensions that makes Palette more useful in those subjects. I could convert this issue to a discussion thread if you would like to discuss possibilities, rather than requesting a specific feature.

[marcpabst]

I think converting this to a discussion (or start a new one) to discuss more far-reaching questions is a good idea - let's use this one to track DKL space support!

[Ogeon]

Sounds good! Feel free to open a discussion thread. I'll rename this issue.