madVR - high quality video renderer (GPU assisted)

[Asmodian]

There is no best but I do like Jinc + anti-ring though it keeps my GTX 680 a lot more active.

Bicubic doesn't ring (much?), it's problem is more with aliasing.

[NicolasRobidoux]

Originally Posted by madshi

Is this new stuff different to your original idea to stretch the S curve to cover the extended value range? Is the curve still a perfectly symmetrical S curve? Or does the curve have a somewhat different form now?

The curve is still a perfectly symmetrical S curve over the interval [A,B], not over [0,1], unless -A=B-1. So, I believe the answer to the first question is "no", the answer to the second is "yes, but maybe not the way you understand it", and to the third, "no, in a sense, but also yes, in a sense".
Although this is different than the sigmoidization I've used, I think that actually this may work better than any other fix because of the fact that conversion from Y'CbCr over and undershoots when converted to linear RGB.
I really do. I don't want to go into a big lecture as to why, because the proof (or disproof) will be in the pudding.
However, I'll also do the math for the fix that extends the S in a straight line past [0,1], in case you want to try that too. That would be my "second best fix".
I really really don't like the mirroring solution.

[cyberbeing]

NVIDIA pushed out new WHQL drivers supporting all cards yesterday.

306.97 WHQL English (WinVista/Win7/Win8 x64)
306.97 WHQL International (WinVista/Win7/Win8 x64)

306.97 WHQL English (WinVista/Win7/Win8 x86)
306.97 WHQL International (WinVista/Win7/Win8 x86)

306.81 WHQL English (WinXP x86)
306.81 WHQL International (WinXP x86)

[6233638]

Originally Posted by Asmodian

I don't agree with the poster named "6233628" (I think the choice for chroma is also just a recommendation) but they do offer good examples. Note these are worst case examples that show the issues with softcubic that 6233628 doesn't like.

I still maintain that there's not much to choose from with Chroma. The purpose of Chroma upsampling is only to get the best match to the Luma image, and it is always 2x scaling. You don't use Chroma upsampling to tailor the look of the image to your personal preference the way you might decide to use a softer/sharper Luma algorithm depending on your preference for sharpness, tolerance for ringing/aliasing etc.

If you use a chroma algorithm that is too soft, colour bleeds out the edges of objects, and the brightness/saturation is reduced. (particularly with finer details) If you use one that is too sharp, objects can be brighter than they should be, and ringing becomes a problem. I've still never seen a sample from anyone using SoftCubic for Chroma that actually shows it to be beneficial, and I must say that I find it extremely rare for aliasing to be a problem with chroma. (at least using an algorithm that suffers from aliasing, nothing will fix it if it's a part of the source)


I've actually been doing testing again recently due to the introduction of the anti-ringing filter. (and actually, have reviewed it a couple of times in the past - I don't think the post you linked to was the most up-to-date)
I didn't really want to post anything yet though, because I haven't had the time to really look into it yet, and there has been a lot of interesting discussion regarding the scaling algorithms recently. (and technical discussion that is beyond me - my choices are based on observations and measurements from the final scaled images)
It sounds like there could be some interesting developments in the near future, which I didn't want to detract from, nor did I want to write up a big post that could be outdated pretty quickly.

For what it's worth though, the anti-ringing filter has noticeably changed the results - I'm actually quite liking Lanczos 3 with it so far with all the samples I've tried, but that is from very incomplete testing. I'm quite sure there will be samples where Lanczos is too sharp, and that I just haven't run into them yet.
I don't know that I'm a fan of Jinc for Chroma though. There has only been one sample I've tried where it has looked best, and there were some noticeable drawbacks.

[trip_let]

