Welcome to Pixelblaze! This is a common think I’ve noticed too, that most of the all-on whites tend to be a very high color temperature (very blueish).
It’s a little different for each strip, but when I want to warm up my whites, I’ll generally try hue values in the 0.05-0.15 range, and saturations between .5 and .9. So try something like:
hsv(.08, .7, 1)
For a look at some code that calculates specific white color temperatures, have a look at Zranger1’s UtilityColorTemp, currently on page 6 of the pattern library.
Thanks for the reply.
These strips are pretty bad. Like, in patterns where it should be yellow or amber like the spark/fire patterns, they’re green…
The issue is when I modify that hsv line, it changes the color of all the pixels to that hue… It doesn’t apply some level of color temp modification to the existing color pattern.
Do I add a second hsv line which applies the correction while leaving the original intact?
Wow, greenish, huh? Just wanted to double check that the RGB order is correct. When you play the first pattern, “An intro to Pixelblaze” is the order of the colors R, then G, then B?
There’s no global color temperature correction function that is just a setting or a line of code. I think the simplest approach, which is admittedly still daunting for people early in their journey with Pixelblaze code, would be to replace calls to hsv() with one that tries to correct whites towards a warmer white. This would probably apply an interpolation based on the pattern’s uncorrected saturation value. If you decided the correct warm white was at hue 0.08 and saturation .6, then you’d write a little math that scales the pattern’s initial hue and saturation values towards that, reaching it fully when the input saturation was zero. Experimentally you’d have to determine if linear interpolation looked ok.
Yes, the rgb order is correct. The white balance looks better when it is not correct… But, it is correct. (I played around w/ that for a while)
So, this is where I am lost… I don’t know how to do what you are saying in the code.
I tried some simple math, like multiplying h by .08, and that causes the colors to change slightly around amber, but it is 90% amber.
I am probably not going to wrap my head around the code… (at least not any time soon… Busy time of year). So… Maybe I’ll switch controllers… Wled and fastled both have white balance adjustment as part of their initial basic setup. I’m just making a fun light for my sons fort… Don’t need anything fancy. But I really would like the colors to be better.
Yeah, PB doesn’t have that built in. Might be a good todo item (ie global color adjustment setting) for @wizard
it’s a non-trivial bunch of math to do it to HSV. It’s absolutely easier with RGB (essentially, you adjust the values to compensate for one/two of them being brighter/stronger (or weaker/darker) than expected (to give you the closest equal level of RGB to yield white.
For @wicked1 and anybody else who needs to adjust white levels, Here’s a short example that shows white balancing in hsv-based patterns: (I have some highly blue tinted LEDs myself this year!)
// Quick and dirty white balancing for hsv patterns
//
// 11/29/2021 ZRanger1
// call this function at pattern initialization with the RGB values
// that produce the best white on your display.
// Input values should be in the range 0.0 to 1.0 or very
// strange things will happen.
var rBal = 1; gBal = 1; bBal = 1;
function setWhite(r,g,b) {
rBal = r;
gBal = g;
bBal = b;
}
// call this in your pattern instead of the default hsv()
// simple, quick HSV to RGB algorithm adapted from random GLSL
function hsv_balanced(h,s,v) {
var r,g,b;
h = h * 6;
r = (h+5) % 6;
r = v - v * s * max(min(min(r,4-r),1),0);
g = (h+3) % 6;
g = v - v * s * max(min(min(g,4-g),1),0);
b = (h+1) % 6;
b = v - v * s * max(min(min(b,4-b),1),0);
rgb(r*rBal,g*gBal,b*bBal);
}
// change the values in the call to setWhite to
// what looks best on your system.
setWhite(1,1,1)
export function beforeRender() {
;
}
// shows full LED white on first half of display,
// "balanced" white on second half.
export function render(index) {
p = index/pixelCount;
h = 0
s = 0
v = 1
if (p < 0.5) {
hsv(h, s, v)
}
else {
hsv_balanced(h,s,v);
}
}
To be fair, 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
I don’t see anything in WLED for white balance correction. The color correction checkbox applies a singular gamma table for each RGB element for any kind of LED, white in one of the existing pallets/effects would remain unchanged. It does have a white color temperature picker for custom colors.
@wizard, I totally agree this is a giant can of worms. I’ve been thinking a lot about it myself, since ExpanderVerse explicitly supports random mixing of LED types, so being able to match whites is pretty desirable. But wow… color matching curves for every LED clone out there. Ugh!
@zranger1
You know, now that I see your example perhaps the best way to handle white temperature would be to let people pick a white in settings that reflects their ideal white on their LEDs.
Would handle led clone, subjective, perceptual, and environmental differences all in one.
Are you feeding it enough power? I have some strips where different colors attenuate faster when they don’t get enough amperage, e.g. my RGB strips get a little ‘cyan’ when all-white.
@wizard, the “gotcha” that I’ve run into with the simple approach is this: the amount of adjustment that you have to apply to get a decent white out of a random set of LEDs can be huge. If you apply the adjustment over the whole color range, you wind up losing a lot of brightness on saturated colors.
I didn’t do it in the example I posted, but in Expanderverse, I’m applying the correction in proportion to the square of (1-saturation). This doesn’t effect fully saturated colors at all, and so far, passes the, “looks about right to me” test!
Edit: oops, fixed backwards thinking about saturation.
Thanks for the replies!
Yes, my power supply should be enough power… and the color is the same whether I’m powering 100 led’s or 600.
Here’s some info on the wled forums, but I have not really dug in to know exactly what they’re talking about:
And, I like both methods that have been brainstormed so far… Either R, G, and B sliders to manually adjust the white color, or a white color chooser where we have several options and choose whatever ‘white’ looks best.
(Sorry for starting two threads about this)
Thanks a lot… I figured this was a topic more than just me would be interested in.
Funny enough, the RGBW/WW issue is slightly different… I know @wizard just added RGBW support (so if you use at least equal amounts of RGB, it’ll convert that to W). But that’s actually a interesting question in relation to WW… The white balance might not be exactly 1:1:1 on many lights, it might be .9:.9:1 (for example), so a straight 1:1:1 removal would actually look wrong in that case… A more Amber light, same issue.
So adding a white balance could help improve the RGBW support for sure too.
Hi, I gave you a heart the other day, but wanted to actually type out…
Thanks for the ‘quick and dirty white balcancing’ code. It’s working great.
And got me over my fear of jumping in to the programming. I’ve gotten a lot of things figured out now.
Since this is for my sons fort, and he’s still a bit young for the app, I think I’ll build a box w/ a couple buttons and knobs. Have the button switch between programs. Knobs to control speed and adjust hue.
Thanks! I’m glad it worked for you, and even happier that you got started programming the Pixelblaze. It’s a bit of a switch in thinking from FastLED and such, but I think you’ll find it’s by far the easiest tool around for prototyping ideas for new lighting patterns. Hope your son enjoys the fort!
Do you find your colour correction needs different levels at different brightness too? I’d expect the brightness curve of each pixel to be non linear, and each colour to be it’s own special amount of whacky
Yes… I noticed mine are much more blue at lower brightness levels.
Which… I don’t fully understand if these are PWM… That’s sort of the point of dimming w/ PWM with LED’s in general… At least for architectural lighting when you’re concerned w/ CRI… Lowering the voltage changes the CRI, but pulsing it at full voltage doesn’t.
But anyway, yes, with these it’s different.
But for me personally, I don’t care. I adjust it to what looks best at the brightness the lights will be used at the most.
SK9822 LEDs get a little greenish when the global brightness bits are used for HDR. The extra brightness bits work via different constant current levels, with PWM on top of that. APA102 use a slow PWM on top of PWM, so the balance is constant at the cost of refresh rates.
Thanks, that’s interesting.
It’s strange to me that the chips on the LED’s themselves are controlling things… But I know that’s how it is now… (I’m coming back to electronics after about 20 years… I was an EE in my youth… Somehow started an IT business and the EE became a hobby… then I got busy w/ kids and life, and EE became non existent)
