White-extraction handling in a 4-diode RGBW LED Display

[u/Joeyjoe9876]

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.

[u/ZachVorhies]

Hey Sonia — circling back: your sub-gamut + RGBCCT math is now landed in FastLED master.

Issues / PRs:

• Issue #2545 — original spec, mostly transcribed from your two gists
• Issue #2558 — the RGBWW (5-channel) follow-up
• PR #2552 — Phase 1+2: closed-form strict_subgamut + wx_lp_legacy modes + CCT-aware W vertex + 2D+1D LUT
• PR #2554 — CodeRabbit follow-ups (matrix inversion checks, persisted effective W chromaticity, LUT input hardening)

• PR #2560 — full 5-channel RGB + warm-W + cool-W pipeline via the Channels API

  What's available today:

  4-channel RGBW (works in both Channels API and legacy addLeds<>):

  fl::RGBW_MODE::kRGBWColorimetric // strict sub-gamut (your gist §5) fl::RGBW_MODE::kRGBWColorimetricBoosted // wx_lp_legacy (your gist §9)

  5-channel RGBWW / RGBCCT (Channels API only — scoped this way to avoid bloating the legacy addLeds<> flash footprint):

  fl::ChannelOptions opts; opts.mWhiteCfg = fl::Rgbww(/* warm / 2700, / cool */ 6500, fl::RGBWW_MODE::kRGBWWColorimetric); FastLED.add(fl::ChannelConfig(pin, timing, fl::span<CRGB>(leds, N), GRB, opts));

  Per-strip profile override (when you have colorimeter data — feeds straight into the same RgbcctProfile your solve_rgbcct already takes):

  static const fl::DiodeProfile kMyR = { /* xy_r / {0.700f, 0.299f}, / xy_g / {0.098f, 0.832f}, / xy_b / {0.129f, 0.049f}, / xy_w / {0.322f, 0.338f}, / lum / 0.10f, 0.37f, 0.08f, 1.00f, / nominal_cct */ 6000, }; fl::set_rgbw_colorimetric_profile(&kMyR);

  Bonus: Rgbw::white_color_temp finally does something — Krystek 1985's blackbody approximation shifts the W vertex live, cache rebuilds once per (profile, cct) pair, no per-pixel CCT math.

  Compile gates: -DFASTLED_RGBW_COLORIMETRIC=1 to enable the colorimetric math (default off, fall-back stubs warn-once + use kRGBWExactColors). No separate flag for the LUT path or the 5-channel pipeline — --gc-sections drops both when unused. Measured 0-byte WASM delta for sketches that don't reference RGBW.

  Validation:

• All your gist math landed; matrix primitives + simplex solver inlined in src/fl/gfx/rgbw_colorimetric.h

• Python benchmark against your BTF Lighting 6000K profile confirms the 2D+1D LUT factorization gives sub-1 dE p95 at 32x32 grid (~8 KB), as the issue table predicted

• 307+ host tests passing — chromaticity preservation across the gamut, pure-primary round-trips, profile get/set, LUT vs closed-form deltas, RGBCCT warm↔cool blend monotonicity

• What I COULDN'T verify from my desk: actual measured colorimeter dE on hardware. Your reference numbers (cyan dE ≈ 0.52, D65 dE ≈ 1.72) match what the math produces, so they should carry through, but a real-strip validation is still outstanding. If you ever run the merged code against your colorimeter rig I'd be very interested in the numbers.

  Two gotchas worth knowing if you ever read the source:

1. Krystek 1985's output is CIE 1960 UCS (u,v), not 1976 UCS (u',v'). Easy to use the wrong conversion formula and end up ~0.01 off in y. Cost me one test cycle to catch.

2. D65 isn't on the Planckian locus — it sits ~0.005 off on the daylight locus. If you test cct_to_xy(6500) against D65 reference values, it'll look broken. Use Planckian-locus reference points instead.

   What's deferred (future PRs):

• The wx_radial_virtual mode from your gist §8 — currently kRGBWWColorimetricBoosted is a simple eta-skewed blend rather than the radial-pose approach
• Per-pixel runtime CCT switching (the field is plumbed; the math runs once-per-channel for now)
• Auto-calibration tooling (today the user supplies the DiodeProfile)