I know that the focus right now is on greater things, but can anybody else check and confirm? MadVR does not work when the player is on a monitor in portrait mode for me (I've tried in previous versions as well as the most recent one, with MPC-HC; using Mobility Radeon HD 3650).

Seems like there have been a couple previous posts in this thread about this issue, but I did not find any resolution:

Originally Posted by Seegs108

Okay, I'm using MadVR v0.74. I notice that when I use it in conjunction with MPC-HC and the latest version of FFDShow when I try to open a videoon or drag it to my portrait monitor MPC-HC freezes and forces me to end the process in the Task Manager (windows 7 and amd 6950 if that matters). Here's how it's set up:

http://img683.imageshack.us/img683/7114/madvr.png
[removed image tags so it doesn't hog the page]

Everything works fine when switching to EVR Custom. I don't know if there is something wrong on my end but it seems that this version has an issue rendering a file on a portrait set display.

Anyone else have this issue?

Originally Posted by nuhi

madshi, when you get to it please check if it's possible to make madvr work with the native Nvidia Rotation from the driver.
Basically how to reproduce the issue is to right-click Desktop, go to Nvidia Control Panel, Rotate Display, and pick e.g. Portrait (flipped).
Then when playing with madvr the picture is just black, sound is ok.
Thanks.

For me, it doesn't crash. The screen is just black, and it doesn't play. If a video is playing on another monitor and is dragged to one in portrait, it will go black and pause the video without crashing. So there's no sound for me either. Playback can resume if the player is moved back to a landscape-orientation monitor. Likewise for me, it works with the other MPC-HC renderers, just not with MadVR.

Portrait / landscape can be set in AMD / Nvidia control panels or Windows "screen resolution" page.

To be honest, I actually have some 256 x 384 content that could really use some high-quality upscaling to 1080 x 1620 size on a 1080p monitor. Well, having normal 4:3 / 16:9 content also work would be nice too, for whenever my main monitor is set to portrait (of course, changing the orientation and physically rotating the thing does not take more than half a minute, but still...).

[sunnah]

Originally Posted by Asmodian

Here is a big discussion about chroma scaling from this thread. It offers lots of different reasons for different resizers but there really isn't a "correct" answer. There are trade-offs for any option. That said I have been impressed by the new options being worked on, if you have the GPU to handle them.
:

Yes I have a really High-End GPU, I just want to use the most efficient option that's available. But as madshi already said: most taps doesn't mean directly being the best. (because of the added ringing even with anti-ringing) Altough the anti-ringing option is a true blessing in madvr now

Originally Posted by Asmodian

There is no best but I do like Jinc + anti-ring though it keeps my GTX 680 a lot more active.

Bicubic doesn't ring (much?), it's problem is more with aliasing.

I think we should encourage people more to go after their own taste. I personally like Jinc 4 taps + anti ringing, 8 taps is a little too much ringing in my opinion. The sharpness difference between the two is almost forgetable. If some people are doubting look for the less ringing option. And of course you have to look at your GPU too.

[Asmodian]

Originally Posted by sunnah

I think we should encourage people more to go after their own taste. I personally like Jinc 4 taps + anti ringing, 8 taps is a little too much ringing in my opinion.

True, and that is what I am using too.
tbh, Jinc 8 taps + anti-ring is too much for my video card (GTX 680) doing 720p/1080p -> 2560x1440.

Originally Posted by 6233638

I still maintain that there's not much to choose from with Chroma.

I did take your advice and try bicubic 75 and Mitchell-Netravali. I liked them and used bicubic 75 until recently, trying 3 tap Jinc + anti-ring for chroma now. I am just not convinced there is really a correct method.

[ajp_anton]

Nicolas &... um... Mathias? =)
If the curve only is defined in [0,1], then I don't see the problem with clipping. Introducing a new curve for out-of-range values seems kind of arbitrary, and there's the convex/concave problem.
Of course, I'm no expert on this, and I haven't even tried it myself. But it "feels" better to just extend the [0,1] input range to cover all possible values. Would that make it look weird? Or just clip it =).

[ryrynz]

Originally Posted by ajp_anton

Nicolas &... um... Mathias? =)

LOL, hey now.. He's Madshi to us. Maybe when you reach NicolasRobidoux's level you can get away with being on a first name basis

[NicolasRobidoux]

The issue is where the BTB and WTW come from, and what is done with them.
Which I don't fully understand, so I have to go with my guts.
-----
When solving real world problems, math should shadow the world, not the other way around.
Cows are not spheres, (ir)regardless of how elegant the proof becomes with this assumption.

The Grand Poobah of Postmodern Mathematics and Other Fuzzy Religions

P.S. The sigmoid curve is a tool, not a prescription. Once you (meaning me) have decided that the way to deal with over and undershoots is more or less to stretch things exponentially near gamut extremes, it's a way of piecing two exponential curves smoothly given that one of them is upside down.
Maybe piecing two gamma curves or other power laws would be better. Actually, I may have to try just that: Symmetrize a pair of gamma curves.
Or something that evenly spreads over and undershoots computed explicitly from the filter kernel. (Numerical math nightmare.)
Maybe. But the sigmoid curve seems to work well. Better than a few others I quickly tried. Probably cluelessly.

[Blight]

madshi:
I'm investigating the option to port some of ZP's MadVR OSD rendering to add side-by-side 3D support.
So far, other than a negligible CPU overhead, it seems to quite easy to implement.
The question is, wouldn't it be better to do it on the renderer rather than the player?

Here's what I'm experimenting with (not sure it's the best approach, as I lack the 3D hardware for testing):
I took the OSD image, made sure its width is mod 2 (to simplify things) and then what I do is this:
I split the source image into two by taking every alternating vertical column of pixels, one column for the left eye and the next for the right-eye and splitting the source images into a left/right eye images.
Then I half the X-Offset to compensate for the left/right scaling being performed on the target device and place the left image.
For the right-eye image, I add half the video's width and half of the x-offset.

Here's how it looks like:


What do you think?

P.S.
I noticed in the OSD API's code there is an option to define a 'left' and 'right' bitmap for 3D.
Does this code do anything or is it just a place holder for now?

[6233638]

Originally Posted by Asmodian

I did take your advice and try bicubic 75 and Mitchell-Netravali. I liked them and used bicubic 75 until recently, trying 3 tap Jinc + anti-ring for chroma now. I am just not convinced there is really a correct method.

I can find several examples where Jinc is a bad choice for Chroma. I don't recommend it.

Now that we have the anti-ringing filter for Chroma, I don't think Mitchell-Netravali is the best choice, as its main benefit was a lack of ringing, at the expense of other areas of image quality. As I said, the anti-ringing filter changes things.

[NicolasRobidoux]

This is in a different thread than what has been talked about, but if you wanted something a) cheap b) without ringing c) reasonably smooth, even when upsampling, then I would recommend tensor quadratic B-spline smoothing.
The footprint of the filter is really really tight: It's a square with width = 3 (compare to 4 with all the bicubics).
What this scheme is: The (archetypal, meaning lost) "middle child" in the B-spline family, which goes like this: box filtering (width=1), bilinear (width=2), quadratic B-spline smoothing (width=3), cubic B-spline smoothing (width=4).
It's basically for someone who likes the standard cubic B-spline smoothing but can't stand the blurriness. The quadratic version is sharper a nudge, without introducing the "ridges" that bilinear brings to the table..
-----
But then I don't really know what video people are after, in luma or chroma.

[Blight]

One other thing I forgot,
It seems that the latest builds are slower at existing FSE compared to v0.82.5
This is most evident when opening ZP's fullscreen navigation interfaces, it takes probably 200-300ms longer for the navigation GUI to appear.

[NicolasRobidoux]

Originally Posted by 6233638

I can find several examples where Jinc is a bad choice for Chroma. I don't recommend it.

Interesting. I'd love to understand why.

[madshi]

Originally Posted by NicolasRobidoux

The curve is still a perfectly symmetrical S curve over the interval [A,B], not over [0,1], unless -A=B-1. So, I believe the answer to the first question is "no", the answer to the second is "yes, but maybe not the way you understand it", and to the third, "no, in a sense, but also yes, in a sense".
Although this is different than the sigmoidization I've used, I think that actually this may work better than any other fix because of the fact that conversion from Y'CbCr over and undershoots when converted to linear RGB.
I really do. I don't want to go into a big lecture as to why, because the proof (or disproof) will be in the pudding.
However, I'll also do the math for the fix that extends the S in a straight line past [0,1], in case you want to try that too. That would be my "second best fix".
I really really don't like the mirroring solution.

Thank you. I've now implemented your sigmoid function "stretching" and it seems to work well, from what I can see.

However, after testing the new sigmoidized jinc on a few sample clips I found that I had to dial the contrast down from 11.5 to 7.5 to avoid problems and even then I'm finding that there's an improvement in some situations and things get worse in other situations. So I'm not really sure right now if sigmoidization is a good idea for video playback.

For photo editing the situation is a bit different: There having a slider to play with is a great thing. For some images it improves the quality, and if it doesn't, you simply dial it down. However, a movie has tons of different scenes, some of which may benefit from sigmoidization and other scenes may get worse instead. I'm not really sure if that's an option I should offer. I'd like to offer options which in 99% of all cases at least don't make things worse. So right now I'm not sure if I'm going to offer sigmoidization as an option in future madVR builds. But I haven't fully decoded yet. Any thoughts on this?

