Why use Y for brithness ?

[neoteknic]

When I uset setRGB (0,0,255) I want max brightness blue but instead I have a very very low brightness with blue. Why use y for brightness, instead of max([R,G,B]) ? It seem more logical for me ?

What do you think ?

[garrettw]

That's just how the XYZ scheme works.

Check out the output of this test script (scroll to the bottom).

As you can see, an RGB value of [0,0,255] yields a brightness of 12. (Strangely enough, when I worked through the calculations manually, I got 10, but I guess it's close enough that it doesn't matter.)

However, it also shows that if you take the X and Y from that RGB but use a brightness of 255, you get a wildly invalid RGB value where the blue is 942.

If you look here on WIkipedia and here in the code, you can see how the formulas match up.

[garrettw]

BUT..... after playing with Colorizer.org, I can see that the B slider under HSB does in fact behave like max([r,g,b]) -- so maybe that would be the way to go, assuming that the lights are indeed expecting a brightness and not a lightness or luminance value.

[neoteknic]

Yes, in my logic, with 0,0,255 I expect a 100% brightness for blue led, not 12/255 (0,0,12 for that)... Of course 255,255,255 will be much brighter than 0,0,255, because 3 LEDs are ON instead of 1 with blue only), that's why the XYZ can be wrong for hue, because 100% brigth blue is only 12% of 100% bri white. What is the value to have 100% blue with RGB and the XYZ formula ? I dont think that it's a good formula to use with hue. I already changed it in my fork to have alway max(R,G,B) or manual setRGB(r,g,b,bri). It's more user friendly to use formula like colorizer to set the brightness ! Also all android app with RGB selector seems to do max(r,g,b).

[neoteknic]

You can use my fork, color logic fix integrated better if you work with RGB, and more features. https://github.com/neoteknic/Phue