WS2812BHueStrip, dimming issue

[betonishard]

Hello,

Great work, liked it the first time I used it. I use the ws2812B Hue strip, and I have a small issue. with dimming the strip. It seems that full brightness is reached after around 20% when using the official hue app. In other words, there is no difference between 20% dimlevel and 100% dimlevel of the ledstrip. DId you see that occuring in your setup?

I used your WS2812 ino file on both esp01 and nodemcu.

Thanks again.

Best regards.

[Mevel]

Same here with original hue App and hue Switcher.

Nodemcu + ws2812b strip.

[kurniawan77]

Here too... Sk6812.

[mariusmotea]

Hi,

This is true, xy to rgb conversion formula is not so good. You need to be very good at mathematics to understand how this can be corrected. Basically a quick fix can be to increase the parity from 255 to 1024, but i'm not sure if in all conditions the maximum level will be obtained. If 20% => 100 brightness in all situations, then we can divide with 5 and the problem is solved, but this need to be confirmed first.

[mariusmotea]

Conversion formula is copied from here https://en.m.wikipedia.org/wiki/SRGB#The_forward_transformation_.28CIE_XYZ_to_sRGB.29

Anyone brave enough to modify it?

[shbatm]

Disclaimer: I'm not at home and can't test this, so I may be way off -- but I think you have the gamma correction reversed.

The gamma correction in lines 127-129 appear to be the reverse of what is used in NeoPixelBus's RGBColor.Correct() function. If that's correct, then the lines should read (EDIT:) as below.

Graph of the two functions attached. Notice how the green line goes much higher (brighter), much faster. You are correcting up to 50% of full brightness at 20%, versus the reverse, where you don't cross 50% brightness after correction until nearly 75%.

EDIT: I re-read the link you sent, it appears pow(x, (1.0f / 0.45f)) is the simplified, approximated version of the full piece-wise function (1/0.45 = 2.2). So you could use the following 2 options:

  // NeoPixelBus RGBColor.Correct() version
  r = pow(r, (1.0f / 0.45f));  
  g = pow(g, (1.0f / 0.45f));
  b = pow(b, (1.0f / 0.45f));

or

  // Fancy Wikipedia Version
  r = r <= 0.04045f ? r / 12.92f : pow((r + 0.055f) / (1.0f + 0.055f), 2.4f);
  g = g <= 0.04045f ? g / 12.92f : pow((g + 0.055f) / (1.0f + 0.055f), 2.4f);
  b = b <= 0.04045f ? b / 12.92f : pow((b + 0.055f) / (1.0f + 0.055f), 2.4f);

[mariusmotea]

Hi,

Your findings looks good. I will try to test when i will arrive home. If you test this and is working better then maybe you can create a pull request, so your contribution will be noted.

Marius.

[Mevel]

// Fancy Wikipedia Version r = r <= 0.04045f ? r / 12.92f : pow((r + 0.055f) / (1.0f + 0.055f), 2.4f); g = g <= 0.04045f ? g / 12.92f : pow((g + 0.055f) / (1.0f + 0.055f), 2.4f); b = b <= 0.04045f ? b / 12.92f : pow((b + 0.055f) / (1.0f + 0.055f), 2.4f);

Works! 👍 replacing

However: The Brightness change is less visible on colors, compared to plain white.

Example: White: 70%-100% Visible Blue / Red / Green : 70%-100% Barely Visible

All Colors: 0%-70% Visible To Sum it up: Very nice! Thank you!

EDIT: Found out, that the lights go Off at 1%. No big deal but the Standard "Nightlight"-Scene in Original Hue App is Orange at 1% --> shutting down the lights.

System: NodeMcu + WS2812b

[mariusmotea]

The Brightness change is less visible on colors, compared to plain white.

This is normal for WS2812b, white nuances are made from power of 3 leds, while red, green or blue is generated from power of only one led.

Found out, that the lights go Off at 1%

This is a problem also for me, Nightlight scene is applied after hour 23:00 on motion detected.

[Mevel]

I did some Testing with my NodeMcu and WS2812b Strip + Original Hue App.

• Original Firmware by Marius

• Color Mixing 👍 Nice Colors, Correct Mixing with Colorwheel of Original Hue App

• Dimming 👎 Unable to Dim correct

