Undim to last known hue and brightness

[cees-elzinga]

Request from the blog:

I was also wondering if it was possible to make an option to disable the hue selector in the advanced menu so it just stays as the default colour. Still an amazing app though.

[..]

The colour my lights are when I start the application. in the advanced setting there’s an option now to change the hue colour when it dims and comes back up but I preferred it in 3.8 where it would just dim the hue colour I already had. So I was wondering if that feature could be optional.

[cees-elzinga]

should be fixed in version 0.5.0

[robwalch]

Sill acts a little weird. One thing I added was to also restore initial saturation, but the way it's setup that might be getting changed before or on initial playback.

[cees-elzinga]

Wow Rob! This is some fantastic work!

I've been way too busy lately, haven't been able to do any development. Just merged your pull request and played around with it a bit... the improved colours and smoother transitions look amazing.

Unfortunately I don't have the time right now to take a detailed look at the code. But saw some nice tricks (eg using the xbmc Monitor class to watch for changes in the settings file, because my polling solution was not the best ;-)). And very curious to the changes you made in the improved handling of the blue-green spectrum

On Mon, Jul 1, 2013 at 4:16 AM, Rob Walch notifications@github.com wrote:

Sill acts a little weird. One thing I addedhttp://../commit/0d760a756aeb6ad381ec06f2214e7503556e40acwas to also restore initial saturation, but the way it's setup that might be getting changed before or on initial playback.

— Reply to this email directly or view it on GitHubhttps://github.com/cees-elzinga/script.xbmc.hue.ambilight/issues/5#issuecomment-20260354 .

[cees-elzinga]

I'd like to post an update on my blog but don't want to take the credit for your work. If it's okay with you I'll add your name to it?

On Sat, Jul 13, 2013 at 2:09 PM, Cees celzinga@gmail.com wrote:

Wow Rob! This is some fantastic work!

I've been way too busy lately, haven't been able to do any development. Just merged your pull request and played around with it a bit... the improved colours and smoother transitions look amazing.

Unfortunately I don't have the time right now to take a detailed look at the code. But saw some nice tricks (eg using the xbmc Monitor class to watch for changes in the settings file, because my polling solution was not the best ;-)). And very curious to the changes you made in the improved handling of the blue-green spectrum

On Mon, Jul 1, 2013 at 4:16 AM, Rob Walch notifications@github.comwrote:

Sill acts a little weird. One thing I addedhttp://../commit/0d760a756aeb6ad381ec06f2214e7503556e40acwas to also restore initial saturation, but the way it's setup that might be getting changed before or on initial playback.

— Reply to this email directly or view it on GitHubhttps://github.com/cees-elzinga/script.xbmc.hue.ambilight/issues/5#issuecomment-20260354 .

[robwalch]

Thanks! Sure, I appreciate the cred ;)

You did the hard work creating this plugin. I've had a lot of fun tweaking it. I'll write up some code change highlights in a bit.

[robwalch]

Here are some small changes that had a big impact

Turn Off the Red Light

The lights turned red when the majority of pixels were very dark or the primary color on screen had a low score. This change got mixed in with color analysis enhancements.

def most_used_spectrum(self, spectrum):
# range(36) results in an incremental list [0, 1, 2, .... 35]
# so 35, red at the end of the spectrum, is often selected when it shouldn't be
-    ranges = range(36)
# [0, 0, 0, ...]
+    ranges = [0] * 36

The Blue-Green (and YellowGrab) Problem

Hue cannot display the color cyan (green+blue). The green triangle outlines the colors which hue can address:

So if the detected color hue lands in the middle of the spectrum on cyan, the value we send to the lights is shifted so that we don't get a cold white. I also found that light greens and yellows were shifting towards orange!

This object is used to store the averaged dominant HSV values and the ratio of frequency to scanned pixels. Any correction can be done here right when we convert the normalized HSV to the values used by the Hue API:

class HSVRatio:
  cyan_min = float(4.5/12.0)
  cyan_max = float(7.75/12.0)

def __init__(self, hue=0.0, saturation=0.0, value=0.0, ratio=0.0):
...
  def hue(self):
    if self.s > 0.01:
      if self.h < 0.5:
        #yellow-green correction
        self.h = self.h * 1.17
        #cyan-green correction
        if self.h > self.cyan_min:
          self.h = self.cyan_min
      else:
        #cyan-blue correction
        if self.h < self.cyan_max:
          self.h = self.cyan_max

Some other things I'd like to work on if there's time, increased user base, and interest

• Architecture and performance enhancements (I'm new to python so there's a lot of room for improvement here)
• Spectral frequency based analysis. Right now selected colors are grouped and averaged into even slots. It used to be 36 slots but I made it adjustable. Charting and isolating colors based on a waveform would be way better.
• Send each color to best matching light. Expanding on 'transition time based on hsv distance'. Transitions would be even more seamless by assigning lights based on distance.
• Eliminate delay between ambilight and screen (look ahead or cached color analysis. Also new to XBMC plugin development so a lot to learn here)
• Inclusion in XBMC Official add-on repository

