Change calculation of white on RGBW LED strips

[stefanbode]

in xdv_04_light.ino i changed following:

  light_current_color[0] = (uint8_t)(r * 255.0f);
  light_current_color[1] = (uint8_t)(g * 255.0f);
  light_current_color[2] = (uint8_t)(b * 255.0f);
  if(light_ct_rgb_linked){
    //stb mod
    light_current_color[3] = (uint8_t)( ( (r < g && r < b) ? r : (g < b) ? g : b )    * 255.0f);
    //end
    light_current_color[4] = 0;
  }
}

If using RGBW LED stripes with hue or any other app only RGB is transmitted and you do not use the benefits of the white light. The change set the white LED to the minimum value of all colors. This increases light emission and still allow to use pure red/green....

[s-hadinger]

Very interesting. Calculation of channels changed in PR #5702. I could easily retrofit this one.

Open question, should we add a new Option for this behavior or take it as the standard behavior?

[stefanbode]

The fix is a one-line fix and does not really take into consideration the intensity and color of the white light compared to the RGB. The change is only 100% correct if the emitted color of the RGB is the same as the white one, which is for sure not true.

Therefore I assume it is not a solution for everyone. A SetOption should make it valuable for everyone. I can confirm, that for indirect lightning with the iOS App Huemote the visual effect is great and feel natural.

[s-hadinger]

Afterthoughts I can see 3 possible behaviors:

1. (current implementation) RGB and W are independent. Until you trigger the CT mode (ex: "ct 500" and use dimmer), the White channel is not used. Pros: white in CT mode is pure. Cons: RGB-mode white is not as pure as white leds.

2. (your implementation) in RGB mode, set W channel to the min of RGB - ie. (255-sat). Pros: adds some pure white to the RGB-white, Cons: white is still not as pure as white leds, and you might double the brightness. It's also probable the you will desaturate non-fully saturate colors.

3. (alternative) in RGB mode, set W channel to the unsaturated value (ie min of RGB, or 255-sat), then substract this value to RGB channels. As a side effet, RGB is never used for white and one component is always 0. This would gradually move from RGB to W. Pros: you keep the full gamut of colors and white is pure. Cons: it depends on the compared brightness of RGB and W leds.

I don't have any RGBW led strip so I cannot compare brightness of RGB vs W leds. It could make sense to make it the default behavior - if we don't want the cost of adding an Option.

Note: doing math on led power may require to apply gamma correction, to make it feel more natural.

[s-hadinger]

One more thing, if you do brightness comparisons, please ensure that you enables Gamma Correction with "Ledtable 1"

[JumpmanJunior]

I am also using Espurna on some of my LED controllers which already has such a feature. So maybe a look at their implementation would be helpful. But I was not always convinced by the results. So having multiple calculation options would be nice.

[ascillato2]

@s-hadinger

Is this request fixed with #5748 ?

[s-hadinger]

@ascillato2 No it is not fixed, it is a feature enhancement.

It looks like easy to implement but difficult to calibrate with regards to the diversity of LEDs. It's also a risk for the power supply, see #5741

I'm working on MQTT for AWS IoT features right now so don't expect a change in the short term from me on this feature.

[s-hadinger]

I'm thinking on some simple way to solve both #5704 and #5741. I will reuse the rbgwwTable[5] to signal we want to do RGB+W mixing, leaving a way to customize both Brightness and White balance.

[JumpmanJunior]

Why is this issue closed? @ascillato2 could you please reopen it?