I’ll add a feature request…
It would be great to have an option to set the white balance for the strips, globally, so it applies to all patterns. (and for beginners like me who can’t figure out how to do this in the code per pattern, yet)
I did just answer this here
Adjusting when using RGB is pretty easy: Given values of R, G, B, you adjust one or two of them to match the levels of the 3 colors to give you a white level that seems correct. (so if your blue is too low, you’d either boost your blue, or more likely, lower your green/red to meet the level of blue generated, so that it displays ‘white’ (or at least as white as your strip is capable of)
Doing this with HSV, it’s a very non-trivial math (mostly: converting to RGB first, adjusting as above, and then converting BACK to HSV) but if you really want to do it, figure out your adjustment with RGB, then use code (elsewhere on this forum) to do hsv2rgb(), adjust(), rgb2hsv() and then use hsv.
I agree, it’s a reasonable request to ask for a white balance setting to set a global adjustment in PB, however, doing so for multiple strings of lights (anything more than 1) would be annoying to code for… so mixing and matching different types is likely NOT in scope of this request. Just ONE adjustment should be pretty basic though.
Yeah, just a basic adjustment, assuming all strips are the same, would be great. People mixing and matching are likely more experienced, and could likely correct it themselves in the code.
Replying here too…
It all gets converted to RGB in the end, and now that I’ve figured out a good way to do HDR with RGB values, I could add in a layer of while balance support there.
The tricky thing in my mind has been that every LED clone out there will have different settings. Others may have solved this stuff already, so I shouldn’t have to reinvent the color wheel
If anyone has code/math examples to point to I’ll be happy to take a look!
@zranger1 posted code that essentially does a short version of what I suggested above: takes hsv, converts to rgb and then just uses the RGB directly to light the led. (I was figuring you might want to continue with hsv, so you’d convert back, but @zranger’s use case is likely true in 99% of the needs out there.
@wizard, I think the “setting” is basically 3 sliders (RGB) which light up the first few LEDs as 100% and then you lower the sliders to make the “whitest” combo (so in my example above, you’d slowly turn down red and green, until the LEDs were the most white), save that adjustment, and then it would apply that small correction behind the scenes on all patterns.
I’m curious if white balance might be added to the code. I’ve been able to modify individual patterns, but would love to be able to simply turn down the blue globally. So I can simply run other peoples code w/out having to modify each one.
maybe the mapper feature could be reused or added on, to allow for WB/color adjustments.
in my case, the “backfire” sign i created (and posted about in another thread), i started with a small order of LEDs to prototype one letter then I bulk ordered the rest to complete the sign, and of course much to my dismay, the initial batch is a bit dimmer and bluer than the rest.
i’d love for a way to apply a correction to that specific region of pixels in the mapper, instead of having to try to correct for it in each pattern.
For a 2D pattern, you could put it in the mapper’s z coordinate, then rename your Render2D to Render3D and use the z value for whatever correction you need at output time.
I do this for a 2D picture frame pattern where I store θ normalized to 0…1 in z:
(my feature wish is: just let the mapper return an arbitrary-length array and deliver it all to my render function)
thats a good suggestion! although that does still mean i have to update every pattern i want to use.
Indeed … but at least you wouldn’t have to update them again for every different set of LEDs! I agree that having it baked in as a firmware feature would be best.