Color Space Problems / Queries
#46
athloni Wrote:I use "Limited" and it seams to display oke.
I checked it with the Test Paterns in XBMC

When you say you tested it with the XBMC pattens can you be more specific. I don't know what they really do. I am using real H264 source material from avsforum.
Reply
#47
Here are my measures from a test H264 screen of Y=235, and Y=255. Nothing was changed in onward chain (DVDO Edge input set as Video Level, output as Video Level, to Panasonic 50V10) across all measures.

Luminance
ColorRange VDPAU_Studio_Colour L@Y=235 L@Y=255

Limited Enabled 84 97
Limited Disabled 96 96
Full Enabled 95 110
Full Disabled 112 112

Screen is calibrated for a Y=235 level to give around 95cd/m2

The only correct output here is the Full ColorRange with VDPAU_Studio_Colour enabled.

EDIT - sorry about the lack of formatting as I did try to add spaces but they get stripped
Reply
#48
That's interesting. We're struggling with options that don't work.

I'm gonna try VDPAU_Studio_Colour and let you know..

hudo
Reply
#49
Well NVIDIA probably think they do work! I believe most of the companies making these graphics drivers simply don't understand the video spec's properly. My xtreamer clips >235 too!

So far I can see no advantage for me in the 260.x drivers from nvidia - they are slower than 195.x for VDPAU by 30% or more with my ION-NG (I believe because the clock speeds are reduced). In addition VDPAU is slower than DXVA2 by some margin too. I don't really want to move to windows but the drivers seem a little better (though still wrong color levels, and refreshrate bugs).
Reply
#50
No updates from anyone? Please can someone show evidence that you can get WTW when using video levels with XBMC+Nvidia. In addition any suggestion on then how to get JPEGs at least to display with Black mapped to same level as the video black.
Reply
#51
I'm still testing. So far no luck.
Reply
#52
@TheSwissKnife: Does it make any difference if you set the nvidia drivers to output in YCbCr or do you get the same results as with limited RGB?

Edit: Never mind.. no btb/wtw with YCbCr output, as well
Reply
#53
Thats right -I get no joy with YCbCr444 mode. I guess it boils down to NVidia (and others) not understanding that "useful digital video range" is "really" 16-255 (though 255 may not really usable in 8-bit mode over hdmi). <16 BTB is not necessary and can be clipped. A lot of screens won't show BTB and WTW but that does not mean it makes senses clip them as others want to see WTW displayed! It is ok to keep FULL RANGE of course but the point is we want the desktop and JPEG etc to be scaled so that BLACK is then 16 with max white probably 235 to cater for all users with the option to have it scale to 255 for slightly better result for those who don't mind such brightness levels.
Reply
#54
BTW, the behaviour is different with NVidia in Windows at least with latest 258.xx drivers). The only way to get DXVA to show > 235 values as >235 is to set the control panel to RGB and Limited range (16-235). All other configs mess it all up one way or another (clipping or rescaling or both) {YCbCr444, range 0-255}, {YCbCr444, range 16-235}, {RGB, range 0-255}. So no consistency it seems even within the same company!
Reply
#55
I just noticed something in my Xorg.0.log

(WW) Oct 04 17:08:30 NVIDIA(GPU-0): The requested color space is not supported by the GPU or
(WW) Oct 04 17:08:30 NVIDIA(GPU-0): display. The selected default color space is RGB

Apparently it can't do YCbCr444... wtf? No wonder I can't get BTB and WTW...
Can somebody confirm this under /var/log/Xorg.0.log?

hudo

**EDIT**
Ok. It gets weirder... A power-off cycle renders a new Xorg.0.log which no longer has the above warnings...
Reply
#56
TheSwissKnife Wrote:Thats right -I get no joy with YCbCr444 mode. I guess it boils down to NVidia (and others) not understanding that "useful digital video range" is "really" 16-255 (though 255 may not really usable in 8-bit mode over hdmi). <16 BTB is not necessary and can be clipped. A lot of screens won't show BTB and WTW but that does not mean it makes senses clip them as others want to see WTW displayed! It is ok to keep FULL RANGE of course but the point is we want the desktop and JPEG etc to be scaled so that BLACK is then 16 with max white probably 235 to cater for all users with the option to have it scale to 255 for slightly better result for those who don't mind such brightness levels.
Well, if you think about it, nvidia does not have another choice but to implement it the way they did with the current beta drivers.
If I'm not mistaken, you want support for xvYCC output...

You might be able to get WTW with the old drivers and VDPAU studio color conversion, because enabling VDPAU studio color conversion applies a different colorspace conversion matrix when doing YCbCr to RGB conversion.

Without VDPAU studio color conversion enabled your video just gets expanded by XBMC to full range RGB while converting YCbCr to RGB. This will clip anything that is outside of "limited" YCbCr and that is why you won't get anything outside of that limited range no matter what you tell the nvidia driver to output to. The information was lost while XBMC converted YCbCr to RGB and the nvidia driver cannot get it back.

