Can I use LUT3D_Jakob2019 to build a lookup table for XYZ instead of RGB?

[hakanai]

I have an application where I'd like to convert XYZ to a spectrum, and the Jakob2019 method seems like the best current option.

Rather than writing a slow method to do this, I thought I could generate the Jakob2019 data table using this library and then just read the file from my own code (non-Python) and do the fast lookups from the data table.

But, the data files which they released along with the paper don't include the data file for XYZ. Their generation script does support generating the file for XYZ, and generating the XYZ data file does work, after a lot of fiddling with dependencies, but on closer inspection, their code doesn't take the colour matching functions into account at all when doing the optimisation work. So I am going to find it really hard to round-trip this with my existing logic (I want to be able to convert from XYZ → spectrum → XYZ and get the original value back, where possible).

At some point, XYZ_to_sd_Jakob2019 was updated to take XYZ as input instead of RGB, but the same wasn't done for the LUT3D_Jakob2019 class, so it still takes an RGB_Colourspace and requires me to pass in RGB.

But this is Python afterall, so is there a non-obvious value I can pass into that thing to get it to generate the table for XYZ anyway?

Or, am I better off cloning that class and making an XYZ version?

[KelSolaar]

Hi @hakanai,

The main reason that the LUT3D_Jakob2019 was not updated is because we need to be able to read the existing optimised LUTs from @wjakob.

I think the cleaner would be indeed to take the existing code and probably modify it to make an XYZ version. One problem you will find though is that while sampling a RGB colourspace is easy because it is a cube, doing so with CIE XYZ is not trivial!

Cheers,

Thomas

[hakanai]

Well...

RGB is only a cube if you constrain the values to 0~1, but as soon as emission is involved they're going to exceed 1, so I think it's non-trivial for RGB as well. I was hoping to scale the values to the range the LUT supports, look up the spectrum and then scale the spectrum back up by the same amount. And then when I integrate that, I should hopefully get back what I started with.

If anything, the biggest problem I can see using the table with XYZ is that XYZ contains a lot of values the eye can't see, so the table might be wasting a lot of space with nonsense entries.

But in any case their code does already support generating the table with XYZ:

/// Currently supported gamuts
enum Gamut {
    SRGB,
    ProPhotoRGB,
    ACES2065_1,
    REC2020,
    ERGB,
    XYZ,
};

And if you use XYZ there, you get a table in exactly the same format, so it's still going to be compatible.

[KelSolaar]

RGB is only a cube if you constrain the values to 0~1, but as soon as emission is involved they're going to exceed 1,

Nothing prevents you to normalise the values before though.

If anything, the biggest problem I can see using the table with XYZ is that XYZ contains a lot of values the eye can't see, so the table might be wasting a lot of space with nonsense entries.

Yeah this is the main problem I foresee.

[KelSolaar]

Thinking about it, you could design a RGB colourspace that is effectively XYZ and thus not have to change the code (assuming the LUT build works with it):

>>> import colour
>>> import numpy as np
>>> colour.primaries_whitepoint(np.eye(3))
(array([[ 1.,  0.],
       [ 0.,  1.],
       [ 0.,  0.]]), array([ 0.33333333,  0.33333333]))