How do I "unpatch" a single color on a single pixel?

[deonb]

So let's say I have a matrix and one of the pixels somewhere in the middle has its green LED out.

I can still send blue & red to the pixel (which I want to do), and if green is sent to the pixel it turns black, which is also fine and not that noticeable.

However, when I send white to it, it will turn pink, which is very noticeable.


How do I tell xlights not to try and send White to it (or any color that mixes in Green)?

In Vixen I would unpatch the Green color breakdown to that one pixel - what is the equivalent in xLights?


Failing the ability to unpatch one color - how do I turn a pixel off completely?

[Gilrock]

Only one way I can think of is to create a single channel model, point it to that channel, place it at the bottom of the model list so it renders last, and drop an Off effect across the duration of the sequence.

[deonb]

Only one way I can think of is to create a single channel model, point it to that channel, place it at the bottom of the model list so it renders last, and drop an Off effect across the duration of the sequence.

Ok. That will have to turn it completely dark, but good to know.

Actually, come to think of it .fseq is like the easiest file format in the world. I can just post-process it with a small app to zero out the pixel when the bad channel gets lit. That way I don't have to mess with my sequences.

[Gilrock]

Only one way I can think of is to create a single channel model, point it to that channel, place it at the bottom of the model list so it renders last, and drop an Off effect across the duration of the sequence.

Ok. That will have to turn it completely dark, but good to know.

Actually, come to think of it .fseq is like the easiest file format in the world. I can just post-process it with a small app to zero out the pixel when the bad channel gets lit. That way I don't have to mess with my sequences.

No I said Single Channel model so it would only black out one channel not all 3 channels of the node.  Just create a Single Channel model that is mapped to the green channel.

[deonb]

No I said Single Channel model so it would only black out one channel not all 3 channels of the node.  Just create a Single Channel model that is mapped to the green channel.

That doesn't help though. I don't need to black out the green - it's already blacked out by the fact that the green LED is broken.

What I need to do is black out Red / Blue IFF green is being mixed in as well (e.g. if the output color is White or Yellow). If green is not being displayed, then Red / Blue output works fine.

I've tried doing the setup as you described above and it only blacks out the actual green channel. If it's trying to display Yellow in this setup, I get Red instead of Black.

But this technique works fine for blacking out the pixel completely if I do all 3 channels.

[Gilrock]

Ok fine but when you said in Vixen you would unpatch the green color that sure sounded like it would end up with a zero for that channel.

[deonb]

Ok fine but when you said in Vixen you would unpatch the green color that sure sounded like it would end up with a zero for that channel.

It's actually smart enough to know if a pixel doesn't have all three colors patched to it and you require an unpatched one to output a particular color, that it can't send the other 2 colors either.

So it just leaves the pixel black. Sort of like going into a RG or GB or RB mode and only outputting colors that can be made up with the remaining LEDs.

[Gilrock]

I have a pixel on my roof that has one of the 3 leds burnt out.  I'm the only one that notices.

[Gilrock]

So I guess to close this out the answer is you can't do that.  If you want enter a Github issue for it.  With how xLights works the best way I could imagine to handle this would be having a way to enter a bad pixel/channel map.  Not sure when someone would want to focus on working on a feature to handle bad hardware though.

[dkulp]

IF I were to implement this in xLights (big IF), it would likely be a modification the dimming curve dialog for the panel where there is a separate dimming curve for each color.  Basically, if the "green" dimming curve is 0% the entire way, have an optional checkbox to have it zero out the others if there is a green component or similar.   

Really, when I wrote the dimming curves, I had thought about trying to allow some sort of pluggable functions or similar in there that the user could write something.   However, the dimming curves are on a critical performance path so setting up a scripting engine and running a script or whatever would have killed the performance so I never pursued it. 

[dkulp]

Actually, that wouldn't work either as the dimming curve is for the entire model.   

[Phrog30]

So I'll be the one to ask, why not just replace the bad pixel?

Sent from my Pixel using Tapatalk

[deonb]

So I'll be the one to ask, why not just replace the bad pixel?

I need two consecutive rain free days before I can get up and change pixels, otherwise my boom lift gets stuck in the mud. I should really upgrade to a 4WD, but it is what it is right now. That means the light may be out for days or sometimes weeks before I can get back to it.

Gilrock's suggestion allows me to disable the pixel completely though, which is basically 90% there. Still allowing colors over the other 2 channels when it works is just a bonus.

It's actually not always better doing this - it looks terrible with e.g. a butterfly effect, since the light will flicker on and off constantly as gradients pass over it - which is worse than just staying off completely.

But with something like Logan's Star Wars sequence last year it worked beautifully.

[dkulp]

Another thought:  are you using FPP to run the show?   Do you have any ranges of channels anywhere in the fseq file that don't have any props assigned?   If so, you could remap 3 channels of "blank data" onto the three channels of that pixel within FPP and not have to touch anything in xLights and re-render and then remember to undo all of that when you fix it.