Is the temperature only relevant when the saturation value is zero? And when it is not, the kelvin value is simply ignored?
Hope that helps.
I have conducted some further tests and it looks like that the kelvin value is taken into account when saturation is not 100, not when saturation is 0. But the impact of the temperature on the overall color depends on the saturation level.
Could you please test this when you have some free time and let me know if this is the case?
Feel free to chip in on my question above as well.
The kelvin has some influence when saturation is above zero, but the higher you go the less influence it has.
I’m curious to know why you want to know how much of an influence it has.
It is something i noticed and because I am writing my own scripts to control my lights it would be helpful to know. A related question, do you happen to know any resources that explain the relationship more generally between saturation and the temperature? It seems to me that these two metrics influence the color similarly but I have not been able to find much on this topic and I would like to educate myself further.
Ok, so I asked the firmware team about this. The short answer is it’s quite complicated to turn HSBK values into the correct LED output! I don’t completely understand their explanation, but this is what they said.
In a standard HSV colour picker like in Photoshop, the hue causes it to mix adjacent primaries where 0 is red, 120 is green and 240 is blue. The midpoints are also special because they correspond to the brightest available hues. For example, 60 is 100% red plus 100% green and hence brighter than either red or green. The red or green fall off either side of yellow keeping the other on 100%. This means 90 is 100% green plus 50% red. The saturation causes a weighted average of this colour with D65 white which is considered to be 100% red, 100% green and 100% blue. The resulting colour is always the brightness possible version of that chromaticity. Finally the “V” in HSV (essentially brightness) darkens the colour in proportion.
So, for LIFX, instead of D65 white, we use the chosen Kelvin colour. The Mobile apps will set kelvin to 3500 whenever saturation is non-zero to keep colours consistent. At the LIFX protocol level, the H, S, B and K are individually controllable and independent. We take these values and make a weighted average of the hue colour and the kelvin colour according to the saturation. This means when you have 100% saturation the hue will only be used and the kelvin is ignored. The opposite happens when saturation is 0%, and the proportion changes as you go from 0% to 100% as you’d expect.
Some caveats to that is the computation is done in “gamma applied” space. This makes for a complex and unpredictable relationship between HSV and HSBK and the colorimetric values such as chromaticity, brightness, kelvin or Duv. (Duv is the chromaticity perpendicular to Kelvin axis or effectively the kelvin error or “tint” off-white)
It should also be noted that we use a different gamma value (3 rather than the 2.4 used in HSV) and we apply further corrections to control total current consumption and for historical reasons there are some other corrections. Notably this makes greenness depend on brightness and saturation depend on Kelvin, further complicating the colorimetric result.
I recommend starting with a colour picker on your computer, apply that to your device, and then adjust from there.
Many thanks for taking the time to get back to me on this. This is very informative indeed. I was always curious about the interplay of temperature with HSV but as i said before i have not found much on this topic. The Lifx solution seems complicated but for my educational purposes the explanation provided is sufficient!