FWIW, it seems to be a good contrast algorithm, so it will come in handy when at some point in the future I'll add contrast/brightness/color controls to madVR. So even if I don't use it for resampling, the work we've done on it wasn't in vain in any case.

Originally Posted by trip_let

I know that the focus right now is on greater things, but can anybody else check and confirm? MadVR does not work when the player is on a monitor in portrait mode for me

Portrait mode is currently not supported. It's on my (very long) to do list.

Originally Posted by ryrynz

LOL, hey now.. He's Madshi to us. Maybe when you reach NicolasRobidoux's level you can get away with being on a first name basis

I don't care if you guys call me madshi or Mathias or Karl-Heinz-Otto, as long as I know who you mean.

Originally Posted by Blight

I noticed in the OSD API's code there is an option to define a 'left' and 'right' bitmap for 3D.
Does this code does anything or is it just a place holder for now?

Currently it doesn't do anything. The "right" bitmap is simply ignored. It's a placeholder for the future.

[NicolasRobidoux]

Mathias:
If I have time (probably not), I'll have to think about the consequences of 4:2:0 w.r.t. to filter choice.
-----
What I'm focusing on now is Y'CbCr, which in my understanding is the origin of the BTB and WTW in R'G'B' and linear RGB. (Almost always Y'CbCr is the "anchor" space, yes?)
While I put together the "straight line extensions" pseudocode, could you please try the following if you have a minute, and tell me how it looks:
Use sigmoidization on Y'CbCr values unmodified. No conversion to R'G'B' or RGB. Straight up.
Maybe I'm off my rocker, but in practice this may actually work well. I don't want to go into a discussion of why I think so: If it sucks, my dirty heuristics don't matter. Part of it is that I'd really like to apply sigmoidization to a luminance or luma channel, and at this point I'm willing to pay the price of not sigmoidizing in linear light, which may or may not be the best for human viewers anyway.
P.S. I'll try to wrap this up quickly. I realize that most likely you need to move on.

[NicolasRobidoux]

Originally Posted by madshi

...
However, after testing the new sigmoidized jinc on a few sample clips I found that I had to dial the contrast down from 11.5 to 7.5 to avoid problems and even then I'm finding that there's an improvement in some situations and things get worse in other situations. So I'm not really sure right now if sigmoidization is a good idea for video playback...

I had not read yours before writing my latest.
-----
So, you discovered "the safe contrast value business".
Honestly, even 7.5 is a bit on the "showy" side.
It it was not that I want things to look noticealy better than enlarging straight through sRGB most of the time, I'd have set the recommended value lower than 7.5. At 7, or 6.5, or even 5, 4, or 3. But then you can ask: Worth it?
-----
So: No offense taken, truly.
However, please quickly document what you try or tried and what "bugged you".
-----
Should I put together the "straight line hair extensions" pseudo code, or just let it go?

[NicolasRobidoux]

Karl-Heinz-Otto:
My thought:
Put sigmoidization out there with a request for comments, after having settled yourself on a value that seems to almost never do harm. (6.5?)
Bad comments -> Bye.

[NicolasRobidoux]

KHO:

Another thing:

If you are willing to use low constrast, there comes a point where the
WTW values are fine without modifying the sigmoidal function. (The
BTB, really, are not an issue.)

That is, you can use the formulation with A=0 and B=1 (which
simplifies things a bit) and the atanh will not over or underflow ever
without any ifs or buts.

If I use that the largest WTW is 1.2143440435408780674380747705496
(this is the value you posted), you can use the "[0,1]" sigmoidal
(which is perfectly symmetrical w.r.t. black and white interchange) in
linear RGB safely as long as the contrast value a is STRICTLY LESS
than 2.4173259816672438931 (you may want to push this down a fudge).

Of course, the question arises as to whether this noticeably improves
things.

Interestingly, when sigmoidal-contrast (in ImageMagick) is actually used
to increase the contrast by modifying the color histogram (which
sigmoidization does not do ... much), contrast = 3 is considered to be
about as far as one should push things. But this is a different context.

P.S. I suck. Algebra mistake. Fixing.