Restore pre 16.0 looks on several FX#5684
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughAcross ChangesGamma inversion across WLED effects
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ 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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@wled00/FX.cpp`:
- Around line 4762-4765: The comment on line 4762 states "Apply gamma
correction, further expand to 16/16/16" but the code on lines 4763-4765 does not
actually apply gamma correction—it only multiplies by 257 to expand 8-bit color
values to 16-bit. Update the comment to accurately reflect the actual behavior:
remove the mention of gamma correction and describe only the 8-bit to 16-bit
expansion via multiplication by 257.
- Around line 4185-4192: The hardcoded Pacifica palette values
(pacifica_palette_1, pacifica_palette_2, pacifica_palette_3) are pre-inverted
for gamma 2.0, but they are not adjusted when the user changes the configurable
gamma setting at runtime via the HTTP API, causing visual inconsistency. Either:
(1) modify the palette initialization or retrieval logic to apply runtime gamma
correction using the current gammaCorrectVal and recalculate the palette values
whenever NeoGammaWLEDMethod::calcGammaTable() updates the gamma tables, or (2)
add clear documentation in the Pacifica effect explaining that the palette
appearance assumes gamma 2.0 and will shift visually if gamma is changed, along
with a comment in the code near the palette definitions noting this constraint.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e7d4b123-d52f-4caa-a0c6-219805dbd75c
📒 Files selected for processing (1)
wled00/FX.cpp
|
ready to merge, if anyone wants to test still please state so, otherwise I will merge&cherry pick by the end of the week. |
fix for #5603
Tested in direct comparison to 0.15 and the updated effects now look pretty similar.
I was not able to fully restore the looks of "Pacifica" as that effect really relies on direct color manipulation which gets changed with applying gamma. I made some tweaks to brighten it up and it does not look bad, just a bit different.
Summary by CodeRabbit
Release Notes