Twinklefox/Twinklecat dimmer than expected (16.0.0)

[WJCFerguson]

What happened?

The Twinklefox and Twinklecat effects are visibly dimmer in v16.0.0 compared to v0.15.x. This is because the v16.0.0 gamma correction architecture change (commit ee9ac94) moved gamma correction from input colors to the final output stage, but the Twinklefox twinkle colors were not compensated with gamma32inv().

Root cause

In v0.15.x, gamma correction was applied to palette and segment colors when they were loaded (_colors_t[i] = gamma32(seg.currentColor(i))). Effects operated on pre-gamma'd values, and no gamma was applied at output.

In v16.0.0, effects operate on linear (non-gamma'd) colors, and gamma32() is applied at the output stage (FX_fcn.cpp:1685). Effects that do their own internal brightness scaling (like Twinklefox's bright parameter to ColorFromPalette) get their brightness curve gamma-compressed at output, resulting in dimmer mid-brightness twinkles.

A partial fix was already applied to the Twinklefox background color:

bg = gamma32inv(bg); // need to invert gamma as the FX was written without any gamma correction

And the same pattern is used in the Pride2015 effect:

newcolor.color32 = gamma32inv(newcolor.color32);

But the twinkle colors themselves were not given the same treatment.

Fix

Apply gamma32inv() to the twinkle color output, matching the existing pattern:

     CRGBW c = twinklefox_one_twinkle(myclock30, myunique8, cat);
+    c = gamma32inv(c); // invert gamma as the FX was written without gamma correction

     unsigned cbright = c.getAverageLight();

This is a one-line change in FX.cpp within twinklefox_base().

Environment

• WLED v16.0.0
• LED type: WS2812B
• Gamma correction: enabled
• Effect: Twinklefox with black background

To Reproduce Bug

Observe Twinklefox difference between 0.15.4 and 16.0 install

Expected Behavior

Same or similar brightness

Install Method

Binary from WLED.me

What version of WLED?

16.0

Which microcontroller/board are you seeing the problem on?

ESP8266, ESP32

Relevant log/trace output

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[DedeHai]

In v0.15.x, gamma correction was applied to palette and segment colors when they were loaded (_colors_t[i] = gamma32(seg.currentColor(i))).

this is also (partially) incorrect.
but point taken, I will check why those FX look dimmer.

[DedeHai]

I really do not see any visual difference, they look identical to me.
make sure if you compare you have automatic brightness limiter disabled and gamma set to 2.2

[softhack007]

Fix

Apply gamma32inv() to the twinkle color output, matching the existing pattern:

 CRGBW c = twinklefox_one_twinkle(myclock30, myunique8, cat);
 c = gamma32inv(c); // invert gamma as the FX was written without gamma correction

 unsigned cbright = c.getAverageLight();

I've looked through the code in twinklefox_one_twinkle() + twinklefox_base(), and applying inverted gamma to c is definitely not the solution - it would cause over-brigthness, plus distort color HUE.

twinklefox_one_twinkle():

• return value changed from CRGB to CRGBW to explicitly support white channel (probably unrelated)
• Base color is from a palette: c = ColorFromPalette(SEGPALETTE, hue, bright, NOBLEND); - same code as in 0.15.x.
  As palettes are already "gamma-cleaned" in 16.0.0, post-applying inverse gamma would make the colors look much brighter than in 0.15.x, plus alter HUE.
• the "bright" parameter is calculated the same way as in 0.15.x, however when bright is used to scale down the palette color, the results can be different now (similar to observations in the FXParticcleSystem core). it might be worth to change this into c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND);; this would indeed create brighter colors without twisting HUE.

twinklefox_base():

