madVR - high quality video renderer (GPU assisted)

[huhn]

jriver mediacenter has madvr support but it is not free

[Weirdo]

jriver mediacenter has madvr support but it is not free
I know, I was talking about Smooth Motion. :)

edit: Actually, it can be used in Custom mode, but replacing madVR in MC's folder with the newer version is required, and there are some problems with that.

[Stephen R. Savage]

I've been trying to figure out how to approach the color management settings in madVR. I've found a lot of contradictory advice in this thread and from Google and am at a loss as to how to calibrate my display and what settings to pick in madVR.

I have:
- 1x wide gamut LCD display (100% sRGB, ~98% AdobeRGB)
- 1x colorimeter w/ ambient light sensor

Based on what I've found, it seems like I need to use ArgyllCMS with TI3Parser (http://forum.doom9.org/showthread.php?t=162285)) to generate a 3DLUT. How should I set the following options:

- White point: 6500K?
- Tone curve: sRGB? BT.709? 2.2? 2.4?
- Ambient light correction: yes? no?
- (TI3Parser) Auto-calibration: yes? no?

Likewise, in madVR after I've obtained the 3DLUT:

- Disable GPU gamma: yes? no?
- Gamma processing: enabled? 2.4? 2.2? BT.709? Power?

Once I've set up my calibration, how can I evaluate it? Am I missing something or going about this in completely the wrong way?

[cyberbeing]

The reasons for contradictory advise, is because there are multiple options for going about this. Everybody has their own preferences, and certain displays may yield better results with certain methods. If you are picky, experiment. None of the available solutions for creating madVR 3DLUTs are near-perfect at this point. YMMV.

White point: D65 (x0.312713 y0.329016)
PC & TV: I explicitly set these values.

Tone curve: Personal Preference. First decide or experiment to figure out if you desire a power curve like 2.2, 2.35, 2.4, or a "special" curve like BT.709 or sRGB
PC: I use BT.709
TV: I have a target I aim for, but ultimately whichever curve gives me D65 across the entire range by adjusting hardware controls alone, with roughly a known curve that works with the lighting conditions of that room

Ambient light correction: Yes if using BT.709, otherwise No.
PC: I usually set this to 32 lux to roughly match the controlled D65 lighting I have in this room, which brings the BT.709 gamma to an average of 2.35 or 2.4.
TV: I don't use ArgyllCMS at all. Calibration was already done as desired with hardware controls.

TI3Parser or yCMS: Personal Preference.
PC & TV: I use yCMS, with White Point and Primaries only as measured by ColorHCFR

TI3Parser Auto-calibration: Personal Preference, but in general should only be considered if using a BT.709 or sRGB curve. If you have an custom ICC profile installed, this will requires GPU gamma ramp disabled for Fullscreen Exclusive, and using Overlay instead of Windowed.
PC: I tried using TI3Parser auto-calibration before, but always got worse results than having my GPU lut handle gamma instead.

Gamma processing: Personal Preference.
PC & TV: I've never used this, since I always calibrate my display to the gamma I desire.

