AVS Forum banner
Status
Not open for further replies.
1 - 20 of 33 Posts

·
Registered
Joined
·
1,358 Posts
Discussion Starter · #1 ·
There has been several threads lately about color space conversion issues that have prompted me to start this thread.


I always assumed that color space conversion was was taken care off by flawless cooperation of MPEG2 decoder software, DirectDraw (overlay), Direct X 9.0 (VMR9), and video hardware. OK, except for the chroma bug that was a common fact. However, I am not sure any more. I tried to set the output color space in FFDShow (built Nov 03) to only one dedicated color space (as opposed to default values where most of the boxes are checked, so you do not actually know what is going on) and noticed quite different results depending on which output colorspace is used. Image brightness and contrast varry depending on the output color space used, and some of them have sub-black levels and some don't.


To the best of my knowledge once YUV 4:2:0 is converted to YUV 4:2:2 (either through hardware assistance or in software mode that depending on the MPEG2 codec and video hardware could cause various issues, chroma bug being the most notable), signal will at one point have to be converted to RGB format as this is "computer video color space" as opposed to YUV that is "video color space". Bit by bit, YUV is larger space than RGB, so 32 bit YUV signal will not fit in RGB 32 bit signal format. It needs to be clipped to fit within 0-255 range of RGB space. This is a tricky part where lots of things can go wrong.


All newer hardware would natively support both conversion within YUV space as well as conversion from YUV to RGB space and methods used supposedly would cause only a minimal degradation of the signal quality as a rasult of the conversion. Well, first I am not sure about that assumption any more, and second what happens if FFDShow processing is involved, and furthermore how are things different if overlay vs. VMR9 is used, and finally how does hardware acceleration vs. software mode of the decoder play with this.


Without spending much time testing, quick and dirty conclusion after watching 2-3 my reference scenes in LOTR FOTR EE is that using only RGB32 space looks best in my set up. Image is less bright (i.e I had to increase brightness by 10 nits) and contrast range is wider (i.e. I had to reduce my contrast on display by 15 nits), while there is more detail than I had before, resulting in picture being more 3D and "jumping out" of the screen. Also colors looked a bit different. They were more saturated, which is fine, as simple adjustment can bring it back to where they should be. Apart from that, there was an overall shift in colors, I just did not have time to figure out if it was for the better or worse. Negative side effect is that there is a bit more noise, but this is definitely something I can live with and is conmesurate with improvement in detail. RGB signal using this path does not have sub-black component (Digital Video Essentials Test), so I am not sure if this is good or bad. For example, if I leave all the boxes checked in the FFDShow, signal will have sub-black component. Similarly, if I do not use FFDshow, signal brigthness and contrast ranges are in line with the FFDshow with default settings as far as the output color spaces are concerned.


I would tend to say that lack of sub-black signal component is great news, (aside from the fact that it might be more difficult to set your brightness level) because in the compressed RGB range (as compared to YUV) there is no reason (?) to have sub-black and above/supra-white portion of signal as in YUV color space. I.e. if you can fit more of the "visible" signal in RGB range and get rid of the sub&supra signal portion, this should result in increased dynamics (contrast) range of the image. For example, if sub&supra portion of the signal populates 0-10 and 245-255 part of the RBG range, effectively dynamics of the signal would be 235, while if sub&supra part of the signal is clipped it would be 255. Bigger is better, right? However, I am not sure if this type of conversion creates some other problems and issues.


It would be great if we could somehow come to a concensus what really happens with color space conversion using FFDShow and overlay as well as VMR9. Any input will be appreciated, including partial contributions as to any particular part of this process.


My set-up is: AMD FX-51 (although CPU probably should not have effect on these issues) with 9800XT (with 7.96 FireGL drivers, not Catalyst) via DVI @ 1280x720x60hz to Samsung HLN617W DLP monitor. Software is XP SP1, DX 9.0b, Nvidia Forceware 3.0 beta (generaly same results with ZP 3.2 Pro + Sonic filters) in software mode with VMR9 and Reclock 1.2 as renderers, FFDShow built Nov 03, with 1280x720 spline or lanczos resize and chroma/luma resize sharpening of about 4. My Samsung was calibrated in the service meny by using slightly tweaked results from rear projection forum and Digital Video Essentials. Additionally my video card was calibrated (i.e. to compensate for poorly calibrated display) using 3Deep software that adjusts video card output gamma to match display calibration. All gear power conditioned with AVS 2000 / HTS 5000 combo.
 

