Sharing Dimming Curves

Interesting idea - I've been thinking specifically of the color issue as well.

For example if you go from red to say - orange or purple, the involvement of the second LED adds brightness. I'm wondering if there is a way to basically stipulate that full white, will be no brighter than any single LED, so that all colors are of relative equal brightness?

One way to do this may be to ensure that R + G + B always adds up to no more than 255 (perhaps with some different curves for the R/G/B components) - while this will result in dimmer colors overall, it would ensure that you get a consistent brightness during color shifts.
 
ptone said:
For example if you go from red to say - orange or purple, the involvement of the second LED adds brightness. I'm wondering if there is a way to basically stipulate that full white, will be no brighter than any single LED, so that all colors are of relative equal brightness?

One way to do this may be to ensure that R + G + B always adds up to no more than 255 (perhaps with some different curves for the R/G/B components) - while this will result in dimmer colors overall, it would ensure that you get a consistent brightness during color shifts.
Click to expand...

Yes, that is the best way to level out the brightness.

If you are using custom firmware or plug-in (or a dimming curve if it is RGB-aware), you can enforce it there automatically. Otherwise, you would need to apply the rules at the time you select the RGB values in the sequencing software.

Regarding the "dimmer colors overall", the LED is still on so your eye sees it as on, but you're correct in that it will not look that bright. (doesn't really need to that bright if it's in a grid or matrix with many other pixels neat it).

BTW, this also saves power.

don
 
Last edited:
djulien said:
Yes, that is the best way to level out the brightness.

If you are using custom firmware or plug-in (or a dimming curve if it is RGB-aware), you can enforce it there automatically.
Click to expand...

do such things exist - or is this hypothetical?

-P
 
HLS has had dimming curves since it was created.

