My blacks look washed out with MPC and Coreavc

[zeroprobe]

When Im watching films the black levels look grey. Any ideas?

[Sharktooth]

yeah, dont use VMR9 but stick with VMR7 or Overlay.
However someone (i read it somewhere on this forum but i dont remember exactly where) mentioned coreavc has an option in the decoder to correct the color range...

[foxyshadis]

Either set the output device to Overlay, or use ffdshow's levels to convert 16-240 to 0-255.

[Sharktooth]

The FFDShow levels conversion will eventually slow down the decoding, something you dont want if you bought CoreAVC...
At least i think you bought it for the decoding speed reason...

[HeadBangeR77]

VMR9 renderless, windowed & VMR7 renderless - so called "TV scale" color range. Too bad if you want to make use of MPC's own subtitles fuction.

As written above - Overlay output and VMR7 windowed don't have that bug.

[falcon2000eg]

do you mean this option
http://img294.imageshack.us/img294/6179/untitledii4.jpg

[Morte66]

You could also use ZoomPlayer, which does 0..255 in VMR9 renderless, and use the player's brightness/contrast or ffdshow's features to stretch the 16..240 in your source to fill that. That will work with all decoders including CoreAVC. But you have to buy the Pro version of ZP (quite cheap) if you want to play DVDs as well as plain files.

[qyqgpower]

I think force the decoder to output RGB32 color space would be better than add a level filter or set the fix option in coreavc under VMR9

http://www.ranobe.com/up/src/up166020.png

[HeadBangeR77]

@ qyqgpower
It seems obvious, but I must ask: is that really the same source, and exactly the same frame? Not only the brightness is different, but colors as well (& probably saturation a bit)!

:eek: :eek: :eek:

[DarkZell666]

Geez, I didn't know the difference could be that bad O_O
Thx for opening my eyes to a sad truth :o

[ChronoCross]

I don't think he's telling the truth to be perfectly honest....something that obvious wouldn't even have shown it's face on the initial core release. Also from all my tests I haven't seen anything like what his pictures show.

[Sharktooth]

Smells like BS to me too...

[JohnnyFu]

Overlay output and VMR7 windowed don't have that bug.

i recently found coreavc's color level bug on VMR7 windowed (king kong h264)

