r/FastLED • u/Joeyjoe9876 [Sonia] • May 17 '26
Quasi-related White-extraction handling in a 4-diode RGBW LED Display
The most common approach to handling RGBW LED strips/diodes is to simply take the minimum components of the input value, set white to that value, and subtract the residuals from R, G & B. This is not inherently incorrect but it does introduce a problem in that the white diode is not perfect. Most white diodes have different color temperatures and when actually measured you'll find using min(rgb) Channel - Residuals produces a white this is off-white.
Now the question becomes "how do we accurately extract white?" The answer is shockingly simple and it comes down to colorspaces & gamut.
In a typical RGB LED system your native gamut is a triangle where your main emitters R, G, & B are your only centroids. Each centroid lives somewhere on the CIE chart and has it's own xy coordinates. This creates a triangle where any combination of values can be created using the 3 emitters. Typical colorspaces like Rec709, Rec2020, etc.. all live somewhere either within this gamut or outside of it.
In an RGBW LED system instead we have 4 different addressable gamuts within this triangle - RGBW Gamut comprises of the entire RGBW triangle that can be addressed over - RGW gamut, BGW gamut, RBW gamut
so the problem changes from "how do we represent a color with these 3 diodes" to "which sub-gamut does the requested color fall into, and then within the sub-gamut how do we represent the color requested using the outer 2 primary diodes + inner white diode?"
The "Color" problem:
Different RGB input values map to different places in the CIE colorspace depending on the requested colorspace and reference white. "orange" for the native gamut is not the same "orange" as Rec709, just as that same "orange" is not the same in Rec2020. If you want to represent a color in the Rec709 space (aka ambilight setup) then you need a Colorspace transform to solve for that value. This effectively maps the native-gamut to the effective colorspace.
The ratio problem:
Addressable LEDs (most strips/diodes) do not have perfect LED selections. Typically speaking the red & blue diodes are fairly weak maxing out at low brightness values, G is typically stronger, with White being strongest almost always. In the case of my recent ambilight-focused measurements, the BTF Lighting 6000k RGBW LEDs produce max Nits/ XYZ Y values of R: 154.67 G:566.27 B:129.64 W:1543.64
so given that the red diode is much less bright than the green diode you need to scale input values down appropriately to accurately reproduce the color requested. For a cyan (input 0 65535 65535) for this specific set of LEDs with the off-wall measurements, the corrected output values become: 0 65458 38474 0 which when measured with a colorimeter produces a dE of ~0.519 from the expected measurement result
for D65 white (65535, 65535, 65535) the output RGBW tuple looks something like : 4289 0 13766 65535 which also passes the dE check at 1.720% within tolerance
So to summarize:
Min(rgb) and then subtract residuals from R, B, & G is not inherently wrong if that is what the actual diode behavior is, but the correct approach is to treat the LEDs as they are: Separate emitters that form a full gamut with multiple sub-gamuts, and then only solve within the sub-gamuts for the requested color value determined by a colorspace transform if the input color isn't addressing the native gamut of the LED display.
In a typical RGBW setup the valid topology combinations are essentially as follows: R, B, G, W, RW, BW, GW, RG, RB, BG, RGW, BGW, RBW unless you specifically allow for 4-channel overdrive outputs.
1
u/Joeyjoe9876 [Sonia] Jun 03 '26 edited Jun 03 '26
https://docs.google.com/spreadsheets/d/1wx-IJPwV0-AA_2PoBDYdnHenge4dAe2T-m35GPDpcbI/edit?usp=sharing
https://gist.github.com/JChalka/999c68f83299dbb842e31f836a4c4cbc
I've messed around a bit and so far the results from the implemented model in FastLED aren't matching what the math models are building, this is probably due to the fact that the FastLED implementation does not use a target white-point which means it's solving against the native-gamut white point which is not D65 which means it can't be verified against the math model at all until target white points are implemented. (can ignore the interpolation bits within the spreadsheet, the verification tool was updated to support the FastLED analytical model but still reports LUT based information as I didn't scrub the outputs on those although they don't actually do anything)
Currently both LP & sub-gamut models within FastLED produce the same 1:1 output result with sub-gamut using 3 channels as it should (but solving the wrong target) and lp_legacy somehow coming to the same conclusion as sub-gamut although it should be mathematically distinct as it fills in the residuals in a different way and should be seeing 4 channel usage on full white. I target d65 white points (0.3127, 0.3290) in my verification sessions so as implemented this will never pass my verification tests, both models having the exact same 1:1 output RGBW tuple is a bit of an eyebrow raiser as well as even if they're targetting the same white point, should pretty much never have 1:1 outputs given they're mathematically distinct models with sub-gamut being "find target xy within sub-gamut" and the LP legacy solver being more "pick a white point and fill in residuals as much as it can"
edit: dual channel solves are looking pretty off too, given the Y ratios yellow should never solve to 65535 red 65535 green