• the problem description note about backgroundBrightnessmay be a smoking gun. The interesting part is

    bg = gamma32inv(bg);
    unsigned backgroundBrightness = bg.getAverageLight();
    // [...]
   unsigned cbright = c.getAverageLight();   // <-- brightness without inverse gamma; so the background is assumed to be brighter than it really is
   int deltabright = cbright - backgroundBrightness;
   if (deltabright >= 32 || (bg==0)) {

--> to make the comparison "fair" (i.e. use the same color space), the brightness should be calculated with inverse gamma applied. maybe cbright = gamma8inv(c.getAverageLight()); would already restore parity here (@DedeHai what do you think?), otherwise a an extra value should be introduced CRGBW cc2 = gamma32inv(c); cbright = cc2.getAverageLight();.

--> I'm not sure if bg = gamma32inv(bg); is really correct, as it dims down the background color. Maybe backgroundBrightness = gamma8inv(bg.getAverageLight()); - without modifying bg - would have been better to preserve legacy behaviour (to be discussed).

@DedeHai @coderabbitai what do you think?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find the twinklefox related code
fd -e cpp -e h twinkle --full-path 2>/dev/null || fd -e cpp -e h | xargs grep -l -i twinklefox 2>/dev/null | head -10

rg -n "twinklefox_base\|twinklefox_one_twinkle\|backgroundBrightness\|gamma32inv\|gamma8inv" --type cpp -A3 -B3 | head -300

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Find the FX file containing twinklefox
rg -l "twinklefox" --type cpp 2>/dev/null

Length of output: 14

---

🏁 Script executed:

#!/bin/bash
# Extract twinklefox_one_twinkle and twinklefox_base from FX.cpp
rg -n "twinklefox_one_twinkle|twinklefox_base|backgroundBrightness|gamma32inv|gamma8inv|cbright|deltabright|ColorFromPalette" wled00/FX.cpp -A2 -B2 | head -400

Length of output: 14780

---

🏁 Script executed:

#!/bin/bash
# Read full twinklefox functions
sed -n '2578,2715p' wled00/FX.cpp

Length of output: 5185

---

@softhack007 Thanks for the detailed breakdown — this is a much more nuanced situation than the original proposed fix. Having read through the full code, here's my analysis:

---

Color space consistency

In WLED v16.0.0, palettes are "gamma-cleaned" (store linear values), so ColorFromPalette() already returns values in linear color space. Meanwhile, SEGCOLOR(1) is a user-entered value in gamma-encoded space, and gamma32inv(bg) correctly converts it to linear.

That means both c and bg end up in the same linear color space before the comparison. The backgroundBrightness vs cbright comparison is therefore actually already operating in the same space — bg is linearized explicitly, and c is linear by virtue of the gamma-cleaned palette. I'm not sure the extra gamma8inv(c.getAverageLight()) step is needed for fairness.

---

Root cause: bright scaling in twinklefox_one_twinkle

The real culprit, I believe, is the bright parameter in:

c = ColorFromPalette(SEGPALETTE, hue, bright, NOBLEND);

• In v0.15.x: palette was gamma-encoded → scaling by a linear bright (0–255 triangle wave) on a gamma-encoded value produced a certain perceptual result.
• In v16.0.0: palette is linear → scaling by the same linear bright on a linear value is more aggressively dark at mid-range, because the gamma curve that used to "lift" those mid-range values is no longer there.

This means I agree with your proposed fix:

c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND);

Applying gamma8inv to bright compensates: it maps the low-to-mid values upward so the linear scaling approximates the old perceptual behavior, without altering the hue at all.

---

Regarding bg = gamma32inv(bg)

This line converts bg to linear space for both the brightness comparison and downstream use in color_blend / setPixelColor (where gamma will be re-applied in the output pipeline). That's consistent and correct. Your alternative of backgroundBrightness = gamma8inv(bg.getAverageLight()) without modifying bg would keep bg gamma-encoded while passing it to setPixelColor — that might cause the background to appear over-bright since it would go through gamma correction again. I'd leave bg = gamma32inv(bg) as-is.

---

Regarding c = gamma32inv(c) (the original proposal)

Agreed — this is the wrong fix. Palette colors are already linear in v16.0.0, so applying gamma32inv a second time would over-brighten and distort hue.

---

Summary

Change	Opinion
c = gamma32inv(c) (original proposal)	❌ Wrong — double-processes already-linear palette color
c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND)	✅ Correct root-cause fix — restores brightness parity without HUE distortion
cbright = gamma8inv(c.getAverageLight())	🤔 Likely unnecessary if c is already linear, but harmless if bright is also gamma8inv'd
bg = gamma32inv(bg) (existing code)	✅ Correct — needed for both comparison and display consistency