PDVD7.2_Frame375 VMR7 (windowed) MPC (http://home.arcor.de/johnnyfu/screen_shots/frame375_pdvd_dxva-off_VMR7.png)
CoreAVC_1.2_Frame375 VMR7 (windowed) MPC (http://home.arcor.de/johnnyfu/screen_shots/frame375_coreavc_VMR7.png)

[HeadBangeR77]

i recently found coreavc's color level bug on VMR7 windowed (king kong h264)

PDVD7.2_Frame375 VMR7 (windowed) (http://home.arcor.de/johnnyfu/screen_shots/frame375_pdvd_dxva-off_VMR7.png)
CoreAVC_1.2_Frame375 VMR7 (windowed) (http://home.arcor.de/johnnyfu/screen_shots/frame375_coreavc_VMR7.png)
Sorry to hear that - in your case it is truely the matter of tv-scale colors.
... searching ...
MPC says directly that VMR7 windowed "runs in overlay when it can" ;) - so in your case it obviously doesn't (for whatever reasons hidden from me ;) ), and hence the above bug.

[JarrettH]

I use RGB32 + high quality YV12--->RGB conversion is ffdshow. It looks WAYYYY better than YV12 and corrects the colour range too. I gave up with toying in Overlay, this is a much better solution IMO. You don't want to adjust your brightness and contrast every time you watch a movie.

[HeadBangeR77]

I use RGB32 + high quality YV12--->RGB conversion is ffdshow. It looks WAYYYY better than YV12 and corrects the colour range too.
For my eyes YV12 without the mentioned bug and RGB32 don't differ much from each other, apart from the first having some nasty color bleeding. I compared many screenshots, spent a couple of days on it. When no red is present, they really look the same. I use YUY2 atm - much less bleeding, less CPU usage.

I gave up with toying in Overlay, this is a much better solution IMO. You don't want to adjust your brightness and contrast every time you watch a movie.
I tried that too, true enough ;) No matter what I was doing with brightness, contrast and saturation the black color just didn't want to look like black :p And the whole image was darker. Waste of time, imo.

[fofwp]

My desktop has an nvidia card and my HTPC an ATI, and in both I was getting gray blacks in VMR9 renderless mode, but I was able to solve both without changing anything in ffdshow.

For nvidia there is a registry fix explained in the release notes (http://download.nvidia.com/Windows/93.71/93.71_ForceWare_Release_Notes.pdf) on page 19 second bullet point, but they switched the dword values. 0x3 will give you the extended range and fix the black level with VMR9.

For ati it went away with the latest catalyst drivers (v7.1)

Try it out and see if it works.

[qyqgpower]

ok, it seems that the color of YV12 is affected by the video driver settings and RGB32 isn't
so in my shots they show differences so obviously(but in fact, I didn't adjusted any settings in Nvidia's control panel when I took those pictrues, they are at default values)
because of this, again I don't think YV12 is a suitable colorsapce if you want to get correct color display

[Seb.26]

Isn't this only about "how TV scale and PC scale are managed by overlay and VMR9" ?

[DarkZell666]

@Seb.26: well, it was at first, until qyqgpower posted some screenshots showing CoreAVC rendering very wierd colors (with AND without their "fix VMR9" option). The screenshots have been removed, and it seems that: that the color of YV12 is affected by the video driver settings and RGB32 isn't (at least on his card). But as far as zeroprobe's problem goes, it's solved :)

[Audionut]

I tried that too, true enough ;) No matter what I was doing with brightness, contrast and saturation the black color just didn't want to look like black :p And the whole image was darker. Waste of time, imo.

I dare say that your monitor settings are not adjusted correctly, hence you would need to adjust those settings first.

With an Nvidia card you want to do as JarrettH and qyqgpower has suggested.
Use a program like display mate to adjust your monitor/desktop settings.
http://www.displaymate.com/

In FFDSHOW.
http://img223.imageshack.us/img223/210/ffdshowkr5.png

And in MPC.
http://img218.imageshack.us/img218/2655/mpcrj9.png

And adjusting the desktop color settings in the nvidia control panel will adjust the video displayed in MPC. Atleast it does in the latest control panel/drivers.

edit: Using the incorrect settings can really make the difference between correctly displayed picture an crap. As seen in the screen shots posted by qyqgpower.

[Audionut]

This is a screenshot using the settings as posted above.
http://img206.imageshack.us/img206/82/rgb32ee9.png

Adjusting FFDSHOW setting to use YV12 as shown below.
http://img206.imageshack.us/img206/9205/yv12ffdshowby4.png

Results in this washed out image.
http://img206.imageshack.us/img206/1738/yv12ih6.png

Adjusting MPC to use overlay as below.
http://img209.imageshack.us/img209/5181/overlayff7.png

With FFDSHOW set to use YV12 as posted above, Results in a very dark and oversaturated image.
Sorry I couldn't easily capture an image rendered with overlay.

[Seb.26]

This is a screenshot using the settings as posted above.
http://img206.imageshack.us/img206/82/rgb32ee9.png

Adjusting FFDSHOW setting to use YV12 as shown below.
http://img206.imageshack.us/img206/9205/yv12ffdshowby4.png

Results in this washed out image.
http://img206.imageshack.us/img206/1738/yv12ih6.png

Adjusting MPC to use overlay as below.
http://img209.imageshack.us/img209/5181/overlayff7.png

With FFDSHOW set to use YV12 as posted above, Results in a very dark and oversaturated image.
Sorry I couldn't easily capture an image rendered with overlay.

And where is the problem ??? :rolleyes:

All looks normal for me ...

[foxyshadis]

This is just something you have to deal with. It's like fiddling with the knobs to calibrate your TV and monitor. Get a reference pic and movie (SMT has posted several of these), calibrate your settings for your preferred output method, and happily watch away. Expecting a magic bullet to take care of every combination of player, codec, video driver, video card, and monitor to work out of the box is overoptimistic.

(Video card drivers are the #1 culprit, due to not adhering to TV/PC conversion standards; everything else has to work around the problem. If anything, blame nvidia and ati.)

Some people prefer RGB because it needs the least effort to calibrate, and it's the least likely to break after upgrading stuff. But YV12 is faster more versatile for post-processing, and YV12 in overlay faster still. So find one that works and stick to it.

[HeadBangeR77]

@ Audionut

I think a small misunderstanding took place, 'cause I didn't tell the whole story. ;)

1) I "played" with overlay brightness /contrast /saturation settings in ffdshow, while using tv-scale in VMR9, without any fix (ffdshow YV12 => RGB32 or changing 2D dispaly drivers of my graphic card). The reason was I had googled for many threads on that matter, and some claimed everythig could be done with proper monitor calibration, without fixing the range (not everyone uses ffdshow, we seem to forget ;)). Since I didn't want to calibrate my CRT (for my work, surfing, and all other possible uses it's just perfect right now for my eyes, I had had spent days on calibrating some time ago) just to watch a film, I used the above software, more infirior method. After that I also tried to mess with with my monitor directly, but still couldn't achieve the desired effect. That all coresponds to your 2nd movie screenshot (YV12 in VMR9, using tv-scale, resulting in washed-out colors). So ...

