Add raw light spectrum to XYZ conversion

[tatref]

Hi!

Would it be interesting to add support for spectrum to XYZ conversions?

The spectrum can be represented as a [f32; XXX] (XXX depending on the sampling of the spectrum). Where the f32 values are the intensities (in arbitrary units), for each wavelength from ~400 to ~800 nm. Then the XYZ coordinates are a matter of simple matrix multiplication, given the XYZ weights.

The weights are available on different websites (http://www.cvrl.org/cie.htm)
There is also analytic aproximations (http://jcgt.org/published/0002/02/01/paper.pdf)

I've already started a POC, so I might submit a pull request (the code is not that clean yet though).

Tell me what you think about this.

[Ogeon]

Hello, and sorry for my late response! I was at work and wanted to take my time to write a proper answer. Anyway, this sounds like something that could perhaps fit in. It could also work as a separate library. I did a similar implementation once, and I think it was relatively small, so I guess it won't be a maintenance problem, but it depends on how it will work. (Just thinking about the practical details 😄) Speaking of which, a few things I'm going to request is that it's:

1. self contained, meaning that it keeps track of its own limits and parameters,
2. should catch user mistakes as early as possible (preferably at compile time),
3. fault tolerant, when it can't catch the mistake,
4. at least generic over the float type (preferably as generic as the XYZ type),
5. reasonably bare bones.

I realize that it's tricky and it's no big deal if the POC doesn't fulfill it. Take it one step at the time. It's a POC, after all, and I'm happy to give feedback when I have the time. The reason for this is that I want it to be as easy to use as possible, without relying om too many assumptions (it's a balance act), and I want it to be easy to overlook and maintain in the future. Part of the new order here is also that I'm trying to be more clear with my expectations, and these are the things I can think of right now that I'm usually working towards. Feel free to ask if you want me to elaborate.

Also a few question, out of curiosity: Is the idea that the input spectrum has to match the number of weights, or is there some kind of interpolation in place? Would it make sense to to combine it with the built in gradient code?

I would also love to see the POC, even if it isn't finished. I don't mind, and I have nothing against using pull requests for feedback and as a scratch space. It would also make it easier for me to make a proper decision sooner, rather than later.

[tatref]

Ok so here's the POC, but I couldn't get the generic type working (I can't find a way to convert from Float back to f32)...

For the moment, the input spectrum has to match the number of weights, but we could also add a sparse spectrum (for example using a hashmap<wavelength,intensity> ?)

[Ogeon]

Just to give an update on this feature request, since it pops up now and then. My current stance is that this is probably not going to be 100% covered by Palette. There are a few parts to the problem:

1. Represent a spectrum. How is the data stored and represented? Interpolation? On stack? Heap?
2. Working with a spectrum. Operations, like multiplying, adding, analyzing, what not. Depends a lot on the point above.
3. Converting a spectrum to other color representations. Which observer? How to interpret the representation?

I think (1) representing a spectrum is beyond the scope for this crate at the moment. Different needs require different representations, and that is probably one of the reasons why this hasn't been implemented yet. Working with a spectrum (2) should be possible to support, to some extent, if the spectrum can be abstracted in a nice way. The conversion support (3) is probably the easiest to implement, if the spectrum can be abstracted to the point where we just need to read its values and output a color.