You can create them for a single color or for RGB (Note - RGB actually uses three dimming curves so that you can normalize and balance the R, G, abd B led intensities.

They are located in the DimmingCurve Folder under HLS.

Share them by giving them to someone and they just place them in the folder.

They are a simple XML file --- so you can use HLS to create them - you create them youself.

Hope that helps.

Joe
 
JHinkle said:
You can create them for a single color or for RGB (Note - RGB actually uses three dimming curves so that you can normalize and balance the R, G, abd B led intensities.
Click to expand...

Three dimming curves for RGB is not the same thing as normalizing the intensity across a range of hue values, does it attempt to normalize the color brightness across a range of hues at "full" value?

-P
 
So here is a video showing three LEDs dimming under different conditions.

The one on the far right is unadjusted, the one in the middle uses the hand-made curve posted at the start of this thread, and the far left is using a gamma 2.5 curve using this formula:

https://github.com/ptone/BirdFish/blob/master/birdfish/colors.py#L15

Jim said he liked using a gamma of 2.0 when talking about this sort of pseudo-dimming curve
http://auschristmaslighting.com/forums/index.php?topic=1091.0


The differences are dramatic. I'm going to experiment now with the idea of normalizing brightness across hue and see how that looks.

-P
 
ptone said:
So here is a video showing three LEDs dimming under different conditions.

The one on the far right is unadjusted, the one in the middle uses the hand-made curve posted at the start of this thread, and the far left is using a gamma 2.5 curve using this formula:

https://github.com/ptone/BirdFish/blob/master/birdfish/colors.py#L15

Jim said he liked using a gamma of 2.0 when talking about this sort of pseudo-dimming curve
http://auschristmaslighting.com/forums/index.php?topic=1091.0


The differences are dramatic. I'm going to experiment now with the idea of normalizing brightness across hue and see how that looks.

-P
Click to expand...

Looks pretty good, Hopefully this will stop people complains about pixels/leds haveing a bad dimming compared to incans.
 
Preston-

Awesome demonstration. Puts the curve I made to shame! I'm going to take a look at your code when I have some time. The last few days both work and life have kept me from doing much more than keeping up on the forums. Not much play-time.

What I want to figure out is, taking your gamma formula, how I can get values to then plug in to the HLS dimming curve file?

It also looks like you have some adjustments for RBG. I look forward to deciphering what you are doing there.

I know you have several "out of the box thinking" type of projects, and it's good to have your voice and ideas about things. I also really like the idea you posted earlier in this thread about some intelligence on balancing the overall pixel brightness based on the individual component intensity to always equal 255.

Josh
 
Ok, I might be a little dumb....

Looking at your snippet of code, tell me if I'm understanding things:

The first array, DIYC_DIM, are the values I posted earlier in my attached dimming curve.
The second array, GAMMA25, are the values you derived from your formula and using a gamma value of 2.5.

Then, you include the forumula you used to create those values. So... to create a dimming curve file based on the 2.5 gamma, I can just plug those GAMMA25 values in to a HLS dimming curve file. Right? And, if I want to create dimming curves based on other gamma values, I can run your code with different gamma values, such as 2.0, for example.

I've mentioned to Joe the idea of simplifying the dimming curve feature of HLS, where a user could just input a gamma value, and HLS would handle the rest. But, that would remove some customization. But, for those who wanted more control, they could use the current interface. I think it would be awesome to click on a channel and apply a 2.4 gamma or whatever and be done.

Your code doesn't make use of the colors and their values though. Are you still thinking on how you would make use of those bits?

There are two SEPARATE issues with regards to RGB:

1. Preston mentioning the constant intensity; the idea that, no matter what the mix of RGB components are, it always totals up to the overall intensity value set in the sequence. If I want white, rather than each RGB component displaying 255/255/255, it would be more like 85/85/85. I think that's what is meant...

2. Controlling for intensity variations in the separate colors themselves. For example, a red led that displays "brighter" than a blue led at the same intensity value. This would mean, when mixing for purple, for example, the shade might be affected by the inherent difference in brightness or power of the led color component. This is what Joe is talking about when he mentions separate curves for each color. Controlling for variations in RGB individual color intensity would help with color mixing so that the output color would remain true in the actual display.
 
Last edited:
I am looking at implementing a Gamma Curve based on your request.

Once created - you can modify it.

All that curve does is to make the Sequencer's LINEAR intensity requests Appear to be linear to the eye --- which is what we want.

The other issue with RGB pixels that a user needs to address is the sliding of those dimming curves so that the same COLOR intensity exists for the same REQUESTED intensity. THAT is what is going to get you Yellow to look like yellow.

Single color gamma correction is not enough --- you then have to have THREE different curves - so when you mix a specific linear intensity request - you get the color you expected.

Joe
 
JHinkle said:
I am looking at implementing a Gamma Curve based on your request.

Once created - you can modify it.

All that curve does is to make the Sequencer's LINEAR intensity requests Appear to be linear to the eye --- which is what we want.

The other issue with RGB pixels that a user needs to address is the sliding of those dimming curves so that the same COLOR intensity exists for the same REQUESTED intensity. THAT is what is going to get you Yellow to look like yellow.

Single color gamma correction is not enough --- you then have to have THREE different curves - so when you mix a specific linear intensity request - you get the color you expected.

Joe
Click to expand...

Joe- that sounds really awesome! Best of both worlds: quick curve creation that is still open to customizing.

With regards to rgb: you are right that it is a much more complex task. Separate dimming curves are absolutely needed so that the color output matches sequence color. Hopefully, through observation of output, we could eventually get to a point where a user could look at the rgb power: red 300ma, green 500ma, blue 300ma, and knowing that info could set appropriate gamma values to get desired color mixing.

It would also be great to have OVERALL intensity matching as well. Ex: 2 rgb floodlights shine on opposite sides of house. One set on white, not set on red. Both set at 50% intensity in sequence. HLS would be able to output a specific dmx value to both floodlights that would reflect similar levels of brightness, even though the white color is actually powering more LEDs than the red color.
 
jlowe said:
Your code doesn't make use of the colors and their values though. Are you still thinking on how you would make use of those bits?

There are two SEPARATE issues with regards to RGB:

1. Preston mentioning the constant intensity; the idea that, no matter what the mix of RGB components are, it always totals up to the overall intensity value set in the sequence. If I want white, rather than each RGB component displaying 255/255/255, it would be more like 85/85/85. I think that's what is meant...

2. Controlling for intensity variations in the separate colors themselves. For example, a red led that displays "brighter" than a blue led at the same intensity value. This would mean, when mixing for purple, for example, the shade might be affected by the inherent difference in brightness or power of the led color component. This is what Joe is talking about when he mentions separate curves for each color. Controlling for variations in RGB individual color intensity would help with color mixing so that the output color would remain true in the actual display.
Click to expand...

First off, you can use a simplified version of the formula in an excel spreadsheet, which will be easier than running code:

Y=(X/255)^G*255 where X is raw DMX value, G is gamma and Y is gamma-corrected DMX

You are completely right about your two points above - however the reality is that the second point may make results of the first point moot. That is, if the blue LED is is actually lower in brightness and is perceived as dimmer, then bluer color will be "dimmer" even if you normalize the DMX values.

Getting the perceived brightness normalized across colors has actually turned into a pretty tough puzzle, because you don't want to effect the hue.

There are some formulas for calculating luminance, but my guess is it will be difficult to do this and preserve predictable color mixing.

Luminance (standard, objective): (0.2126*R) + (0.7152*G) + (0.0722*B)
Luminance (perceived option 1): (0.299*R + 0.587*G + 0.114*B)
Luminance (perceived option 2, slower to calculate): sqrt( 0.241*R^2 + 0.691*G^2 + 0.068*B^2 )

When applying dimming curves to RGB, you can't just apply gamma correction to RGB individually, you have to apply it while in HSV colorspace to the V or intensity, and then let the colorspace conversion handle the reduction in RGB. If you apply dimming to each RGB channel, it really screws with color mixing.

Then there is the interesting area of using LAB colorspace.

Right now I think most of us are using HSV to do color mixing and blends. This lets us blend a single hue value. But the color mixing is light based, so mixing blue and yellow = white, where as in LAB space it would be green, like when you mix paints.

While I ultimately don't think classic displays care about precise color or gamma correction, there are a couple reasons to keep exploring this area:

video projection on a matrix - this requires more "true color" and gamma correction so that things don't look washed out. I'm perhaps a black sheep here as I really have no interest in pixel based matrix's in displays, as to me they just look like low res screens rather than architecturally or landscape integrated lighting.

The LAB colorspace could also be interesting to provide alternative color transitions compared to the classic "rainbow" spread that is familiar. I have other ways of doing custom blends, but LAB might be another option, and more efficient than my current multi-segment envelope approach.

If you want a good geeky article on LAB, check out:

http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/

-Preston
 
The exponential nature of light sensitivity seems intuitive (at least the superficial aspects). Take the output of a given bulb in fixed viewing circumstances; going from 2 to 3 lumens is likely to seem much more significant than going from 20 to 21 lumens; in fact it'll probably be more like going from 20 to 30. Each step of perceived incremental brightness (think of moving right one step on an X axis perceived brightness) would be expected to require an increase in brightness proportional to the previous step (eg: 30% brighter) - think of the Y value being 30% above the previous one). That's an exponential curve. The adaptation of they eye to brighter lights could be another factor (eg: pupil narrowing); as I recall there is something on the order of 1,000,000:1 difference in moonlight and sunlight but our eyes adapt (OK, part of that is about rods vs cones too, I'm simplifying).

A gamma curve (which appears to be polynomial) could approximate this shape.

Where it gets more confusing is with more colors. For example, consider the perceived difference beween LEDs at brightness 0,0,2 vs 0,0,3. That's a significant step, unlike 0,0,202 vs 0,0,203. Gamma correction could assist this. But what about 200,0,2 vs 200,0,3? That would be a significant step in the blue channel considered alone, but would it be perceived as significant when mixed? Thinking along this line, one might expect that accomplishing a perceptible shift in hue *might* take a change in channel balance more proportional to the total luminance than to the individual channel. That is, there might be an interaction between the gamma curves. The optimal gamma curve for red might seem different depending on whether blue and green were low, or high.

The simplest (conceptual) approach might indeed be to use the gamma correction in HSV space. as previously described, applying gamma to only the V.

However, it seems like other devices (video displays of various technologies, printers) have already needed to sort out the question of simultaneous RGB gamma correction. For example video boards with adjustable gamma. Do they do anything other than apply the same gamma curve to each of the RGB channels? Are we overthinking?
 
This discussion is truly quite fascinating. It's amazing how many variables go into trying to gamma-correct blended colors.

But, I too wonder how this is handled elsewhere in electronics. I'm not sure if the issue is being over-thought, where the differences are negligible, or else there must be some complex models out there dealing with this. I bet it's the former. "Real world" Christmas lights will probably be ok.
 
Zeph said:
The exponential nature of light sensitivity seems intuitive (at least the superficial aspects). Take the output of a given bulb in fixed viewing circumstances; going from 2 to 3 lumens is likely to seem much more significant than going from 20 to 21 lumens; in fact it'll probably be more like going from 20 to 30. Each step of perceived incremental brightness (think of moving right one step on an X axis perceived brightness) would be expected to require an increase in brightness proportional to the previous step (eg: 30% brighter) - think of the Y value being 30% above the previous one). That's an exponential curve. The adaptation of they eye to brighter lights could be another factor (eg: pupil narrowing); as I recall there is something on the order of 1,000,000:1 difference in moonlight and sunlight but our eyes adapt (OK, part of that is about rods vs cones too, I'm simplifying).
Click to expand...

It makes sense that these would all have an effect, although not sure how significant the visual impact is. A further complication would be that the display is constantly changing (typically), which may reduce the noticeability. (ie, you wouldn't see a few % difference in color variation for something like a fast chase effect, but you might notice it on one that changed more slowly).

Zeph said:
Where it gets more confusing is with more colors. For example, consider the perceived difference beween LEDs at brightness 0,0,2 vs 0,0,3. That's a significant step, unlike 0,0,202 vs 0,0,203. Gamma correction could assist this. But what about 200,0,2 vs 200,0,3? That would be a significant step in the blue channel considered alone, but would it be perceived as significant when mixed? Thinking along this line, one might expect that accomplishing a perceptible shift in hue *might* take a change in channel balance more proportional to the total luminance than to the individual channel. That is, there might be an interaction between the gamma curves. The optimal gamma curve for red might seem different depending on whether blue and green were low, or high.
Click to expand...

I think this is where an RGB-aware correction would be beneficial, so it can take into account the interaction in the R, G, and B channels.

jlowe said:
But, I too wonder how this is handled elsewhere in electronics. I'm not sure if the issue is being over-thought, where the differences are negligible, or else there must be some complex models out there dealing with this. I bet it's the former. "Real world" Christmas lights will probably be ok.
Click to expand...

It seems that any hardware, firmware or sequencing software tools that provide a correction curve feature often just defer the question to the user to decide.

ptone said:
If you want a good geeky article on LAB, check out:

http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/
Click to expand...

Maybe we should change out the color pickers in the sequencing tools to use HCL instead of RGB or HSV?

don
 
Last edited:
You must log in or register to reply here.
Back
Top