Running at 100% brightness...

[robbiet]

Assuming that I have power to spare, what is the reasoning for reducing brightness at the controller?  It seems like most of you are running at reduced brightness. Is it just to save power consumption because you are maxed out on your PSUs?  For year one I’m pretty overbuilt and have plenty of power. At pure white I would be running my power supplies at about 70%. I’d like to just software limit brightness in Xlights and keep the option to go to 100% brightness when I want. Thoughts from all you veterans?


Sent from my iPhone using Tapatalk

[mikewlaymon]

So I won't be seen from space...   

[robbiet]

Haha. I don’t think I’ll burn anyone’s retinas with my 2000 pixels. Need a few more years.


Sent from my iPhone using Tapatalk

[mikewlaymon]

I live in an urban neighborhood with fairly high density, so primarily I do it to keep the neighbors at bay, and since most viewers are only 30-50 feet away, it's much easier on the eyes.

[Gilrock]

Usually because anything above 80% just dumps in more power but doesn't really make it any brighter.  Also you appear to have a misunderstanding of how the software and hardware perform brightness reduction.  If you use xLights to reduce the brightness to 70% then 70% is what you get when the controller is set to 100% brightness because the controller has no idea its at 70% when it receives the commands.  So if you set it to 70% in xLights and then 50% in the controller you end up with 35% brightness.  ALL brightness reduction is accomplished by changing the actual RGB byte values sent to the pixel.  It doesn't not reduce voltage or anything like that.  If you send 255, 255, 255 that is max brightness.  If you send 128, 128, 128 that is 50% brightness.  So technically if you define a half white greyscale color for an effect its equivalent to a 100% white effect set to 50% brightness.   If you define an effect as full white 255, 255, 255 and then set it to 50% brightness in xLights it becomes 128, 128, 128 or maybe 127's but lets not nitpik.  Then you have the controller set to 50% that effect command becomes 64, 64, 64 when it hits the pixel.

3 ways to reduce brightness/power consumption in xLights:
Change the color of the effect by reducing the RGB values equally
Lower the brightness slider in the color panel
Add a dimming curve to the model

[mikewlaymon]

Although it limits flexibility, I dim at the controller level (Falcon) .  Easier for me to "balance" my display instead of tinkering with the sequences.

[Gilrock]

I prefer to limit brightness in the controller because in many cases it would blow the 5 amp fuse on the output if I let it go 100%.

[robbiet]

Usually because anything above 80% just dumps in more power but doesn't really make it any brighter.  Also you appear to have a misunderstanding of how the software and hardware perform brightness reduction.  If you use xLights to reduce the brightness to 70% then 70% is what you get when the controller is set to 100% brightness because the controller has no idea its at 70% when it receives the commands.  So if you set it to 70% in xLights and then 50% in the controller you end up with 35% brightness.  ALL brightness reduction is accomplished by changing the actual RGB byte values sent to the pixel.  It doesn't not reduce voltage or anything like that.  If you send 255, 255, 255 that is max brightness.  If you send 128, 128, 128 that is 50% brightness.  So technically if you define a half white greyscale color for an effect its equivalent to a 100% white effect set to 50% brightness.   If you define an effect as full white 255, 255, 255 and then set it to 50% brightness in xLights it becomes 128, 128, 128 or maybe 127's but lets not nitpik.  Then you have the controller set to 50% that effect command becomes 64, 64, 64 when it hits the pixel.

3 ways to reduce brightness/power consumption in xLights:
Change the color of the effect by reducing the RGB values equally
Lower the brightness slider in the color panel
Add a dimming curve to the model

Ok. That makes sense. I didn’t realize that changing brightness at the controller just changed RGB values also. Guess I figured it was an overall voltage reduction or something like that. So do you find that changing brightness at the controller impacts the color(hue?) of the light as set from xlights?  For example if I were to set the color as orange, would the resulting visible hue look the same if I dimmed at the controller vs in xlights?


Sent from my iPhone using Tapatalk

[Gilrock]

I believe the colors appear less washed out to your eye when the brightness is lowered but you should just test it out and find what you prefer.  It took me a few years to settle on what I like for my show.

[robbiet]

Ok. Thanks for all the info.


Sent from my iPhone using Tapatalk

[chadthedrummer7]

Newbie question, and I know everyone runs at 80% or less, but how do you do that on the controller? you don't do that while you are sequencing do you? thanks for any info you have.

[MikeKrebs]

It depends on your controller.  Most have a setting where you setup the universes. What controller are you running?

[ozaz]

FYI
During the Sydney/Picton mini a question was raised regarding the issue we have in Australia being on daylight saving hours during December and it still being bright outside at 8pm or later.

if you've dropped brightness, either via controller and/or sequencer, to say 40/50% then it may not be bright enough when people visit early.

Keith suggested if running xSchedule you could set your lights to a higher brightness (either in controller and/or sequencer) then run multiple schedules and drop the brightness using xSchedule's output processing a set percentage every, say, 1/2 hour until it was dark and you were at your desired lowest brightness.