Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
APA102/SK9822 global brightness sometimes incorrect #656
I am very happy that FastLED is now making use of the global brightness aspect of the APA102/SK9822 LEDs. Even with the brightness turned down very low (and using much less power), these LEDs are capable of providing a wide dynamic range of colors with this feature.
However, while trying out the global brightness setting for an SK9822 LED strip, I noticed some odd brightness behavior that I was able to track down the cause of. Specifically, in the following chipsets.h code:
the right side of the
Even if the overflow is caught and
The above algorithm does not experience the
Just a quick chime in. I've compared global brightness on APA102 and SK9822 and they both really have a different behaviour. In my experience the SK9822 starts to shift Hue as well when changing the GBC parameter. I didn't test with the FastLED implementation, but with SmartMatrix. Some discussion: https://community.particle.io/t/smartmatrix-apa102-library-open-hardware-photon-apa102-shield/21562/67
referenced a pull request that will
Sep 27, 2018
Indeed I also noticed that those days as I switch my led strip from WS2813 to APA102C but I haven’t had the time to find the source of the problem.…
On 27 Sep 2018, at 19:53, Oleg Anashkin ***@***.***> wrote: One thing I've noticed during the testing is that when setCorrection(TypicalLEDStrip) is used (like in provided FastLED examples) the hue shift is very apparent on low brightness settings. White color becomes some weird purple-ish tint. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#656 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMEiRN8FrPQIh215W0TfPcQBY6oqp-Liks5ufRCngaJpZM4W6GrE>.
I have been using
Because the final scale factors are restricted to integer values, they cannot be kept in the same ratios as the numbers get small. Calling
This scaling procedure works fine for 8-bit RGB outputs, but APA102/SK9822's essentially have a dynamic range of 31*256 (~13 bits) that this procedure was not meant to handle (in its current form).
Thanks for all this explanations. What I did notice apply to all the brightness scale value corrected. The APA102C tends to be more reddish when setCorrection is applied. I haven’t had the time to investigate more about this as I’m currently abroad for work. Keeping you in touch when back home.…
On 27 Sep 2018, at 23:20, cmsavage ***@***.***> wrote: I have been using setCorrection(UncorrectedColor) and did not notice a hue change through even the lowest brightness levels. Now that I try setCorrection(TypicalLEDStrip), I can see the hue changes at very low brightness changes. I can see one issue that causes hue changes: the 8-bit storage of the RGB scale factors in the controller.h computeAdjustment() routine. The scale factors s0, s1, s2 that are used in the APA102/SK9822 global illumination calculation in the parent post above are given by scale*(Correction[k]+1)*(Temp[k]+1)/65536 where scale is the overall scale passed into show(), and Correction and Temp are the RGB color correction and color temperature factors. Here are some results using the TypicalLEDStrip correction: Scale Correction Adjusted (s0,s1,s2) 255 (255,176,240) (255,176,240) 128 (255,176,240) (128,88,120) 64 (255,176,240) (64,44,60) 32 (255,176,240) (32,22,30) 16 (255,176,240) (16,11,15) 8 (255,176,240) (8,5,7) 4 (255,176,240) (4,2,3) 3 (255,176,240) (3,2,2) 2 (255,176,240) (2,1,1) 1 (255,176,240) (1,0,0) Because the final scale factors are restricted to integer values, they cannot be kept in the same ratios as the numbers get small. Calling show(4) results in a more purple hue [→(4,2,3)] than show(255) [→(255,176,240)], while show(3) is reddish [→(3,2,2)], show(2) is even more red [→(2,1,1)], and show(1) is just red [→(1,0,0)]. This scaling procedure works fine for 8-bit RGB outputs, but APA102/SK9822's essentially have a dynamic range of 31*256 (~13 bits) that this procedure was not meant to handle (in its current form). @extesy, @christophepersoz: When you say low brightness levels, are you talking about scales below around 8, where the finite resolution effects of the adjusted scales starts to be significant? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.