madVR - high quality video renderer (GPU assisted)

Sorry, should have read replies above before asking this!

[luk008]

In my opinion, super-xbr is the best option for chroma upscale. For image doubling, NNEDI3 is better for 32 or more neurons.

[madshi]

So here comes an improved image comparison for super-xbr:

clown - downscaled with lanczos (?) - heavy ringing artifacts:
unscaled original - - | - - super-xbr original AR - - | - - super-xbr no AR - - | - - super-xbr madVR AR

clown - downscaled with bilinear (?) - no ringing artifacts:
unscaled original - - | - - super-xbr original AR - - | - - super-xbr no AR - - | - - super-xbr madVR AR

"original AR": This is a very strict AR algorithm written by Hyllian. It removes almost all ringing that isn't in the source. Sounds good, but sometimes ringing is helpful!
"no AR": This is super-xbr without any AR. This adds noticeable ringing, of course.
"madVR AR": This is a selective AR algorithm which tries to surpress unwanted ringing, while keeping helpful ringing.

If you look at the 2nd set of images, you should see that both AR algorithms remove most of the ringing and that super-xbr itself doesn't really ring much at all if the source is clean. It *does* sharpen=increase ringing that is already in the source, though.

You can also directly compare Hyllian's fast and agressive AR algorithm to the (slower and more complicated) one madVR uses. Hyllian's algorithm is better for comic style video games, but I believe mine's better for photos and movies.

Thoughts?

[madshi]

Originally Posted by Hyllian

It's quite simple. In each pass there are only two calls to sinc function. They're called to return the weights necessary to the filter. The var 'w' recieves the weights. So, what you have to do to test other filters is to replace the sinc call by other weight calls or coefficients. For example, using those cubic coefficients, firstly you need to comment the sinc calls:

//float4 w = sinc(nb*s2, w5);

//w = sinc(nb, w8);

And put the new cubic weights directly:

float4 w = float4(-1.0/16.0, 9.0/16.0, 9.0/16.0, -1.0/16.0);
//float4 w = sinc(nb*s2, w5);

//w = sinc(nb, w8);

And that's it!

It works for any filter, even bilinear!

obs: it isn't totally accurate to use the same cubic coeffs to replace the second sinc call, though. For a totally accurate replacement, you should create a cubic function with the cubic calculations as in other cubic filters elsewhere. This I don't have at hand.

Thanks! So I can replace the first call with the fixed coefficients, and should ideally replace the second call with a calculation, right? What meaning do "nb" and "w8" have in the second sinc call? Which of them is the "distance" I would usually use for such a cubic coefficient function?

Originally Posted by XMonarchY

So Super-XBR is superior to NNEDI3 for both Chroma Upscaling and Chroma/Luma Image Doubling?

Who said anything like that? You may want to re-read my posts, starting with the v0.88.12 release post.

[MS-DOS]

Originally Posted by madshi

Thoughts?

I agree with you on this one. MadVR AR removes a notable ringing without harming the overall quality\removing details which the original one does.

[kasper93]

"madVR AR" seems to produce different colors in lanczos version. And I agree that "original AR" little bit too aggressive. MadVR's AR seems to be nicely balanced.

[Hyllian]

Originally Posted by madshi

Thanks! So I can replace the first call with the fixed coefficients, and should ideally replace the second call with a calculation, right? What meaning do "nb" and "w8" have in the second sinc call? Which of them is the "distance" I would usually use for such a cubic coefficient function?

Yes, though for a first approximation, you should replace both sinc calls by those cubic coeffs. nb = neighbors and w8 is a empirical value I found, it's just a phase coeff input for the sinc function. There are two phase coeffs empirically found by me and I call them w5 and w8. If you see, they're just constants.

[aufkrawall]

Is super-xbr done via OpenCL? It seems so to me, Nvidia driver enters CUDA power state.

[madshi]

Originally Posted by MS-DOS

I agree with you on this one. MadVR AR removes a notable ringing without harming the overall quality\removing details which the original one does.

Thanks. It's the same general concept used for Bicubic/Lanczos/JincAR.

Originally Posted by kasper93

"madVR AR" seems to produce different colors in lanczos version. And I agree that "original AR" little bit too aggressive. MadVR's AR seems to be nicely balanced.