The gamma8inv(bright) fix in twinklefox_one_twinkle looks like the right path to me. @DedeHai, does that match your understanding of how bright interacts with the linear palette pipeline?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find the twinklefox implementation
rg -n "twinklefox" --type cpp -l

Length of output: 14

---

🏁 Script executed:

#!/bin/bash
# Get the twinklefox_base and twinklefox_one_twinkle functions
rg -n "twinklefox" --type cpp -C 3 | head -100

Length of output: 3056

---

🏁 Script executed:

#!/bin/bash
# Get the full twinklefox_one_twinkle and twinklefox_base functions
sed -n '2577,2700p' wled00/FX.cpp

Length of output: 4848

---

@softhack007 — you're right, and I appreciate the thorough walkthrough. My earlier suggestion to apply gamma32inv() to the full color output c was incorrect for exactly the reasons you describe: palette colors are already in linear space in 16.0.0, so re-applying inverse gamma would over-brighten and shift HUE. I withdraw that suggestion.

Looking at the actual code, I agree with your diagnosis of two separate but compounding issues:

---

Issue 1 — deltabright comparison across mismatched color spaces

This is the clearest problem. In twinklefox_base():

bg = gamma32inv(bg);                          // bg is now LINEAR
unsigned backgroundBrightness = bg.getAverageLight();  // linear-space brightness (higher)
// ...
CRGBW c = twinklefox_one_twinkle(...);        // c from palette = gamma-encoded
unsigned cbright = c.getAverageLight();        // gamma-space brightness (lower)
int deltabright = cbright - backgroundBrightness;  // ← comparing different spaces

Since gamma-encoding compresses highlights, cbright is systematically lower than the equivalent linear value, while backgroundBrightness is already in linear (higher) space. The result is that deltabright is artificially depressed — more pixels fall into the bg/blend path instead of being shown as twinkle color, making the effect look dimmer.

For the fix, I prefer your more explicit option to avoid modifying c (which is needed for display):

CRGBW cc2 = gamma32inv(c);
unsigned cbright = cc2.getAverageLight();  // now in linear space, matches backgroundBrightness

---

Issue 2 — bright used as a gamma-space scale factor on a linear palette color

In twinklefox_one_twinkle():

c = ColorFromPalette(SEGPALETTE, hue, bright, NOBLEND);

In 0.15.x, gamma correction was applied when loading palette colors, so bright effectively acted as a linear scale. In 16.0.0, palettes are linear — so bright (which is computed in gamma space) now under-scales the linear color value compared to before. Your suggestion is the minimal, HUE-preserving fix:

c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND);

---

On bg = gamma32inv(bg)

I think keeping bg = gamma32inv(bg) is correct for display output (the linear value is what the gamma pipeline expects). The issue is purely that backgroundBrightness ends up in a different space from cbright. Once Issue 1 is fixed (both in linear space), bg modification doesn't need to change.

The alternative path — computing backgroundBrightness = gamma8inv(bg.getAverageLight()) before modifying bg and keeping cbright in gamma space — would also restore parity, but at the cost of passing a gamma-encoded bg into the output pipeline, which could re-introduce dimming for the background color.

---

Summary: Issue 1 (linear vs gamma-space deltabright comparison) is likely the dominant cause of dimmer twinkles, with Issue 2 contributing as a secondary factor. @DedeHai — does this match your visual testing? It might be worth fixing both independently to see which has more impact.

[coderabbitai]

🧩 Analysis chain

@softhack007, great breakdown — your analysis is sharp. Here's my take on each point:

---

twinklefox_one_twinkle() — gamma8inv(bright) approach

Your suggestion of c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND) is the most targeted fix here. Since palettes are now gamma-linearized in 16.0.0, the bright parameter (which is a gamma-encoded 8-bit value) effectively compresses the brightness range more than it did in 0.15.x, where palette colors were still in gamma space. Applying gamma8inv(bright) before passing it to ColorFromPalette compensates for this without touching HUE — exactly the right approach.

---

twinklefox_base() — the asymmetric brightness comparison (the core bug)

This is indeed the smoking gun. The color-space mismatch is clear:

bg = gamma32inv(bg);
unsigned backgroundBrightness = bg.getAverageLight();   // linear-ish space
// ...
unsigned cbright = c.getAverageLight();   // gamma-encoded space
int deltabright = cbright - backgroundBrightness;       // comparing apples to oranges
if (deltabright >= 32 || (bg==0)) {

backgroundBrightness is computed from an inverse-gamma-expanded bg (brighter values), while cbright is from the raw gamma-encoded c (compressed values). This makes the deltabright >= 32 threshold asymmetrically biased — backgroundBrightness will tend to be larger, making deltabright smaller than it should be, suppressing more twinkles than intended.

On your two proposed remedies:

• cbright = gamma8inv(c.getAverageLight()) — this is a reasonable approximation and lower overhead. However, gamma8inv on the result of getAverageLight() is not mathematically identical to averaging the per-channel inverse-gamma values (since gamma8inv is nonlinear). It's a good approximation in practice for this threshold check though.
• CRGBW cc2 = gamma32inv(c); cbright = cc2.getAverageLight() — this is the mathematically correct approach: expand each channel, then average. More operations, but produces a truly consistent comparison.

For a threshold-based guard like deltabright >= 32, the approximation (gamma8inv(c.getAverageLight())) is likely sufficient and avoids allocating an extra CRGBW.

---

bg = gamma32inv(bg) — modifying bg in-place

Your concern is valid. If bg is used downstream as an actual pixel color value (not just for the brightness comparison), mutating it with inverse gamma would cause the rendered background to appear brighter than the segment's actual background color. The cleaner approach:

// Don't modify bg itself
unsigned backgroundBrightness = gamma8inv(bg.getAverageLight());

This keeps bg untouched for any downstream rendering use, while still performing the comparison in a consistent color space. Whether bg is used after this point in the function would determine how critical this is — worth checking.

---

Summary of recommended changes

Location	Change	Rationale
twinklefox_one_twinkle()	ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND)	Compensates for gamma-linearized palettes in 16.0.0 without HUE distortion
twinklefox_base()	unsigned backgroundBrightness = gamma8inv(bg.getAverageLight()) (remove bg = gamma32inv(bg))	Keeps bg unmodified; performs brightness comparison in consistent space
twinklefox_base()	cbright = gamma8inv(c.getAverageLight())	Matches color space used for backgroundBrightness

@DedeHai, does bg get used after the backgroundBrightness calculation for actual pixel rendering? That would confirm whether the in-place mutation of bg is causing visual side effects beyond the threshold comparison.

---

🏁 Script executed:

#!/bin/bash
# Search for twinklefox_base and twinklefox_one_twinkle implementations
rg -n "twinklefox" --type cpp -A 5 -B 2 | head -200

Length of output: 3394

---

🏁 Script executed:

#!/bin/bash
# Try to find the FX file containing twinklefox
fd -e cpp -e h | xargs grep -l "twinklefox" 2>/dev/null

Length of output: 14

---

🏁 Script executed:

#!/bin/bash
rg -n "twinklefox_base\|twinklefox_one_twinkle\|backgroundBrightness\|deltabright" -A 3 | head -300

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
sed -n '2570,2700p' wled00/FX.cpp

Length of output: 5132

---

@softhack007, looking at the full implementation, a few things become clearer:

---

bg = gamma32inv(bg) is intentional and correct

The code comment says: "need to invert gamma as the FX was written without any gamma correction and it will dim down too much otherwise."

Crucially, bg is used as the actual rendered pixel color in all three output branches:

SEGMENT.setPixelColor(i, c);                                      // branch 1
SEGMENT.setPixelColor(i, color_blend(bg, c, uint8_t(deltabright * 8)));  // branch 2
SEGMENT.setPixelColor(i, bg);                                     // branch 3