[cees-elzinga]

Turn Off the Red Light

Ahh, nice find.

The Blue-Green (and YellowGrab) Problem

Cool. Nice of Philips to give some info here :)

Spectral frequency based analysis. Right now selected colors are grouped and averaged into even slots. It used to be 36 slots but I made it adjustable. Charting and isolating colors based on a waveform would be way better.

Saw you added it to the settings. I'm new to using waveforms, but I think the main issues with the add-on are 1) the delay, and 2) improved colors

Eliminate delay between ambilight and screen (look ahead or cached color analysis. Also new to XBMC plugin development so a lot to learn here)

I was thinking in this direction as well. I posted on the XBMC forums if it's possible to "look ahead" in the video stream from an add-on ( http://forum.xbmc.org/showthread.php?tid=154360):

"Not possible, XBMC holds a buffer of compressed video, the path from decoder to renderer is very short, there are only 2 frames buffered. Buffering a second of video would require quite a big rewrite of the rendering path, and it would also have to be added for every hardware decoder."

I wonder how effective cached color analysis is. The delay is most notable when the colors change drastically. I'm not sure how cached data is going to help predict the new color? (My assumption is that most time is spent not on calculating the new color, but to get to light in this new state)

Inclusion in XBMC Official add-on repositoryhttp://wiki.xbmc.org/index.php?title=Official_add-on_repository

I posted once on the developer mailing list and asked for inclusion but never got any response. Might check into this once more.

Some other things I'd like to work on if there's time, increased user base, and interest

During development of the add-on I got a lot of feedback, bug reports and feature requests. Now the add-on is getting more stable (and me just being too busy to answer to e-mails timely) it got a bit quieter, but I think there are a couple dozen of users out there :-)

On Sat, Jul 13, 2013 at 5:49 PM, Rob Walch notifications@github.com wrote:

Here are some small changes that had a big impact Turn Off the Red Light

The lights turned red when the majority of pixels were very dark or the primary color on screen had a low score. This change got mixed in with color analysis enhancementshttps://github.com/robwalch/script.xbmc.hue.ambilight/commit/01184494b27f2de05285728f975b23dd45c469a8 .

def most_used_spectrum(self, spectrum):# range(36) results in an incremental list [0, 1, 2, .... 35]# so 35, red at the end of the spectrum, is often selected when it shouldn't be- ranges = range(36)# [0, 0, 0, ...]+ ranges = [0] * 36

The Blue-Green (and YellowGrab) Problem

Hue cannot display the color cyan (green+blue). The green triangle outlines the colors which hue can address: [image: CIE color space]https://github-camo.global.ssl.fastly.net/95c9bcdcf9ea3ba64b9e3dc0dcc396d594810366/687474703a2f2f646576656c6f706572732e6d6565746875652e636f6d2f6173736574732f7468656d65732f747769747465722f696d672f6369652d636f6c6f7273706163652e706e67

So if the detected color hue lands in the middle of the spectrum on cyan, the value we send to the lights is shifted so that we don't get a cold white. I also found that light greens and yellows were shifting towards orange!

[image: Unacceptable!]https://github-camo.global.ssl.fastly.net/20f679abd87215ae9da48c87527a3a52a334f45e/687474703a2f2f742e716b6d652e6d652f3372326b356a2e6a7067

This object is used to store the averaged dominant HSV values and the ratio of frequency to scanned pixels. Any correction can be done here right when we convert the normalized HSV to the values used by the Hue API:

class HSVRatio: cyan_min = float(4.5/12.0) cyan_max = float(7.75/12.0) def init(self, hue=0.0, saturation=0.0, value=0.0, ratio=0.0):... def hue(self): if self.s > 0.01: if self.h < 0.5:

yellow-green correction

    self.h = self.h \* 1.17
    #cyan-green correction
    if self.h > self.cyan_min:
      self.h = self.cyan_min
  else:
    #cyan-blue correction
    if self.h < self.cyan_max:
      self.h = self.cyan_max

Some other things I'd like to work on if there's time, increased user base, and interest

• Architecture and performance enhancements (I'm new to python so there's a lot of room for improvement here)
• Spectral frequency based analysis. Right now selected colors are grouped and averaged into even slots. It used to be 36 slots but I made it adjustable. Charting and isolating colors based on a waveform would be way better.
• Send each color to best matching light. Expanding on 'transition time based on hsv distance'. Transitions would be even more seamless by assigning lights based on distance.
• Eliminate delay between ambilight and screen (look ahead or cached color analysis. Also new to XBMC plugin development so a lot to learn here)
• Inclusion in XBMC Official add-on repositoryhttp://wiki.xbmc.org/index.php?title=Official_add-on_repository

— Reply to this email directly or view it on GitHubhttps://github.com/cees-elzinga/script.xbmc.hue.ambilight/issues/5#issuecomment-20921786 .