Separatel I've started a conversation on the dashboard colour wheel. And that opened up another thought. DCJ suggested I look at the text input control in colour picker mode, relying on the browser's colour picker. That is indeed one way to control RGB lighting but not ideal. I guess this separate issue is common to both mechanisms... let's say you are controlling RGB lighting - specifically but not likmited to a LED STRIP. One testing this I've just realised the control is linear, but except for special complete kit, if you find yourself controlling a LED RGB light or strip, the LINEAR nature of this control is problematic when you turn the levels down... the LEDS will look bright right down to very low levels (0-255 per colour). If it were possible to add the option to make the levels even very crudely logarythmic, that would fix it. So off the top of my head, value 255 full brilliance, value 0 obviously off.. Let's say we are controlling green.. value 64 far from being 25% brilliance looks around half way up. Under 20 shows as maybe 25% brilliance, 5 shows as maybe 10$ brilliance. Given time I could make that more realistic but the point is, our eyes are not linear, more like logarythmic so a brilliance control should at least attempt to emulate that. Also the visual effect you see in your browser of the new value is all to hell .... at value 80 (in my green only example) the actual LED is as I said still very bright yet the button colour onscreen ia almost black. That too might benefit from an opposite log change.
here at value 80 for green, around 1/3rd.. we see a button in the dashboard which is almost black, yet our LED is still quote bright.. 
Good on you for not trusting your eyes (so unfair that iris control is autonomic and not conscious...) Might be overkill, but you could pick up a cheap lux meter and take measurements at different power or pwm cycle levels and chart out the values to come up with your own best fit curve to apply a custom calibration. It's a lot of brute-force testing and would be needed for every type of LED you use, but it's the only way I can think of to get solid quantitative results rather than relying on qualitative judgments.
and as if to amplify the point I just selected green on RGB lights using the text input, browser (chrome) colour selector. I thought I was bang in the middle of green but sufficiently out that there were values 241 green, 27 blue. This was enough as the controls are linear, to give a significant blue tint to the green (ie almost cyan).
I've used LOTS of colour LED lights - you are right of course, one could get very technical with this (and I can).. but for general use (as we only have 256 levels inc off for each colour) - I suggest a simple lookup table as option for the output.. a hand-drawn curve even to play with. For example, 200 looks nearly as bright as 255 - not on the button icon which becomes quite a bit darker but on the LEDs. 100 looks maybe half intensity or higher on the LEDs but very dark on the button.
Of course depending on how the LEDs are driven (assuming PWM for now) and lead lengths, right down at the bottom end could vary a lot but the general idea of more log than linear control is generally sound. If there was an option or two in the control then such lighting could be handled without compatibility issues. To do all of this externally involves doctoring values ro make the lights look linear AND doctoring the button colour to be made brighter until much lower values.
A lookup table would probably be a great plug and play way to go about it if you don't feel like going through the trouble of trying to determine the function of your best fit curve (I mean, it's technically better but so far into diminishing returns that it's starting to get a bit obsessive.)
If you were to sufficiently standardize your lookup table, with the right sensors you could probably even throw together a flow to automatically cycle your LED through its range and plot the corresponding brightness/setting table for you. Push button, it craps out a file you can slot into a flow and there you go: easy mode to get LEDs from all sorts of manufacturers (and batches) living together in total harmony.
edit: ugh you're giving me ideas and I don't have time 
https://www.adafruit.com/product/1980
1 Like
Sounds like a good general purpose solution would be to add exponential/logarithmic modes to the existing core range node, which right now only scales linearly -- or perhaps a new contrib node that scales the input based on a graphical curve or function, like setting the gamma curve for graphics cards in the old days...
Looks like I've sparked something off. Am I right in saying the most popular use for an RGB control would be for LED lighting - hence this all seems reasonable.
Only things I've used it for have been RGB LEDs and setting button colors dynamically (in an attempt to match said RGB LEDs in a dashboard.) Until someone comes up with color e-ink wallpaper I expect this will continue to be the trend.
But the dashboard isn't the only way of generating RGB values to control lights. So I think it would be better as a separate node.
