NeoPixelBrightnessBus being deprecated

[Makuna]

It is being replaced by NeoPixelBusLg. This new wrapper provides both luminance and gama correction in a supportable layer.

NeoPixelBusLg<NeoRgbFeature, NeoWs2812xMethod> strip(PixelCount, PixelPin);

// If speed is an issue and memory is not, then you can use the gama table variant
// which is much faster but uses 256 bytes of RAM
// NeoPixelBusLg<NeoRgbFeature, NeoWs2812xMethod, NeoGammaTableMethod> strip(PixelCount, PixelPin);

// If you want to turn gama correction off, then you can use the null gama method
// NeoPixelBusLg<NeoRgbFeature, NeoWs2812xMethod, NeoGammaNullMethod> strip(PixelCount, PixelPin);

• The sample for NeoPixelBrightnessBus has been removed
• A new sample for NeoPixelBusLg has been added
• NeoPixelBrightnessBus is still present but will be removed on some future MAJOR version.

[blazoncek]

Hi, I would like to suggest an enhancement to NeoGammaTableMethod to be truly useful (when speed is required).

The NeoGammaTableMethod::_table[] is const uint8_t meaning it cannot be changed and it is fixed at (what I reverse engineered to approximately) 2.
Why not make it dynamic and allow something like NeoGammaTableMethod::SetGamma(float gamma) that will populate this table/array at specific gamma?

[Makuna]

There are couple of big things to consider here.

1. Dynamic allocation versus const static tables - some processors have separate code and ram memory; so, they can put const tables into code space rather than use dynamic RAM, saving that precious resource for other uses.
2. Gamma tables values really don't change much from LED to LED. So, being dynamic is trading code to generate it versus static entries?
3. Most variance in gamma is in how the curve is calculated, so it's not just a variable that would change but the equation itself. You can see this in this still outstanding pull request. The easiest way is to just provide another NeoGammaMethod specific to your needs. It's a simple class. And about that pull, it wasn't taken yet as it will become a new NeoGammaMethod but it has not been on priority list as its effects are pretty minor so that most people wouldn't know how to choose between them as data about gamma is not often published on specific RGB LEDs in these strips.
4. Table lookup for 16bit color elements (like Rgb48Color) can't realistically use a full look up table. I just added (days ago) a hybrid using the current 255 entry table and another hinting table that is tailored to that existing table to quickly calculate a gamma value for a 16 bit element.

[blazoncek]

1. you already have a space saving variant that does use the math. Make the array dynamic (using heap) and there is no memory lost if not used (apart from the pointer).
2. I am not talking about using gamma for LED specifics. I want to use arbitrary gamma to achieve certain brightness curve.
3. I was referring to the ability to use internal gamma calculation functions to pre-populate gamma LUT for speed. IMO it may be silly to invent a new class just to populate that array (you can do that on Begin() and not rely on static array - see 1.).
4. yes, I've seen it and think it is a clever approach

[Makuna]

I think you are missing the point on #1 as you are used to using ESP chips maybe (or something with lots of RAM). The const table version isn't going away.

To me, it sounds like a very esoteric request, something that the sketch writer can easily write and the code base allows the easy replacement to achieve what you want.

[blazoncek]

Yes, I do not have any experience with non-ESP hardware. Sorry about that. 😄

To clarify: I code for WLED project and we have our own gamma correction and we also allow user to modify that gamma correction by specifying arbitrary gamma value. But instead of computing brightness values every time using exponential function we store those pre-calculated values into static array during initialisation. We use that for individual color adjustment later on.

As the NeoPixelBusLg provieds gamma correction I was excited to replace our own gamma with the one provided by NPBLg. Unfortunately I cannot unless my suggestion from above is implemented as we are already short on CPU cycles with everything WLED does simultaneously.

But do not worry (if you did) 😉 there is no need to change anything as we can continue using our own implementation. I will research the possibility to make our own gamma method class.

[Makuna]

This is why I pointed you to that pull request, all it contains is a newly created instance of gamma method. Not much to it really. Just keep everything static as no instance of it is ever created as you would never want more than one to be created.

[Makuna]

#665
Added a new NeoGammaDynamicTableMethod and an example demonstrating how to use it.

[Makuna]

In the v2.9.0 release the NeoPixelBrightnessBus will be removed. v2.9.0 has not be released yet, but the early work is in the CoreShaderBeta branch.