Howto: Manually set the colorspace on an Ion system over HDMI
#31
well, I've tried setting color space to YCbCr444 and it looks fine after putting the display to Hdmi Black Level Low.

Studio Level Correction is off, as with on I got a pretty lame image quality, with colors very washed out.

Thanks cowfodder!
Reply
#32
LB06 Wrote:Well I'm not sure about that one? Aren't displays themselves always using RGB? So somewhere the translation to RGB has to be made. And I don't think all displays/drivers can be told to expect YUV as input (e.g. normal PC monitors?). Also, the XBMC GUI is rendered in full RGB, so this will look noticeably worse (heavy banding) in limited/YUV.

I think XBMC already takes care of proper RGB rendering. Studio Color Level Conversion just makes sure that the colours are rendered to RGB in such a way that 0-15 and 236-256 can be safely truncated (i.e. without truncating blacks and whites, other than BTB and WTW). This is in case the input of the device doesn't accept full RGB levels.

Yes, displays create a picture using RGB. No, that doesn't mean that RGB is the correct color space. I don't know why this seems so hard to believe, especially when I've linked multiple resources showing and stating that YCbCr444, or REC.709, is the correct colorspace for digital video, period, no exceptions. It doesn't matter whether or not a new TV can accept full range RGB, it's still not the correct color space.
Reply
#33
I'm not disputing that ITU-R BT.709 is the industry standard colour space for (HD) video. I'm saying that whatever the source gamut, it will have to be converted to RGB, no matter what. So this can be done by the display device, which is usually the case with 'dedicated' devices. But it does not mean that this conversion cannot also be performed properly by the source itself, in this case XBMC.

Besides, and you ignored this point, the XBMC GUI itself (and the artwork) is not digital video and therefore does not and should not conform to video standards, but to PC standards.
Reply
#34
yeah.. but what do you prefer, a perfect XBMC gui picture quality or perfect movies quality? I myself prefer to make sure that the movie looks as good as possible, not the gui.
Reply
#35
PatrickVogeli Wrote:yeah.. but what do you prefer, a perfect XBMC gui picture quality or perfect movies quality? I myself prefer to make sure that the movie looks as good as possible, not the gui.
The YCbCR -> RGB translation a display device does (internally), shouldn't be any different from the YCbCR -> RGB translation a source device does, given that the same (standardized) conversion matrix is used.

So taking that into account, preventing an RGB->YCbCR->RGB translation for the GUI and artwork isn't such a bad idea. I think XBMC made the right choice.
Reply
#36
LB06 Wrote:The YCbCR -> RGB translation a display device does (internally), shouldn't be any different from the YCbCR -> RGB translation a source device does, given that the same (standardized) conversion matrix is used.

So taking that into account, preventing an RGB->YCbCR->RGB translation for the GUI and artwork isn't such a bad idea. I think XBMC made the right choice.

Except that most TV manufactures will not do a RGB-YCbCr conversion. Most HDTVs on the market today will just blindly display whatever is coming in to them, regardless of whether or not the signal is correct. So what you're suggesting is pumping out an oversaturated picture in order to make the UI look good, and having the movies look cartoonish and unreal.

BTW, the UI looks fine on YCbCr.
Reply
#37
cowfodder Wrote:Except that most TV manufactures will not do a RGB-YCbCr conversion. Most HDTVs on the market today will just blindly display whatever is coming in to them, regardless of whether or not the signal is correct. So what you're suggesting is pumping out an oversaturated picture in order to make the UI look good, and having the movies look cartoonish and unreal.

BTW, the UI looks fine on YCbCr.
Uhm, I don't believe any display device is capable of displaying YCbCr without converting it to RGB first. YCbCr is digital. The light coming from your TV screen is not. Even YPbPr can't be displayed as is. It's just a space/bandwidth saving encoding format for (a part of) the RGB spectrum.
Reply
#38
so conclusion of this thread is, we should use:

Option "ColorSpace" "YCbCr444"

without second option (Option "ColorRange" "Full"),
because of "YCbCr supports only limited color range." (driver README Appendix B)

right?
Reply
#39
@ [mil]

Option "ColorSpace" "YCbCr444"

No more, no less
Reply
#40
LB06 Wrote:Uhm, I don't believe any display device is capable of displaying YCbCr without converting it to RGB first. YCbCr is digital. The light coming from your TV screen is not. Even YPbPr can't be displayed as is. It's just a space/bandwidth saving encoding format for (a part of) the RGB spectrum.

