Human-eye linear dimming for PWM strips

[mcer12]

PWM dimming does not look linear to human eye. Not much we can do in terms of addressable strips but it should be very simple to add a lookup table for PWM strips, as a optional setting. This would make low brightness dimming tremendously better and smooth!

Enabling this option would:

1. set PWM resolution to 12bit (should be enough)
2. add lookup table for 8bit
3. lowering PWM frequency a bit might be required for this

[mcer12]

Here's a great article about this with a python script to generate the lookup table. I personally used this for one of my projects and it's really awesome in practice. It's day and night difference. (don't mind the broken ssl certificate)
https://jared.geek.nz/2013/feb/linear-led-pwm

[Aircoookie]

Thank you for the idea!
Gamma correction with 2.5 gamma is actually really close to the CIE1931 formula (except that the latter gives a higher output at low brightness levels, which might be nice).
In any case, it seems beneficial to go with a gamma of 2.5 instead of the current 2.8, as that aligns much closer to perceived brightness. Maybe we should swap the current gamma table for the CIE table entirely, though I'm not sure if that would improve or worsen low brightness hue accuracy.

Regardless, I agree that a PWM resolution of 12 or even just 10 would help a lot with low brightness color accuracy.

[mcer12]

@Aircoookie CIE1931 sounds like the proper way to do things. With addressable strips, it doesn't really matter which one we pick because on low brightness they are all useless anyway. From my personal projects, to archieve really smooth 255 step pwm dimming, we need 12bit table, 10bit sounds like it's good enough but it's really not, it's exponential so on brightness below 10 it will still be choppy. I guess it would be a sensible compromise if there were memory constraints but ESP32 and ESP8266 both should handle the calculation without lookup table if that's the case. Excuse me if some of the suggestions are already implemented since I am not familiar with the code yet.

[mcer12]

@Aircoookie It's worth a note that Philips Hue (and probably others) also use CIE1931 since it's an industry standard. So it should make WLED more accurate and compatible with other lights.

[softhack007]

Found this recently, where a lookup table is used for achieving LED brightness curves that look linear to the human eye.

Looks easy:
https://github.com/Zanduino/SmoothLED_8bit
https://github.com/Zanduino/SmoothLED_10bit/wiki/CIE1931-Compensation
https://github.com/Zanduino/SmoothLED_10bit

A common misconception is that gamma correction should be used, as it does have a very similar response to the eye. However, gamma correction has nothing to do with how humans perceive light, it is just coincidence that it appears to work. The CIE 1931 lightness formula is what actually describes how we perceive light.

[mcer12]

@softhack007 I'm sorry but this is totally off topic, it's atmega code, useless with ESP. ESP32 does 12bit pwm natively so we don't need any interrupts, just a lookup table so it's even more simple here. It's possible to use https://github.com/StefanBruens/ESP8266_new_pwm for esp8266 but that would require reimplementation of pwm and it's not clear if it would be compatible with the rest of the WLED code (because of HW interrupts) so to me it makes sense to do this ESP32 exclusive which should be a minor change.

[softhack007]

@softhack007 I'm sorry but this is totally off topic, it's atmega code, useless with ESP.

Why? Its essentially a lookup-table. That's not specific to atmega or ESP32. My idea was just to use this mapping table for "WLED brightness" -> PWM brightness, and use the resulting number for the PWM driver.

If you think that's off-topic, no problem, just go ahead and don't let me disturb your circles...

Edit: I was thinking about this table, not the rest of the code:
https://github.com/Zanduino/SmoothLED_8bit/blob/8fc9b85842597b3af0eb4c3a8ef013306f15a737/src/SmoothLED.h#L77-L91
or https://github.com/Zanduino/SmoothLED_10bit/blob/896d341e34c661b04d212d9e16965525d0f6cd46/src/SmoothLED.h#L88-L150

a small script to generate a table is in the code comments, so it should be simple to make a similar static LUT for 12-bit or other resolutions.

[softhack007]

@mcer12 wrote

Here's a great article about this with a python script to generate the lookup table. I personally used this for one of my projects and it's really awesome in practice. It's day and night difference. (don't mind the broken ssl certificate)
https://jared.geek.nz/2013/feb/linear-led-pwm

Seems i overlooked that you made a very similar proposal a few weeks ago. What you said was also totally off topic, I presume?

[mcer12]

@softhack007 No actually my issue is not off-topic and please don't be combatitive, it's not very productive. I would love to see how exactly the 8bit lookup table that you shared solves choppiness at low brightness. Because this is already how WLED works (gamma correction), just calculated without lookup table. What I proposed and what we're talking about here is 12bit lookup table with 255 values which results in prefectly smooth 8bit linear dimming even at low brightness.

[mcer12]

@softhack007 10bit makes it little bit better but doesn't solve the issue whatsoever. All you really have to do is take a look at first few values in the the lookup table (lowest brightness values) to see the issue.

[softhack007]

Hi @mcer12 ok, this was also what I had in mind. Thanks for explaining.

Personally, I find it not very helpful to get slammed as "off-topic", and then see that the same idea was expressed "on-topic" already. But OK, i'm not angry about that any more. So let's forget it.

[mcer12]

@softhack007 mate if you had the same idea then why you're sharing a library that doesn't implement that idea? :D The library does exactly what WLED already does. If the library mapped 10bit values to 8bit, then that would have been a differnt conversation. If you took it as slamming then I'm sorry but you were off topic so I don't know what to tell you.

[softhack007]

Yes I can see your problem that you are facing.

Just to clarify what's needed: is the question
a) how to get from "WLED brightness" (8 bit) to "PWM" brightness (eg. 12 bit)
b) get from higher resolution future WLED brightness (eg 12bit ) down to PWM 8 bit?

Case b) does not seem very usefull, because the lost resolution (-4bit) combined with any kind d of calibration curve will lead to the same bad results in low brightness ranges as if you came from 8bit.
In case a) finding the best PWM resolution that allows to preserve details in the low brightness ranges might be possible. In this case, I can imagine that existing scripts/formulas can be used to make a LUT, either reprenting each input value or use interpolation to make the LUT smaller.