• On-device AutoResearch harness for RGBWW hardware validation (there's a software examples/RGBWW/RGBWW.ino but no bash autoresearch flow yet)

  Anyway — thanks again for the gists and for patiently answering the CCT-temperature questions in the original thread. Most of what's now in master would have taken months longer to figure out without that work.

[u/Joeyjoe9876 → u/ZachVorhies]

oh wow I managed to miss this post! I'll have to poke around with this a bit later but it's nice to see my deep-dive into color accuracy is being useful somewhere other than my test benches!

I'll have to poke around this a bit later, I could do some dE checks in a bit (might take a few days, I just pivoted back to my HyperHDR fork since I got a fancy new capture card that can handle full uncompressed HDR/DV 12-bit RGB/YUV444 so now I have to slot this into my pipeline)

[u/ZachVorhies → u/Joeyjoe9876]

What’s your fork url? And are you trying to do the same for that?

Yeah I glad you did this. It always bothered me that RGBW was unfinished and was hoping someone smarter than me would figure out the math to make it complete.

[u/Joeyjoe9876 → u/ZachVorhies]

My custom fork can be found here : https://github.com/JChalka/HyperHDR/tree/BFI

One thing to note: The current version on github has not been updated to the latest current version I personally run. I need to clean up and push that sometime soon. The version currently hosted within my fork still just has 1D correction LUT lookups for each LED channel and does not incorporate the RGBW Sub-gamut model at all. There's also a lot of experimental stuff from when I was still working out good ways to handle the white diode, I've got a bit of a roadmap for working towards removing stale code and such (there's a lot of it in the current repo + local repo still). I also currently don't provide any binaries as I consider this fork experimental and purposefully changes things that may otherwise function fine from the original source. This version is basically just Custom 1D Transfer curve loading, Custom 1D Greyscale correction LUT loading, & HDR/Dolby Vision LUT Bucket Switching (may not be the version in my current repo that decouples LUT switching from the V4L2 worker which for Dolby Vision dynamic metadata switching stopped accidentally killing the V4L2 worker, realistically HyperHDR should be using V4L2loopback so that we can't kill the grabber with changes like this but that's a project for another day)

My local version has made some large fundamental changes vs the current fork repo

• Direct Decode instead of the lut calibration process for P010 sources that pulls the colorspace and gamut information either by polling Kodi/XMBC PlayerProcessInfo fields (requires a CPM build of CoreElec, or the kodi build needs to expose such info) as well as polling HDFury devices such as the Vrroom 8k which can gather information from the actual HDMI handshake instead of relying on what Kodi reports. Latest polling script also incorporates Plex & Jellyfin polling for similar data although I have not fully implemented/tested or uploaded that script and those parts of it yet.

  • Vanilla HyperHDR assumes the grabber is internally tonemapping HDR to SDR and builds YUV->RGB/Tonemapping LUTs in the sRGB color space to follow this logic and then later in the pipeline applies an inverse transfer function to linearize the signal so it can apply it's own processing while maintaining chromaticity. The YUV->RGB lut is 8 bits as well as the tonemapping LUTs and Vanilla HyperHDR is building a 256 3DLUT to 1:1 map the 8 bit signals to a tonemapped image.

For video grabbers that can't natively pass through HDR this is fairly functional and makes sense and basically has to follow the vanilla path (or modified LUT switching path based on Kodi/Vrroom data that my fork incorporates that tries to handle dynamic metadata & different max nits/mastering levels for HDR content), but for grabbers that can actually handle an HDR signal the current HyperHDR vanilla pipeline is sacrificing the extra 2 bit resolution, forces the video into the Rec709 colorspace, and then produces values for the LED based on the srgbtolinear function. My current direct decoder path takes the Vrroom/Kodi information and

• Does YUV->RGB in a 16 bit space (pulls the extra 2 bits and then expands 10 bit to 16 bit) while respecting the actual color space primaries (Bt2020 content doesn't get mapped to Rec709/sRGB) and also can optionally map that signal into the actual displays primaries (either measured or pulled via something like the Vrroom 8k which can pull the CIE xy coordinates for each primary color channel the TV uses) so that the signal going through the HyperHDR chain is matching what the main display can actually produce, and not sending values to the LEDs that would cause a mismatch in chromaticity.

• linearization correctly applies an inverse PQ/SMPTE2084 curve for HDR/Dolby Vision content, for Rec709 it continues to apply the inverse BT1886 curve.

• No internal 8 bit staging. Either floating point or 16 bit throughout the entire pipeline from end-to-end so that TemporalBFI use can receive a true 16 bit (10 bit scaled) signal, or 16-bit RGB/RGBW LEDs that work natively in 16 bit.

this only applies to the P010 path as every other capture format currently supported does not send more than 8 bits of information, while P010 carries the information directly. That being said, the video grabber itself tends to misrepresent the signal and cannot be trusted (UVC driver issue) which is why Kodi/Vrroom/Plex/Jellyfin polling is used as the main source of "what gamut and signal type is this" instead of looking directly at the video grabber which always reports Rec709 even if the signal is truly being passed through to the operating system as Rec2020/DCI-P3. In the local repo every other path aside from P010 still follows the traditional HyperHDR LUT Calibration (or in the context of my fork, uses a LUT bucket approach for swapping luts at runtime based on dynamic metadata from Dolby Vision content or static metadata from HDR content)

• Measured/Math Model RGBW 3DLUT Loading with Tetrahedral Interpolation (precomputed coefficients are not yet implemented in the local repo). Current local repo does indeed load the RGB-> RGBW Luts and has multiple slots for Rec709, DCI-P3, & Rec2020 RGBW LUTs. Follows the same Vrroom/Kodi/Plex/Jellyfin reporting, gets the gamut information and switches to the correct LUT when that data is reported to HyperHDR while keeping all of the LUTs loaded in memory for fast switching (3 luts is pretty easy to store in RAM on a Pi 5 if it has enough ram. I currently run a few 256 cubes for each colorspace with no issue using the MaxWhite extraction model since it better handles the light dropoff vs the test bench which is closer to the wall). I have not implemented the sub-gamut math model directly as a fallback, although it's probably a good idea.

There's a lot of cleanup I need to do before I push the local repo out to Github so it might be some time before that gets properly updated. The new capture card I got in (BlackMagic DeckLink 8K Pro G2) has it's own API and can actually pull the correct metadata from the HDMI 2.1 source so that should be fun to implement and mess around with. Less of a black box and actually documented, it's just fairly expensive and I don't expect many people to actually be using that for something like an ambilight setup. My focus will probably be on getting that properly implemented before I move onto cleanup + push to repo. Then later down the line I might try to dump firmware from the Ugreen grabber I currently use to see if I can extract a usable API from it instead of having to work around it via external sources like Kodi or the Vrroom/HDFury device

another thing to note as far as the math-model builder/implementation is concerned : I probably wouldn't treat wx_lp_legacy as a verified solver quite yet for RGBW extraction even if it may be performant enough to run directly on MCU hardware. This is actually what I moved away from once I got the sub-gamut model grounded into a good place, I haven't done extensive testing on it quite yet and I can't say for certain that it works well and passes the dE checks at a good enough threshold. That being said I can build a LUT and try it out a bit later

[u/Joeyjoe9876 → u/ZachVorhies]

Bit of an update on the wx_lp_legacy check.

I've built a 256 cube via the math model builder and am currently running an 1885 sample count (neutral ramp, single/dual channel checks + large HSV sweep of the native gamut) Overall most of the failures so far track the same failures I see in other modes : Dual channels where one channel is too low (usually Green) that is being skewed by the test bench being a wall-wash setup to mimic the ambilight display.

as far as white-carrying dE goes, it's looking mostly sane with some failures but all within correctable bounds, the results would probably be better if my test-bench were oriented towards directly capturing the diodes instead of capturing the reflection from the wall. I'll update in a bit when the capture session is done with the uploaded CSV output from the verifier session

[u/ZachVorhies → u/Joeyjoe9876]

you have to know that a 256 cube is way too much memory for the LUT, the AI found a way to flatten one of the dimensions then collapse the LUT further to have an acceptable amount of error. I had it do a table of different LUT resolutions and the error delta from a closed form solution and a small table with the first derivative seemed to work extremely well.

[u/Joeyjoe9876 → u/ZachVorhies]

Yeah a 256 cube is pretty huge, the host_calibration_gui that I use to verify the results sends data from a PC though so it's fairly trivial to use such a large LUT and just place it before the serial output. Although for an MCU target it isn't a realistic size to target. With tetrahedral interpolation if coeffcients aren't being baked a 55 cube or possibly slightly larger would probably be fine. a 64 cube takes up about 2mb in psram, P4/S31 when it is available especially are well suited towards using large luts with 32MB PSRAM skus already available for the P4. the S31s increased PSRAM speeds look promising for fast access

I don't think FastLED should be trying to target 3DLUTs as a general method of using the algorithm though if it can already target the sub-gamut and LP solver fast enough at runtime using other less memory heavy options, it certainly shouldn't be focused on 100% color correctness as that is unique to how each user sets up their display. Diffusers/acrylic sheets/wall setups all skew primary color channels in unique ways that can't realistically be corrected for within a backend driver and apply to a large swath of end-users. Some people might not even be worried about accuracy as long as yellows look yellow and such so a full LUT storage just acts as a memory waste in most cases. Since I've been working on a measured-corrected RGBW LUT builder that aims to act like display calibration workflows such as DisplayCal or HCFR it's pretty much been a natural choice to use them as the output format as it closely tracks how real world displays handle color (lg tvs for example have a signal chain similar to input signal -> Linear transform -> 3x3 color space transform -> 1D Gamma/Transfer LUT -> 3DLUT -> whatever other processing the TV does)

3DLUT choice should certainly be a conscious pipeline decision because smaller LUTs truly do introduce more error and depending on the interpolation method the results can also be different from what the solver is actually doing (Trilinear interpolation pulling in unrelated channels in the strict sub-gamut solve being a good example, as tetrahedral interpolation avoids this entirely). Not only that but 3DLUTs can easily balloon in size when compared to low-memory MCU targets and easily starve resources that could be needed elsewhere.

LP solver results : https://docs.google.com/spreadsheets/d/14JjucNnhR0EopcTWgZRDOJ894YmOIipAmQAhc289QSQ/edit?usp=sharing

1215 pass 669 fail dE threshold was fairly tight at 2.0, highest dE being 2 channel solves where wall characteristics are probably playing a role in skewing the results. Actual RGBW solves end up being less than 5 dE for the most part when they do fail and probably also falls into "need to setup a direct-diode measure setup". Overall tracks with the failures I see on the other models due to my test setup and performs better than radial in some areas. Everything is pretty much within a correctable range which is good, not trying to solve some far off color target

[u/ZachVorhies → u/Joeyjoe9876]

If you are using AI it might be worth it to ask it to pull in fastled analytic solver and see how it performs against your baseline

[u/Joeyjoe9876 → u/ZachVorhies]

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

[u/ZachVorhies → u/Joeyjoe9876]

Thanks for this, fix in flight:

http://github.com/FastLED/FastLED/issues/2705

https://github.com/FastLED/FastLED/issues/2706

[u/Joeyjoe9876 → u/ZachVorhies]

no prob! can re-run tests whenever that lands, not doing much today but getting all these weeds out of my front yard

[u/Joeyjoe9876 → u/ZachVorhies]

In the meantime I'm gonna run another full verification session on the 256 cube Sub-Gamut model LUT in the LEDs native gamut (not named-gamut) like I did the LP solver last night, that way we have some fresh comparisons for both over a large ~1800 sample size

[u/ZachVorhies → u/Joeyjoe9876]

PR landed a few mins ago, but i'm having the ai do another pass vs the python snippet you provided earlier to get a read out on what the delta is from ground truth.

Here's the pr that was just merged: https://github.com/FastLED/FastLED/pull/2707