FastLED v2.1 Dithering
This sketch is running with FastLED.setBrightness( 3 ) {out of a possible 255}, and using the new FastLED v2.1 temporal dithering.
This looks really great guys!
omfg, you guys are awesome!
Our next trick will be driving ~500 leds off of an ATTiny at 8Mhz w/512 bytes of ram. I’ll let you do that math 
(Also, we have to finish 2.1 first, then I have a handful of other large scale led projects to get finished, so maybe summer for the ATTiny stupidity
I have been praying for a way to do more pixels on a tiny. I keep thinking about 4-bit colors and a lookup table. Then we could cycle hue’s by tweaking the table or move the pixels by changing the LED array…
To be fair, the project I want to do with the ATTiny is more of a proof of concept/showing off how to do more with less, and likely won’t be anything directly applicable to the library - but who knows? Many of the library features come from an evolution of things that @Mark_Kriegsman and I end up doing for our own personal projects.
Zeke: why a tiny?
This looks really great. Amazing work guys.
Parsimony? For example, I did a piece that was an umbrella with falling raindrops. I could have easily gotten away with 16 shades of white, but ran out of memory on the strips. I ended up using a teensy which was way overkill. If there was an 8-pin chip with more memory that was easy to program I’d be stoked.
I’m doing a lot of wearable or small mobile stuff and the attiny85’s are fun to work with in that context because I can just use a battery, the tiny and some lights and do all sorts of interesting stuff.
I can’t wait to play with the dithering. I’m pretty much always running at brightness to conserve battery so things should get a lot prettier. Thanks for the hard work as always.
-Zeke
What about small boards like this - http://www.dx.com/p/mini-controller-module-black-works-with-official-arduino-board-287192#.UzX-ktywO0x
those are awesome! they are 10x the price of the attiny’s, but so much cooler. I do love the explosion in hardware options over the last few years.
Keep up the great work guys!!!
what do you have to do to exlpoit the dithering?
Justin: the dithering is totally automatic; here are the three steps to get best results.
First, program your animations for FULL brightness, meaning don’t universally ‘dim down’ your colors or leds[] array. Program as if you wanted everything eyewateringly bright and power-sucking.
Second, use the FastLED master brightness control FastLED.setBrightness(0…255) to turn the light level of your whole project down to the brightness and power consumption level that you want. As you adjust the brightness down, the dithering will automatically kick in more and more to keep your colors balanced and smooth.
Last, for smoothest visual results, replace any regular “delay(…)” call with a call to “FastLED.delay(…)”. The library will use the ‘delay time’ to keep refreshing the LEDs with dithered pixels. The more and faster refreshes it can do, the better the dithering will look.
Short version: program for full brightness, use FastLED.setBrightness(…) to adjust light and power level, and use FastLED.delay(…) for best visual results.
Let us know how it works for you!
The animation in the video above was programmed for FULL brightness colors (eg CHSV( hue, 255, 255) ), and then the master brightness control was turned down to the absurdly low level of … 3.
On the left you can see that the undithered LEDs’ colors look chunky and coarse.
On the right, with dithering in full effect, you can see that even at the ridiculously low brightness level “3” (out of 255), the colors still have good dynamic range and smoothness.
The ONLY difference between these two video shots is that I disabled dithering on the left. The right side is running with all the default dithering settings for v2.1.
You all know way more than I do about the light spectrum/processing stuff. I am really not that smart… So is the real benefit here for low light conditions? Or when you want your colors to blend together really well?
How do you disable it?
Last question… (probably not)… I am getting away from doing delay() and going to using timers so I can do other things while I am waiting to refresh the next set. I am assuming Fastled.Delay() is a synchronous function call? Or are you using timers?
FastLED.setDither( 0 ) disables dithering.
Yes, FastLED.delay(…) is synchronous.
And yep, the whole point of it is to solve a problem that only occurs at lower brightness levels. At brightness 255, dithering has literally no effect. Without dithering, if you drop the brightness to, say, 20, there are only twenty different light levels that each led can have, and the steps between them are pretty visible. Since the led strips are digital, integer-based devices, you can’t show a pixel with brightness “11.5” – it has to be 11 or 12. (Spoiler: you get 11.)
With dithering enabled, if you drop the brightness to, say, 20, the library kicks in to use the time domain to create fractional “in between” light levels. Suppose you have some pixel whose scaled light level should be 11.5. As noted above, the led strip can only display 11 or 12, no fractions. What FastLED will do is this: on the first call to show(), it’ll send 11 to the led strip for that pixel. On the next call to show(), FastLED will send 12 to the strip for that pixel. Subsequent calls will automatically ‘dither’ back and forth, mixing the right proportion of integers over time so that the net visual brightness from that pixel is actually 11.5.
Even though the strip’s hardware can only show 8 bits of color depth resolution, FastLED is using temporal dithering to add more precision. Exactly how much depends on a lot of factors, but I’d say we might be adding another four bits maybe.
If you want to see what it’s doing, run one of your animations with FastLED.setBrightness( 4 ), and put in a full second delay between frames using regular delay(1000). You’ll see how FastLED is blending colors in the time domain. (Now drop out the delay, and you’ll see the net result.)
Hope this helps explain a bit more!
Ok… thanks for the explanation…
I am hand coding all my own stuff and I use Gamma Correction for any fading of brightness . Will the dithering affect the colors in those cases then? I guess I will have to download 2.1 and try with and without the dithering and see if I see a difference…
Given that you’re already doing some interesting things ‘by hand’, I recommend that you try v2.1, and play around with the various brightness and dithering settings. The brightness/dithering that takes place in the library is “free” in terms of CPU power, so see what you can do with it!
But it sounds like in order to take advantage of dithering, one has to have fast periodic calls to FastLED.show(), correct?