·
Registered
Joined
·
264 Posts
I found the bug in the ffdshow compile. Its the libmplayer.dll wich cause the problems of green by using rezise. The bug was found in all latest ffdshow versions.


Its fixed in the actual cvs build, atm im trying build a working and stable ICL8.0 Build. Will post it here for testing if i get it working.
 

·
Registered
Joined
·
1,358 Posts
Discussion Starter · #3 ·
AndyIEG,


Thanks for your response. Any ideas how this whole process works and why are YUV to RGB conversion results different? I do not mind the green bug so much as I can compensate for it with 3Deep adjustments, but I do like the extended dynamic range of RGB 32 output and increased level of detail.
 

·
Registered
Joined
·
1,056 Posts
I'm not quite sure I understand how you are shifting between colorspaces in ffdshow. Could you explain that a bit further?
Quote:
...using only RGB32 space looks best in my set up. Image is less bright (i.e I had to increase brightness by 10 nits) and contrast range is wider (i.e. I had to reduce my contrast on display by 15 nits), while there is more detail than I had before, resulting in picture being more 3D and "jumping out" of the screen. Also colors looked a bit different. They were more saturated, which is fine, as simple adjustment can bring it back to where they should be. Apart from that, there was an overall shift in colors, I just did not have time to figure out if it was for the better or worse. Negative side effect is that there is a bit more noise, but this is definitely something I can live with and is conmesurate with improvement in detail. RGB signal using this path does not have sub-black component (Digital Video Essentials Test), so I am not sure if this is good or bad. For example, if I leave all the boxes checked in the FFDShow, signal will have sub-black component. Similarly, if I do not use FFDshow, signal brigthness and contrast ranges are in line with the FFDshow with default settings as far as the output color spaces are concerned.
This is a very similar description to what I see with a change from Overlay to VMR9 mode (only). However, I don't seem to find it necessary to trim brightness or contrast, as while brightness is lower, there is detail in there I couldn't see before. And while contrast is higher it doesn't seem unnatural. Colors are richer, but more in line with what I would see in HD and there's certainly more distinction between shades. At the same time there *appears* to be a softness to the image which I'm not really sure is real softness because it doesn't seem to lose detail. It's somehow smoother and more believable but without certain types of detail being overemphasized (?). Where you notice this a lot is in background images. In VMR9 mode, the background objects are easier to make out and seem to be part of the picture, whereas with Overlay mode they're there but seem strangely detached from the foreground.


It really does appear to be a colorspace difference but it's not at all clear what exactly is happening between the two formats relative to the video codec and ffdshow. I find myself repeatedly going back to it in most cases, though I originally shyed away from it due to the apparent softness. Now I'm not so sure.


My set-up is: Intel 865PERL at 1.8Ghz with Matrox Parhelia at 1440x810x72hz, RGBHV to Ehome 9501LC Projector to an 8' wide Stewart 1.3 screen. Software is XP SP1 + all patches, DX 9.0b, Primarily using WinDVD5 audio/video filters in software mode with Overlay/VMR9 and Reclock 1.2 as renderers, FFDShow 20030927, with 1440x810 lanczos resize and luma/chroma resize sharpening of 2/1.8. Sometimes I add Dsaler sharpening at about 40 (after resize only). I have all the other player filters too, but in this configuration WinDVD5's seem consistently superior in presentation of detail. The projector has Mike Parker's VIM and Neckboard mods, plus several of my own, and is calibrated with Colorfacts. I also have the Xcard/PDI Deluxe combo but don't find it to be superior to the all-software setup. It's close, though.


DVD playback has long been a sore spot with me because no matter what you do it's such a distant second to HD, so every little bit of naturalness/presence/detail you can recover is significant.


--Bill
 

·
Registered
Joined
·
264 Posts
im still messign around with compiles... Everytime i use gcc to compile the mplayerlib.dll i get the green color conversion bug, if im using ICL 8.0 or VC 6 the bug is gone ... but i cant optimize the compiling much it seems. Even with all ICL 8.0 settings for Pentium2/3 the rezise performance is poor and unusable....


maybe i find a way compile it with gcc (and maxxed speed) without getting that colorspce error.... Seems the version/speed of that lib has huge impact on the ffdshow filter's.
 