Thanks. Hmmmm... Both AR algos work on R, G and B separately. Which means that if AR becomes effective for only one or two channels, there can be color artifacts. Maybe I should do the AR in YCbCr? That might improve the situation. But it would be slower again than what we have now. The same general problem also applies to BicubicAR, LanczosAR, JincAR etc, btw.

Originally Posted by Hyllian

Yes, though for a first approximation, you should replace both sinc calls by those cubic coeffs. nb = neighbors and w8 is a empirical value I found, it's just a phase coeff input for the sinc function. There are two phase coeffs empirically found by me and I call them w5 and w8. If you see, they're just constants.

Ok, thanks, will try that. But my weekend is over now, so it'll have to wait for next weekend.

Originally Posted by aufkrawall

Is super-xbr done via OpenCL? It seems so to me, Nvidia driver enters CUDA power state.

Nope, simple D3D9 HLSL pixel shaders.

[RainyDog]

Great work madshi

Need to do some proper IQ tests but first impression is that I do like being able to run the full suite of super-xbr options (luma and chroma doubling, plus chroma upscaling) with less than 8ms render times.

[aufkrawall]

Originally Posted by madshi

Nope, simple D3D9 HLSL pixel shaders.

That's great! So now AMD users now have good alternative to NNEDI3, combined with SuperRes.

Originally Posted by madshi

I don't know, maybe the DirectCompute compiler didn't optimize the code as well as the OpenCL compiler did? Or maybe I was too stupid to write well optimized DirectCompute code? I tried to directly convert the OpenCL kernel to DirectCompute, and while it produced correct image output, it was very slow. Could very well have been my fault, for all I know.

Well, someone else couldn't make it fast with DirectCompute neither (you don't want me to explain this more in detail ).

I just compared the same clip in WMP vs. madVR and I have to say that without FineSharp or LumaSharpen madVR (best quality settings) does make the image so soft that some people may dislike it and prefer playback via WMP simply due to sharpness, especially if you sit close to your display. LumaSharpen changes that.

Have any tests shown whether LumaSharpen adds more ringing than FineSharp?

[iSunrise]

Originally Posted by madshi

I will not reply to this post of yours, unless you reply to my earlier posts first. I've written detailed replies to most of your previous FineSharp LL related posts, and so far you've decided to not comment on any of that at all. I can only hope that you've simply missed my posts?

Yes, I missed it indeed. As I said, you are way too fast with changes, extremely hard to keep up.

To your questions:

1) All my examples are done in image enhancements, under the processing tab (so before upscaling). This is because all the algorithms will be applied before upscaling, which shows me the differences a lot more clearly.

2) Regarding the thinning under upscaling refinement, I agree, lower strengths are also advantageous here, I would say thinning should be between 0.020 and 0.035, not higher. I definitely had some strange artefacts appear with a setting of 0.100 on my first samples I posted, therefore I would not recommend them.

3) Thanks for fixing the bug so fast, really appreciated.

4) Regarding your question, which image looks subjectively better, it's pretty clear for me and I invested quite a lot of time to be sure. I think if you take a look at my enhanced screenshots, you will agree.

5) The brightness you see is exactly what a sharpener does if you use way too high strengths, that's why I was absolutely against too high values. Like I wrote before, a good sharpener enhances fine details and by looking at your shots, no LL does exactly represent what I would expect, instead of masking and darkening the result. A sharpener should in an optimal case never do anything else than to sharpen. Your shots all look more accurate from a sharpener point if view with no LL, as do the squirrel shots. The other two examples you provided (the dark ones) are all masking the weird blackness mask that the LL enabled finesharp introduces. This is not the case with the no LL finesharp. The no LL finesharp is a lot more accurate even at higher strengths, so if we might settle on values like 0.5, 1.0 and 2.0, then I think everyone should be equally happy. I prefer mild sharpening, while others will like a higher setting,

If you need further tests, I can do them, but I think when you look at the enhanced squirrel, you will see the heavy artefacting that I am speaking of.

[cyberscott]

Originally Posted by madshi

http://madshi.net/madVR.zip

[code]madVR v0.88.12

* added workaround for one more cause of queues not filling in D3D11 FSE mode

madasihi,

My "present queue" fill beyond 4 now. I set the present queue to 12 and I'm getting 11/12 in DSD11 FSE 10 bit mode. First time since v088.8

[har3inger]

Super-xbr and some light superres (1 pass, .75 str, .3 sharp, .1, soft, .3 AA, 1.0 AR) works really quite well for 720p. The superres seems to help clean up some artifacts when stripes (like on skyscrapers) are upscaled by super-xbr.

Can't wait to test the version with madshi's AR filter.

[Anima123]

I doubt that SuperRes's sharpness enhance would be needed if Super-xbr used. Here's what I am using for 576p: 2pass, 0.65 str, 0.0 sharp, 0.2 soft, 0.25 AA, 0.75 AR.

Edit: With both sharpness and softness set to 0, it seems more passes won't hurt too much of the quality. I just tested with pass 8, and the quality didn't is quite good to my eyes.

[JarrettH]

Originally Posted by madshi

So here comes an improved image comparison for super-xbr:

clown - downscaled with lanczos (?) - heavy ringing artifacts:
unscaled original - - | - - super-xbr original AR - - | - - super-xbr no AR - - | - - super-xbr madVR AR

clown - downscaled with bilinear (?) - no ringing artifacts:
unscaled original - - | - - super-xbr original AR - - | - - super-xbr no AR - - | - - super-xbr madVR AR

"original AR": This is a very strict AR algorithm written by Hyllian. It removes almost all ringing that isn't in the source. Sounds good, but sometimes ringing is helpful!
"no AR": This is super-xbr without any AR. This adds noticeable ringing, of course.
"madVR AR": This is a selective AR algorithm which tries to surpress unwanted ringing, while keeping helpful ringing.

If you look at the 2nd set of images, you should see that both AR algorithms remove most of the ringing and that super-xbr itself doesn't really ring much at all if the source is clean. It *does* sharpen=increase ringing that is already in the source, though.

You can also directly compare Hyllian's fast and agressive AR algorithm to the (slower and more complicated) one madVR uses. Hyllian's algorithm is better for comic style video games, but I believe mine's better for photos and movies.

Thoughts?

The colour is juiced up in lanczos super-xbr madVR AR

http://madvr.com/doom9/clown/clownSuperXBR.png

[MS-DOS]

Hmm, found a bug on the image doubling page in the latest version: it shows chroma doubling as enabled for NNEDI3 even though it's actually disabled.

[Anime Viewer]

Originally Posted by madshi

Interestingly, for upscaling refinement with a good image doubling algorithm (e.g. NNEDI3), I find that I like rather low strength, but higher thinning. E.g. I've tried strength 0.0 and thinning 0.35 and like it. But it's hard to say which is "better". It might really be a matter of taste. Unfortunately that's not going to help. I very very much want to reduce the number of options as much as possible.

I like the 0.0 strength and 0.035 (I'm guessing you meant 0.035 and not the 0.35 you typed as you can only go up to 0.27ish, and that setting produces a lot of jaggedness). I hadn't even contemplated 0.0 as a strength setting in my previous testing because I thought 0.0 would effectively be disabling FineSharp. Is that not the case? What about a 0.1 strength, does that produce anything unwanted in your tests? (In mine I don't see a difference in 0.0 and 0.1 strength, but that may be related to the source files I'm testing with...)

I think those settings work just as well when paired with super-xbr for image doubling.

NEDI was my previous image doubling choice (NNEDI3 was far to much of a resource waste and generated too high render stats for what it gives comapared to NEDI in my mind), but now I find I like the sharpness of the super-xbr better. On the 720p video I tested NEDI runs at ~11.5ms while super-xbr runs at ~15.7ms, and for 480p 6.4ms (NEDI) and 8.5ms (super-xbr).

[aufkrawall]

Seems like super-xbr looks nice for chroma scaling.
Jinc3AR:


super-xbr:


NNEDI3 256:


Luma scaling was NNEDI 256 doubling for all three examples (and will be for the following if not stated otherwise).

Regarding sharpening (image enhancement):
FS seems to thicken and darken contoures, I don't like this artificial look for cartoons. Lumasharpen is brighter, but this can be reduced by lowering clamp value (e.g. to 0.02).
FS (1;0):


LS (1;0.035;1):


No sharpening:


LS (0.8;0.02;1):


Will talk about luma scaling in the next post.