• Aproximation Formula

  // NeoPixelBus RGBColor.Correct() version r = pow(r, (1.0f / 0.45f));
  g = pow(g, (1.0f / 0.45f)); b = pow(b, (1.0f / 0.45f));

• Color Mixing 👎 Displays Wrong Colors (i.e. Select Orange get Purple)

• Dimming 👎 Not Working (Changing intesity changes color) Guess: not all Channels get Dimmed?

• Fancy Wikipedia Version

  r = r <= 0.04045f ? r / 12.92f : pow((r + 0.055f) / (1.0f + 0.055f), 2.4f); g = g <= 0.04045f ? g / 12.92f : pow((g + 0.055f) / (1.0f + 0.055f), 2.4f); b = b <= 0.04045f ? b / 12.92f : pow((b + 0.055f) / (1.0f + 0.055f), 2.4f);

• Color Mixing Displays Colors Correct, BUT unable to Mix dark Purple or Orange (Red Channel)?

• Dimming Works, but shuts down at 1%

[shbatm]

Looks like the approximation formula should actually have been:

// NeoPixelBus RGBColor.Correct() version
r = pow(r, (1.0f / 0.45f)) + 0.001961f;
g = pow(g, (1.0f / 0.45f)) + 0.001961f;
b = pow(b, (1.0f / 0.45f)) + 0.001961f;

This is a translation of NeoPixelBus' Correct function: 255.0f * (pow(value, (1.0f / 0.45f)) / 255.0f) + 0.5f

I'll be home tomorrow and can test some variations. I've ran into the issue before where orange and purple are flipped on another project, and I can't remember how I fixed it.

There is also a lookup table method which is supposed to be faster but uses more memory. See resources below.

• NeoPixelBus function source
• NeoPixelBus table
• NeoPixelBus Wiki
• Adafruit Article

[shbatm]

Added a test script for WS2812BHueStrip.ino to use the NeoPixelBus table method for gamma correction if anyone wants to try it. You can find it on this branch: https://github.com/shbatm/diyHue/commit/3b73139a37f574e991e0ff48b48e5fc6d0b4f702

[Mevel]

Added a test script for WS2812BHueStrip.ino to use the NeoPixelBus table method for gamma correction if anyone wants to try it. You can find it on this branch: shbatm/diyHue@3b73139

Tested. Working so far but same issues with too much Red (need to select Yellow to get Orange) --> Fancy Wikipedia version. Also: below 3% the green Channel does not light up but thats marginal i'd say.

[betonishard]

I tester the same thing shbatm and all these options. Results were at least the same.unfortunately unsatisfying. Hopefully a better resolution will be found, or up my skills..

[shbatm]

Hello, I have had some time to play with this on my own devices. I think I have a working solution, please see my branch or Pull Request #91 to test. If you find it works, I will update the rest of the firmware files (right now only Arduino/SK6812HueStrip, Arduino/WS2812HueStrip, PlatformIO/SK6812HueStrip, and PlatformIO/WS2812HueStrip have been updated.

Findings:

• I think the original Gamma Correction was the correct formula.
• The sRGB conversion formulas were different in the Arduino and PlatformIO files -- Arduino files matched the matrix on Wikipedia, so I have updated the PlatformIO file to match.
• Moved the brightness conversion to the end of the convert_xy() function. I now think performing this adjustment at the beginning was causing the dimming issues.

Please test and let me know what you find. Color mixing and dimming now both working on my WS2812 strip.

[mariusmotea]

I tested with WS2812 and i'm very impressed, i can dim the colors very nice now. Thanks also for updating PlatformIO projects

[Mevel]

Works really nice! Thank you! Color Mixing 👍 Dimming 👍

One Minor finding: When using "Nighttime"-Scene (Default in Hue App) at 1% with Orange Color --> Only Red Channel gets illuminated. At 2% and above, colors are displayed correct. My Solution: Make own Scene with 2% Default.

Thank you very much! Works really nice!

WS2812 + NodeMcu

[mariusmotea]

My Solution: Make own Scene with 2% Default.

better to override 1% bri to 3-4% bri in xy mode.

[mariusmotea]

I believe this will be ok:

  int optimal_bri = bri[light];
  if (optimal_bri < 5) {
    optimal_bri = 5;
  }

and at the end:

rgb[light][0] = (int) (r * optimal_bri); rgb[light][1] = (int) (g * optimal_bri); rgb[light][2] = (int) (b * optimal_bri);