·
Registered
Joined
·
1,358 Posts
Discussion Starter · #7 ·
I have posted my questions in a bit different format under Forceware 3.0 Beta thread. I got excelent response from the Nvidia person that leads that thread.

http://www.avsforum.com/avs-vb/showt...79#post3273679



bblue,


Under "Codec" section of FFDShow there are several options for output colorspace. Each one you can activate (check the box) or de-activate (uncheck the box). Default settings have most of them activated, so FFDShow determines based on some internal code/preference and probably your hardware capabilities which one to use. If you uncheck all the options but one, than FFDShow will be using that option. As indicated, RGB32 is the one that probably fits our HTPCs with 32 bit color depth enabled in display settings. If you go with some other option, or if FFDShow chooses a different option under default settings, you are likely introducing another layer of color space conversion. None of them are completely lossless, so I'd say less is more in this case.


Your experience with overlay vs. VMR9 is what one would expect. If you are using ATI card, ATI overlay has been known (see some other threads on this - one by Blight, developer of ZP) to add way to much sharpness to the image. IMO VMR9 is able to resolve more of the "real" detail in the image, and as you described put together more consistent and more 3D-like image.
 

·
Registered
Joined
·
3,351 Posts
There is definitely funny stuff going on with ffdshow and colourspaces. Here's my bit of anecdotal data.


I use TT with ffdshow. When Sonic is in S/W mode it outputs YUY2 uncompressed. If I enable only YUY2 as the output colourspace of ffdshow it uses more CPU than if I select YV12 as the output colourspace?


What's up with that? I would have thought that by selecting YUY2 as the output all processing would be done in that colourspace so there wouldn't be any conversions going on. The fact that it uses less CPU leads me to believe that something funny is going on.


Perhaps ffdshow doesn't work in YUY2 and by specifying it as output then there are multiple conversions going on, i.e. YUY2(in) -> ? -> YUY2(out). When I select YV12 as output there is definitely one convervsion so it doesn't make sense to me that it should take less CPU than staying in YUY2 all the way.


From a H/W perspective the ATI cards seem to handle both YV12 and YUY2 equally well in the overlay as far as I can tell.


I haven't tried using RGB32 as the output colourspace but I will give that a shot.
 

·
Registered
Joined
·
590 Posts
@vpopovic
Quote:
Your experience with overlay vs. VMR9 is what one would expect. If you are using ATI card, ATI overlay has been known (see some other threads on this - one by Blight, developer of ZP) to add way to much sharpness to the image. IMO VMR9 is able to resolve more of the "real" detail in the image, and as you described put together more consistent and more 3D-like image.
Sorry, but this is completely crap!:rolleyes:


VMR9 scales bilinear instead of bicubic. This is the reason why the frequency response is so bad and the image looks so soft!

Every better (higher order) scaling algorithm (bicubic, spline, sinc) introduces ringing. Also Lanczos from ffdshow does. This is unavoidably and the intensity also depends on the parameters. This is the way better scaling works!

Bilinear filtering is a bad choice, but today 3D pipelines doesn't support bicubic scaling. This is the reason why VMR9 looks the way it looks.


The statement that there is edge enhancement in the overlay is completely wrong.


Btw, the ringing is introduced only on the highest frequencies which never appear on movie DVD's. Only test DVD's have a frequency response that high.

So it is nearly irrelevant in real life.

A very good link to ringing and EE
 

·
Registered
Joined
·
1,358 Posts
Discussion Starter · #10 ·
FoLLgoTT,


Ultimately whether ATI overlay has or has not edge enhancement beyond original DVD signal is not important. What is important is that VRM9 produces better image quality on my setup. As I indicated, number of people share that opinion, some of them quite advanced members. So there is a lots of "crap" in this world, but that is nothing new.


If you were reading my original post at all, you would notice that instead of VMR9 scaling I am using lanczos or spline FFDShow scaling. So this is what happens:


Forceware decodes DVD signal into 720x480 YUV 4:2:2 format that is fed to FFDShow. FFDShow (not sure in what order) converts signal to 1280x720 using spline and then converts YUV 4:2:2 format into RBG32 (not sure if this is hardware assisted or not). Bingo, VMR9 assembles the image and 9800XT sends it to my DVI port @ 60 hz. Very simple "crap".
 

·
Registered
Joined
·
590 Posts
@vpopovic
Quote:
What is important is that VRM9 produces better image quality on my setup. As I indicated, number of people share that opinion, some of them quite advanced members. So there is a lots of "crap" in this world, but that is nothing new.
That many advanced members believe it doesn't make it technically right. ;)


