Quote:
Originally Posted by STaRGaZeR
What you call "the truth" is what ffdshow RGB32 outputs, or what Fraps lossless outputs, for example. These 2 decoders output RGB32. Why do I think that this output should not be touched? Because both of them compute the RGB32 frames using the correct matrices for 601/709, SD/HD, levels, etc. They do (in ffdshow you can configure it, Fraps is always 709/PC range) what you do in madVR when feeded with YV12, so their RGB32 output is comparable to the RGB32 output of madVR to the graphics card.
|
No, that's actually not true.
NTSC, Blu-Ray and PAL all have different primary color coordinates. The differences are *NOT* dealt with by just using the correct YCbCr -> RGB matrix. E.g. if you take the color "red: 200; blue: 20; green: 20", this color is supposed to result in a different wavelength being produced by your display for NTSC content than for PAL or Blu-Ray.
Practically that means, if you display an NTSC SD DVD you have to calibrate your display to BT.601 primaries. If you display a Blu-Ray, you have to calibrate your display to BT.709 primaries. If you display a PAL DVD, you have to calibrate your display to PAL primaries. If you don't do that, you'll get incorrect colors. All of this applies even if you convert YCbCr -> RGB with the correct matrices!
The solution to this dilemma is to perform gamut correction. Basically if you have RGB data coming from an NTSC DVD, madVR converts this RGB in such a way that it no longer needs NTSC primaries, but instead it's converted to HD/BT.709 primaries. As a result you can display this NTSC on your BT.709 display now with correct colors. Which is *not* possible without gamut correction - unless you calibrate your display to BT.601 instead of BT.709.
Quote:
Originally Posted by STaRGaZeR
Processing in madVR is a bad idea, because it'll redo everything, messing up colors, levels, gamma, etc. as it does right now.
|
madVR doesn't redo everything. madVR only performs those conversions which are necessary to achieve correct results. If there's double processing the reason for that is simply that madVR wasn't informed properly that another filter already performed the same operation before.
Quote:
Originally Posted by STaRGaZeR
The most interesting effect happens with the levels setting. My monitor is a PC monitor, so 0-255 of course. When PC levels is selected in madVR the videos are double expanded: by ffdshow/fraps (because they assume no further conversions will be done) and then by madVR, yet I'm telling madVR the truth, my monitor is PC range. This option doesn't have a "something else" setting, so I have to lie to madVR and tell it my monitor uses TV range to get proper levels.
|
The real fault here is in ffdshow/fraps. They can not assume that no further conversion will be done because it's the duty of the video renderer to care about display levels. ffdshow/fraps don't even know on which display the output will be shown!!!! If you have a dual monitor setup and one monitor needs PC levels while the other monitors needs video levels, how would ffdshow/fraps know what is needed?? They are not in a position to make such decisions. Only the video renderer is. Configure ffdshow to leave levels alone and the double stretching will go away.
Quote:
Originally Posted by STaRGaZeR
RGB32 is a format that is intended to be displayed as-is
|
Not true at all.
Quote:
Originally Posted by STaRGaZeR
On a side note, in MPC-HC you can tell EVR your monitor's output range, and it does work when EVR itself does the YCbCr->RGB conversion. However, if you feed EVR with RGB32 the setting will have no effect, like it should be.
|
You're actually using EVR behaviour to proof a point? Are you serious!?
The reason why EVR reacts to the monitor output range information when being fed with YCbCr, but not when being fed with RGB is that the GPU driver performs the video levels stretching when the video renderer calls the Direct3D StretchRect API to convert YCbCr -> RGB. This is purely a programatical thing, not a decision based on science or anything.