apply inverse gamma to segment brightness for better color preservation

[DedeHai]

to make global brightness slider and segment brightness slider behave the same, the segment brightness needs to be gamma-inverted when using gamma for color correction.

the reason being (wigh g = gamma)
global brightness: (color)^g * brightness
segment brightness: (color * brightness)^g

using brightness^(1/g) results in (color * brightness^(1/g) )^g = color^g * brightness i.e. the same as with global brightness.

The way WLED handles gamma is not mathematically correct but is an approximation and a good compromise (I ran A LOT of tests on that before setteling for the way it is currently done). The correct way would actually be to do (color * brightness)^g but the issue is that that results in color loss. To make it work would require to scale colors to 16bit, apply brightness, then apply gamma, then scale back to 8bit, which is much slower and does only gain "linearity" in brightness scaling which was never really a thing in WLED.

Fixes #5342

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Enhanced gamma correction handling to ensure brightness scaling maintains color accuracy and consistency during rendering operations.

[coderabbitai]

Walkthrough

The change modifies the WS2812FX::blendSegment function in FX_fcn.cpp to apply inverse gamma correction to opacity when gammaCorrectCol is enabled. This ensures consistent brightness scaling behavior regardless of whether brightness is adjusted globally or per-segment.

Changes

Cohort / File(s)	Summary
Gamma correction in blending wled00/FX_fcn.cpp	Added inverse gamma correction to opacity in blendSegment function when gamma correction is enabled, addressing brightness resolution inconsistency between global and segment brightness controls.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• add inverse gamma 32 function and fix colors in pride #4722: Adds inverse-gamma correction to color blending in pride-effect, using similar gamma linearization approach for color composition.
• fix particle brightness distribution with new gamma correction #4710: Introduces inverse gamma correction utilities and applies them to brightness/opacity handling, foundational work for gamma correction consistency.

Suggested reviewers

• blazoncek

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: applying inverse gamma to segment brightness for color preservation, which directly matches the changeset's purpose.
Linked Issues check	✅ Passed	The PR addresses issue #5342 by implementing inverse gamma correction for segment brightness, making segment brightness behave consistently with global brightness when gamma correction is enabled.
Out of Scope Changes check	✅ Passed	The changes are limited to applying inverse gamma to segment brightness in WS2812FX::blendSegment, directly addressing the linked issue with no apparent out-of-scope modifications.

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

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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]

to make global brightness slider and segment brightness slider behave the same, the segment brightness needs to be gamma-inverted when using gamma for color correction.

Fun fact - I am experimenting in WLEDMM with moving gamma corrections to bus driver level, to exploit HUB75 with 10bits per color. I ran into the same observation that you made: if effects run in "no-gamma space", then segment brightness (segment::opacity) requires inverse gamma to look the same as with previous WLED versions.

[blazoncek]

global brightness slider and segment brightness slider behave the same

FYI these were not meant to behave the same, one is brightness the other is opacity. Opacity with single segment behaves similarly as brightness but is not brightness.

moving gamma corrections to bus driver

This is the only correct way of handling gamma and I've made that a few days back in my fork.

BTW don't forget that gamma may not always be applied always.