2) I decided to go for YV12 => RGB32 HQ conversion (forced, as in your first screenshots of ffdshow /MPC's settings) in ffdshow and that resulted in a prefect image (like in your first movie screenshot), while running in VMR9 renderless.

@ Seb. 26 - I can see the difference. ;)

Everything was set as in your first post, with the exception of 2D reendering (I find 3D rendering useless, since I don't use any shaders effects). However, it cost some additional CPU cycles, 5-10% more than using YV12 & Overlay, that I wanted to spend on sth else. Funny thing, VMR7 renderless was even slower (?!).

3) After all that I tried YV12 in Overlay (default for many software players) and in VMR7 windowed, and, believe me or not, I didn't get any any oversaturation (compared many screenshots VMR9, RGB32 vs. Overlay, YV12), only with nice, bloody red color bleeding in some cases. When no red is present, I can't spot any difference.

4) Finally I read more about compressed colors and decided to give YUY2 a try, and that's exactly what I'm using atm: VMR7 windowed (screenshots can be taken, important while dealing with different codecs, CQMs, filters etc.) + YUY2. The above mentioned bleeding can still be noticed, but is much smaller than by YV12. Point. :)

The point is, as foxyshadis wrote, we've got a vast variety of different configurations: monitors, graphic cards and their drivers, decoders, software players, display modes and hell knows what more ;) The only thing everyone has in common, we don't like washed out colors (this thread began because of them). Anyway, thanks a lot for your efforts.

PS. ATI Radeon 9800 PRO @ XT, old drivers - and I do want to stick with them.

PS2. When a 30-year old guy, who has started with ZX Spectrum 48 and a tape recorder, is looking for solutions on washed-out colors, then some other people also might. That's why I hope all my mumbling above might be useful, at least for one soul, lost in color ranges. :D

[Seb.26]

@ Seb. 26 - I can see the difference. ;)
I wasn't say << I can't see difference >>, but :
<< The difference is normal : you compare Overlay and VMR9 with YV12 input ... so result is different ... >> ;)

What I know about this :

TV scale is 16..235 ( for Y, 16..240 for U & V )
PC scale is 0..255

Some renders do "TV->PC scale" :
- Overlay.
- VMR9 with RGB32 input.

Some don't :
- VMR9 with YV12 or YU2.

So it's normal to don't have same color when changing render or frame format ...

[DarkZell666]

Dunno what the mods (congrats. for your mod nomination foxyshadis btw ;)) think about this, but what about making this thread a sticky ?

I believe it's the sort of problem that's encountered often enough to have a permanent subject on the matter (imho :D).

It isn't AVC-specific though ... the software-players section seems appropriate if you ask me :)

[HeadBangeR77]

@ Seb. 26
I get it - it was obvious for you, sorry, my mistake.

@ DarkZell666
Yeah, why not? ;) I think we can all agree on the following:

1) RGB32 is always the best quality-wise. Even if sb doesn't get washed-out colors, it always delivers the best possible image and is not affected by color bleeding. Enable it, when you can, no matter what player and output mode you use. Just one downside - it's also the slowest one!

2) Performance-wise YV12/YUY2 running in overlay or VMR7 windowed (when it can run in overlay) is the fastest solution, not affected by tv-scale color range, however affected by color-bleeding and sometimes oversaturation (not in my case). YUY2 doesn't seem to utilize more CPU than YV12 and has got less color bleeding, so force it, if you only can.

The above is as general as it can be - it deals with color spaces, and tries to stay away from specific software players /graphic card drivers /decoders and so on.

3) Output modes affected by tv-scale (washed-out colors):
- VRM9 renderless & windowed
- VMR7 renderless (&windowed, in some cases).

Btw. my hosting has expired and I didn't pay yet - where could I upload some examples?

[Seb.26]

@ Seb. 26
I get it - it was obvious for you, sorry, my mistake.
... probably mostly due to my poor english ... :o

About RGB32, another bad point is that there isn't lot of FFDShow's filters that accept it ...

Classic playback chain looks like :

Codec produce YV12 or YU2 ( YV12 is native for almost codec )
FFDShow do filtering and out RGB32-HQ ( with TV scale since main renders do TV->PC scale ... but I think Haali's don't do )
Render ... render frames

:D

... my 2 cents are over ...
( soon )

[Seb.26]

IMO there are some other problems with Overlay :

1) all post processing are done on a limited dynamic range ( 16..235 ... full is 0..255 )
-> Not a really big problem, I don't thing it produce visual artefact

2) Overlay crop BTB & WTW
-> This point is important for me ...

3) you can't snapshot overlay

4) you can't use clone mode for dual monitors

[CruNcher]

useing RGB32 in CoreAVC will give you better chroma upsampleing but still not as good as ffdshows high quality mode i reported that problem months ago to the devs but it looks like it's still not enhanced thats really sad especialy, seeing that Mainconcept allready has this better upsampleing even with Hardware acceleration ready in their latest Decoder.
But as foxyshadis allready said it is personal preferance at least how Hollywood DVDs look on a PC Monitor in the end as those are calibrated for Video color balance and gama response also the Operating System plays a role here Windows is different in Gama then for example OSX you never gonna see the Movie how it looked in the Studio in PP for example, as those Systems are calibrated for Film not for Video.

[Crisidelm]

...seeing that Mainconcept allready has this better upsampleing even with Hardware acceleration ready in their latest Decoder...

Any hints about when the demo of this codec will be available?

[foxyshadis]

Dunno what the mods (congrats. for your mod nomination foxyshadis btw ;)) think about this, but what about making this thread a sticky ?

I believe it's the sort of problem that's encountered often enough to have a permanent subject on the matter (imho :D).

It isn't AVC-specific though ... the software-players section seems appropriate if you ask me :)

