Converting CCT to sRGB, values out of range?

[Queuecumber]

I think that this has been touched on in a few places but I am still not entirely sure how to handle out of range values.

The story is I am given a color temperature in mired which I need to output to an RGB LED.

So my procedure is:

kelvin = mired_to_kelvin(float(temp))
xy = colour.CCT_to_xy(kelvin)
XYZ = colour.xy_to_XYZ(xy)
self.__color = colour.XYZ_to_sRGB(XYZ)

So for a simple test I used mired 154 which is like 6493 kelvin, which should be a blue color.

This gave me an xy value of array([0.31359506, 0.32376116]), so far looking ok (I think).

Next converting to XYZ I get array([0.9686 , 1. , 1.12009659]), ok that looks like its out of range.

Finally getting the RGB value gives array([1.01874103, 0.99284812, 1.01475415]) which are all out of range, and if I normalize that its more of a white/gray color.

So am I doing something wrong here? It seems to me that the xy to XYZ conversion went wrong since that is where the first out of range value came from, but maybe its the xy value itself which looks like it also should be gray

[Queuecumber]

OK actually I think the color temperature slider I am using is just making it look like the color should be bluer than it really should be. Based on https://upload.wikimedia.org/wikipedia/commons/b/ba/PlanckianLocus.png it should be pretty white at 6500k

The main question still stands though, should I just normalize the final color and is the xy -> XYZ conversion working right?

[KelSolaar]

Hi,

I'm on the road and hard to join but everything as I see it is normal! Getting values above 1 is entirely normal upon conversion to RGB. Those colours are still within the gamut and doing a slight excursion in higher dynamic range. The conversion from xy chromaticity coordinates to tristimulus values will always normalise values so that luminance Y==1.

Now on how to deal with those colours depends entirely on what you want to do with them.

Are you driving your LEDs directly with them?

6500k should be almost pure white in sRGB colourspace and please note that the XYZ_to_sRGB definition encodes the colour values non-linearly by default with sRGB OETF, i.e. they are gamma corrected.

[Queuecumber]

@KelSolaar Thanks for the response

I'm on the road and hard to join but everything as I see it is normal! Getting values above 1 is entirely normal upon conversion to RGB. Those colours are still within the gamut and doing a slight excursion in higher dynamic range. The conversion from xy chromaticity coordinates to tristimulus values will always normalise values so that luminance Y==1.

So this is pretty in line with some of my assumptions. I was already dealing with a controller that supplies color information but no brightness information (HS but not V for example) and the most sensible thing is to set the luminance to 1 in that case. I'm still not sure how it ends up the color information outside of range in that case, but I'm willing to accept that it's doing the right thing and I dont understand the process.

Are you driving your LEDs directly with them?

Yes the final RGB output is directly converted to a duty cycle for PWM driven LEDs, I am currently clipping the values instead of normalizing as it seemed to produce something closer to what my controller is expecting, but if there is a more standard way to handle it I want to do that

6500k should be almost pure white in sRGB colourspace

Indeed, the reference image that the controller is using is highly exaggerated, the white color is definitely correct.

and please note that the XYZ_to_sRGB definition encodes the colour values non-linearly by default with sRGB OETF, i.e. they are gamma corrected.

I'm not sure what that means, is it something I need to worry about for accurately reproducing the color?

[KelSolaar]

Sorry for the late reply, I just got back home with a stable connection yesterday.

I'm not sure what that means, is it something I need to worry about for accurately reproducing the color?

Given you are assuming Luminance == 1 you should be fine, but if you were planning to also change luminance you would need to know whether the input colour needs to be non-linearly encoded or not.