madVR - high quality video renderer (GPU assisted)

[feisty2]

Originally Posted by madshi

Remove the distance weighting of which Bilateral algorithm? The one in madVR/MPDN? Or do you mean some Bilateral algo in AviSynth/VapourSynth? Thanks...

well... not sure, as long as the weighting function is the same and it should just work theoretically...
according to the doc of KNLMeansCL, the function (wmode=1) is called "Leclerc weighting function", the one also used in TNLMeans

[madshi]

Originally Posted by Manni

Exactly, although I wouldn't necessarily restrict it to a user mode, it could be a factory preset as well (maybe that's what you meant, not sure how MadVR refers to user modes, if it's by number or by name).

For example, the correct mode for HDR playback in the X7000 is cinema2, which calls up a P3 calibration with the P3 filter and PQ gamma. This of course doesn't apply when MadVR is doing the conversion to SDR, but it would apply in the future if/when we have the option to passthrough the HDR data/metadata untouched to the display.

The idea would be that selecting "cinema2" or "user1" or "standard" with IP control would allow the user to bring in the correct baseline with all the relevant settings (lamp mode, iris setting, filter or not, gamma curve etc and baseline calibration on which the corresponding 3D LUT should be applied) automatically, instead of having to select the user mode manually.

So in my example, and with the current implementation, it would look like this:

rec-709 3D LUT -> select user1 (rec-709 baseline) in the PJ with IP Control
smpte-c 3D LUT -> select user1 (rec-709 baseline)
PAL 3D LUT -> select user1 (rec-709 baseline)
P3 3D LUT -> select user2 (P3 baseline)
rec2020 3D LUT -> select user3 (rec2020 baseline)

Ok. Well, maybe something to look at in some future version, but probably not any time soon.

Originally Posted by Manni

Also if there is a rec2020 3D LUT, would you consider not converting rec2020 content to P3?

Simply configure madVR to "this display is already calibrated to BT.2020".

Originally Posted by feisty2

well... not sure, as long as the weighting function is the same and it should just work theoretically...
according to the doc of KNLMeansCL, the function (wmode=1) is called "Leclerc weighting function", the one also used in TNLMeans

Ok, but which KNLMeans/Bilateral code should I use as the base for my implementation then? I don't have the time/resources to implement one myself from ground up atm, so I need some C++ (or other) code to look at. And legally, it can't be GPL... Oh well, I guess if I look at some code just to understand the algorithm, and then totally write it new from scratch in HLSL/OpenCL/whatever, legally that should probably be alright, I suppose.

[feisty2]

https://github.com/VFR-maniac/VapourSynth-TNLMeans
okay, this one is LGPL

[madshi]

Sounds good, thanks. So that one would produce exactly the same output/quality?

[Manni]

Originally Posted by madshi

Ok. Well, maybe something to look at in some future version, but probably not any time soon.

No problem, I agree it's not a priority at this stage, thanks for considering it.

Originally Posted by madshi

Simply configure madVR to "this display is already calibrated to BT.2020".

Thanks.

1) Where is this option? I've probably missed it, but I've never seen it.

2) Will this allow to use a rec-709 calibration for rec-709, PAL and SMPTE-C, a P3 calibration for P3 and a rec2020 calibration for rec2020? Or will it force us to use the same baseline for all calibrations?

[feisty2]

Originally Posted by madshi

Sounds good, thanks. So that one would produce exactly the same output/quality?

KNLMeansCL was initially an OpenCL version of TNLMeans, so I guess yeah,
parameters used in chromareconstructor:
ax=ay= radius
az=0
sx=sy=bx=by=0
a=1.0
h=str
ssd=1
"rclip" (external clip as the weighting reference) wasn't implemented in TNLMeans, guess you have to do that by yourself, but it should be pretty easy..

[huhn]

Originally Posted by madshi

That is with forced film mode disabled, right? If the decoder says it's 30fps then madVR treats it as such, if forced film mode is disabled. I cannot possibly know whether it's a reliable soft telecine video file or not. It might be. Then I could switch to 23p and enable smooth motion. But it could also be true 30p, or 60i, or the video could switch back and forth between 23p, 30p and 60i all the time in the middle of the movie.

Files like this is what the "if in doubt activate deinterlacing" setting is meant for. Usually that setting activates deinterlacing for files like this, which is probably the right solution.

wouldn't IVTC fail in this case too?

ok it could kind of survive 30p. are the informations from media info unreliable or unaccessible?

can madVR always read the repeat flag and act different when they are found? like enabling smoothmotion.

so every case that is not interlaced is not harmed by this.

[nevcairiel]

Originally Posted by Manni

2) Will this allow to use a rec-709 calibration for rec-709, PAL and SMPTE-C, a P3 calibration for P3 and a rec2020 calibration for rec2020? Or will it force us to use the same baseline for all calibrations?

