Make twinkle FX look more like it was in the past

[DedeHai]

fixes #5622

Summary by CodeRabbit

• Bug Fixes
  • Improved brightness handling in the TwinkleFOX effect for more consistent and accurate twinkle intensity.
  • Adjusted how new twinkle pixels initialize brightness for more even visuals.
  • Switched color averaging to use RGB-only averaging, improving overall color rendering and background comparison.

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e503dd87-93f7-4bd1-bec8-88970e2179fd

📥 Commits

Reviewing files that changed from the base of the PR and between 1046de2 and 33e6aee.

📒 Files selected for processing (1)

• wled00/FX.cpp

---

Walkthrough

Replaced CRGBW four-channel averaging with an RGB-only getRGBaverage(). Twinkle palette brightness inputs (spawn and per-twinkle) now use gamma8inv(...). TwinkleFOX background color_fade and per-pixel brightness delta were rewritten to use RGB averages and gamma8inv-derived scaling, then recompute background light.

Changes

TwinkleFOX Brightness Scaling

Layer / File(s)	Summary
RGB-only averaging method wled00/colors.h	CRGBW’s average helper now computes the integer mean of R, G, B via getRGBaverage(), removing the four-channel averaging helper.
ColorTwinkle spawn brightness wled00/FX.cpp	mode_colortwinkle uses ColorFromPalette(..., gamma8inv(64), ...) for newly spawned non-black pixels instead of a fixed 64.
Per-twinkle palette brightness gamma wled00/FX.cpp	twinklefox_one_twinkle passes gamma8inv(bright) into ColorFromPalette instead of bright.
Background scaling & per-pixel delta wled00/FX.cpp	twinklefox_base now computes bglight from bg.getRGBaverage(), applies color_fade() using gamma8inv(...)-based scales across thresholds, recomputes bglight, and compares per-pixel c.getRGBaverage() to the recalculated bglight.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• wled/WLED#4728: Modifies TwinkleFOX brightness behavior in FX.cpp, overlapping changes to per-twinkle brightness computation.
• wled/WLED#4710: Adds/fixes inverse-gamma support (gamma8inv) used by the new brightness scaling.

Suggested labels

Awaiting testing

Suggested reviewers

• blazoncek

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely summarizes the main objective: restoring twinkle FX appearance to match historical behavior.
Linked Issues check	✅ Passed	The PR addresses issue #5622 by applying gamma32inv() to twinkle colors and related brightness calculations, matching the proposed fix and consensus from discussion.
Out of Scope Changes check	✅ Passed	Changes include twinkle color gamma corrections and background brightness adjustments aligned with issue objectives, plus a new helper method (getRGBaverage) necessary for the fixes.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[softhack007]

did a quick test, looks good to merge.
The PR seems to make the twinkling a bit brighter on average, compared to 16.0.0. But this is really a "nuance" on my LEDs, nothing like "did not look right previously." But then, i'm also not an expert on the twinkle* effects 🤷

Technicially:

• make sure the auto brightness limiter is not set up too strictly (per-output ABL is sometimes stonger than previously)
• Make sure you have gamma set to 2.2, and "use gamma correction for color" checked

[DedeHai]

@softhack007 I ran some experiments on different gamma gorrection curve approaches in general (less compression at the low end) but they all resulted in some color artefacts in one way or another. Then I took a more in depth look at the twinkling effects and now think your initial suggestion of using inversegamma on brightness for colorpalette should be used, but not in general, just for twinkle base: reason is that not doing it changes the original look of the effect which I have no issue with but then I also do not really use it much so lets give people what they are used to.

[softhack007]

using inversegamma on brightness for colorpalette should be used, but not in general, just for twinkle base: reason is that not doing it changes the original look of the effect which I have no issue with but then I also do not really use it much so lets give people what they are used to.

@DedeHai sounds good 👍 I agree with the "just for this effect" point - i've played a b it with "2D DNA" at it does look much better as it is in 16.0. The same is true for AnimArtix and a few more 2D effects - looks like they were built for "linear brightness", we should not completely go back to 0.15 palettes.