Enhancement: Implementation of my fully-coded mod to Glediator effect

[johnty4321]

One of the best and mostly unheralded updates to Nutcracker was Sean’s addition of the Glediator effect which allowed using .gled files as input. This allowed me to capture great videos from YouTube, mp3 Visualizers, etc. with Glediator, perfectly sized to my 40x20 matrix, and create an entirely new “effect” in less than five minutes. I created hundreds in the summer of 2014. They looked fine in the Nutcracker preview window but when I displayed them on my 2811 pixels, the colors were very faded –not even close to what I was seeing on my PC monitor.

I started looking at the underlying code in wxWidgets and found a documented issue with colors in the RGB/HSV domains. Since Nutcracker was just reading the RGB values in the .gled file, it occurred to me that if there were sliders for Hue, Saturation and Value in the Glediator Effect Settings window, I might be able to increase the color saturation of the pixels to look more like the preview.

I spend months learning how to set up a Developers environment, Code::Blocks, modify an Effect, write in C++, etc. I changed the effect from RGB to HSV and added the sliders to the Settings window. Running a compiled copy on my PC, the change worked like a champ. Not only could I increase color Saturation, adjusting the Value slider let me get rid of background noise while the Hue control let me change the entire color palette of the video giving me multiple effects for the price of one!

Problem was, Nutcracker was now many releases down the road and I didn’t know how to put my changes back on GitHub without screwing up something. I’ve continued to run my matrix from my local v3.4.4 copy. I have now built more pixels displays and I’m using the latest xLights version for programming but I can’t integrate my matrix.

Long story short (too late) I’m hoping a kind developer will take my changes and integrate them into the production version of xLights. I have a Word document (attached) that has everything that was changed: the definitions that were modified with the new HSV slider values (Effects.h, PixelBuffer.cpp, etc.), the C++ code that changes the effect from RGB to HSV, the new Pane1_Glediator widget definitions, Slider Values and Tooltips for each of them. Assuming the basic layout for the Glediator effect hasn’t changed to accommodate the new xLights GUI, it should be mostly a copy and paste effort to update the effect.

I think many users would find this mod useful. Not only can Glediator capture video perfectly sized for the pixel display, it renders a LOT faster in xLights than the Video effect.

If somebody steps up to the plate I’d be ever so grateful.

John Tyson (johnty) Denver, CO jblue@earthlink.net Glediator HSV Mod to Nutcracker v3_4_4.docx

[AzGilrock]

We don't use the color code from wxWidgets it was slow so Dan wrote a class called xlColor that handles all our color and we have all our own functions to convert from RGB to HSV color spaces and I even added HSL to support one of my effects. If we did add Hue and Saturation adjustments my guess is it would just be a global setting in the Color panel not specific to just the Glediator effect.

[madsci1016]

They looked fine in the Nutcracker preview window but when I displayed them on my 2811 pixels, the colors were very faded –not even close to what I was seeing on my PC monitor.

The issue you are describing is why Gamma Correction exists. Due to the non-linearity of how we perceive light, colors will appear faded. You don't need to switch color spaces and mess with saturation, you just have to apply a dimming curve to your RGB values.

Some Pixel controllers can apply Gamma correction for you. Mine don't so I used a dimming curve in Vixen 3 on each of the RGB values individually before they are blended. I'm new to Xlights, so I don't know if they have the same premise. But thats what will fix your issue, Gamma Correction.

[AzGilrock]

Yes we have the same concept. For every model in Layout you can define a dimming curve. We provide a simple gamma/brightness adjustment as shown in this screenshot or there are more complex options in the drop down if you want a different curve per color. You can even specify an input file for each color.

[johnty4321]

Bill, Gil, thanks for the feedback.

 “But that’s what will fix your issue, Gamma Correction.”

It’s not a gamma issue.

I didn’t mention that all native xLights effects don’t have color saturation issues. If the pixel controller in test mode lights a red sub-pixel (255,0,0), the pixel is a bright red. If I drop an ON effect onto my matrix and choose the same red value, it displays the same red. Monitoring the E1.31 data stream with SACNView, I can see the RGB values being sent to the pixels. For the ON effect set to red, the hex values for the three channels of the first pixel are

FF 00 00 - 100% red, no green or blue.

If I display a 255,0,0 red field on my monitor and capture it with Glediator the result is

77 0B 0E - 46%red, 4% green and 5% blue.

It might be a Glediator capture issue. Doesn’t matter; my HSV mod fixes the problem. By moving the Saturation slider to about 120% of unity and Value to 175%, I get

FF 00 05 - just a speck of blue but close enough to match an internally generated xLights red.

The color gamma adjustments available on a per model basis would be needed if I were trying to change the color temperature of a white pixel or to compensate for different types or ages of pixels on different models. I have none of these conditions.

“ If we did add Hue and Saturation adjustments my guess is it would just be a global setting in the Color panel not specific to just the Glediator effect.”