How to verify: Video Test Patterns (http://www.avsforum.com/t/948496/avs-hd-709-blu-ray-mp4-calibration) loaded with madVR and measured via something like ColorHCFR in "DVD manual" mode.

[dansrfe]

Why choose D65 over 6500k or vis-a-versa?

How do you determine the appropriate tone curve? Is it display dependent? Environment dependent? Or just personal preference without technical basis?

Is controlled lighting required to use ambient lighting correction with D65?

What is the best approach for TV calibration if there is lots of flexibility in hardware controls already?

If a 3DLUT is utilized, isn't it best to leave gamma ramps disabled in madVR regardless of whether an ICC profile is installed or not because the calibration should be performed without any active ICC profiles in the first place?

[cyberbeing]

Why choose D65 over 6500k or vis-a-versa?
Because D65 (~6504K | x0.312713 y0.329016) is expected for video, and when calibrating it's best to have a correct target.

6500K (x0.312779 y0.329183) is essentially a rough approximation of D65, while not being used by anything specifically.


How do you determine the appropriate tone curve? Is it display dependent? Environment dependent? Or just personal preference without technical basis?

It can be any or all of those things.

Recommended viewing gamma is based on lighting conditions. For dim/dark viewing, a curve which averages anywhere from 2.35 to 2.6 is usually recommended on a technical basis. If you have a bright room, stick with using a gamma around 2.2.

Using 32lux ambient compensated BT.709 curve essentially lightens darkest tones ~1.9 gamma, darkens bright tones ~2.6 gamma, with mid-tones ~2.4 gamma. I find this flatter and less punchy look, which favors shadow detail and reduces white crush as more natural and pleasing than using a power curve. Though occasionally you may run across certain content optimized for viewing using a 2.2 power curve, where a BT.709 curve can look really bad in the dark tones.

If your display is able to do a particular curve smooth and naturally, you'll usually get superior results than forcing it into a drastically different curve it doesn't handle well.

At a certain point, personal preference comes into play, and you may need to make a trade-off somewhere to have a subjectively pleasing viewing experience.


Is controlled lighting required to use ambient lighting correction with D65?
No it's not required, just recommended if not watching in a dark room. If ambient light is of vastly different color temperature than D65, it will skew your perception of colors because of how the human visual system works.

What is the best approach for TV calibration if there is lots of flexibility in hardware controls already?

Free option you basically have ColorHCFR. Paid option would be something like CalMAN. Both require you to know what you're doing.

Otherwise, if you have no idea what you're doing, consider paying for an ISF calibration and having someone else do it for you.

If a 3DLUT is utilized, isn't it best to leave gamma ramps disabled in madVR regardless of whether an ICC profile is installed or not because the calibration should be performed without any active ICC profiles in the first place?

It depends if you took your measurements for the 3DLUT with or without the ICC profile gamma ramp active, as they need to match.

IMHO, if using a BT.709 curve you should just keep your ICC profile gamma ramp active, and not use yCMS grayscale measurements. Your GPU lut does the best job of maintaining the accuracy of a custom gamma curve.

The only time you should consider going the route of disabling gamma ramp is:
A) If you calibrate to a power-curve, are using yCMS grayscale measurement, and intend to use madVR's gamma adjustments.
OR
B) Use nand's tools to merge the ArgyllCMS gamma ramp into a 3DLUT because your GPU gamma ramp was causing noticeable banding.

[DragonQ]