I did want to attack you. I just wanted to rectify these things.


When you use Lanczos to resize to your desktop resolution (doesn't uses the scaler of the Radeon) you also have ringing with VMR9. In fact in this case the frequency response, aliasing and ringing are absolutely identically to overlay! :)


Simple per pixel scaling doesn't introduce ringing. If you use it with ffdshow overlay will show NO SIGN of ringing. This is the best evidence that there is nothing like EE.
 

·
Registered
Joined
·
1,358 Posts
Discussion Starter · #13 ·
jvincent,


I assume ugh means it is not good. It would be great if you could post your set-up. I am very interested in figuring out how FFDShow interfaces with ATI's hardware/drivers.
 

·
Registered
Joined
·
1,358 Posts
Discussion Starter · #14 ·
FoLLgoTT,


Although lanczos introduces ringing, I find the image more pleasing than with simple resize.


As far as overlay vs. VMR9, ATI overlay on my display produces less 3D image, and in high-contrast scenes the light parts of the image reveal raster, or grid of pixels. This never happens with VMR9. VMR9 fills the gaps that overlay reveals, and ultimately does have less noise. Probably some kind of filtering happens at one stage of the 3D engine pass. Too bad that ATI does not share info any more on details of video processing in their cards. The last one I found on their site was for Rage 128 or so.
 

·
Registered
Joined
·
189 Posts
I tried RGB32 instead and it's really bad on my setup compare to YUV2. It produces lower brightness and higher pixelation/blockiness, overall, it just looks 'bad'.


SETUP

ZP w/ffdshow, spline resize, VMR9

ATI9700 pro DVI w/catalyst 4.1

Sony 42WE610
 

·
Registered
Joined
·
3,351 Posts
Quote:
Originally posted by vpopovic
jvincent,


I assume ugh means it is not good. It would be great if you could post your set-up. I am very interested in figuring out how FFDShow interfaces with ATI's hardware/drivers.
Correct. Hard to describe exactly what it looked like. Very dark, colours appeared to be offset from each other and very blurry. Just plain ugly.


I am running an AIW 9700 Pro, Cat 4.1, TheaterTek, ffdshow 20030927.


I am connected via the component dongle to a CRT HDTV running at 1776x1000i for DVD playback.
 

·
Registered
Joined
·
1,358 Posts
Discussion Starter · #17 ·
As CinVidGuy mentioned in his response in the other thread, if you are using overlay, you do not want to use RBG 32. Apparently RGB32 signal can not properly connect to overlay, so any YUxx type of signal will produce much better results.
 

·
Registered
Joined
·
1,056 Posts
vpopovic: Yes, I'm familiar with those settings. At the time I was trying different colorspace settings every single one I tried (including RGB32) was producing a filter connection error, so I thought you were manipulating it somewhere else. I must have had something else set wrong at that time, because today all but a few work as expected. RGB32 doesn't look very good here, but YUV2 and (I think) YVYU do well in either Overlay or VMR9.


FoLLgoTT: So in your opinion, with overlay as the superior method, which ffdshow resize filter does the least damage to the resulting video? Also, can you account for the apparent difference in color saturation and depth seen in VMR9 compared to Overlay? I'm not able to duplicate it with traditional saturation and level adjustments in that space. By comparison, Overlay looks like there is less overall color range and if you increase saturation it just increases level of the off-looking colors.


--Bill
 

·
Registered
Joined
·
283 Posts
I've read through this thread several times and tried experimenting with RGB32 selected as the only colorspace instead of YUV12 or YUV2 using VMR9 and lanczos resize.


I need to study the results further; but I am coming round to the same opinion as vpopovic.


Initially I got the highly saturated colors, brightness and contrast that he mentions and I believed that a perceived increase in 3 dimensionality was a result of those factors.


However, last night I levelled the playing field between RGB32 and YUV2/12 by increasing the Gamma, in the levels area of FFDSHOW to about 1.40. This gave me colors with RGB32 that are close to YUV2/12. I also experimented with reductions in brightness and contrast.


After doing that the greater sense of 3 dimensionality and detail remained when using RGB32 by itself, so my currrent thinking is that this is the prefferred colorspace setting in FFDSHOW, providing you make those other adjustments.


geoff
 
1 - 20 of 33 Posts
Status
Not open for further replies.
Top