There's a lot of confusion here about "Limited" and "Full" ranges isn't there?
All broadcast TV and mainstream pre-recorded content released on DVD and Blu-ray uses 16-235 (or 10 bit equivalent) level space (as stipulated in the ITU/CCIR 601 and 709 specs).
The <16 and >235 levels are really there as a legacy provision now (the spec was created in the early 80s when things were very different) to allow for and preserve overshoot and undershoot in analogue sources that were being digitised - and which if clipped would cause nasty ringing. Preserving <16 and >235 levels was important in the early days of digital video, where you converted to and from analogue formats at multiple points in the chain. There should be no real picture content in properly mastered video <16 (and arguably >235 - though that's a slightly more complex issue) When you align a TV, or a broadcast monitor, you specifically adjust it so that 16 is at black (and use PLUGE so that you just can't see the difference between 16 and the PLUGE <16 levels)
However, PCs often use 0-255 level space internally, and also DVI can use it externally. As HDMI is compatible with DVI, HDMI also supports 0-255 level space. When you playback standard video (which is in 16-235 level space) on a 0-255 display (or within a system that uses 0-255 internally) you need to expand the range - so that black moves from 16 to 0 and white from 235 to 255. This can introduce banding (though dithering can help) though - so isn't ideal.
Additionally - and in some cases confusingly - some TVs let you manually switch between 0-255 (aka Full) and 16-235 (aka Limited) level space. If you use an AVR to switch to a single input you need all of your sources to be in the same level space.
Most DVD players, Blu-ray players, Satellite and Cable boxes will default to 16-235 level space (aka Limited) - and in many cases it won't be possible to get them to output 0-255 (aka Full)
If you feed a 16-235 standard video signal into a display expecting 0-255 level space you will get grey blacks, dull whites and washed out colour.
If you feed a 0-255 remapped video signal into a display expecting 16-235 level space you will get crushed blacks (lacking picture detail), blown out whites (losing highlights) and over saturated colours.
It can get worse than this. You can get both video drivers AND applications trying to solve the problem - so end up with doubly wrong pictures in either direction.
In the case of XBMC under Linux you can have TWO options to get Limited output from XBMC.
1. Let XBMC run 0-255 internally. It will remap 16-235 content to 0-255. Then the video drivers will decide whether to output 0-255 (if connected to a DVI or VGA monitor, or an HDMI display in "Full" range) or remap to 16-235 (for a "Limited range" HDMI connection) This will irrevocably lose <16 and >235 content as they are clipped <0 and >255. There shouldn't be content there - and if you can see <16 blacks normally then your display isn't correctly calibrated... This is the default setting. However it relies on the video drivers also working correctly and realising they are feeding a 16-235 display. (Sometimes you can force drivers using xrandr - and in some cases drivers will switch between ranges based on the resolution - using 0-255 for "PC" resolutions like 1024x768, 1440x900, 1680x1050 etc. but using 16-235 for "TV" resolutions like 1280x720, 1920x1080 etc.)
2. Let XBMC keep 16-235 content as 16-235 (which is I believe what the 16-235 checkbox is for?) and make sure that your video drivers THINK they should be outputting 0-255 (and not remapping to 16-235). Effectively you let XBMC handle the "16-235"ness of the content. This means you get 16-235 Limited output BUT the <16 and >235 levels have been preserved. It can also be a solution IF your video drivers incorrectly think they are feeding a 0-255 display rather than a 16-235 one.
This is NOT straightforward. It is also not helped by the additional complication of HDMI having three different pixel formats : YCrCb 4:2:2, YCrCb 4:4:4 and RGB 4:4:4. I think that the YCrCb stuff is only ever 16-235, but the RGB can be either 16-235 or 0-255 (I may be wrong on this). So HDMI can be carrying either Red, Green and Blue signals OR Luminance and two Colour Difference signals - and the latter can have half-resolution colour difference signals.
All mainstream source material is 16-235 4:2:0 (though I've got quite a bit of 4:2:2 stuff from broadcast recordings)
Most consumer gear (satellite and cable boxes, DVD players, Blu-ray players etc.) will output YCrCb 4:2:2 normally.
(2014-07-09, 00:26)Mark the Red Wrote: [ -> ]What I don't know about Linux, OpenELEC kernels would fill the Library of Congress. But there is no question whatsover that the Intel xrandr config file supercedes the XBMC checkbox setting. I can assure you this is not a placebo or psychosomatic fix. It IS a night and day difference. The dudes over at the Intel forum where I located the fix can speak a lot more intelligently regarding the how and why of this.
(2014-07-09, 00:27)jsp1 Wrote: [ -> ]Matt,
Given the instant change in picture quality when the command was initiated, I would assume that for some people the 'Use limited color range' feature is not functional. Mine was already disabled, however it was obviously not using the extended color palette. It was definitely not placebo though I was watching the screen as it happened.
Did some more research/testing. The default color space setting ("Broadcast RGB") for the Intel driver is "Automatic" (vs "Full" or "Limited 16:235"). Depending on your display's color space support, setting the Broadcast RGB value to Full may or may not have any effect. If your display is expecting 16:235 and you set the driver to Full, all you are doing is crushing your blacks/whites. On a properly calibrated display, the Automatic setting is probably the correct one. If you feel like Full gives you a (perceived) better picture, it's likely an indication that your display was miscalibrated, rather than actually being fed the wrong color space.
On my Panasonic plasma, a Broadcast RGB setting of Automatic produces the same picture (after a reboot) regardless of my TV's color space setting. Obviously I can change the TV's setting as well as the driver to produce a mismatch, but I'd bet that most people's displays are expecting a 16-235 color space, and that forcing it to 0-255 is not the correct thing to do
(2014-07-09, 01:06)noggin Wrote: [ -> ]There's a lot of confusion here about "Limited" and "Full" ranges isn't there?
<snip>
All mainstream source material is 16-235 4:2:0 (though I've got quite a bit of 4:2:2 stuff from broadcast recordings)
Most consumer gear (satellite and cable boxes, DVD players, Blu-ray players etc.) will output YCrCb 4:2:2 normally.
lots of good info here, thanks.
Very informative post. Thank you.
EDIT: I tried commenting out the command from autostart.sh and rebooting. I then enabled the 'limit RGB' option, which resulted in a horrible washed out picture.
I'm not sure what to conclude from this. If indeed nothing was being lost why do all my blacks go grey with the option enabled?
I can't use my calibration disc with the chromebox, making the whole endeavor more frustrating. I don't see any crush with full enabled, but am I willing to factually state that it isn't there without measurements? Nope.
Best I can do is go with the closest approximation of my bluray player output since that is definitely calibrated properly.
My Samsung 8000 Plasma is professionally calibrated so it has to retain its "custom" color space. That means the "full RGB Intel NUC" setting gives me full color space.
Previously, when I had my TV connected directly to my Windows based PC via HDMI, I again had to go into the nVidia control center and change the color space from limited to "full" to get complete blacks. Furthermore my Blu-Ray player outputs YCbCr 4:4:4 color space and my Dish TV receiver outputs RGB and both looked great with complete blacks. It is only this NUC Intel driver that caused the washout.
Maybe its a Korean thing. But from a simple language perspective, the Samsung / nVidia verbage makes a lot more sense to me. And based on the hordes of Intel NUC / HTPC forums out there complaining about this issue with Intel integrated graphics, I certainly am not a lone wolf combatting this......
It's a total minefield. Windows was a nightmare for years - with registry hacks often needed either for the drivers OR for Media Center to get black levels and white levels where you needed them.
Because there are so many places where it can go wrong OR where software has workarounds to cope with it going wrong elsewhere it IS confusing. Particularly when drivers "try" to help. (And don't get me started on how confused people get by "Overscan" adjustments in drivers, which should really be called "Overscan compensation")
(2014-07-09, 04:55)Matt Devo Wrote: [ -> ]Did some more research/testing. The default color space setting ("Broadcast RGB") for the Intel driver is "Automatic" (vs "Full" or "Limited 16:235"). Depending on your display's color space support, setting the Broadcast RGB value to Full may or may not have any effect. If your display is expecting 16:235 and you set the driver to Full, all you are doing is crushing your blacks/whites. On a properly calibrated display, the Automatic setting is probably the correct one. If you feel like Full gives you a (perceived) better picture, it's likely an indication that your display was miscalibrated, rather than actually being fed the wrong color space.
On my Panasonic plasma, a Broadcast RGB setting of Automatic produces the same picture (after a reboot) regardless of my TV's color space setting. Obviously I can change the TV's setting as well as the driver to produce a mismatch, but I'd bet that most people's displays are expecting a 16-235 color space, and that forcing it to 0-255 is not the correct thing to do
There was a suggestion that "Automatic" will output "Full" 0-255 for "PC" resolutions (like 1024x768, 1366x768, 1440x900, 1680x1050 etc.) as it expects these resolutions to mean it is connected to a DVI 0-255 RGB monitor, but will output "Limited" 16-235 for "Broadcast" resolutions (1280x720, 1920x1080) as it defaults to expecting these resolutions to mean it is connected to a video display over HDMI expecting 16-235 levels.
The "Full" and "Limited" options are there to override this and cope with anything that conflicts with this logic? OpenElec, for me, on Intel platforms, now outputs video in the same levels range as my digital satellite STB, my Sony Blu-ray player, my PS3 (without altering its default level settings) and various other sources (WDTV Live, Popcorn Hour etc.) I may have clipped BTB and WTW content - but I don't have a problem with this (as my display is correctly calibrated to not show <16 sub-black content, and I don't have any real analogue conversions that could introduce ringing)
There may also be some signalling over EDID that can be recognised by the driver re: level spaces?
(2014-07-09, 10:25)noggin Wrote: [ -> ]It's a total minefield. Windows was a nightmare for years - with registry hacks often needed either for the drivers OR for Media Center to get black levels and white levels where you needed them.
Because there are so many places where it can go wrong OR where software has workarounds to cope with it going wrong elsewhere it IS confusing. Particularly when drivers "try" to help. (And don't get me started on how confused people get by "Overscan" adjustments in drivers, which should really be called "Overscan compensation")
There was a suggestion that "Automatic" will output "Full" 0-255 for "PC" resolutions (like 1024x768, 1366x768, 1440x900, 1680x1050 etc.) as it expects these resolutions to mean it is connected to a DVI 0-255 RGB monitor, but will output "Limited" 16-235 for "Broadcast" resolutions (1280x720, 1920x1080) as it defaults to expecting these resolutions to mean it is connected to a video display over HDMI expecting 16-235 levels.
The "Full" and "Limited" options are there to override this and cope with anything that conflicts with this logic? OpenElec, for me, on Intel platforms, now outputs video in the same levels range as my digital satellite STB, my Sony Blu-ray player, my PS3 (without altering its default level settings) and various other sources (WDTV Live, Popcorn Hour etc.) I may have clipped BTB and WTW content - but I don't have a problem with this (as my display is correctly calibrated to not show <16 sub-black content, and I don't have any real analogue conversions that could introduce ringing)
There may also be some signalling over EDID that can be recognised by the driver re: level spaces?
it's probably some combination of EDID + resolution that determines the color space output in Automatic mode. I'm testing with a direct connection from the CB to display, not thru an AVR (don't have one w/HDMI support), which can obviously affect the EDID reported back. Also, my monitor is 1900x1200, which may fall into the "PC" category - I'll have to set it to 1920x1080 and see if there's a difference.
The main thing I feel for people to take away from this though is that color space is a complicated issue, and blindly applying a setting they found in the forums will likely not result in a quantitatively better picture - one needs to understand what the setting does, and when/why it may be needed.
Just happily cruising along with my OpenELEC Cbromebox and have just one issue. My UPNP servers (BubbleUPnP, Mezzmo Android) don't recognize it as a playback device when I try to "Play To" from my mobile devices. My Raspberry Pi that is also running OpenELEC is recognized fine.
I e-mailed support for Mezzmo who said the box is not identifying itself as a UPNP or DLNA device. I have XBMC configured to be recognized on the network (exact same settings as the RaspPi) but still not showing as a "Play To" option. Anyone found a solution for this?
i'd been following the haswell nuc thread for a while before finding out 2955u in the chromebox was a haswell chip and getting that instead. lmyllari did a lot of testing and bug squashing and i believe the same information should apply. that being:
(2013-12-05, 02:17)lmyllari Wrote: [ -> ]The banding comes from expanding luma from 16-235 to 0-255. This is done for typical PC monitors, which expect a full range signal. New Intel linux drivers by default give TVs a limited range signal, taking the expanded 0-255 and scaling it to 16-235. This does not eliminate the banding that was created by the original expansion, and original information below 16 and above 235 was already lost in that same step. (Why do they do it? It's the right thing according to the standards, and some TVs don't like full range -> crushed blacks.)
If the player software (xbmc in this case) decodes to 16-235 (meaning "don't change luminance, keep black at 16 and white at 235"), the video card outputs full range 0-255 (meaning "don't scale the levels, just output what you're given"), and display is set to limited range input (meaning "16 is black, 235 white"), we eliminate the banding in greyscale ramp (because the range is not scaled at any point) and keep blacker-than-black (luma values under 16) and white-than-white (luma values above 235).
If your plasma defaults to limited range RGB (and doesn't listen to the infoframes in the HDMI stream) or you can set limited range manually, you don't need anything special. Just set your player software to 16-235 (which you can now do with Gotham and software decoding) and make sure the video card doesn't change the signal (the xrandr broadcast range "Full" setting mentioned a lot in this thread). In my case, the monitor obeys the infoframes (and there are other devices connected to the same input preventing a manual setting), so I need a patch to switch it to limited range without altering the video signal.
so for my vt50 setting the range to full with the autostart script and then using the 16-235 setting within xbmc gives proper black and colors.
avsforum has a good set of calibration media you can use within xbmc here:
http://www.avsforum.com/forum/139-displa...ation.html
If your set supports it (mine does, Panny VT50), you can set the color range to auto, leave the intel driver setting on Automatic (default), and set XBMC to full range (default) and everything will look like it should
Thanks for the info furii. Using those calibration patterns I am able to verify some things now...
1. I was experiencing a degree of black crush using the 'full rgb' xrandr command. (I failed to perceive this without patterns, with them it was quite clear)
2. I was not getting a properly calibrated image leaving everything as is (default).
3. I do get a perfectly calibrated image by using xrandr full rgd + limited output option from within xbmc.
This is tested and verified with the same patterns used on my BD player and my television default tools.
A combination of the two puts out a superior picture on my setup. No black crush and no washed out colors.
I have no idea who else this might apply to, but I am confident in trusting the test patterns for accurate results.
What a confusing bit of nonsense this all was. My television is verified fully 0-255 4:4:4 RGB compliant and compatible, I have verified this using windows from a different machine in the past. So, in theory whatever I pass to it should be compatible and then if clipping need be done it should be done by the set itself. I'm more confused than ever. Having said that, I at least have tangible evidence to ease my mind that I'm in compliance now. Thanks to everyone for the efforts.
(2014-07-10, 05:11)Matt Devo Wrote: [ -> ]If your set supports it (mine does, Panny VT50), you can set the color range to auto, leave the intel driver setting on Automatic (default), and set XBMC to full range (default) and everything will look like it should
my blacks were ok the problem was the banding which was clearly visible on the greyscale ramp test pattern.
(2014-07-07, 20:24)Matt Devo Wrote: [ -> ]that's a backup of your original ChromeOS install (on the internal HDD) and does not contain a backup of your stock firmware unless you created on manually.
my script simply reads the current firmware (off the chip) and writes it to a file called 'stock-firmware.rom' on the first partition of the selected/inserted USB drive
Is
stock-firmware.rom on the backup of the original ChromeOS the only thing that's important/unique on the flash drive. Or can everything else be recreated from the stock restore?
(2014-07-10, 16:53)YellowDog Wrote: [ -> ] (2014-07-07, 20:24)Matt Devo Wrote: [ -> ]that's a backup of your original ChromeOS install (on the internal HDD) and does not contain a backup of your stock firmware unless you created on manually.
my script simply reads the current firmware (off the chip) and writes it to a file called 'stock-firmware.rom' on the first partition of the selected/inserted USB drive
Is stock-firmware.rom on the backup of the original ChromeOS the only thing that's important/unique on the flash drive. Or can everything else be recreated from the stock restore?
the stock-firmware.rom file and the ChromeOS backup (from earlier versions of the script, no longer used/needed) are two separate things, and would be on two different USB sticks.
(2014-07-10, 06:10)jsp1 Wrote: [ -> ]1. I was experiencing a degree of black crush using the 'full rgb' xrandr command. (I failed to perceive this without patterns, with them it was quite clear)
2. I was not getting a properly calibrated image leaving everything as is (default).
3. I do get a perfectly calibrated image by using xrandr full rgd + limited output option from within xbmc.
If I check the limited range option after the xrandr command it defaults to the original washed out greyed image.
My TV is a Samsung PN59D8000. I have the color space calibrated via 10p white balance which may explain why my TV is somewhat abnormal in this matter. However, Samsung TV's are no small percent of the market share either...
Just got my new IR receiver in. Now my wife and I are living the dream! A couple of remote commands are not intuitive to program, but it works fantastically! Thanks again Matt!
I read Yuri's post earlier, but has anyone figured out to have an IR command remote power this thing on from sleep / hibernate mode? It's really no big deal, just a curiosity.
Finally, I just would very much like to give Matt a very sincere and deserved thank you for all your help on this thread and for pioneering this HT solution. This $210 4GB XBMC box (+ IR receiver) exceeds my wildest expectations as to performance and value. It boots in like 4 seconds. Streams HD via WIFI effortlessly and makes my TV look capital "P" pimp with the Ace skin. You are a great man!