Recommended viewing gamma is based on lighting conditions. For dim/dark viewing, a curve which averages anywhere from 2.35 to 2.6 is usually recommended on a technical basis. If you have a bright room, stick with using a gamma around 2.2.
My friend's TV has a gamma of ~1.4 and it isn't editable (no way of changing tint and the colour/brightness/contrast controls don't alter it). Hard to get used to, haha.

[6233638]

6500K (x0.312779 y0.329183) is essentially a rough approximation of D65, while not being used by anything specifically.6500K does not have specific coordinates - it is a line.

This image from Wikipedia (http://upload.wikimedia.org/wikipedia/commons/b/ba/PlanckianLocus.png) has 6000K marked rather than 6500K, but you can see how 6000K could be a value that is neutral, or heavily tinted green/magenta. Same thing for 6500K. This is why CCT values are not useful.

Using 32lux ambient compensated BT.709 curve essentially lightens darkest tones ~1.9 gamma, darkens bright tones ~2.6 gamma, with mid-tones ~2.4 gamma. I find this flatter and less punchy look, which favors shadow detail and reduces white crush as more natural and pleasing than using a power curve. Though occasionally you may run across certain content optimized for viewing using a 2.2 power curve, where a BT.709 curve can look really bad in the dark tones.You should not calibrate your display to the BT.709 curve. It is not intended to be used on displays. Generally a 2.4 power curve is accepted to be reference gamma now if your display is capable of more than 10,000:1 contrast. Otherwise use the BT.1886 function.

My friend's TV has a gamma of ~1.4 and it isn't editable (no way of changing tint and the colour/brightness/contrast controls don't alter it). Hard to get used to, haha.It can be fixed with madVR and 3DLUTs though. (as long as it's not dynamic)

[QBhd]

I noticed the EDID info for my TV states it has a gamma of 2.5... I was wondering if it is a Power Curve 2.5 or a BT.709 Curve 2.5? It doesn't state what type it is. More of a curiousity than anything else and since we seem to be talking about this now I was hoping one of you guys could shed some light on it :)

QB

[e-t172]

You should not calibrate your display to the BT.709 curve. It is not intended to be used on displays. Generally a 2.4 power curve is accepted to be reference gamma now if your display is capable of more than 10,000:1 contrast. Otherwise use the BT.1886 function.

Wow, I did not know about BT.1886, that's a very useful specification as it puts an end to the never ending "2.5 is display gamma, NOT 2.2" (http://www.avsforum.com/t/1008297/2-5-is-display-gamma-not-2-2) debate (which started 3 years before BT.1886 was published). From my understanding of this document, the One True Display Gamma©®™ is actually 2.4.

There's a few things I don't quite understand in the document, however:

- You say "use 2.4 if you have high contrast, BT.1886 otherwise". Thing is, BT.1886 uses a gamma function with… 2.4 as the exponent. What's the difference? Is it because the BT.1884 function has "black compensation" (the "+ b" term)? As far as I'm aware, most calibration software (at the very least HCFR) displays black compensated gamma, i.e. when calculating gamma, L' is used with L' = L - L(black). That would mean that, within such software, the "+ b" is already accounted for and thus your target really is 2.4 as calculated by the software.

- Appendix 2 indicates that "This Recommendation does NOT change any signal parameters defined in Recommendation ITU-R BT.709". The way I understand it, this only makes sense assuming that BT.709 defines the optical → electrical transfer function, while BT.1884 defines the electrical → optical transfer function. However, having different transfer functions for "input" and "output" strikes me as odd, as that would mean that when capturing something using an ideal reference camera and then playing it back on an ideal reference monitor, the display will not be consistent with the reality of what has been captured, because of the difference between the transfer functions used for capture and playback. What gives?

[DragonQ]

As far as I'm aware from my limited research, anywhere between 2.2 and 2.4 is fine. 2.2 is usually suggested for brighter environments (including PC monitors) and 2.4 for darker environments.

[cyberbeing]

You should not calibrate your display to the BT.709 curve. It is not intended to be used on displays. Generally a 2.4 power curve is accepted to be reference gamma now if your display is capable of more than 10,000:1 contrast. Otherwise use the BT.1886 function.

I'll try out using BT.1886 (-f0 -G2.4) next time I calibrate, but unless it's much different, I've always found using a 2.4 power curve (-f1 -G2.4) to be horrible on my >10,000:1 GDM-F520 CRT. There gets to be a point where everything has unrealistic contrast, and while dark tones are defined and evenly spaced, they become difficult to be seen unless you are in a pitch black room.

An ambient light scaled BT.709 curve via ArgyllCMS helps compensate for this, in a similar way that sRGB curve does for the PC space. I've heard people say that sRGB shouldn't be calibrated to either, yet if you don't, color management software will change the curve to sRGB anyway on sRGB images. Not exactly same thing for the TV space, but that a lot of content isn't mastered to have natural looking contrast @2.4 Gamma, I still see as a major problem for my subjective viewing experience.

[Stephen R. Savage]

While we are on the subject of gammas, what does calibrating a display to a set gamma with ArgyllCMS do when using the generated 3DLUT (either from yCMS or TI3Parser) with madVR? Also, when using yCMS to generate a 3DLUT, should the GPU gamma ramp be disabled or not?

For example, if the video has 2.2 gamma (for the sake of argument) and you have calibrated your display via ArgyllCMS to 2.4, will madVR then remap the video gamma to your new 2.4 display gamma (hence not changing anything) or will the perceived image have "2.4 gamma" contrast? Do you need to check "enable gamma processing" to see the image with "2.4 gamma"?

[dansrfe]

While we are on the subject of gammas, what does calibrating a display to a set gamma with ArgyllCMS do when using the generated 3DLUT (either from yCMS or TI3Parser) with madVR? Also, when using yCMS to generate a 3DLUT, should the GPU gamma ramp be disabled or not?

For example, if the video has 2.2 gamma (for the sake of argument) and you have calibrated your display via ArgyllCMS to 2.4, will madVR then remap the video gamma to your new 2.4 display gamma (hence not changing anything) or will the perceived image have "2.4 gamma" contrast? Do you need to check "enable gamma processing" to see the image with "2.4 gamma"?

madVR will remap the 2.2 gamma video to 2.4 based on the 3DLUT. The gamma processing option is if you aren't using a 3DLUT.

[Stephen R. Savage]

madVR will remap the 2.2 gamma video to 2.4 based on the 3DLUT. The gamma processing option is if you aren't using a 3DLUT.

I've read in a few places that to properly view images the "correct way", one should reinterpret the Rec709 (approximately "2.2") encoded data as 2.4 without correction. Apparently this is intended to correct for the difference between studio (1000 lux) and regular (4-32 lux) viewing conditions. In this case, would I want gamma processing enabled or not?

[Pat357]

There's something wrong with new madTestPatternSource.
With new version image is broken with any renderer (except madVR), pic (http://firepic.org/images/2013-03/23/abkbo7314h1q.png). With old one everything is ok.
What do you mean by "new madTestPatternSource" ?
I have the feeling that I'm missing something', because my "madTestPatternSource" is dated 09/04/2009, not exactly new i'd say.

I noticed however that the latest MadVR v0.86.1 did not include a "madTestPatternSource.ax", so I still have the one from previous MadVR versions in my directory.

Where is this new "madTestPatternSource.ax" available ?
Was it released as a seperate file ?

Thanks if you could clear this up for me !

[nevcairiel]

Where is this new "madTestPatternSource.ax" available ?
Was it released as a seperate file ?

Look in the first post in this thread.

[6233638]

I'll try out using BT.1886 (-f0 -G2.4) next time I calibrate, but unless it's much different, I've always found using a 2.4 power curve (-f1 -G2.4) to be horrible on my >10,000:1 GDM-F520 CRT. There gets to be a point where everything has unrealistic contrast, and while dark tones are defined and evenly spaced, they become difficult to be seen unless you are in a pitch black room.That sounds like you were calibrated to an average of 2.4, and not 2.40 gamma at every point on the curve. (10% and below are particularly important, and difficult to get right on a CRT)
If your display has more than 10,000:1 contrast, the BT.1886 curve is 2.40 gamma.

I've heard people say that sRGB shouldn't be calibrated to either, yet if you don't, color management software will change the curve to sRGB anyway on sRGB images.I can't think of any professional calibration package that calibrates to the sRGB curve by default - few even offer the sRGB curve as an option. A 2.2 power curve is typical for PC displays.

The sRGB specification (http://www.color.org/srgb.pdf) also defines white at 80cd/m² and black at 1cd/m², giving you a display contrast of 80:1, which looks ridiculous today.

I've read in a few places that to properly view images the "correct way", one should reinterpret the Rec709 (approximately "2.2") encoded data as 2.4 without correction. Apparently this is intended to correct for the difference between studio (1000 lux) and regular (4-32 lux) viewing conditions. In this case, would I want gamma processing enabled or not?

The BT.709 curve is approximately 1.96 gamma, not 2.2 and is "camera gamma" it is not intended to be used on displays. Nothing was specified because CRTs were in use at the time, and they have a native gamma of approximately 2.4 when correctly set up. (at least studio monitors do)

[baii]

Which colorimeter do you have? depending on the model, it may not even work properly for wide gamut.

My personal approach (although may not theoretical correct. It is easy to use)
Argyllcms with dispcalgui - > ti3praser–>madvr gamma depend on the content and my liking.
D65 or 6500k hardly matters unless you have reference grade equipment imo .

[6233638]

D65 or 6500k hardly matters unless you have reference grade equipment imo .Again, CCT is not a specific point, it is a line (http://upload.wikimedia.org/wikipedia/commons/b/ba/PlanckianLocus.png).

D65 has a CCT of 6504K, but not all measurements that read 6504K are D65. You can have a strong green or magenta tint and still measure 6504K.

I suggest evaluating your white balance using dE u'v' values as it will give you the strictest results, and ignores luminance (gamma) errors.

[dansrfe]

Are there any recommendations for beginner calibration guides and advanced calibration guides that I can go to after that? I really want to learn all the ins and outs of calibration but I don't know where to start.

[e-t172]

- You say "use 2.4 if you have high contrast, BT.1886 otherwise". Thing is, BT.1886 uses a gamma function with… 2.4 as the exponent. What's the difference? Is it because the BT.1884 function has "black compensation" (the "+ b" term)? As far as I'm aware, most calibration software (at the very least HCFR) displays black compensated gamma, i.e. when calculating gamma, L' is used with L' = L - L(black). That would mean that, within such software, the "+ b" is already accounted for and thus your target really is 2.4 as calculated by the software.

- Appendix 2 indicates that "This Recommendation does NOT change any signal parameters defined in Recommendation ITU-R BT.709". The way I understand it, this only makes sense assuming that BT.709 defines the optical → electrical transfer function, while BT.1884 defines the electrical → optical transfer function. However, having different transfer functions for "input" and "output" strikes me as odd, as that would mean that when capturing something using an ideal reference camera and then playing it back on an ideal reference monitor, the display will not be consistent with the reality of what has been captured, because of the difference between the transfer functions used for capture and playback. What gives?

Okay, so, thinking about it some more, I arrive at the following conclusions:

- BT.709 very clearly uses the term "opto-electronic conversion", while BT.1886 uses the term "electro-optical transfer function". This does seem to indicate that BT.709 defines the parameters for the capture/transfer side, while BT.1886 defines the parameter for the playback side. I am still unsure why they are different, but I assume there's a good reason.

- BT.1884 describes "black-compensated gamma", which, as far as calibration software and procedures are concerned, is basically what is referred to as simply "gamma". Black-compensated gamma is equal to simple gamma when the display contrast is infinite (e.g. CRT).

- According to BT.1884, the One True Display Gamma©®™ is 2.4.

One very interesting thing is that display gamma being 2.4 and not 2.2, this means it is actually different from the sRGB gamma, which is 2.2 (well, approximately). This brings me to an interesting thought regarding madVR: considering that madVR is running on a Windows PC, the defaults should assume that the display is calibrated for sRGB, which is the standard for this platform, and should by default convert the content from 2.4 to 2.2.

In other words, for maximum compliance with current specifications, madVR should default "the display is calibrated to the following transfer function / gamma" to "pure power curve 2.20" (IIRC it already does), because sRGB, and more importantly, it should default "enable gamma processing" to "enabled, pure power curve 2.40", because BT.1884.

@madshi: I'm advocating a change in the default settings. What do you think of this reasoning?

On a related note, it would be useful to have a "sRGB curve" option under the "calibration" tab. It should be extremely easy to implement as it is exactly the same curve as BT.709 but with different coefficients for the linear part. If this is to be implemented then the default setting would be "sRGB curve 2.40" (as 2.2 is just the pure power curve approximation).

[cyberbeing]

That sounds like you were calibrated to an average of 2.4, and not 2.40 gamma at every point on the curve. (10% and below are particularly important, and difficult to get right on a CRT)
If your display has more than 10,000:1 contrast, the BT.1886 curve is 2.40 gamma.
No I calibrated to a 2.40 gamma curve exactly, verified by plotting the measurements against a reference. The native gamma of this GDM-F520 CRT is very close to a 2.4 gamma power-curve to begin with. I maintain that I subjectively find using a true >=2.4 gamma power-curve as pretty horrible, unless I never intend to watch in any conditions except a completely dark room. If there is any ambient light whatsoever, the human visual system will begin crushing shadow detail, making images appear darker than they actually are and completely unnatural.

From what I've seen, my Panasonic GT50 plasma also naturally ends up with something close to a scaled BT.709 curve, rather than a power-curve, when calibrated to darker gamma.

I can't think of any professional calibration package that calibrates to the sRGB curve by default - few even offer the sRGB curve as an option. A 2.2 power curve is typical for PC displays.
Only basICColor and ArgyllCMS seem to allow calibrating to an sRGB curve directly, but that's not the point. No matter what gamma you calibrate to, using an ICC profile in color managed software like Photoshop will adapt the gamma curve to sRGB when viewing an sRGB image.

[kostik]

Does anyone know if its possible to disable dithering in Lav video decoder?
madVR dither the video so both of them doing dithering add more noise , isn't it?
thanks!

[Qotscha]

I think LAV Video does dithering only when it is needed (e.g. when input is 10-bit and LAV outputs 8-bit). So, when using with madVR, LAV Video does not dither unless you have disabled some output formats in LAV or you have some filters between LAV and madVR which e.g. do not accept 10-bit input.

[iSunrise]

Does anyone know if its possible to disable dithering in Lav video decoder?
madVR dither the video so both of them doing dithering add more noise , isn't it?
thanks!
A quick search on Google for you:

http://forum.doom9.org/showpost.php?p=1562162&postcount=12403

@Qotscha: Yes, madVR should only ever need to dither at the output stage, before all the data is send to the display.

[nevcairiel]

I think LAV Video does dithering only when it is needed (e.g. when input is 10-bit and LAV outputs 8-bit). So, when using with madVR, LAV Video does not dither unless you have disabled some output formats in LAV or you have some filters between LAV and madVR which e.g. do not accept 10-bit input.

This is correct. Dithering in LAV is only performed when the format is converted to a lower bitdepth - if you output 10-bit untouched to madVR, no dithering is ever performed, and if you don't output untouched, you need to dither, otherwise rounding will be used, and that adds banding.

[digitech]

This is correct. Dithering in LAV is only performed when the format is converted to a lower bitdepth - if you output 10-bit untouched to madVR, no dithering is ever performed, and if you don't output untouched, you need to dither, otherwise rounding will be used, and that adds banding.

I have to sacrifice and select don't use dithering in madvr cause i have an acer nvidia ion, what's the disadvantages of doing that as quality concerns Nev? I also has selected use 10 bit croma & image buffer instead of 16 bit in madvr trade quality 4 performance settings.

[Dodgexander]

I have to sacrifice and select don't use dithering in madvr cause i have an acer nvidia ion, what's the disadvantages of doing that as quality concerns Nev? I also has selected use 10 bit croma & image buffer instead of 16 bit in madvr trade quality 4 performance settings.

I would read the first post from Madshi to understand what dithering does.

[Niyawa]

I may have missed something, but is madshi working on something else like commercials again? He's been online and all but no replies.

[dansrfe]

I may have missed something, but is madshi working on something else like commercials again? He's been online and all but no replies.

I think he's busy with commercial work atm. I'm sure he'll re-start development and respond to posts when he has more time.

[Gelatinous]

I may have missed something, but is madshi working on something else like commercials again? He's been online and all but no replies.

Thats usually how it works. madshi will drop lots of new builds in the space of a few months, then will be silent for the next few months. It all depends when he's got free time.

[Niyawa]

I think he's busy with commercial work atm. I'm sure he'll re-start development and respond to posts when he has more time.
I see, he probably just stops by to keep himself updated with the issues and stuff.

Thats usually how it works. madshi will drop lots of new builds in the space of a few months, then will be silent for the next few months. It all depends when he's got free time.
Noticed that, second time that I've seen at least.

Well, I'm holding up my guide update because I want to update madVR together, so I was curious when I could expect him to appear or something along those lines.

[Devrim]

I see, he probably just stops by to keep himself updated with the issues and stuff.


Noticed that, second time that I've seen at least.

Well, I'm holding up my guide update because I want to update madVR together, so I was curious when I could expect him to appear or something along those lines.

I was looking at your madVR scaling algorithms chart and I had a question about the smooth motion.

There are 3 options under smooth motion, what is the best one to pick?

http://kthnxbai.info/PicAyzo/1581a8.png

-edit-

Nevermind, read the rest of you guide, I changed a few more options too :)

[DragonQ]

madshi, do you know why colours aren't in the same place in EVR and MadVR? Is it to do with the fact that chroma subsampling isn't strictly defined in terms of position?

In the example below you can see the coloured text is shifted by a pixel to the left in MadVR compared to EVR. I have no idea which is correct, if there is a "correct".

MadVR (http://www.aotplaza.com/Files/HTPC/Screengrabs/EVR%20Scaling/MPC-HC%20MadVR.png)
EVR (http://www.aotplaza.com/Files/HTPC/Screengrabs/EVR%20Scaling/MPC-HC%20EVR-CP.png)

[nevcairiel]

do you know why colours aren't in the same place in EVR and MadVR? Is it to do with the fact that chroma subsampling isn't strictly defined in terms of position?


There is two commonly used chroma subsampling positions for 4:2:0, the MPEG1 and MPEG2 way, the latter being used by most modern formats.

MPEG1:
http://upload.wikimedia.org/wikipedia/commons/thumb/1/11/Yuvformats420sampling.svg/100px-Yuvformats420sampling.svg.png

MPEG2:
http://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/Yuvformats420samplingMPEG-2.svg/100px-Yuvformats420samplingMPEG-2.svg.png

As you can see from these images, using the wrong position for upsampling can shift the chroma by half a pixel, which results in chroma bleeding over edges.
If in doubt, its usually safe to assume that madVR does it correctly, doubtful that EVR would even be able to distinguish between the two.

[dukey]

You could at least compare the same video frames.

[DragonQ]

You could at least compare the same video frames.
The text doesn't move.

I chose that section initially because it was text (easy to see aliasing) and I had leeway when pressing Print Screen (MediaPortal doesn't do frame stepping).

[kasper93]

The text doesn't move.

Doesn't matter. You need to compare always exactly the same frame.

[DragonQ]

Doesn't matter. You need to compare always exactly the same frame.

You're not the boss of me.

But fine, for the purposes of this comparison I've updated the MadVR image (CTRL+F5 to see it). Oh look, the same thing is visible.

[dansrfe]

Guys, chill out. Everyone is just trying to help each other.

[Niyawa]

Nevermind, read the rest of you guide, I changed a few more options too :)
Well, the chart is still somewhat in a feedback stage. I've been reading some recommendations from other users and I came with this configuration:

http://i.imgur.com/yf5i52w.png

The only thing that really changed was the removal of Linear Light from downscaling in High, since it's really demanding indeed. I'm also using "blending" to make it more easy to understand but I still need to make a version with all the details included in the image. Just don't have the right tools to do it right now in the way I would like to.

[fairchild]

I'm more of a fan of chroma with no AR. I keep going back to the Mid option (chroma: Bicubic75, upscaling: Lanczos3 AR) even though my system is fast enough to run the best settings (Jinc 3 AR). Also don't run FRC since I want as pure of a signal as possible. (hence no AR on chroma, which is perfect for Blu-ray, and AR on upscaling for non 1080p content).

[Asmodian]

Niyawa don't listen to fairchild, I really like your table. :cool:

But I am sure it isn't optimal for everyone, there is a reason we have all the options we do.

[Keiyakusha]

Well, the chart is still somewhat in a feedback stage. I've been reading some recommendations from other users and I came with this configuration

Personally I use Jinc3taps AR for everything so I can't say about other options, but just wanted to comment on Smooth motion option.
I watch anime mostly (like 99% of everything that I watch offline and 95% of what I watch in general), where the difference between frames is often huge even if its not a scene change. And I find smooth motion to look very ugly. I can easily see where it occurs. However without it I can't tell the difference, can't tell that something wrong even if some frames get dropped due to video/display framerate mismatch or whatever.
Maybe I set up something wrong or something, but as I said for me everything looks fine even without this option, so I don't want to invest a time to check this. I just want you to check whatever this option really that useful before recommending it to someone, especially if its many people. Just because this option is there and some people in this thread use it, it doesn't means that it should be used by everyone.

[nevcairiel]

I agree, smooth motion isn't something that should be directly tied to a quality level table, its quite separate from that (and doesn't eat all that much performance to matter), and more importantly, some people don't even see the 3:2 judder (like most people who have seen this most of their life on NTSC TVs), but maybe would see the extra blur and artifacts it adds.

[truexfan81]

Well, the chart is still somewhat in a feedback stage. I've been reading some recommendations from other users and I came with this configuration:

http://i.imgur.com/yf5i52w.png

The only thing that really changed was the removal of Linear Light from downscaling in High, since it's really demanding indeed. I'm also using "blending" to make it more easy to understand but I still need to make a version with all the details included in the image. Just don't have the right tools to do it right now in the way I would like to.

just curious, is there ever a good time to use soft cubic? i notice its not on your chart anywhere

[Asmodian]

I also agree, smooth motion is not for everyone. I must admit I have never tried smooth motion as I use a 120 Hz display or a 24/60 Hz TV with Reclock so I cannot comment on it.

I was only thinking about resize settings when I endorsed said table. :p

just curious, is there ever a good time to use soft cubic? i notice its not on your chart anywhere

Anytime you like it more. ;)
Some have reported they like it, I would assume instead of non-AR Bicubic 75 or Lanczos 3.

[truexfan81]

I also agree, smooth motion is not for everyone. I must admit I have never tried smooth motion as I use a 120 Hz display or a 24/60 Hz TV with Reclock so I cannot comment on it.

I was only thinking about resize settings when I endorsed said table. :p



Anytime you like it more. ;)
Some have reported they like it, I would assume instead of non-AR Bicubic 75 or Lanczos 3.

i actually like softcubic better for chroma

[dbcooper]

Niyawa, are the settings in your chart optimised specifically for Anime or for general viewing?