Profiles!

[mark0077]

Hi all, maybe this is already well known, but I thought I would mention it. I was noticing ~3ms rendering times when the mpc-be window was at any size but not maximised. After maximised (non exclusive mode), the rendering times were around 16ms. Exclusive mode fixed this and brought it back to ~3ms but without exclusive mode, using the "use Direct3D 11 for presentation" option also brings rendering times down to 3ms in non exclusive mode. I can't remember seeing this checkbox having such a big impact on rendering times when I tested before but now I'm using Windows 10 so maybe that made the difference.

Just thought it was worth mentioning anyways for those not using fullscreen exclusive mode. I'm using GTX 980 in Windows 10.

[huhn]

have you checked the GPU powerstate?

rendertiems aren't reliable without GPU powerstate.

[mark0077]

According to nvidia inspector its staying in state P2 regardless of this checkbox.

[Manni]

Originally Posted by nevcairiel

Profiles!

If I could find the option, maybe

[ibius]

devices -> "device name" -> calibration

[Manni]

Originally Posted by madshi

Simply configure madVR to "this display is already calibrated to BT.2020".

Originally Posted by ibius

devices -> "device name" -> calibration

Thanks, that's where I would have looked first, but there is no such option there (or anywhere that I can see):

At least not for my display.

[ibius]

Originally Posted by Manni

Thanks, that's where I would have looked first, but there is no such option there (or anywhere that I can see):

At least not for my display.

Em, what options do you get on that page?

You don't see "this display is already calibrated"?

[Manni]

Originally Posted by ibius

Em, what options do you get on that page?

You don't see "this display is already calibrated"?

Sure, I see this option, but how does this help? It disables all the 3D LUTs, so it would only work if I wanted to select a display mode with a native rec2020 calibration and no 3D LUT with MadVR, which isn't what I'm trying to do.

What I'm trying to do is to be able to get MadVR not to convert rec2020 content to P3 when there is a rec2020 3D LUT.

This is why I didn't understand Madshi's answer to my question, as I don't see an option that allows you to select "this display is already calibrated to rec2020" when using a rec2020 3D LUT.

[aufkrawall]

Originally Posted by mark0077

Just thought it was worth mentioning anyways for those not using fullscreen exclusive mode. I'm using GTX 980 in Windows 10.

Those statistics can be deceiving, there shouldn't be any real performance difference between D3D9 or 11 path.
The differences in overhead or whatever between the APIs are neglectable compared to shader run times.
When GPU load gets a little too high, I get dropped frames, no matter if D3D9 or 11. Got a 980 and Win 10 as well.

[huhn]

Originally Posted by mark0077

According to nvidia inspector its staying in state P2 regardless of this checkbox.

try GPU-z

[aufkrawall]

It will say the same. What's interesting is not the used power state but the actual clocks.

[Warner306]

Originally Posted by madshi

Can you show a screenshot where the ringing is visible? Ideally a short video sample with which I could reproduce it? Improving the sharpening anti-ringing filter is on my to do list, but it's not too easy. We want to supress the ringing, but we want to allow sharpening, too. If I make the anti-ringing filter too strict, I might also remove some valid sharpening.

I don't have any screenshots showing excess ringing with sharpen edges. My concerns with sharpen edges relate mostly to watching uncompressed 1080p Blu-rays on a 1080p display. The "shimmer" effect during scenes of motion is due to the aggressive and obvious edge enhancement of this sharpener. I am sure this is lessened considerably when sharpen edges is applied instead from upscaling refinement.

Let me clarify. I currently use image sharpening with all profiles to keep the appearance of the image consistent:

• SD -> 1080p (crispen edges (1.0), SuperRes (3))
• 720p -> 1080p (SuperRes (1))
• 1080p -> 1080p (sharpen edges (0.5))

The 1080p profile is where madVR begins to look inconsistent. SuperRes is the primary image sharpener on other profiles. Not only does SuperRes produce less aggressive edges; it also looks much better in motion. Normally I don't like crispen edges because it alters image brightness. But I find it is not offensive at a 2x scaling factor and actually blends very well with SuperRes, which can look bloated at high values, and crispen edges helps with this.

So, for the 1080p profile, I am left using small values of image enhancements to match the look of the other profiles. Of the bunch, I prefer sharpen edges, but it is very harsh (almost clinical) when applied to 1080p Blu-ray rips. Even at small values, the haloing around objects, which can be a combination of fattened lines and/or ringing is sometimes distracting. The sharper the Blu-ray, the more distracting the ringing can be. If you could tame the edges, even slightly, this would be my prefered sharpener. I know crispen edges is available, but I find it changes the brightness of the image in unwanted ways.

An even better solution than improving sharpen edges would be to introduce an image enhancement that looks similar to SuperRes. Also, perhaps the sharpening anti-ringing filter needs to be more aggressive with image enhancements?