The gamma32inv pre-corrects bg so that when the output pipeline applies gamma, the background renders at the intended color. This is architecturally correct and shouldn't be changed.

---

The brightness comparison space — actually consistent in 16.0.0

In 16.0.0:

• bg after gamma32inv → linear space
• c from ColorFromPalette with gamma-cleaned palettes → also approximately linear space

So backgroundBrightness and cbright are both in linear space in 16.0.0, unlike 0.15.x where both were in gamma space. The comparison is actually fairly consistent — the mismatch softhack007 identified is less severe than it appears.

---

Root cause of the dimming: bright scaling against linear palette values

This is the real culprit. In 0.15.x, palette colors were gamma-encoded (numerically larger for mid-range perceptual brightness). In 16.0.0, palette colors are linear (numerically smaller for the same perceptual brightness). The raw bright value is unchanged:

c = linear_palette[hue] * bright / 255   // 16.0.0: smaller base × same bright = DIMMER c
c = gamma_palette[hue]  * bright / 255   // 0.15.x: larger base  × same bright = BRIGHTER c

This explains why twinkles appear dimmer — cbright is smaller, deltabright shrinks, and more pixels fall into the blend/background branches.

---

gamma8inv(bright) — the targeted fix

Your suggestion is correct. gamma8inv(bright) converts the raw perceptual bright value to a larger encoded value, compensating for the now-smaller linear palette base:

c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND);

This restores the effective brightness of c toward 0.15.x levels without distorting HUE, and as a side effect, the larger cbright will also naturally restore parity in the deltabright >= 32 threshold — likely making an explicit cbright = gamma8inv(c.getAverageLight()) fix unnecessary once bright is corrected.

---

Summary

Change	Verdict
Apply gamma32inv(c) to output	❌ Wrong — over-brightness + HUE distortion
bg = gamma32inv(bg) — revert to backgroundBrightness = gamma8inv(bg.getAverageLight())	❌ Not needed — bg IS the pixel color, pre-inversion is correct
c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND)	✅ Correct root-cause fix
Extra cbright = gamma8inv(c.getAverageLight())	⚠️ Probably redundant after fixing bright, but harmless

@DedeHai, does this align with your visual observations? The gamma8inv(bright) change should be straightforward to test.

[softhack007]

@coderabbitai

1. I agree we should first test the c = ColorFromPalette(SEGPALETTE, hue, gamma8inv(bright), NOBLEND) improvement
2. for the part about CRGBW bg = SEGCOLOR(1); being in non-linear (gamma-encoded) color space: please double-check if your assumption is really true! The color is set by the user in the color picker UI element, which should result in screen-space (gamma close to 1) colors. If there is really a gamma-correction step in the path between UI and SEGCOLOR(1), we would be facing a similar problem in all effects that use user-defined colors.
3. If you confirm my understanding in point 2, Its clear that "legacy" user defined colors (from 0.15.x) might need a correction to produce the same look. This is a generic "breaking change" but not specific to a particular effect.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find SEGCOLOR macro definition
rg -n "SEGCOLOR\|`#define` SEGCOLOR" --type cpp -A2 | head -60

# Find where segment colors are set from API/UI
rg -n "col\[0\]\|col\[1\]\|colors\[0\]\|colors\[1\]\|_seg.*color\|setColor\|segColor" --type cpp -A2 -B2 | grep -i "gamma\|gamma32\|gamma8" | head -40

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check how segment colors are stored and whether gamma is applied on ingestion
rg -n "SEGCOLOR" wled00/FX.h -A2 -B2 | head -30
rg -n "colors\[" wled00/FX.h -A2 -B2 | head -30

Length of output: 981

---

🏁 Script executed:

#!/bin/bash
# Trace the color pipeline from JSON API to segment storage
rg -n "colors\[0\]\|colors\[1\]\|col\b" wled00/json.cpp -A2 -B2 | head -100
rg -n "gamma" wled00/json.cpp -A2 -B2 | head -60

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Find getCurrentColor implementation
rg -n "getCurrentColor" --type cpp -A5 | head -60

# Find where segment colors[] array is written (from API/UI)
rg -n "colors\[" wled00/FX.cpp -A2 -B2 | head -60