Gil, it’s only the Glediator effect that needs these adjustments. Each of the hundreds of videos I’ve captured has slightly varying HSV slider settings. Global sliders in the Color panel wouldn’t help this problem. Changing values for one effect would probably screw up all of the other effects.

“I even added HSL to support one of my effects.”

That’s exactly what I did. Is your effect with HSL support in the latest version of xLights or some standalone copy? Was it a one-time effort or something that will be there with each new version release? None of my captured videos will work in xLights v4.x because they can’t find the HSV sliders. I’m just trying to fix this once so that I’m not tied to a specific release that couldn’t benefit from future enhancements.

[AzGilrock]

Actually I looked and it's not in an effect but I did add the functions to Color.cpp for working in the HSL color space and I use it to allow the user to reduce the Lightness of the background image in the CustomModelDialog.cpp.

[AzGilrock]

By the way the Color Panel settings are not global...every effect you drop on the grid has it's own copy of the settings from the Color Panel. Same with the Layer Settings and Layer Blending panels all the settings are part of the effect.

[madsci1016]

I'm still not convinced it's not a Gamma correction issues, or at least the data your presented doesn't rule it out, if that's what you were trying to do. Gamma Correction won't change a full Red value if applied right.

Let's be clear if you are using images of video taking on a pixel grid, something HAS to be doing Gamma Correction or else it will look faded and washed out. Our monitors do it for our PC so it looks right on the screen. The color Orange is also very hard to get right on LEDs if not corrected. IF you want to test if Xlights is doing gamma correction correctly, try setting a nice orange of 255 135 0 and you should see in the sACN something like 255 51 0.

Gamma correction is not about white balance or matching pixels. It's about mapping values against a curve to account for the non-linearity of the human eye. It's so essential in the science behind color mixing and electronics that it's usually embedded in LED control drivers themselves. ( I was actually surprised the first time I learned it's not in the Ws2811, as it has been in many other systems I've developed) You TV is doing it, your monitors do it, and our LED displays have to do it as well.

[johnty4321]

"IF you want to test if Xlights is doing gamma correction correctly, try setting a nice
 orange of 255 135 0 and you should see in the sACN something like 255 51 0."

Bill, I did try this. An orange of 255 135 0 in xLights outputs 255 135 0 with RGB gammas set to default 1.0 in the model Dimming Curves section. Choosing RGB Brightness/Gamma from the drop-down list in that window and setting Green Gamma to 2.5, the output changes to 255 52 0. I don't have any pixels hooked up at the moment but I'll try connecting the hardware tomorrow and see what the pixels look like in the real world.

Assuming this approach is in the right direction, how would red and blue gamma be set? Same sort of increase? By eyeball? Where did you get the 255 51 0 value? Testing with pixels?

Great discussion. This doesn't fix everything that my HSV mod can do to a video but it might make some of them usable.

[madsci1016]

I'm still a beginner to Xlights so I don't know it's specifics and only have knowledge of this Gamma Issue after researching the problem having faced the same issue you faced with video and pictures appearing muted and the colors washed. Vixen 3 did not have a Gamma correction menu, so I created my own output curves by experimentation until colors looked right on my pixels.

This is the curve I used to get the numbers I posted. I'm actually surprised I was only off by 1, as my curve was achieved through trial and error. This same curve is applied to my red, green, and blue channels.

I surmise a Gamma of 1.0 on that drop down is a 1:1 mapping of the requested value meaning no correction taking place, as you demonstrated, and a Gamma of 2.5 creates a curve similar to my own. I suspect you should set all color gammas to the same 2.5 value on ant model you'll use images or video and see if that resolved your problem.

I've found Gamma Correction is usually applied by Look Up Table, and if you google you can find many people sharing a common table. Here's more info with an example table. https://learn.adafruit.com/led-tricks-gamma-correction/the-issue

[keithsw1111]

I have looked at your code for HSV adjustment and I dont get it. You seem to allow the user to set HSV values from 0-100 which you then turn into 0.0-1.0 values which you then add to each and every pixel. That seems odd. Why would you add the same value to every pixel ... wouldnt you sometimes want to reduce the value ... maybe scale should be -100-100. Should the adjustment vary based on the current pixel colour? THis just may be my lack of understanding of HSV.

[keithsw1111]

More I think about it ... S&V I should add/subtract ... linearly i guess. H however should wrap. If it goes < 0 then I should add 1 as H is a continuum

[johnty4321]

You don't have to do any processing. I've sent some comments to your email address.

[madsci1016]

@johnty4321 did you ever verify if the gamma setting change corrected your images? Curious about the outcome.

[johnty4321]

Bill, changing the gamma setting on my matrix model to 2.5 did absolutely nothing. Colors on the 2811 pixels are still very faded. Increasing gamma to 50 (max allowed) did increase the color saturation but also adversely affected the Glediator file by putting big random moving black holes in the image. This enhancement request is now closed so I don't know if you'll see this response or if the requested changes that would fix the problem were implemented.