Context

Issue #2748 reported several RGBW colorimetric solver divergences. The major regressions from that report were addressed by #2749 and #2752:

• native single-channel topology authority is preserved;
• native dual-edge topology is locked to RG/RB/GB without W or inactive-channel bleed;
• dual edges are solved from measured XYZ/Y rather than raw passthrough;
• strict 3-channel/interior solves use chroma/value separation;
• wx_lp_legacy is separated from boosted/overdrive mode.

After #2752, the remaining discussion in #2748 identifies follow-up work that should be tracked separately from the original large report.

Follow-up 1: sub-gamut endpoint scaling

The current sub-gamut path can still scale outputs from the white-extraction split-channel energy rather than from the actual input RGB value.

Reported example from #2748:

h315_s015_v100
RGB input:              65535 / 55705 / 63077
current RGBW sub-gamut: 35438 / 0 / 20984 / 55705
expected shape:         ~41695 / 0 / 24691 / 65535

The reported issue is deterministic: W is capped at 55705, matching the lower split/input component, rather than allowing the endpoint to scale against the full input value. This is distinct from the earlier value-ramp collapse fixed by #2752.

Acceptance criteria

• Add a focused regression test for the h315_s015_v100-style case or an equivalent deterministic fixture.
• The strict sub-gamut output scales according to the intended input RGB endpoint/value, not the intermediate white-extraction split energy.
• Existing RGBW FastLED Implementation Divergences, bug report, & proposed fixes with pseudocode #2748 topology guarantees remain intact: native single channels stay exact, native dual edges stay topology locked, and interior solves may still use W.
• The fix remains analytical and MCU-friendly; no baked 3D LUT is required.

Follow-up 2: shared colorimetric solver plumbing and RGB colorimetric path

The #2748 follow-up discussion also proposes splitting portable solver logic out of rgbw_colorimetric.cpp.hpp into a shared colorimetric_response layer so RGBW, RGB, and future 5-channel+ paths can reuse the same matrix/profile/solver primitives.

Suggested phased direction from the discussion:

1. Land the RGBW sub-gamut endpoint-scaling fix above.
2. Move portable solver functions from rgbw_colorimetric into shared colorimetric_response files.
3. Implement an opt-in RGB colorimetric path using the same profile/source-space machinery.
4. Identify the correct integration point for RGB colorimetric dispatch without changing legacy/default RGB behavior.

Acceptance criteria

• Shared code extraction does not change existing RGBW outputs except where explicitly covered by the endpoint-scaling fix.
• RGB/RGBW colorimetric behavior remains opt-in and compile-time gated where needed for binary size.
• The design keeps the algorithm compressible into a discrete form, per maintainer feedback in RGBW FastLED Implementation Divergences, bug report, & proposed fixes with pseudocode #2748.
• Add tests or fixtures that prove the extracted solver path still matches the current RGBW behavior and supports an RGB-only solve shape.

Related

• feat(rgbw): sub-gamut white-extraction algorithm for chromaticity-accurate RGBW output #2545 introduced the original RGBW colorimetric solver tracking/spec.
• RGBW FastLED Implementation Divergences, bug report, & proposed fixes with pseudocode #2748 is the original divergence report and discussion thread for these follow-ups.
• fix(rgbw): native topology authority for strict + boosted solvers (#2748) #2749 fixed the first native topology guard.
• fix(rgbw_colorimetric) Fix dual-channel Y ratio solving, Fix 3-channel solve granularity issues, re-implement legacy_lp solver #2752 fixed native dual-edge solving, 3-channel value granularity, and wx_lp_legacy separation.