Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Sharing Dimming Curves

  1. #11
    Join Date
    Dec 2010
    Location
    Logansport, LA
    Posts
    945
    Post Thanks / Like

    Default

    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
    House [17k channels]: [URL="https://vimeo.com/album/4110945"]https://vimeo.com/album/4110945[/URL]
    Town [24k channels]: [URL="https://www.facebook.com/allthingssabine/videos/1816339391975617/"]Drone footage[/URL]
    Like: [URL="http://facebook.com/logansportlights"]http://facebook.com/logansportlights[/URL]

  2. #12
    Join Date
    Dec 2010
    Location
    Logansport, LA
    Posts
    945
    Post Thanks / Like

    Default Re: Sharing Dimming Curves

    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 by jlowe; 03-01-2013 at 12:45 PM. Reason: Clarity

  3. #13
    Join Date
    Dec 2011
    Location
    Key West, FL
    Posts
    3,637
    Post Thanks / Like

    Default Re: Sharing Dimming Curves

    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
    Link to my DownLoad Site: [B][COLOR=#ff0000][URL]http://www.joehinkle.com/HLS[/URL]

    [/COLOR][/B][IMG]http://joehinkle.com/HLS/HLS%20Logo%20Small.jpg[/IMG]

  4. #14
    Join Date
    Dec 2010
    Location
    Logansport, LA
    Posts
    945
    Post Thanks / Like

    Default

    Quote Originally Posted by JHinkle View Post
    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
    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.
    House [17k channels]: [URL="https://vimeo.com/album/4110945"]https://vimeo.com/album/4110945[/URL]
    Town [24k channels]: [URL="https://www.facebook.com/allthingssabine/videos/1816339391975617/"]Drone footage[/URL]
    Like: [URL="http://facebook.com/logansportlights"]http://facebook.com/logansportlights[/URL]

  5. #15
    Join Date
    Oct 2010
    Location
    Santa Barbara, CA
    Posts
    134
    Post Thanks / Like

    Default Re: Sharing Dimming Curves

    Quote Originally Posted by jlowe View Post
    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.
    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-equ...nt-hsv-colors/

    -Preston

  6. #16
    Join Date
    Dec 2011
    Location
    Northern California
    Posts
    1,062
    Post Thanks / Like

    Default Re: Sharing Dimming Curves

    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?

  7. #17
    Join Date
    Dec 2010
    Location
    Logansport, LA
    Posts
    945
    Post Thanks / Like

    Default

    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.
    House [17k channels]: [URL="https://vimeo.com/album/4110945"]https://vimeo.com/album/4110945[/URL]
    Town [24k channels]: [URL="https://www.facebook.com/allthingssabine/videos/1816339391975617/"]Drone footage[/URL]
    Like: [URL="http://facebook.com/logansportlights"]http://facebook.com/logansportlights[/URL]

  8. #18
    Join Date
    Jan 2008
    Location
    Fountain Valley, CA (Orange County, So. Cal)
    Posts
    2,147
    Post Thanks / Like

    Default Re: Sharing Dimming Curves

    Quote Originally Posted by Zeph View Post
    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).
    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).

    Quote Originally Posted by Zeph View Post
    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.
    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.

    Quote Originally Posted by jlowe View Post
    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.
    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.

    Quote Originally Posted by ptone View Post
    If you want a good geeky article on LAB, check out:

    http://vis4.net/blog/posts/avoid-equ...nt-hsv-colors/
    Maybe we should change out the color pickers in the sequencing tools to use HCL instead of RGB or HSV?

    don
    Last edited by djulien; 03-09-2013 at 05:04 PM. Reason: added HCL comment
    Click for display details >>
    web site: http://www.eShepherdsOfLight.com or http://www.facebook.com/eShepherdsOfLight
    technical articles: http://downloads.eshepherdsoflight.com

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •