About "CIE XYZ" to "CIE xyY" transformations behaviour with negative numbers.

[sobotka]

Long ago, in a galaxy far, far away, the calculation for xyY was formed back when simpler times existed, and all coordinates were positive.

Right now, in the galaxy very, very close, the calculation for normalization falls apart with negatives. With digital cameras and modern encodings using negative chromaticities to define their respective colour encodings, this is sadly a show stopper.

TODO: This is likely also an issue with Ye Old 1976 Luv* and probably 1960 stuffs.

[KelSolaar]

This is a rather big one, we need to give more explanation and examples on what fails, how and why.

Given the CIE recommendations have not changed, our default behaviour must be compliant, so we will need some "magic" to activate the fixed behaviour.

[sobotka]

Indeed. I can understand the vantage that the CIE reference is canonized. I also believe that the default implementation, in 2021, the formulas should work properly for displaying, for example, camera encodings. I have caught a few plot errors out in the wild that are directly attributed to the negative errors, and it makes one wonder how many are spotted?

Challenging and nuanced surface.

[nick-shaw]

When plotting, I have found it preferable to cull pixels with a Y value below a certain threshold, in order to remove extreme (and meaningless) xy values in the noise floor. There could be an argument that what is really needed is a Y_threshold parameter in the plotting functions.

[sobotka]

There could be an argument that what is really needed is a Y_threshold parameter in the plotting functions.

I don’t think that helps for the case of arbitrary encoding primaries, does it? We should be able to see the 2D or 3D Cartesian position regardless, no?

in order to remove extreme (and meaningless) xy values

Aren’t all values beyond the spectral locus meaningless? ;)

[KelSolaar]

So just to illustrate what we are talking about here for the general audience

Given this code to generate an ACES IDT matrix, we are all good:

import colour
import numpy as np

def RGB_to_RGB_matrix_to_normalised_primary_matrix(RGB_to_RGB_matrix,
                                                   XYZ_to_RGB_matrix):
    M = np.dot(RGB_to_RGB_matrix, XYZ_to_RGB_matrix)

    M = np.linalg.inv(M)

    return M


sensitivities = colour.MSDS_CAMERA_SENSITIVITIES['Nikon 5100 (NPL)']
illuminant = colour.SDS_ILLUMINANTS['D55']
M_IDT = colour.matrix_idt(sensitivities, illuminant)

NPM = RGB_to_RGB_matrix_to_normalised_primary_matrix(
    np.linalg.inv(M_IDT),
    colour.RGB_COLOURSPACES['ACES2065-1'].matrix_XYZ_to_RGB)

P, W = colour.primaries_whitepoint(NPM)
print(P, W)

colour.plotting.plot_RGB_colourspaces_in_chromaticity_diagram_CIE1931(
    colour.RGB_Colourspace('Nikon 5100 (NPL)', P, W, 'ACES')
);

But with a simple change to the plotting space:

colour.plotting.plot_RGB_colourspaces_in_chromaticity_diagram_CIE1976UCS(
    colour.RGB_Colourspace('Nikon 5100 (NPL)', P, W, 'ACES')
);

[KelSolaar]

I will unroll the numbers a bit later!

[sobotka]

Coming back to this, I believe the above plot in CIE stimulus xyY space is also wrong? The normalization will fail for the negative components, and yield incorrect relative magnitudes?