That's not a bad idea. I'll see if I can condense all the information out there into an easy-to-follow faq. (If anyone wants to contribute a draft they're welcome.) I think it might be time to move this into software players forum anyway.

[shae]

I'm suffering from this annoying problem too, on Win9x and an nVidia 5200 card. There's no obvious solution. Maybe nV's Win9x driver (as opposed to the NT one) is part of the problem.

* The VMRCCCSStatus registry value doesn't work for me (assuming I found the right location for it; the dox only specify it for NT).

* Software convertion to RGB takes more CPU than I can spare in many cases.

* Earlier drivers without this problem (<6x.xx) are either bad for games (in the case of 5x.xx), ruin video playback differently (4x.xx), or are too old for this gfx chip (<4x.xx).

Too bad it's not possible to run two driver versions concurrently, selecting which one each software uses. :(

[Sharktooth]

ensure the saturation in overlay settings in the drivers is at 100% (nvidia defaults it at 114%).
also, disable digital vibrance...

[shae]

ensure the saturation in overlay settings in the drivers is at 100% (nvidia defaults it at 114%). also, disable digital vibrance...
I'm not using overlay, of course. There's no way to have overlay not mess with the colors. I'm using VMR9 output.

[KoD]

I'm not using overlay, of course. There's no way to have overlay not mess with the colors. I'm using VMR9 output.

Are you sure VMR9 is not messing with your colours ?

[shae]

Are you sure VMR9 is not messing with your colours ?On the contrary, I am sure it is. That's the problem. :)

ffdshow/AviSynth/ColorYUV(levels="TV->PC") seems to help, though, I'm yet to compare it to the original to make sure it's completely identical. And I suspect this takes more CPU than just having the driver do the right thing. What's a way to benchmark decoding speed including the renderer?

ffdshow's HQ YV12->RGB is another option, which, at the same time, fixes the ugly chroma upsampling, but it certainly is more taxing.

I also hear MPC can extend the range with pixel shaders. Does anyone know anything about that? Might be a nice CPU-less solution (that is, if I were using MPC, and assuming my graphics card is fast enough to handle it).

I vaguely remember that extending the YUV range in software didn't work in older driver versions (I'm on 81.98 now) which just clamped it back, but I might be mistaken. I'll see if it works if/when I revert again to older drivers.

How pitiful can nVidia be, leaving Win9x with no single driver version that can both play games and show video (at least for the GF5 series)?!

Where's Matrox when you need them...

[mushishi]

I checked a few things myself, and no two of the following combinations produced identical outputs:


VMR9 + RGB32
VMR9 + YV12 + FFDshow levels 16-235 to 0-255 modifying only luminance
VMR9 + YV12 + FFDshow levels 16-235 to 0-255 modifying chroma as well
IIRC ColourYUV(TV->PC) did not yield the same result as either the second or third. It might have been almost identical to RGB32, albeit a little noisier. That might be my filter chain

Is RGB32 the one that definitely produces accurate colours? If so, I will just use it, despite the extra CPU utilisation.

[check]

I'm not using overlay, of course. There's no way to have overlay not mess with the colors. I'm using VMR9 output.
Unless your overlay is seriously borked, you can change the overlay colour information in your video card config. It's trivial to disable any modification to the colour information in there, even if the nvidia defaults are a little strange.

[shae]

VMR9 + YV12 + FFDshow levels 16-235 to 0-255 modifying only luminance
VMR9 + YV12 + FFDshow levels 16-235 to 0-255 modifying chroma as wellI think the problem with these might be that luma should be 16-235 but chroma 16-240.

Unless your overlay is seriously borked, you can change the overlay colour information in your video card config. It's trivial to disable any modification to the colour information in there, even if the nvidia defaults are a little strange.I'm pretty sure there's no way to get original colors on nV. Even if everything is at 100%/1.0 (besides the things that just *have* to be off by 1-2), it's still far from the original. Plus, there's some smearing. It was worse on my TNT2, but it's still not it. I think it was mentioned somewhere that overlay only looks right on ATIs.

Are you aware of any registry tweaks to make overlay work right?

[check]

everything looks identical on my 7300GS, when compared on the same monitor to my Radeon 9550. Perhaps you are using evil drivers? I'm using 93.71

[shae]

everything looks identical on my 7300GS, when compared on the same monitor to my Radeon 9550. Perhaps you are using evil drivers? I'm using 93.71Does it look the same as ffdshow's RGB output (or another known problem-free reference)?

How can you compare two overlay modes? (Is there a way to take screenshots?) What player(s) are you using?

Perhaps the GF7 or 9x.xx drivers work better than GF5 and <9x.xx drivers.

[check]

I compared overlay + YV12 on my nvidia to overlay + YV12 on my ati 9550. Both were output to the same monitor, although the nvidia went through DVI-D and the ati through VGA. Flipping between them I saw a small difference, but it was small enough to be negligible.

[NoX1911]

