Better LED colours and gamma by rogere66 - testing and bugfixing thread - FEEDBACK NEEDED

[openshwprojects]

Ok, so this is a thread for this pull request:
#447
It was merged and I added my changes (config save, float pwm access).
The channel values on main page are also shown as floats.
Here is @rogere66 readme:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/led_gamma_control.md

Please flash to one device and check carefully!

Please double check if everything is ok and report.

I checked on my N bulb and it seems GREAT!

I can't believe how wrong I was, this is a real game changer, I should have merged it sooner, but I was put off by float channels (but I solved it, they are still integers for all case except PWM and it works now). @rogere66 really improved LEDs a lot.

[rogere66]

The release also works fine on my 7231T bulb!

I noticed that the setting confirmation message is gone - if not deliberate I would suggest to call led_gamma_list() whenever CFG_MarkAsDirty() is called on successful command exit.

In the code I just noticed that alternate cw mode use "value_brightness" and don't get gamma correction - this should be included as well - was the same in the PR.

[leoshusar]

Thank you! However this still didn't solve my main problem, but I'm honestly not really sure if it even is a problem and not just my imagination or limitation of something. I unfortunately don't know how stock Tuya firmware worked.

I have bulbs with BP1658CJ drivers. When I set the brightness to lowest possible, it can only show like 10 colors. This entire section shows always the same blue:

When I go one step towards cyan, it then jumps to cyan.
In log I can see it sends #000001 for the whole blue section and then #000101 for cyan. So technically correct.

I was able to find this about the driver:

they say it can do 1024 steps.

If my understanding of it is correct, that is 1024 steps means steps per channel, shouldn't there be much higher resolution than I'm experiencing?

[openshwprojects]

@leoshusar Yes, I just realized that I2C led drivers still get bytes (256 steps per color) so they loose 2 extra bits of data. Will also fix that soon.

[openshwprojects]

@leoshusar I pushed it but didn't have a device to test, can you check if it works better for you?
In general, I need testing of last release (the one that is building right now, will be up in few minutes).

[leoshusar]

Thanks, works much better!
Now I just need to figure out the correct calibration - I can't really tell which white is "the most white" :)

[rogere66]

@openshwprojects There is a minor problem with Transitions caused by RGB calibration values. The code has some correction for this, but there are still some corner-cases that don't work well. Transitions are marked as Experimental, but do you regard it as reasonably stable by now? If reasonably stable I may look into a fix for this.

[openshwprojects]

@rogere66 feel free to improve them, it's a very simple lerp in RGB values, maybe it would be better to lerp a hue value or something? Hm.

[jf-wm]

Hi i have some LEDs with adjustable white, the white balance is off therefore I opened #454 to find a fix for this. I tried the new correction mechanism which where implemented with this code (cal and gamma), but unfortunately they don't have any effect on the white balance of my LED. Is it possible to add a calibration feature for adjustable white LEDs ?

[openshwprojects]

@jf-wm can you show the pins config of your device and screenshot from panel? I am not sure if I understand you well. ADjustable white = CW light? Two PWMs?

[jf-wm]

@openshwprojects my light has two PWM pins ( pins 7 and 8), the panel looks like this: