(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.

(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.

(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

(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?

(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.

(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

(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

(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?

(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.