1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

IMPROVEMENT Better Color Adjustment

Discussion in 'Feature Requests' started by Funatiq, 19 May 2016.

  1. Funatiq

    Funatiq New Member

    Messages:
    22
    Hardware:
    RPi2, +PhilipsHue
    Hi guys,
    I'm new here and first of all want to thank you for this great tool and the new website.

    I played around with the color calibration in HyperCon and could not achieve a satisfying result. I took a look at the hyperion code and have a few suggestions which would improve the colors in my opinion.

    1) Change order from "Adjustment -> Transform" to "Transform -> Adjustment"

    The problem with Adjustment first is that the gamma value in Transform changes the pure white color. But the gamma value should only change the curve between white and black and not the values of pure white or black.

    Example:
    2) Change Adjustment

    So this is is a bit tricky, but let me explain my thoughts. If you set your color channels to include another color this does not change the white color but influences the grey colors. My suggestion would be to only apply the color channels when the main color exceeds the other color. This way the grey colors would have an equal ratio of RGB as the white color. Another problem is that the max output value of a color is reached before the color reaches max input. This could both be fixed with a linear increase from grey to maximum.

    Example:

    I hope that I could explain myself well enough and you agree with these changes. I know that with the changes everyone had to do their calibration again, but I think the result will be better.
    I don't really have experience with github, but I think I have to fork the project, apply my changes and send a pull request, so that you can see my code? Thanks again for this great project!
     
    • Like Like x 1
  2. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    @AEtHeLsYn
    some discussion stuff :)
    I can´t say myself that much to it :)

    Yes, forking, commit code, and do a PR against the hyperion Beta branch is the usual way.
    Thank you for your suggestions
     
  3. AEtHeLsYn

    AEtHeLsYn New Member Developer

    Messages:
    28
    Hardware:
    RPi1/Zero, RPi2, RPi3
    @Funatiq
    If you change the order to transform -> adjustment you are achieving a perfect white LED. In fact, in the original tutorial I wrote the need of performing the adjustment again after doing transform, but we can change order.
    About the second modification you proposing, that should be interesting, but I don't really understand whats the code beneath the proposal. Do you mind explaining in detail what linear operation are you doing to R G B channels?

    @Brindosch
    I love discussing about everything, thats the only way we can get better :)
     
  4. AEtHeLsYn

    AEtHeLsYn New Member Developer

    Messages:
    28
    Hardware:
    RPi1/Zero, RPi2, RPi3
    @Funatiq
    Just saw the PR lol, will test.
    Thank you
     
  5. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    @Funatiq
    @AEtHeLsYn
    Is there a solution to let the ambilight light up a little bit the whole time? (also during playback) As a little backlight during movie watching

    Black zones are not black -> they are (your rgb value)
    Even if you add a new option for this. Would be a nice feature!

    Also people are not satisfied with the HSL luminance gain as brightness regulator. They are still using HSV saturation
     
  6. Rick164

    Rick164 Administrator Staff Member Administrator

    Messages:
    190
    Hardware:
    RPi2, +Arduino, +AtmoOrb
    Yep, maybe something is going wrong at the Hyperion end with the new calibrations options but still have to manually add this to the config to lower brightness by 50% like before:

    Code:
            "hsv" :
             {
               ...
               "valueGain"     : 0.5000
             },
    
    When trying to do the same with luminance gain the colors shift considerably and even when correcting it after the luminance gain change can't get it to look right :(
     
    Last edited: 19 May 2016
  7. Funatiq

    Funatiq New Member

    Messages:
    22
    Hardware:
    RPi2, +PhilipsHue
  8. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    As following the explanations i was not sure of the blacklvl removes values (screw up the calibration a little bit?) If not, i will re-add them as backlight option!
    Thank you
     
  9. AEtHeLsYn

    AEtHeLsYn New Member Developer

    Messages:
    28
    Hardware:
    RPi1/Zero, RPi2, RPi3
    @Funatiq @Brindosch
    Nope, blacklevel sets the minimum channel value. Anything below the blacklevel setting will turn leds black.

    Now about reducing brigtness... HSL color space lets you modifiy more than HSV, you can check in wiki, but both transforms are the same. You can try to reduce HSL saturation also to reduce brightness, this will wash out colors a bit, or you can even set lower R,G,B values when doing whiteleveling.
     
    • Like Like x 1
  10. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    @AEtHeLsYn
    nope, the blacklevel sets the "color of leds (regarded as) black"

    @Rick164
    Could you try to lower the new "whitelevel" (not the whitelevel value @the config) to reduce the brightness?
    Is this a workaround? Instead of using HSV again
     
  11. AEtHeLsYn

    AEtHeLsYn New Member Developer

    Messages:
    28
    Hardware:
    RPi1/Zero, RPi2, RPi3
    @Brindosch
    Take a look at this code:
    Code:
    output = _blacklevel + (_whitelevel - _blacklevel) * output;
    
    When you set a blacklevel, as you just said, you will set a minimum color value (so the black would be #101010 instead of #000000), but you will reduce dynamic range. Anyway yes, if you set a minumum big enough (#1F1F1F) you can use that as backlight.
     
  12. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    yes, i will reintroduce it as "backlight" optional option. People asked and i think it don´t hurt that much :)
    Thank you!
    We need to investigate these strange brightness variations. this is the last thing which is a "unclear" point.
     
  13. Funatiq

    Funatiq New Member

    Messages:
    22
    Hardware:
    RPi2, +PhilipsHue
    Another solution for backlight would be to set a minimum luminance at HSL transformation to avoid all "dark" colors. The problem with blacklevel is that it influences all colors where a color channel is low. So pure colors get less pure. Like @AEtHeLsYn said it changes the minimum channel value without regarding the other channels.
     
  14. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    I will try it :)
     
  15. Funatiq

    Funatiq New Member

    Messages:
    22
    Hardware:
    RPi2, +PhilipsHue
    Just tried the new beta and I'm very happy with the result. Grey colors and gradients look much better now. I also think the HSL luminance gain works better now without shifting the colors.

    But there seems to be a problem after starting hyperion, I had to clearall with the remote for the leds to work with pictures or video.
     
  16. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    Thank you for report :)
    Could you upload your .json please?
     
  17. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    //confirmed
     
  18. Funatiq

    Funatiq New Member

    Messages:
    22
    Hardware:
    RPi2, +PhilipsHue
    Here is my config file.
     

    Attached Files:

  19. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    Investigated, i introduced this bug lowering the default booteffect from priority 990 to 700. Looks like the booteffect never stop the effect
    @redPanther
    Should this the case? The logs say the effect finished, but it never remove the priority. I could revert this and just use 700 as default for HyperCon, that it behaves like before the priority cleanup commit

    Bug or behaves like it should?
     
  20. Brindosch

    Brindosch Administrator Administrator

    Messages:
    679
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    revert the priority commit, new .tar.gz(s) online