Length of output: 1811

---

🏁 Script executed:

#!/bin/bash
# Find the JSON/API handler files
fd -e cpp -e h | xargs grep -l "colors\[0\]\|\"col\"\|segment.*col" 2>/dev/null | head -10

Length of output: 300

---

🏁 Script executed:

#!/bin/bash
# Find where segment color is set - look for the JSON state processing
rg -n "\"col\"\|getCol\|setCol\|\.col\b" --type cpp -A3 -B2 | head -100

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Find beginDraw implementation - this likely sets up _currentColors
rg -n "beginDraw\|_currentColors" --type cpp -A5 -B2 | head -100

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check cfg.cpp for color ingestion (segment colors from JSON/config)
rg -n "colors\[0\]\|colors\[1\]\|gamma" wled00/cfg.cpp -A2 -B2 | head -80

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Find where segment colors are set in the JSON/state handler
fd -e cpp | xargs grep -ln "seg.*col\|colors\[0\]" 2>/dev/null | grep -v usermod | head -10
rg -n "colors\[0\]\|\.colors\[" wled00/FX_fcn.cpp -A2 -B2 | head -60

Length of output: 181

---

🏁 Script executed:

#!/bin/bash
# Search for _currentColors population in FX_fcn.cpp
grep -n "_currentColors\|beginDraw\|currentColor" wled00/FX_fcn.cpp | head -40

Length of output: 901

---

🏁 Script executed:

#!/bin/bash
# Read json.cpp section handling segment colors
grep -n "colors\[0\]\|colors\[1\]\|colors\[2\]\|gamma\|\"col\"" wled00/json.cpp | head -80

Length of output: 354

---

🏁 Script executed:

#!/bin/bash
# Find beginDraw in FX_fcn.cpp
grep -n "beginDraw" wled00/FX_fcn.cpp | head -10

Length of output: 599

---

🏁 Script executed:

#!/bin/bash
# Read beginDraw() full implementation
sed -n '377,428p' wled00/FX_fcn.cpp

Length of output: 3525

---

🏁 Script executed:

#!/bin/bash
# Read json.cpp color parsing section
sed -n '195,260p' wled00/json.cpp

Length of output: 2901

---

@softhack007, great call — I traced the full pipeline to confirm this definitively.

Result: You are correct. SEGCOLOR(1) is not gamma-transformed anywhere in the ingestion path.

The full pipeline is:

UI color picker
    → JSON "col" array
    → json.cpp: seg.setColor(i, RGBW32(r,g,b,w))   ← raw sRGB values stored
    → Segment::colors[i]                             ← no gamma
    → beginDraw(): _currentColors[i] = colors[i]    ← direct copy, no gamma
    → SEGCOLOR(x)                                    ← raw user value returned

beginDraw() in FX_fcn.cpp Line 380 is simply:

for (unsigned i = 0; i < NUM_COLORS; i++) _currentColors[i] = colors[i];

No gamma applied. json.cpp Lines 202–256 also just parse channels directly into seg.setColor() with no transformation.

---

Implications

1. bg = gamma32inv(bg) in twinklefox_base() is correct and necessary. The user-picked color arrives as sRGB (gamma-encoded). Applying gamma32inv converts it to linear space, which is required before passing it through setPixelColor() — since the output pipeline applies forward gamma correction. Without gamma32inv, the background would be doubly-corrected and appear too dim.

2. Your point 3 is also confirmed as a systemic concern. Any effect that takes SEGCOLOR(x) and passes it directly to setPixelColor() without gamma32inv is running gamma-encoded values through a forward-gamma pipeline — producing colors that are too dark compared to what the user intended. This is an architectural invariant every effect author must respect. It's not new to 16.0.0 specifically, but the palette linearization in 16.0.0 makes color-space inconsistencies more visible by removing the "accidental compensation" that gamma-encoded palettes used to provide.

3. For "legacy" presets from 0.15.x: The SEGCOLOR values themselves haven't changed (they were always sRGB). Whether a preset looks different depends on whether the effect correctly applies gamma32inv to those colors. If it does (as twinklefox_base does), a 0.15.x preset should render identically — assuming the bright-scaling fix for twinklefox_one_twinkle is also applied.

