[topfs2]

Thanks for the replies, I live in hope there may be a solution for linux that is integrated into XBMC at some point in time.. but I won't hold my breath

In the mean time I have found boblight should fit the bill; http://blogger.xs4all.nl/loosen/articles/408184.aspx

Without saying to much, already looking into it

[bob.smith]

Without saying to much, already looking into it

LOL, that was too much, because now we *must* know

BOB.SMITH

[Swifty]

Without saying to much, already looking into it

Hehe seems I might not have to hold my breath too long after all!

Great work, look forward to seeing some results for this one

XBMC FTW!

[bobo1on1]

Without saying to much, already looking into it

I can see you looking!

No seriously, I found this thread in my referrers, I've been working on an opengl wrapper which wraps glXSwapBuffers() and can be loaded with LD_PRELOAD.
It seems to work with xbmc, except that the constructor gets called 13 times, but use a timeout of 2 seconds and it works fine.

Now to make everyone jealous, here are some pics I just took:

[bob.smith]

Hi bobo1on1,

Looks cool, is that single channel RGB, or are you copying the Ambilight features (multiple RGB channels)

BOB.SMITH

[bobo1on1]

On that setup there are two lights, left and right, which can be controlled individually.
However they're both configured to respond to the entire screen area, because that's how I like it.

[topfs2]

I can see you looking!

No seriously, I found this thread in my referrers, I've been working on an opengl wrapper which wraps glXSwapBuffers() and can be loaded with LD_PRELOAD.
It seems to work with xbmc, except that the constructor gets called 13 times, but use a timeout of 2 seconds and it works fine.

Now to make everyone jealous, here are some pics I just took:

That looks great, I have mostly played with the X11 grabber for now (was meaning to post an howto setup it with code to my arduino project soonish) and that you have there looks great, What are the advantages with going the glxSwapBuffer route? would this take less CPU and/or would this make lag nonexistant?

My basic idea is to make a RGB output support available from either python or cpp plugins, and one of these plugins will most probably (probably the first aswell) be boblight but its still under discussion on how it should be implemented best and take least amount of power to calculate the colors, also make sure the colors are best possible.

Cheers,
Tobias

[bobo1on1]

Using a wrapper for glXSwapBuffers makes the output written to boblightd synchronized to the video output, I don't think it's more efficient, glReadPixels is kind of a cpu hog, on the other hand so is XGetImage, and XShmGetImage which I implemented in the next version of boblight-X11.
One of the advantages is, you can choose what you want to do with the lights depending on what you're doing, for example if you're surfing the net you probably don't want the lights to react to the color on the screen because it's kind of annoying. But when you start a media player, you want the lights to act as an ambilight. So what you need is a boblightd client like boblight-constant which just sets the lights to a certain color, and a boblightd client which starts grabbing the screen whenever a certain app starts, like the wrapper for glXSwapBuffers. Of course this will only work if boblight-constant has a lower priority (which is a higher number) that the glXSwapBuffers wrapper.
One of the things on my todo list is that a client should know if its output is actually used, so in case it's not it can turn off its expensive capture routines.

I have made it multithreaded for better efficiency on dualcore systems, the glXSwapBuffers tries to lock a mutex, if it can it calls glXSwapBuffers, unlocks the mutex, unlocks another mutex which signals another thread that it can read out the pixel data.

This seems to be more efficient, glxgears gets 600 fps with a single thread and 800 fps with multithreading, however without the glXSwapBuffers wrapper it gets more than 3000 fps.
I must admit that because of the high framerate, this really isn't a good benchmark.

If you're going to implement a plugin for boblightd, don't expect the protocol to stay the same, coming up with a good future-proof protocol is on my todo list, as well as putting functions to talk to boblightd in a library, at the moment they're in a header file, which is a big nono.

[topfs2]

May I ask if your bob, maker of boblight, by your response?

If so, do you know if there is some form of documentation about the packages that are sent? because this is still during the initial discussions on how to implement it we are thinking of making it a python plugin, and we would probably need to write a python module for it then. Although the actual RGB Grabbing will be done in cpp, mainly we are going this route as we are unsure if boblight may be enough (mainly because it might not work on osx? and on plattforms beyond the three os´s) so we would ideally like to keep this as module as possible.

They current idea is that we will interpolate and resize the output image, via hw / sw to say 16x16 (nearest neighbor) and get the color values from that. This because we ofc want it to be fast but just skipping pixels (like boblight-X11) may make the color values abit of. Im still just very new to ambilight features so if you have any thoughts on the matter it would mean alot for us.

Cheers,
Tobias

[bobo1on1]

Isn't it completely obvious that I am the author of boblight?

Currently there's no documentation about the protocol, but it's quite simple, feel free to ask if you have any questions.

Scaling output images does work, you could even scale a portion of the screen to a single pixel, but you will lose resolution, mainly because boblightd uses floats internally, but you'll only notice that if you have a 16 bit pwm controller (like I have) and in a very dark scene.

I would use at least a linear algorithm for scaling, because a nearest neighbor algorithm is just the same as skipping pixels.

[Gamester17]

Perhaps write a GLSL shader (or use a GPGPU library like Brook+, BrookGPU, or Lib Sh or ) to make the GPU do all the hard work?

[lagwagon667]

hi there, just some (not so technical) input that might (or might not) be useful for your plans on integrating ambilight functions into xbmc:

I recently got hands on a real Philips ambilight TV and checked its behaviour. There are some obvious significant differences between the Philips ambilight behaviour and the behaviour I tried to gain with my patch:

1. delay: I tried to gain a zero-delay, so if the screen goes black, without a noticeable delay, the LEDs turn off, too. On a real Philips ambilight, even if you set the ambilight mode to "dynamic" there's always a noticeable delay which can be recognized when the screen turns very fast from very dark to very bright. However, during "normal" movie scenes, you barely recognize the delay.

2. turning ambilight off: When the screen goes black, my xbmc-patch turns the ambilight completely off. Very cool when watching e.g. the "die hard 4" intro in a dark room. you see some people with bright backlight, then the screen goes black for a artist credit and you sit in a completely dark room. Then the next scene, ambilight is bright again and so on...
A real Philips ambilight never turns off. even when the screen is completely black, there is always at least a white dimmed backlight. Problem with my patch: sometimes in dark scenes, the ambilight turns red. This probably has something to do with LEDs not scaling their brightness in a linear manner. However, by making sure, all leds have a defined min-brightness you can avoid this behaviour, by the price of not having the LEDs turned off in dark scenes.

3. calculating average / skipping pixels/frames / downscaling / floating average

it seems to me, that Philips doesn't simply calculate the screens average color, but the seem to search for peeks or highlights, e.g. on a mainly grey scene, when there is say one big red dot, there would be two peeks (grey and red) in a corresponding histogram. philips seems to do create such a histogram to find peeks and somehow priorize colors (in the above case, the philips tv would have red ambilight). this would of course eat way more cpu time, but seems to be the better algorithm. at least in my patch, in normal movie (means lots of different colors during all scenes) the ambilights main color is white and mainly its brightness changes what still is a cool effect, but a little bit more color, like when watching the "philips endulge your senses"-video, would be nice, too.

Thats just my 5 cent
HTH

Cheers
dave-o

[bobo1on1]

Although the actual RGB Grabbing will be done in cpp, mainly we are going this route as we are unsure if boblight may be enough (mainly because it might not work on osx? and on plattforms beyond the three os´s) so we would ideally like to keep this as module as possible.

Boblight will probably work on osx, but alsa output won't work, boblight-v4l won't work either and boblight-X11 can't do anything useful because there's no root window.

[topfs2]

Boblight will probably work on osx, but alsa output won't work, boblight-v4l won't work either and boblight-X11 can't do anything useful because there's no root window.

Thats expected, as long as boblightd works on OSX then thats great, as we planned on adding XBMC as a seperate client anyways.

[topfs2]

3. calculating average / skipping pixels/frames / downscaling / floating average

it seems to me, that Philips doesn't simply calculate the screens average color, but the seem to search for peeks or highlights, e.g. on a mainly grey scene, when there is say one big red dot, there would be two peeks (grey and red) in a corresponding histogram. philips seems to do create such a histogram to find peeks and somehow priorize colors (in the above case, the philips tv would have red ambilight). this would of course eat way more cpu time, but seems to be the better algorithm. at least in my patch, in normal movie (means lots of different colors during all scenes) the ambilights main color is white and mainly its brightness changes what still is a cool effect, but a little bit more color, like when watching the "philips endulge your senses"-video, would be nice, too.

Thats just my 5 cent
HTH

Cheers
dave-o

Yeah I believe that aswell, because my testing is the same with boblight in most part in usual watching with just avereging the screen you get mostly white. We definatly need an algorithm that will exagerate the colors lost more so the feeling of ambilight is better percieved.