You're missing the point. If you change the color space, you change the reference points for Red, Green and Blue. That is what you're setting when you set the color space. If you set YCbCr444, then you tell the display that, on a graph, Red=640x 330y, Green= 300x 600y and Blue=150x 60y. If you set it to full range RGB those values will be different, therefor the colors in ALL of your videos will be WRONG.

If you need further proof that the default color space is wrong, use the built in calibration patterens in XBMC. Especially pay attention to everything after the first one. When you're set to RGB-Full, they are all just a solid blob, set to YCbCr444 you find out that they are line graph patterns.
Reply
#41
I did and there was no difference. Aren't those lines black and white anyway?

Aren't the reference points and all other colour points properly converted using a matrix similar to this one?

Image
Reply
#42
Again, you're assuming that the TV will try to convert whatever come in to YCbCr444 color space, which the vast majority of HDTVs will not do. I'm tired of arguing the point. If you prefer for your UI to look better than your videos, then by all means use RGB Full. If you want it to be right, use YCbCr444.
Reply
#43
cowfodder Wrote:Again, you're assuming that the TV will try to convert whatever come in to YCbCr444 color space, which the vast majority of HDTVs will not do. I'm tired of arguing the point. If you prefer for your UI to look better than your videos, then by all means use RGB Full. If you want it to be right, use YCbCr444.
That would be like saying that speakers are able to 'display' FLAC/ac3/mp3/dts without decoding it to LPCM (analogue to RGB) first and then taking LPCM through a DAC to produce audible waves (analogue to visible waves). Y'CbCr is just a (lossy) encoding scheme for RGB.

Also let it be said that YCbCr444 IS the correct setting if your TV's hdmi input simply doesn't accept PC level colours (mostly older HDTVs), otherwise you'll get crushed blacks and whites, or something which people will describe as a 'washed out' picture. I have never disputed that. Alternatively, you can use RGB + VDPAU Studio Level Color Conversion. This will perform the YCbCr444 -> limited RGB conversion with I assume the BT.709 conversion matrix, truncating BTB and WTW. Of course that only works if you actually use VDPAU.
Reply
#44
I up this thread because I've discovered some new things. I got some test videos over at AVSforums, in this thread: http://www.avsforum.com/avs-vb/showthread.php?t=948496 I got the mp4 version.

So I unziped it, went to xbmc (nvidia, output set to YCbCr444) and run the Black Clipping and White Clipping videos.. and oh! surprise! I could only see blackbars from 19 to 25 flash, no matter what brightness I chose. In the White clipping video I would only get flashing bars 230-234.. but at 234 I could barely see it.

So I played a bit around.. changing to rgb full or limited didn't help, same happened. At the end I just enabled VDPAU studio correction and got it! I could see ALL the bars flash, so I adjusted as intended and that's it (the videos play with vdpau).

Doing more tests I saw that both RGB or YCbCr outputs and studio correciton enabled would show all bars, but without studio correction neither would. Between RGB and YCbCr the amount of brightness and contrast needed changed to let it fine.

Also there's a downside: I tunned my display using Enable VDPAU correction and VDPAU enabled setting the output to YCbCr and it looked fine, ok. But then, disabling VDPAU (would be the same as watch some SD divx which plays without vdpau) and running the test was.. a complete disaster. The Black test just displayed a black screen and I couldn't see any bars flashing, so I upped the brightness and.. voila! there they are. However, I couldn't see bars lower than 18.

At the end I've tuned my display: The Movies image setting to go with VDPAU enabled material (most of it) and the Standard to look non VDPAU movies... I'll have to switch from one to another and that's it.

Any comments on this? It would be nice if a developer jumped in to talk about VDPAU studio correction and his thoughts about enabling it and setting the output to RGB or YCbCr or whatever... I'd really like a clarification about what that setting does, since the wiki doesn't really clarify anything about it.

EDIT: a question, does XBMC convert the colorspace for the videos?? All those Blurays are YCbCr444 encoded, does XBMC convert to Full RGB levels or just outputs "as is"?
Reply
#45
When I have time and motivation I plan on running the test patterns through CalMan 4 and comparing RGB Full, RGB Limited, and YCC444 xorg configurations, as well as the VDPAU Studio Level Correction setting. Don't hold your breath though, I've got a lot on my plate right now.
Reply

Logout Mark Read Team Forum Stats Members Help
Howto: Manually set the colorspace on an Ion system over HDMI1