I'm aware of the luma range problem of VMR9 for quite a while now. The only fix i know so far is YUV->RGB conversion with ffdshow. I was kinda surprised as i realized the Catalyst 7.1 worked properly with VMR9 on XP without FFDShow for the first time. I didn't analyze it any further and the day came as i flushed my system to setup Vista.

After finally having all set up properly i noticed the luma range problem once more and ffdshow was needed again to have full range video playback. :confused:

First guess is... Ati has fixed it by driver. The luma range gets corrected in 7.1 catalyst but currently only in XP. The Vista driver hasn't full featureset atm. So chances are the new luma fix for vmr9 is not yet implemented (pray for next catalyst).

But someone should confirm it is working in XP with cat7.1. Maybe my system was just fucked up or sth...
Attached is a testvideo (Avisynth/ColorBars (640,480,"YV12"), XviD). If its playing properly it should look like the lower picture. The upper picture instead has wrong colorspace conversion (Y=0 (TV-scale) = RGB16,16,16. YUV Black != RGB black in this case).
http://img165.imageshack.us/img165/1415/yuvty7.png
(contrast amplified for illustration)
upper picture - VMR9 (bad boy)
lower picture - VMR9+RGB32 or Overlay (good boy)

The lower part of ColorBars is called the pluge. From left to right it consists of: -I, white, +Q, black, -4/0/+4 IRE levels and black. The -4/0/4 IRE levels can be used to set the brightness correctly. The -4 IRE and 0 IRE should have the same brightness, and the +4 IRE should be less[?] bright than -4/0 IRE.[?] - Looks like a typo. Should read 'more bright'. Correct me if i'm wrong...

In short:
If you want to test your system start the testvideo and check if you see 3 bars or 1 bar in the lower right corner (raise brightness or contrast on your crt since those are very small differences. The above pictures were amplified for illustration).

.
.
.

[Seb.26]

In short:
If you want to test your system start the testvideo and check if you see 3 bars or 1 bar in the lower right corner (raise brightness or contrast on your crt since those are very small differences. The above pictures were amplified for illustration).
You also can use the THX Optimizer ( from any THX certified DVD : in setup menu ) ... ;)

[check]

When talking about the VMR9 renderer, it's incorrect to assume that it is designed for 16-235 output. It's just that some nvidia drivers have code that will clip any input to those levels when rendering via VMR9.

[Rumbah]

But someone should confirm it is working in XP with cat7.1.

Yes, it works correctly with WinXP and Cat. 7.1.

[Rash]

This color problem is ridiculous, honestly. :( I work with video and when I get home I have this stupid color problem when it could be solved very easily.

In my job we use SDI (Serial Digital Interface (http://en.wikipedia.org/wiki/Serial_Digital_Interface)) but usually connected to analog devices, such as a CRT display. So we have to calibrate them, even on this digital connection. But on a full digital display, sorry, it is unnaceptable. It should go from the lowest possible black (#000000) to the highest possible color information (#ffffff) and the monitor should show it accordingly to its limitations (technology).

I know this is hard for analog devices. The pixel phophors on different displays have different colors, different brightness, etc. That's why we try to use the same devices calibrated equally in order to maintain color information throughout the video's treatment. But honestly, on any digital device (LCD, OLED, Plasma, LED, etc) it shouldn't be necessary, since these devices translate digital color information into quantized (meaning fixed) levels of voltage, or electrical field, according to its technology.

And we're talking about a full digital path inside your computer. Even if you use VGA, the signal will be converted only at the very end of this path. Up until this convertion, video inside a PC should (and could) be handled much better than it is.

Just my small rant. I am willing to calibrate my videos on Vista and it has been awful so far.

[wozio]

Just to clarify how it looks like now on ati cards with newest 7.3 drivers:

VMR9 (in fact drivers not VMR9 itself) always expands levels from tv to pc during yuv->rgb conversion. It is very comparable to ffdshow's yuv->rgb conversion or haali renderer conversion via pixel shader.

You can see screenshots here:
http://forum.doom9.org/showthread.php?p=988268#post988268