Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Palette effect will not spread palette colors across entire strip #4425

Open
1 task done
blazoncek opened this issue Dec 24, 2024 · 5 comments
Open
1 task done

Palette effect will not spread palette colors across entire strip #4425

blazoncek opened this issue Dec 24, 2024 · 5 comments
Labels

Comments

@blazoncek
Copy link
Collaborator

blazoncek commented Dec 24, 2024

What happened?

If the strip (or segment) pixel count is larger than 256 pixels, the effect will spread colors only across 256 pixels and then repeat, instead of spreading colors across entire strip (or segment) length.

To Reproduce Bug

Create a strip (or segment) with more than 256 pixels (preferably more than 384 to pronounce the effect) and select Palette effect.
You will see a sharp color transition at pixel 256.

Expected Behavior

Spread palette colors across entire strip (or segment) even if pixel count is larger than 256 pixels.

Install Method

Self-Compiled

What version of WLED?

WLED 0.15.0

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

No response

Anything else?

The bug was introduced with #3683 when using SEGMENT.color_wheel() which only takes 256 values instead of SEGEMENT.color_from_palette().
cc @TripleWhy

Code of Conduct

  • I agree to follow this project's Code of Conduct
@blazoncek blazoncek added the bug label Dec 24, 2024
@blazoncek
Copy link
Collaborator Author

blazoncek commented Dec 24, 2024

That's odd. I cannot reproduce after restarting the unit.

EDIT: Visible on ESP8266 but not on ESP32

@DedeHai
Copy link
Collaborator

DedeHai commented Dec 24, 2024

does changing the FX to use floats also on the ESP8266 fix it? with the new integer based sin/cos functions it should not make any noticeable difference in speed, it may increase flash usage a bit.

@TripleWhy
Copy link
Contributor

I don't currently have access to any esp devices for testing, but I can look into it within the next two weeks if no one else does it first. I looked at just the code a bit, but nothing immediately catches my eye.

About the float usage: We could try that for testing purposes, but I would be very surprised if the 8266 behaved any different from the esp32 then. However, I would expect it to be much slower with the float version: Most of the float computations I eliminated with the switch are in the actual function. The trigonometry calls are actually just 2 per function execution, so the new trig functions shouldn't have a huge impact here.

(Btw. I wasn't aware there are esp32 variants without an FPU when I wrote the effect. A switch depending on the existence of an FPU could make more sense than one that tests for esp2866.)

What I would be interested in, only for earlier poking without hardware, would be:

  • Does the anamorphic option have any effect on this?
  • Do any other effect parameters have any influence? If so, it could be helpful if you post a repro preset.
  • Does this work on 0d279cb?

I'm not up to date with the current state of the project. Which branch should I check out for investigating this?

@blazoncek
Copy link
Collaborator Author

Anamorphic fixes it.

Otherwise, just click effect and unselect rotation animation but leave shift animation selected.
You can work on main branch now.

@blazoncek
Copy link
Collaborator Author

blazoncek commented Dec 26, 2024

FYI reducing sInt16Scale from 0x7FFF to 0x3FFF fixes the issue for lengths of 450 or less (tested).
I do not know what else this change does but it definitely has an effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants