AtmoLight - 1.18.6.0 [2016-09-21] (1 Viewer)

[rohnfe]

Hmm somehow i think this could be it... i have played around with this setting too as this was my option 2 mentioned above:
2: LAV set to untouched and no conversion option ticked + Nvidia video color control set to 16-235

This brings BTB and WTW but i still need to setup my TV for HDMI level low (0-255) if i don`t want to have a washed out picture (TV is calibrated for 16-235 at the moment)- what makes me wonder.

And in this setup my leds won`t switch of anymore when the screen is black... what makes me think ambilight somehow "thinks" black is grey.
This would make sense if ambilight uses 0-255 color space because 16 (black on TV) would be grey in that case...

May i ask where you found these info`s about EVR ? i have searched but could not find something that would have helped me.

 

[Rick164]

Found this one that had a extensive post on it:

https://forums.geforce.com/default/...using-hdmi-and-getting-accurate-color-format/

Others were for testing with MPC-HC which seem to work the same way rendering wise as Mediaportal (HW - EVR used), if you want to play around with color levels I recommend using Zoom Player which has a lot of expert options for EVR and even MadVR (alternative rendering).
Washed out colors I read before and not sure why that is, might be source related or somewhere in the pipeline it's still using 0-255.

16-235 might indeed produce a grey bitmap on the AtmoLight end which means it will never completely turn off but not sure how we could handle this correctly as LEDs normally expect a 0-255 range.

 

[rohnfe]

So from what i just found out after your post is that probably nvidia color settings set to limited does exactly the same as the RGB32 option in LAV... that matches what my two options show. Its about RGB conversion.
Now i would just need to know why ambilight does not go totaly black when using these settings.. but i guess it has to do with the color space used by either atmolight or atmowin/ambibox....

Maybe there is a way to expand 16-235 for ambilight otherwise i will switch back to 0-255 for now.

 

[Rick164]

Think it would need to know your color profile on the receiving end (AtmoWin / Ambibox) for this to work right, basically we now send a untouched bitmap (image) for every frame to them for processing which means we have no influence over the actual output.
Been a while since I used AtmoWin but you might have some options for image correction (gamma / brightness etc..) which can can lower the led color output.

Other solution would be to convert the bitmap and apply a color profile (rgb: 6 --> rgb:0) when the TV (6-235) profile is detected within AtmoLight itself, @Lightning303 any ideas on this?


// Update

Are you using AtmoDuino to drive the leds by any chance?
If so you can send me the sketch and will try to fix this at the led end for now , the leds expect a 0-255 range by default but can limit it there.

 

[rohnfe]

No i am using two Seduboards one for my Dreambox and one for my HTPC
Gamma and Brightness does not help that much... i have already adjusted both plus RGB color for both Atmowin and Ambibox just to "calibrate" the colors.
But it does not help with black... i guess the only option would be a conversion/expansion option as you said, in case someone wants to use 16-235 color space
Hopefully this would not "destroy" the rest of the colors besides black and white
Some kind of "movie mode" or limited mode.

PS. i could ask the guy from Ledstudienshop ... if it would be possible to setup this within the Seduboard itself as an option. And what just came to my mind: it works fine on dreambox that should be 16-235 as well using enigmalight but i am not sure about the color space that is really used as there are options to change it from Dreambox side.

 

[Rick164]

Attached a test build for AtmoLight which should convert limit the bitmap colors to the 16-235 range where 16 is converted to black, added test4 build which includes a change recommend by @Lightning303

These are based on our internal developer builds so there might be some bugs in it, best to backup any AtmoLight settings you have just in case something goes wrong.
The setting file is located here C:\ProgramData\Team MediaPortal\MediaPortal\MediaPortal.xml.

If it doesn't work please attach the Mediaportal.log and Mediaportal-Error.log located in C:\ProgramData\Team MediaPortal\MediaPortal\log

 

[rohnfe]

oh that was fast man Thank you i will try it this evening when i get home!
I have also contacted the Seduboard shop .. lets see what they say

 

[Rick164]

Just did some testing with the stable release using Hyperion and the limited color range settings you used and a few other combinations as well, but when it gets dark it sets the leds to off (rgb: 0/0/0) in every scenario so it must be something with the AtmoWin setup or how it's processed there.

This is with Windows 10 + GTX970 running the latest drivers.

 

[rohnfe]

Hm ok that sounds strange, my machine win 8.1 and GT425m.

I will try your testbuild now and let you know.

Update:

this is kind of weird!

1. using the new version does not seem to affect ambibox at all.
2. Atmowin and darkness limit set to 0 leds stay off all the time
3. Atmowin and darkness limit set to 1 seems that the leds show up like the GUI of MePo behind the video as i can see the blue of bar of Titanius skin (at least i think it is the bar)

 

[Rick164]

1. Only changed the AtmoWin part in the new version so that would explain it, can change Ambibox as well if you want

2. So even with video playback they stay off all the time?

3. We have had this new feature for a few builds (latest stable has it as well) now that when you enter the GUI while Mediaportal Live Mode is active (i.e. video not fullscreen) you can use that live GUI data instead of the video, this can be switched off in the AtmoLight settings window under General settings and "Use GUI data when video is minimized in Mediaportal Live Mode"

Btw are you switching between Ambibox and AtmoWin in AtmoLight or only using Ambibox with it?