Using the FastLED, dimply lit LEDs cause R/G/B to jump out disproportionately. After switching to NeoPixelBus, it doesn't.

[pauldotknopf]

What I'm doing: fadding 0xFFFFFF to 0x000000. The RGB values sent to both NeoPixelBus and FastLED are the same. The method to darken the RGB values are the same.

When using FastLED, the trailing end of the fade was causing R/G/B to jump out randomly before the LED's turned off.

After switching to NeoPixelBus, this doesn't happen.

I'm going to use NeoPixelBus because of this issue, but I'd like to know if anyone knows what NeoPixelBus is doing differently that causes this issue to not exist?

FastLED:

NeoPixelBus:

[Makuna]

NeoPixelBus doesn't do anything "fancy" with the output.

I know FastLed has a feature where they "dither" the output quickly updating the LEDs as a means of providing intermediate dimness that the LEDs really don't have. I am unsure if that dithering is on by default or not.

Also interested in what others may have experienced and learned.

[pauldotknopf]

FYI, I found what you are doing that solves the problem:

    void SetPixelColor(uint16_t indexPixel, typename T_COLOR_FEATURE::ColorObject color)
    {
        // THIS LINE IS WHAT FIXES IT
        color = Shader.Apply(indexPixel, color);
        NeoPixelBus<T_COLOR_FEATURE, T_METHOD>::SetPixelColor(indexPixel, color);
    }

More specifically, NeoGammaEquationMethod is what fixes it.

[Makuna]

Ah, you are using the NeoPixelBrightnessBus, so you can apply a global dim value.

The Gamma equation (and table if you need faster lookup) apply a curve so that the dimming seems linear to our eyes. The LEDs are driven with linear PWM but this does not equate to linear perceived brightness, and the gamma equation fixes that.