As far as I can see, libdcp does RGB to XYZ colour space conversion using a fairly calculation-heavy process.
https://github.com/cth103/libdcp/blob/main/src/rgb_xyz.cc#L270-L338

Applying 2.6 gamma for XYZ uses a LUT (presumably to avoid slow pow() operations) performed "piecewise" - so actually 1 LUT for small values and a 2nd LUT for larger values.

Judging by rgb_xyz_lut_test, this LUT is a slight approximation, and produces inaccuracies of +/-1 for at least some values.
https://github.com/cth103/libdcp/blob/main/test/rgb_xyz_test.cc#L154-L162

(also I'm not sure if rgb_xyz_lut_test is testing all relevant values - 0.000001 may not be small enough to cover the very bottom of the scale where errors are most likely)

For at least some input colour spaces, I wonder if it'd be workable to use a 3D LUT which maps from all possible RGB/YUV inputs to XYZ output.

The two most common sources I make DCPs from are:

• H264 (usually 8-bit YUV)
• ProResHQ (usually 10-bit YUV)

Memory required for 3D LUTs mapping all possible input RGB/YUV values to 12-bit XYZ would be:

8 bit input: 2^24 2 bytes/pixel = 32 MiB
10 bit input: 2^30 2 bytes/pixel = 2 GiB
12 bit input: 2^36 * 2 bytes/pixel = 128 GiB

These numbers could be reduced by 25% by packing the bits, at the cost of extra operations to unpack them.

Obviously 128 GiB is too much memory! But 32 MiB seems quite modest, and for computers with plenty of RAM, 2 GiB is also not entirely unreasonable. I often see a single browser tab in Chrome eating up 200+ MB.

I assume that a single LUT lookup per pixel would be faster than all the calculations involved in YUV -> RGB -> XYZ conversion, and it'd also improve accuracy by dispensing with the approximated gamma LUT.

This would be a trade-off between memory usage and processing speed and/or accuracy, but for some common inputs, I think the trade-off might be worthwhile (though I have no idea if colour space conversion is a drop in the ocean compared to the computation required to compress JPEG2000).

Do you think this might be worth investigating? I'd be happy to write a test implementation and benchmark it if you think this may have potential (but in Rust, not C++, I'm afraid).