Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing brightness is changing the RGB color #153

bcatalin opened this issue Jan 13, 2017 · 2 comments


Copy link

commented Jan 13, 2017

Still don't know if is really a bug or I didn't understood the library.

Part of a bigger project I need to modify the color of a strip and its brightness.

Setting the stip to a color ( R or G or B) and changing the brightness is fine but if I set the strip to
RGB (128, 128, 128) and change the brightness for example increment/decrement it in 1 unit steps like

setb = strip.GetBrightness() + 1 * delta;   
strip.SetBrightness (setb);  

I am ending up in a blank strip

  RgbColor pix; pix = strip.GetPixelColor(0);
  Serial.printf("R=%d G=%d B=%d\n", pix.R, pix.G, pix.B); 

Set bri: 59
Set bri: 58
Set bri: 57
Set bri: 56
Set bri: 55
R=0 G=0 B=0


This comment has been minimized.

Copy link

commented Jan 14, 2017

Please include more information. What you gave me is not enough to understand or see the problem.

  • Include a full sketch that demonstrates the problem.
  • Include the debug output so that I can correlate it with the provided sketch
  • Include the Arduino hardware you are working with.

NOTE: Once the internal color channel reaches zero, it will always be zero. So you can never expect to set brightness to zero and then brightness to 100 and expect anything other than black. Dimming this way is a destructive operation (original color is lost).

The only way to retain the original color and do dimming is to use the linear blend method on the color; blend between the color and black by the amount you want and then set all the pixels to that color.

@Makuna Makuna closed this Jan 14, 2017

@Makuna Makuna reopened this Jan 14, 2017


This comment has been minimized.

Copy link

commented Jan 14, 2017

I did some analysis of the code (the brightness feature is Adafruit's code ported, to remain compatible with them).
An iterative approach like you are doing for dimming is causing the small error due to math on every change to accumulate. If you iteratively dim by 2, you get different values. Again iterate by 3 even further different results. This is the nature of the math for their implementation.

This is why I originally didn't include it at all, its flawed.

The best approach is like I stated, keep the original values, calling the RgbColor.LinearBlend() to blend to black, passing a "dim" value of 1.0 (full brightness) to 0.0 (full dim) and then pass the results to the SetPixelColor.

@Makuna Makuna closed this Jan 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.