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!
I have tried your suggestion to start with a colour picker and I have to say that after a lot of experimentation the difference between the pure color value and the one weighted by the Kelvin value can be quite considerable to the extent that the two colors are quite different. It is really surprising!
I was wondering is it possible to turn off the Kelvin value? Alternatively, are you able to provide more information on how exactly the bulb makes the weighted average of the hue colour and the kelvin colour according to the saturation? Is this public knowledge?
For this latter bit, I would be happy if the firmware team could provide me with a simplified weighting algorithm that at least reduces the gap.
Sorry for the late reply, I was on break.
The best way is just always use the same kelvin value. This is what they apps do (they use 3500).
So what do you want from a weighting algorithm?
Hi. Does the use of this kelvin value mean that the colour in the picker corresponds to the bulb colour? There are a couple of algorithms on-line that convert HSBK to RGB but I am not sure how accurate these are without knowing anything about the lifx weighting scheme?
hi MrMangoo, I am also LIFX Developer and I am responsible for this area. So delfick asked me to provide whatever clarification I can on your subsequent questions.
To make sure I understand this correctly, are you saying that the difference between the pure color value (saturation=1) and the one weighted by the Kelvin value (saturation<1) can be quite considerable? That would be expected, since a saturation value of 0 is effectively a completely different colour. I would expect that a saturation value of say 0.9 would be similar to your original colour with the saturation value of 1 though. Or is this not the case, or did I misunderstand you?
The Kelvin value will be ignored when the saturation is 1, as previously stated. This will give you colours in which at most 2 of the 3 RGB primaries are nonzero. So for example, with saturation=1 and 0<=hue<=120 you will get mixtures of red and green, with blue turned off completely.
If you want colours which are not fully saturated, for example if you wanted to add some blue to your red+green mix, then you will have to use saturation<1. And if you want the bulb to behave as much like the Photoshop colour picker as possible, then I recommend to set Kelvin to 6504. That’s because the Photoshop colour picker implicitly uses Kelvin=6504 when saturation<1. Does that make sense?
If you see a recommendation to use 3500K, then that is on the basis that the bulbs produce more light output at 3500K (because they actually contain a 3500K LED). But if you are using saturation>0 then this is not as much of a consideration and you can use whatever Kelvin is convenient e.g. 6504K.
The thing to understand here is that the traditional HSV space, as used in e.g. Photoshop’s colour picker, does not have very good mathematical properties, because the designers of the HSV space were apparently unaware that they were working in gamma-encoded RGB space.
For our algorithm, we need it to have better mathematical properties and we need more predictable behaviour for our users than the traditional HSV space can provide. Still, for compatibility, and to meet customer expectations, we preserve the traditional behaviour as far as makes sense.
Therefore, we do the saturation mixing in chromaticity space, this could be using the CIE 1931 (x,y) space or the CIE 1960 (u,v) space and give the same results. For comparison, the traditional Photoshop style HSV colour picker does the mixing in gamma-encoded RGB space as mentioned.
The specific weighting given to the Kelvin colour and the hue colour is based on the S value you give, but we stretch or squash different parts of the S-scale depending on where we are in hue and Kelvin space, to better mimic the traditional HSV space. Of course, choosing a different space to do the mixing in, such as (x,y), (u,v) or RGB space, also has a similar effect of stretching the saturation scale.
Therefore, the TL;DR here is basically, use the Photoshop colour picker to find the colour you want, and then try that on the bulb with the K=6504 and it should match okay. If not you may fine tune it.
The priority for us right at the moment is to release a consistent colour space to all bulbs, and very good progress has been made on this. Once that is settled, we would aim to provide details to LIFX developers, but I cannot give a specific timeline right now. I will certainly notify you of any update.
@nick_d thank you very much for taking the time to respond to my questions. I really appreciate it.
The difference is between the color on my screen using a color picker (not necessarily Photoshop’s) and the actual bulb color when saturation<1. As i said, this can be quite noticeable and at times annoying.
I think your answer boils down to this: “it depends on the temperature used to generate the colors of the color picker at hand”. In Photoshop’s case you say this is 6504K so this should be used in the bulb when saturation<1. Is that correct?
One last question: I found this java function for converting HSBK to RGB values but it has no documentation whatsoever. How accurate is it in your opinion? Do you have anything similar in mind for converting RGB to HSBK (if this is even possible)?
I created you some utilities to illustrate the concepts explained above by delfick and myself in greater detail. I don’t think the utilities add further information beyond what has already been explained, except for some useful colour theory about CIE 1931 and CIE 1960 colour spaces, and the specifications of the SRGB space, all of which the code references in Wikipedia as appropriate.
You can check out the utilities here:
I won’t go into detail as all is explained in the “readme” file of the repository, so have a look.
The utilities do something similar to the java program you posted, but more comprehensively. I was a bit uncertain about the formula used in the java program for saturation mixing, so I felt that instead of going into a longer discussion about this, it would be easier just to show how to do it correctly. If you want to do a java port of the utilities, I’d be happy to add that to the repo as well.
@nick_d This is truly fantastic and more than anyone could ask. Thank you very much, I will go through the code and get back to you with any question.