Now, with VDPAU studio color conversion enabled and full range RGB set you're basically doing something that does not really comply to HDMI specs as far as I understand them. You convert YCbCr to limited range RGB but you do not explicitly clip anything outside of the limited RGB range. If the video (like the AVS HD 709 test patterns from avsforum) happens to contain something outside of limited YCbCr while converting YCbCr to RGB it will end up outside of limited range RGB. I have no idea what your playback chain does with that, mine seems to be fine with it.

Long story short, if you only care about video quality (ignoring pictures and desktop) and your TV expects limited range RGB you should stick to full range RGB with VDPAU studio color conversion enabled. Otherwise you end up with XBMC expanding to full range RGB and the nvidia driver compressing it back to limited range. I doubt that this is a good thing and it might introduce additional banding in your videos.

The only thing I don't get is what happens when I set the beta drivers to output full range RGB. For some reason, black (as in RGB(0,0,0)) is no longer black but grey which doesn't make sense to me and does not happen with the stable drivers. I would have expected the same picture as with the old drivers. Or do the new drivers somehow shift the colors?
Reply
#57
enkil Wrote:Long story short, if you only care about video quality (ignoring pictures and desktop) and your TV expects limited range RGB you should stick to full range RGB with VDPAU studio color conversion enabled. Otherwise you end up with XBMC expanding to full range RGB and the nvidia driver compressing it back to limited range. I doubt that this is a good thing and it might introduce additional banding in your videos.

So XBMC Live needs a setting (in the apearance screen) to output limited range RGB. With that setting enabled XBMC shouldn't expand to full range RGB anymore.

That would be the only good option to show video AND userinterface with the correct colors and no need for changing driver settings.
Reply
#58
enkil Wrote:Well, if you think about it, nvidia does not have another choice but to implement it the way they did with the current beta drivers.
If I'm not mistaken, you want support for xvYCC output...

I think they have the choice - to do it right, and consistently. I never mentioned xvYCC - and though it would be nice I have no material nor know where such material can be found to utilise it.

Quote:You might be able to get WTW with the old drivers and VDPAU studio color conversion, because enabling VDPAU studio color conversion applies a different colorspace conversion matrix when doing YCbCr to RGB conversion.

Not sure which drivers you are referring to. VDPAU should allow output as RGB or YCbCr444. YCbCr444 should always be in so called "limited range" for video output BUT that range should not be clipped at 16-235 (that is just the nominal range). Software should just be able to pass the video asis and in the case of JPEG or desktop it should adjust (scale) so that black 0 becomes black 16. RGB limited range output should be no different ie using the range 16-255. All would then be fine.

Quote:Without VDPAU studio color conversion enabled your video just gets expanded by XBMC to full range RGB while converting YCbCr to RGB. This will clip anything that is outside of "limited" YCbCr and that is why you won't get anything outside of that limited range no matter what you tell the nvidia driver to output to. The information was lost while XBMC converted YCbCr to RGB and the nvidia driver cannot get it back.


I have no idea what XBMC is doing or if it has to do anything with VDPAU. Once again though the issue is that there is a misconception about clipping above 235 (ie scaling 16-235<->0-255) - I don't know where this idea started but it is where all the problems start.

Quote:Now, with VDPAU studio color conversion enabled and full range RGB set you're basically doing something that does not really comply to HDMI specs as far as I understand them. You convert YCbCr to limited range RGB but you do not explicitly clip anything outside of the limited RGB range. If the video (like the AVS HD 709 test patterns from avsforum) happens to contain something outside of limited YCbCr while converting YCbCr to RGB it will end up outside of limited range RGB. I have no idea what your playback chain does with that, mine seems to be fine with it.

What has this to do with HDMI specs? They allow Y to go above 235. They allow RGB to do so too. Real material has white >235 and it should be seen whether coming out as RGB or YCbCr. I know that some kit (eg DVDO Edge) does have a convert to computer levels (perhaps badly referred to as "full range") mode that will then do this bizarre scaling already mentioned (16-235->0-255)


Quote:The only thing I don't get is what happens when I set the beta drivers to output full range RGB. For some reason, black (as in RGB(0,0,0)) is no longer black but grey which doesn't make sense to me and does not happen with the stable drivers. I would have expected the same picture as with the old drivers. Or do the new drivers somehow shift the colors?

I am not sure what you mean here. Which driver version, and are you talking about non-VDPAU (eg MPEG2)? Are you saying that both RGB(0,0,0) and RGB(16,16,16) map to RGB(16,16,16) on HDMI?
Reply
#59
Still hoping some developer can add it as option in the appearance menu.
Reply
#60
Create a track ticket with the feature request.
Reply

Logout Mark Read Team Forum Stats Members Help
Color Space Problems / Queries0