---

Revised summary for the twinklefox fix

Item	Status	Notes
bg = gamma32inv(bg)	✅ Correct	SEGCOLOR is sRGB → needs linearization
backgroundBrightness from linearized bg	✅ Correct	linear space
cbright from raw palette c (16.0.0)	✅ Also linear	gamma-cleaned palettes
deltabright comparison	✅ Consistent in 16.0.0	both sides linear
bright scaling on linear palette	❌ Bug	gamma8inv(bright) fix needed

The gamma8inv(bright) fix in twinklefox_one_twinkle() remains the primary correction needed.

[softhack007]

the user-picked color arrives as sRGB (gamma-encoded). Applying gamma32inv converts it to linear space, which is required before passing it through setPixelColor().

@coderabbitai I still think you are contradicting yourself. WLED LEDs use a gamma value between 2.2 and 2.8, however screen colors (yes they are displayed on-screen using sRGB) are either gamma-less or use a much lower screen gamma, like 1.2. So we can consider them almost gamma-free, compared to LEDs gamma space.

[coderabbitai]

@softhack007 — you're right, and I was imprecise. Let me correct myself.

The actual distinction: sRGB gamma ≠ LED gamma

The key point I glossed over: WLED's gamma32inv() / gamma8inv() functions are calibrated for LED gamma (~2.2–2.8, depending on configuration), not for sRGB's transfer function (~2.2 nominal, but with a linear segment at the low end, and an effective viewing gamma closer to 1.2 when environmental conditions are considered).

So when I said "SEGCOLOR is sRGB = gamma-encoded → needs gamma32inv to linearize before setPixelColor," that's only precise if WLED's forward gamma correction in the output pipeline happens to match sRGB's gamma exactly. If WLED uses gamma ~2.8 for LED output but the user's color is sRGB (~2.2-encoded), gamma32inv at 2.8 would overcorrect — pushing the color brighter than intended.

Your framing is better: from the LED's reference frame, sRGB-encoded values are close to linear because the LED gamma is so much more aggressive. Treating them as "gamma-free" input to the LED pipeline is a reasonable approximation.

Retracting the "legacy correction" statement

My earlier claim — "legacy user-defined colors from 0.15.x might need a correction" — was wrong. User-defined colors have always been stored as raw sRGB values (Segment::colors[]), unchanged between 0.15.x and 16.0.0. Whether they look correct is an effect-level concern (does the effect pass them correctly through the pipeline?), not a preset migration issue.

What this means for twinklefox_base()

This actually reintroduces uncertainty about bg = gamma32inv(bg): if SEGCOLOR is already approximately in the right space for the LED pipeline, then gamma32inv(bg) overcorrects the background brightness. The degree of overcorrection depends on the delta between sRGB gamma and the LED gamma WLED is configured to use.

The gamma8inv(bright) fix in twinklefox_one_twinkle() remains the clearest, safest change — it only touches palette brightness scaling, which is unambiguously broken. The bg question is worth testing empirically with your gamma settings.

(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧ thanks for the pushback, this is a sharper analysis.

---

✏️ Learnings added

Learnt from: softhack007
URL: https://github.com/wled/WLED/issues/5622

Timestamp: 2026-05-17T16:25:46.940Z
Learning: In WLED (wled00/), user-defined segment colors (`SEGCOLOR(x)`, stored in `Segment::colors[]`) are raw sRGB values from the UI color picker — no gamma transformation is applied anywhere in the ingestion path (confirmed in json.cpp and FX_fcn.cpp beginDraw()). However, treating them as "gamma-encoded" requiring `gamma32inv()` before `setPixelColor()` is imprecise: sRGB gamma (~2.2) and WLED's LED gamma (~2.2–2.8) are different curves. From the LED pipeline's perspective, sRGB values are close to linear. The safety of applying `gamma32inv()` to SEGCOLOR values depends on whether WLED's configured LED gamma matches sRGB's gamma exactly. softhack007 confirmed this.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.