Add temporal dithering and color magic

[swifty99]

Hi,

glad I found your code. This driver is an excellent basis to improve color on adressable strips.
I have written code for an arduino long time ago, with no DMA this is a hassle. However, the visual effects of temporal dithering are stunning, as they add 2-4 Bits color depth.
makuna from Neopixelbus thinks this should not be part of a driver at least not Neopixelbus. Some thoughts have been exchanged to improve WLED in this respect.
Further reading is here wled/WLED#2416

I will try to add some Pixelpipeline stuff to your driver. Not sure how far I will get here, will see. What are your thoughts?

[hpwit]

Hello
Thank you for your message. happy that you like the driver.
I think, yes it could be interesting to have full dithering within the driver.
What is pixelpipiline exactly ?
Ahppyt to colaborate on this

[swifty99]

cool,
what I believe a pixelpipeline is, what is sketched here:

It describes what happens after the application does when it is finished with setPixel(); and show();
The application should not bother to care about gamma, fading, temporal dithering and so on.
However some things need to be done and timing is an important constraint to prevent flicker while dither.

Fadecandy does quite a good job on the dither part. The I2S driver needs to take care of sending data out in the background.

For further reference:
https://github.com/scanlime/fadecandy/tree/artnet

I also found an interesting variant of an I2S driver which covers different ESP32 versions and Binary Code Modulation. Also very interesting, it might help to reduce inrush currents in power supply and electromagnetic noise.

[hpwit]

Very Interesting..
I also found an interesting variant of an I2S driver which covers different ESP32 versions

do you have the link ?
i will take a deeper look at fade candy's work.
with the full DMA buffer option of the driver the dither should be a breeze just the time to calculate the buffer.
i will try to think about it and send you proposals.

[swifty99]

ups,

sorry, here it is: https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA

[hpwit]

hello
yes that is the version to control RGB panels (not ws28xx ones)
thank you

[swifty99]

Yes ,

I was more referring to the HW flexibility of that driver. And the double buffer structure. I think both could be of good use.

[hpwit]

Hello
Indeed that is why the library point to any led buffer on the fly without having to recopy. I did not implement the double dma buffer for reason of memory but I could do it and make it optional.
I think I should make a list of what is to be done and then go through it what do you think

[swifty99]

sounds like a plan :-)
ESP32 has quite a lot of RAM. The pixelpipeline would need a lot. many double buffering is probably unavoidable.

[king2]

Excellent lib, I wonder you're still alive after implementing all these defines and variations in one piece of code :)

One question about dithering: as I understand, DMA can use linked lists, so for dithering you can trade off memory for dithering, i.e. double number of buffers for additional 1 bit of color resolution, make 4x buffers for 2 additional bits and so on?
I assume that first buffer will contain data with color (for each color of each LED), and second buffer will contain same data of zero, depending on which value of additional LSB bit?