madVR - high quality video renderer (GPU assisted)

[omarank]

One question: With debanding there were often some thresholds where increasing one parameter by 0.1 didn't do much, but increasing 0.2 suddenly brought a big change. I think this is not the case with FineSharp, correct?
Yes

A small change in the FineSharp parameters causes a small change in image quality, right?
Right

I suppose if I decided to use 1.4/2.0/2.4 that wouldn't bother you much?
Yes

Or is there something "magic" about your choices of 1.5/2.0/2.3? Not that I'm planning to use 1.4/2.0/2.4, just asking how "fixed" your suggestions are.

There is nothing magical about 1.5/2.0/2.3 as changing a parameter by 0.1 or 0.2 doesn’t cause an abrupt change in sharpness. However, 1.5 is the threshold above which I start to see the sharpening effect that I find pleasing. 2.3 is the upper limit beyond which sharpness seems excessive.


@iSunrise: I saw your comparison screenshots and I found the LL versions more pleasing. The artefacts which you have highlighted are just too insignificant in my opinion and don’t bother me in any way.

You prefer Linear Light being disabled for FineSharp. Apparently, you use dithering algorithms too with Linear Light disabled, as with it enabled you find the images too dark. This may have to do with the calibration state of your display. I can think of two possibilities: either your display is not calibrated and has a weird gamma, or it is calibrated and you are using some custom calibration settings. There are some users who complain about the images being brighter when using LL setting for downscaling. They see this problem for the same reason that their display is not properly calibrated.

[Razoola]

For me there are so many different factors involved with these sharpners and scaling that your never going to get one option fits all. What would be really cool is for an option that works as follows. The user first plays/seeks through a video and pauses on any frame they wish. Then with a set key press madvr will display that frame of video using its various available settings (maybe pressing another key to cycle through each). The user can then choose the setting they require and the video will then play back from the start with the new settings applied.

[Hprd]

I didn't test thinning for finesharp, but with the other settings set to that way (mode 3, linear light, etc), I find that (using finesharp as an image enhancement, not upscaling refinement, because it results in aliasing) the strength I prefer depends on the video type (or how much it's upscaled by it seems).

For quadrupling (nnedi3 64 / 32) I prefer a strength of 0. For doubling (nnedi3 64) a strength of 1 seems pretty good. Basically finesharp upscaling refinement (with the default strength there of 2, and ll on, mode 3, etc. And image refined only after upscaling was complete) is what I compared it with (as I found that gives IMO optimal sharpness for any video type with nnedi3 doubling/quadrupling. But has visible aliasing and increased render times). And those strengths for those videos (DVD/720p video) are what gave pretty much the same (minus the aliasing) results with image enhancement only. I also don't see myself ever using this sharpening on a video that doesn't need to be upscaled, so I didn't test anything there...

Also, the default chroma supersharp settings can result in horrible artefacts on bright/white backgrounds/colors (with jinc3 AR, nnedi3, and I would imagine any other scaler. This was on a dvd sourced video too, maybe it has something to do with that?). I found that setting it to the "non-double" defaults or just simply turning up the anti-rining setting a bit fixed this.

[TheLion]

@iSunrise: I saw your comparison screenshots and I found the LL versions more pleasing. The artefacts which you have highlighted are just too insignificant in my opinion and don’t bother me in any way.


My words and thougths exactly.

[madshi]

While I really like FineSharp (since it's very natural looking, easily my favourite sharpener) and most of the FineSharp settings you settled on, linear light produces artefacts and doesn't look natural at all. Without linear light it's fine. See the following screenshots that show the artefacts very clearly. This happens with other samples as well. I marked them so you can compare original -> no LL (very natural) and original -> LL (unnatural and with artefacts). Also please compare no LL -> LL, because you will instantly see that the LL image is artefacting all over the place.
I do see slightly different behaviour when comparing LL on with LL off. With your screenshots there are some parts where LL off looks "better", but other parts where one could argue that LL on might be nearer to the source. I've also seen other images where LL off had more artifacts than LL on. I find it hard to say which is better. You can find examples which makes either one of them look better than the other. That's why I asked for feedback. And so far almost everybody preferred LL *on*. You're the only one preferring it off atm. That doesn't mean I will necessarily go with the majority, but if I'm not sure myself, the majority is going to win.

For comparisons to really make sense, people need to also do screenshots and show them here. For some reason, the newly introduced features very rarely if at all are really looked at in detail with screenshots. I really would have loved to read some feedback on FineSharp from 6233638 and cyberbeing, too.
Agreed.

As for your questions regarding "low", "medium" and "high", I found that strength "0.2", "0.5" and "1.0" are giving the perfect mix. 0.2 is very mild sharpening (transparent enough to be completely natural), 0.5 is medium sharping (still very natural) and 1.0 is very visible sharpening, where you really need the extra "oomph" for bringing out details (but you can tell it's been sharpened). If you go any higher, you get very visible artefacts up to the point where it gets quite distracting (2.0 already rings like crazy, 1.5 is also not satisfactory).
It's quite interesting how different the feedback is. You suggest 1.0 for high, while others have suggested 1.5 for low. It's going to be difficult for me to make a decision there...

FWIW, are you testing FineSharp in image enhancements or for upscaling refinement?

The thinning parameter is a bit difficult to be honest, I settled on "0.020" for all strengths, because higher values than that give artefacts. You can easily tell when you test with "0.100", which looks horrible. So be careful with that setting.
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.

For some reason you left out 5) when you quoted me, you absolutely need this to reproduce it.

If you really cannot reproduce it, which I doubt, since I am using default settings, I will add it to the bug tracker.
I had expected a neon green image (which you get with corrupted chroma channels). But the problem you reported was just a "mild" green tinge. I've noticed the green tinge now myself when testing with a neutral gray source, and the problem will be fixed in the next build.

It seems that directx 11 is more demanding than directx 9 path. With madvr 0.88.11 or 0.88.8 and this video https://www.youtube.com/watch?v=sLprVF6d7Ug (I have downloaded 8k movie), I have lotsd of presentation glitch with dx11 patch and not with dx9 path

With my 1080p videos, there aren't presentation glitchs with dx11 patch.
There probably isn't much I can do about it. Are you using windowed mode or FSE mode? Try FSE mode, that's usually less sensitive to presentation glitches.

Finesharp: It is quite interesting IMO. It produces a completely different look than LumaSharpen, and I think its up to personal preference. As for me, I like finesharp for doing a bit of a touchup. LSharpen has better effect for more sharpening, if I want that.
Repair at 1 looks great, found no problems. Thinning: lower than 0.025, thats sure, I like it most between 0.018 and 0.02. As for strength: 2.2 seems to be good for high preset for me too. For mid I would go with 1.4, and 0.9-1.1 for low.

I didnt test LL much, but I do prefer it on with anime.
Are we talking about upscaling refinement or image enhancement?

I think for upscaling refinement thinning might benefit from higher values, compared to image enhancement. At least that's an impression I got, but I'm not sure.

Actually, you found exactly the same as I did, however, it seems that you misinterpreted the results of your sample or at the very least, you came up with a different conclusion, because you probably didn't also zoom into the video and inspected more closely why the diagonal lines behave the way they do when they are sharpened. Also, I have found exactly the same image artefacts that I got in my samples in yours, which I showed in my last post (the weird blackness that consumes the image (borders) and seems to completely destroy image details that were there before).

The strength of "2.0" already does so much sharpening to the image that it shows you exactly what you would expect. It amplifies the picture details and thus, it will also show you compression artefacts a lot stronger than before. The diagonal lines now have a white glow around them, which is because there were already quite strong visible compression artefacts that you can see when you zoom into the lines and they get "amplified" by the amount of sharpening you did.

So what does this mean? It means that no LL shows you _exactly_ what you did, it shows you the oversharpening transparently, which is why the diagonal lines look oversharpened. Now, if you take a look at the squirrel (which actually resembles real image content a lot more) it still looks completely natural, although oversharpened, caused by the high strength settings.

Now, this is what happens when I turn on LL:

1) The squirrel image now has very visible artefacts (I marked them) and it looks unnaturally sharpened.

2) What's interesting is that the effects of finesharp with LL for some reason do soften up the visible compression artefacts around the black diagonal lines, so much that it almosts acts like a de-amplification of the sharpener itself, it acts like it masks the sharpening effect. However, this is not what you would expect when you sharpen an image, especially not with the diagonal lines that are already artefacting (compression related) and also should get sharpened up. However, this effect is also not translating to the squirrel image, which is full of artefacts, meaning, you're not only oversharpening and masking, but LL also adds some very weird artefacts to the squirrel that are not part of the original image of the squirrel (look at the red arrows).
When looking at your squirrel screenshots I see something different than you're seeing. Yes, the LL on image has a different look to it than the LL off image. But neither of them matches the original, obviously, because they're both manipulated versions of the original. So the key question is: Which sharpened image looks subjective better? And which sharpened image looks like a better representation of the original?

The "LL off" image seems to brighten up the whiskers of the squirrel, compared to the original image, and it also enlarges the "dot" on the black background right of the right ear. Also if you look at the right ear, it appears to "grow" a little bit, compared to the original image. I don't think that is what a sharpening algorithm should do. If you look at the "LL on" image, a part of the whiskers seems to get more faint, which is bad. However, the size of the "dot" and the whiskers and the right ear etc all seems to stay unchanged. Which to me feels like a more faithful representation of what I would expected from a sharpening of the original image.

There are some other images where I've also found that the "LL off" version appears to make things noticeably brighter, while the "LL on" version manages to make things sharper without changing the overall brightness of the image. E.g. compare these three images with a strength of 2.0:

http://madshi.net/FineSharpTest1.png
http://madshi.net/FineSharpTest2.png
http://madshi.net/FineSharpTest3.png

When enabling FineSharp with "LL off", you should notice that the image becomes brighter overall, compared to the original image. This does not happen (at least not as much) with "LL on". A sharpener is *not* supposed to change the brightness of the original image, is it?

Or what do you say?

So do people like FineSharp more than LumaSharpen?
Yes, I do.

I still keep gettiing occassional stutters, up to 10-15 times during a 45 minute video. It does create dropped and repeated frames during those stutters. I am still unable to figure out what is causing it... Can I provide some log or something? I have very slow upload speed of 512Kbits/second, so if the log is huge, I won't be able to upload it.
Which queues are getting (near) empty when the drops occur? Which is the top most queue (read from top to bottom in the OSD) which is getting near empty? That's the key information to find out where the bottleneck is.

If you can provide screenshots that show real benefits of LL in actual image content, which I doubt, it should be prefered, otherwise it adds unnecessary artefacts which are not there with no LL. The squirrel perfectly shows that no LL is more accurate.
I have my doubts about which squirrel is more accurate, see my comments above.

a Splitscreenfeautre would be great to compare different settings directly. Would that be possible or is it to much programming work?
Maybe in a far away future. Too much work at this point.

LL always was a huge problem, even when we tested the dithering algorithms. It made the picture a lot darker overall. For some reason LL only works really good with downsampling, but doesn't for other features.
Actually for dithering LL is much better, IMHO. If LL dithering makes the image a lot darker that would suggest that your monitor's gamma response is weird. For smooth motion FRC LL is also much better. Same with color, gamut, gamma, saturation, hue, contrast adjustments etc. The only situation where LL really makes problems is scaling, because there it adds stronger ringing artifacts. But apart from the stronger ringing artifacts it also works fine there.

Don't mean to veer off the current topic but what advantage does "D3D 11 for presentation" provide?
It enters and exits full screen exclusive mode much faster and there may be a performance advantage
I don't think D3D11 has performance advantages. However, it allows native 10bit output, if the display supports it. That's the key advantage, and as you say, maybe faster switching between windowed <-> FSE.

I have been paying with the image enhancement setting and I am totally agree with you here fine sharp is absolutely outstanding for me.

So far the best image I got its with repair at 0.50, mode 3.

All the others settings around 0.02/.003.
Do you see any problems with repair set to 1.0? If so, I'd love to see a screenshot. I was planning to remove the repair option and set it fixed to 1.0. So if you found a situation where repair 1.0 is harmful, it would be good to know.

For me there are so many different factors involved with these sharpners and scaling that your never going to get one option fits all. What would be really cool is for an option that works as follows. The user first plays/seeks through a video and pauses on any frame they wish. Then with a set key press madvr will display that frame of video using its various available settings (maybe pressing another key to cycle through each). The user can then choose the setting they require and the video will then play back from the start with the new settings applied.
Not going to happen, sorry.

I didn't test thinning for finesharp, but with the other settings set to that way (mode 3, linear light, etc), I find that (using finesharp as an image enhancement, not upscaling refinement, because it results in aliasing) the strength I prefer depends on the video type (and how much it's upscaled by it seems).
Yes, for image enhancement that's expected.

For quadrupling (nnedi3 64 / 32) I prefer a strength of 0. For doubling (nnedi3 64) a strength of 1 seems pretty good. Basically the default settings for finesharp upscaling refinement (with the default strength there of 2) is what I compared it with (as I found that gives IMO optimal sharpness for any video type with nnedi3 doubling/quadrupling. But has visible aliasing and increased render times). And those strengths for those videos (DVD/720p video) are what gave pretty much the same (minus the aliasing) results with image enhancement only.
Not sure why you get aliasing when using FineSharp in upscaling refinement. Shouldn't be the case. Please set repair to 1.0, that might help a bit. But yes, rendering times are higher when using FineSharp in upscaling refinement. That's true.

Also, the default chroma supersharp settings can result in horrible artefacts on bright/white backgrounds/colors (with jinc3 AR, nnedi3, and I would imagine any other scaler. This was on a dvd sourced video too, maybe it has something to do with that?). I found that setting it to the "non-double" defaults or just simply turning up the anti-rining setting a bit fixed this.
Shiandow is working once again on improving/rewriting SuperRes. So let's wait with that. For now, FineSharp. Thanks.

-------

Please everybody, when giving FineSharp feedback, specify whether you've tested FineSharp in image enhancements or in upscaling refinement. And when testing it in upscaling refinement, please also state your image doubling/upscaling algorithm and the upscaling factor. Thanks! :)

[Ver Greeneyes]

I've noticed something interesting about the "how many video frames shall be presented in advance" setting (testing windowed mode, DX11 path): with anything higher than 8, my rendering times seem to go up significantly! I figured the higher the better, since it would have more of a buffer in case of lag spikes, but 10 raises rendering times by about 2ms, and even more with the higher settings. I'm guessing that with my GeForce GTX 580, at least, anything higher than 8 makes it miss some more optimized paths and/or caching. So yeah, I'll be sticking with 8 - haven't noticed any advantage to lower settings, but that might well depend on the hardware :)

[Hprd]

Please set repair to 1.0, that might help a bit.

I was. I think it's more noticeable for dvd resolution stuff, but on 720p it's there as well.


Comparison (with settings I posted above and 720x480 video):

Enhancement:

http://thumbnails107.imagebam.com/41551/6725aa415503753.jpg (http://www.imagebam.com/image/6725aa415503753)

Refinement:

http://thumbnails105.imagebam.com/41551/e5b25c415503902.jpg (http://www.imagebam.com/image/e5b25c415503902)

[madshi]

I've noticed something interesting about the "how many video frames shall be presented in advance" setting (testing windowed mode, DX11 path): with anything higher than 8, my rendering times seem to go up significantly! I figured the higher the better, since it would have more of a buffer in case of lag spikes, but 10 raises rendering times by about 2ms, and even more with the higher settings. I'm guessing that with my GeForce GTX 580, at least, anything higher than 8 makes it manage the memory differently, and that makes it miss some more optimized paths and/or caching. So yeah, I'll be sticking with 8 - haven't noticed any advantage to lower settings, but that might well depend on the hardware :)
Oh well...

I was. I think it's more noticeable for dvd resolution stuff, but on 720p it's there as well.

Comparison (with settings I posted above and 720x480 video):

Enhancement:

http://thumbnails107.imagebam.com/41551/6725aa415503753.jpg (http://www.imagebam.com/image/6725aa415503753)

Refinement:

http://thumbnails105.imagebam.com/41551/e5b25c415503902.jpg (http://www.imagebam.com/image/e5b25c415503902)
Ouch. Can I have a small sample of that file, so I can test/reproduce it on my PC? Which upscaling/doubling algorithm are you using? LumaSharpen and SuperRes are turned off, right?

[Hprd]

I was using nnedi3 for doubling and quadrupling (64 and 32 neurons respectively), "CR" with AR and LL for downscaling. Jinc3 AR for image scaling and chroma scaling (with super res at "non-double" defaults as normal defaults there gives artefacts for now). Only finesharp on (either image enhancement, or upscaling refinement, never both).

That aliasing appears ONLY when turning on finesharp for upscaling refinement (super res is cleaner, although still not 100% perfect in this regard either). Repair at 1 helps a little (as it's even worse with lower values), but not that much obviously... For image enhancement it doesn't appear at all regardless of the strength and whatnot it seems.

I took out the part I used for the comparisons above:

https://www.dropbox.com/s/79kr00hyz1a7b53/Test%20Clip.zip?dl=0

[Barnahadnagy]

Are we talking about upscaling refinement or image enhancement?

Image enhancement mostly, but its more or less the same for upscaling refinement. For upscaling, at strength 2.4 I do like 0.035 more than 0.02. At lower stregnths I'm not sure. For enhancement I'm not sure at 2.4, and prefer 0.02 at lower.
I think for upscaling refinement I prefer LumaSharpen overall. FineSharp is great to make good (and high-res) sources sharper, but doesnt work that well for more than 2x upscaling, eg. DVDs.

[madshi]

I was using nnedi3 for doubling and quadrupling (64 and 32 neurons respectively), "CR" with AR and LL for downscaling. Jinc3 AR for image scaling and chroma scaling (with super res at "non-double" defaults as normal defaults there gives artefacts for now). Only finesharp on (either image enhancement, or upscaling refinement, never both).

That aliasing appears ONLY when turning on finesharp for upscaling refinement (super res is cleaner, although still not 100% perfect in this regard either). Repair at 1 helps a little (as it's even worse with lower values), but not that much obviously... For image enhancement it doesn't appear at all regardless of the strength and whatnot it seems.

I took out the part I used for the comparisons above:

https://www.dropbox.com/s/79kr00hyz1a7b53/Test%20Clip.zip?dl=0
Thanks, it's an interesting clip. From what I can see, the real cause of the aliasing is in the source (although faint), and somehow the combination of using NNEDI3 for doubling and then FineSharp on top for upscaling refinement brings it out a lot. FWIW, the next madVR build will have Hyllian's super-xbr algorithm as an image doubling alternative, which seems to hide the aliasing a bit better than NNEDI3. With that setup, FineSharp in upscaling refinement seems to work better with this clip, although some aliasing is still there.

With a really high quality source, using FineSharp in upscaling refinement produces better image quality than using it in image enhancements.

Image enhancement mostly, but its more or less the same for upscaling refinement. For upscaling, at strength 2.4 I do like 0.035 more than 0.02. At lower stregnths I'm not sure. For enhancement I'm not sure at 2.4, and prefer 0.02 at lower.
Ok, makes sense. Although I do seem to generally prefer lower strengths and higher thinning for upscaling refinement, compared to image enhancements.

[ikarad]

There probably isn't much I can do about it. Are you using windowed mode or FSE mode? Try FSE mode, that's usually less sensitive to presentation glitches.

Thanks.
I use FSE mode.

Why dx11 path is more demanding?

[baii]

I've noticed something interesting about the "how many video frames shall be presented in advance" setting (testing windowed mode, DX11 path): with anything higher than 8, my rendering times seem to go up significantly! I figured the higher the better, since it would have more of a buffer in case of lag spikes, but 10 raises rendering times by about 2ms, and even more with the higher settings. I'm guessing that with my GeForce GTX 580, at least, anything higher than 8 makes it miss some more optimized paths and/or caching. So yeah, I'll be sticking with 8 - haven't noticed any advantage to lower settings, but that might well depend on the hardware :)
I have similar experience in fse mode but not windowed mode. Always thought it is hardware dependent though. The default setting is pretty safe though.

Sent from my 306SH

[madshi]

madVR v0.88.12 released

http://madshi.net/madVR.zip

* added super-xbr image doubling algorithm
* added super-xbr chroma upscaling algorithm
* added NEDI chroma upscaling algorithm
* added workaround for one more cause of queues not filling in D3D11 FSE mode
* removed FineSharp "mode", "repair" and "linear light" options
* removed SuperRes "error upscaling quality" option
* fixed: screenshots didn't always work when using DXVA scaling
* fixed: luma quadrupling could introduce greenish tint
* fixed: settings dialog required BT.709 3dlut slot to be filled
* fixed: auto 3dlut slot switching didn't always work correctly
* fixed: double clicking madTPG with D3D11 enabled -> black screen
* fixed: custom shader "clock" parameter was not set correctly
* fixed: ConfigureDisplayModeChanger(allowResolutionChanges = false) bug
Please note that I've already removed the FineSharp "linear light" option, although it's still in discussion. The reason for removing it was that at the point when I did the code change, everyone had voted in favor of linear light. Discussion about it only started after I had already remove the option from my code. Users who prefer the "linear light" option to be turned off for FineSharp can of course still use v0.88.11 to create comparison screenshots for discussion etc. I'm still willing to be convinced to disable linear light for FineSharp, with appropriate screenshots etc...

Here are some comparison screenshots showing how the latest upscaling/doubling algorithms (including NEDI and super-xbr) compare. All these are *without* any upscaling refinement:

clown:
bilinear (http://madVR.com/doom9/clown/clownBilinear.png) -|- bicubic (http://madVR.com/doom9/clown/clownBicubic.png) -|- lanczos4 (http://madVR.com/doom9/clown/clownLanczos4.png) -|- jinc (http://madVR.com/doom9/clown/clownJinc.png) -|- nedi (http://madVR.com/doom9/clown/clownNedi.png) -|- super-xbr (http://madVR.com/doom9/clown/clownSuperXBR.png) -|- NNEDI3-16 (http://madVR.com/doom9/clown/clownNNEDI3_16.png) -|- NNEDI3-256 (http://madVR.com/doom9/clown/clownNNEDI3_256.png)

lighthouse:
bilinear (http://madVR.com/doom9/lighthouse/lighthouseBilinear.png) -|- bicubic (http://madVR.com/doom9/lighthouse/lighthouseBicubic.png) -|- lanczos4 (http://madVR.com/doom9/lighthouse/lighthouseLanczos4.png) -|- jinc (http://madVR.com/doom9/lighthouse/lighthouseJinc.png) -|- nedi (http://madVR.com/doom9/lighthouse/lighthouseNedi.png) -|- super-xbr (http://madVR.com/doom9/lighthouse/lighthouseSuperXBR.png) -|- NNEDI3-16 (http://madVR.com/doom9/lighthouse/lighthouseNNEDI3_16.png) -|- NNEDI3-256 (http://madVR.com/doom9/lighthouse/lighthouseNNEDI3_256.png)

lighthouse top:
bilinear (http://madVR.com/doom9/lighthouseTop/lighthouseTopBilinear.png) -|- bicubic (http://madVR.com/doom9/lighthouseTop/lighthouseTopBicubic.png) -|- lanczos4 (http://madVR.com/doom9/lighthouseTop/lighthouseTopLanczos4.png) -|- jinc (http://madVR.com/doom9/lighthouseTop/lighthouseTopJinc.png) -|- nedi (http://madVR.com/doom9/lighthouseTop/lighthouseTopNedi.png) -|- super-xbr (http://madVR.com/doom9/lighthouseTop/lighthouseTopSuperXBR.png) -|- NNEDI3-16 (http://madVR.com/doom9/lighthouseTop/lighthouseTopNNEDI3_16.png) -|- NNEDI3-256 (http://madVR.com/doom9/lighthouseTop/lighthouseTopNNEDI3_256.png)

Please make sure you view these at 100% for proper comparison.

My first impression: super-xbr seems to better than NNEDI3 with 16 taps at producing aliasing free edges. It's also quite sharp and artifact free. However, NNEDI3 looks more "in focus", all the image features are a bit tighter. So I still prefer the overall "look" that NNEDI3 produces. However, super-xbr seems to be the best bang for the buck right now. It's reasonably fast (a bit slower than Jinc and Nedi, but much faster than NNEDI3-16).

Let me know what you think!

[huhn]

the biggest issue i see with super xbr is holoing/ringing on all your screens. let's see what superres can do about that.

[iSunrise]

@madshi
I have enhanced the squirrel so that hopefully you can see what I mean with heavy artefacts with LL. I just want to make sure we are speaking of the same things.

I did enhance both shots with GIMP (input levels set to 0, 2.00, 255) so I basically amplified the medium values for both shots to show you what I mean. Hopefully I can rest my case after this, because if you deny that LL looks a lot worse on the squirrel in the following shots, I will just give up. Because it seems you aren't interested in facts, anymore. You are making changes WAY too fast for anyone to catch up and that saddens me greatly. I am not sure why you suddenly rush things when there wasn't any screenshots from people that still use madVR, apart from maybe TheLion, which I appreciate. Especially since you invested so much time in madVR already that waiting a few more days for others to judge won't hurt anyone.

No LL, enhanced and cropped:
http://abload.de/thumb/sample_thelion_fineshnjp77.png (http://abload.de/image.php?img=sample_thelion_fineshnjp77.png)

LL, enhanced and cropped:
http://abload.de/thumb/sample_thelion_fineshjgoi2.png (http://abload.de/image.php?img=sample_thelion_fineshjgoi2.png)

The samples I provided show the exact same behaviour and the "blackness" that consumes the image more and more if you upscale makes these images a lot worse in general. It's almost like LL crushed black levels.

I am very interested in your opinion on this.

For the strength values, a good middle-way would probably be 0.5, 1.0 and 2.0. So for people that prefer to oversharpen a lot, 2.0 is good for them, 1.0 is good for a medium sharpener and for low-resolution content, 0.5 is already sharp enough without amplifying compression artefacts too much.

I have a hardware-calibrated Eizo that shows perfect levels from 0-255, this is the same monitor that I used when we did the dithering tests and I never changed any settings that could make my results different from others. I now even have it running in perfect 10bit mode (FSE), thanks to you. I even made sure to use the defaults, no change, as expected. If people really want a worse algorithm and don't judge what they see with screenshots (because the eyes cannot judge picture details) all the tests that the majority did are worthless. As harsh as it may sound.

You just cannot judge with your eyes alone, plain and simple. It's a combination of eyes, analysis based on some example images and some subjective inputs.

[huhn]

@iSunrise

not sure why an amplifications is needed.

i see more issue on the left diag part with the white around the black lines which looks way better with linear light but still bad.

but the squirrel? on the right has a lot more "ringing" with linear light.

but i didn't like finesharp in general i guess that's why.

[iSunrise]

@iSunrise

not sure why an amplifications is needed.

i see more issue on the left diag part with the white around the black lines which looks way better with linear light but still bad.

but the squirrel? on the right has a lot more "ringing" with linear light.

but i didn't like finesharp in general i guess that's why.
It is needed because apparently some people just ignore what I have shown them with basically only doing a couple screenshots. That's why such measures are needed to show the differences even more clearly.

I could do countless other examples and LL would exhibit the same problems. No LL is a lot more natural without artefacts, plain and simple. Still, people prefer LL and I don't get it.

And that's at a strength that is already very high (2.0), so that means that no LL could even be cranked up more without showing such nasty artefacts.

[huhn]

i can't disagree on these screenshoots but without LL there are other issue too.

but the squirrel looks way better without LL! and the dark parts of the fur are better without LL too.

[James Freeman]

I think that the more contrast the image has (bigger distance between two close shades) the more obvious the ringing is. This is always true with any upscaler.
LL somehow enhances this even further.

As I see it, LL is better for natural images with smooth transition between shades (closer shades), and gamma light is better for cartoons or generated test patterns.
I may be wrong...

I would prefer to keep LL Off and just add sharpness to avoid ringing.

[iSunrise]

i can't disagree on these screenshoots but without LL there are other issue too.

but the squirrel looks way better without LL! and the dark parts of the fur are better without LL too.
Yes, that's exactly what I see. It is just way more natural. LL adds something to the image that just makes it look totally "processed", while no LL really does a great job and just amplifies the basic picture details like a good sharpener should do it.

Since we are watching videos, movies and also game recordings, all of them look totally "processed" when using finesharp with LL. That's apparently the difference people see, but this is no ways means that it is more accurate. It's exactly the other way around, as you can see in the screenshots.

[flashmozzg]

the biggest issue i see with super xbr is holoing/ringing on all your screens. let's see what superres can do about that.

I agree. It is especially noticeable in lighthouse top fence.
While it looks cool and sometimes better than jinc nnedi is the closest to how it should really look like. If only there was a way to get rid off this ringing...

[iSunrise]

@madshi:
Can you please provide the original lighthouse top crop that you used for the comparisons? I want to make some tests, I need the original source of your crop, though.

From what I can see in your comparisons:

1) super-xbr introduces heavy ringing artefacts compared to NNEDI16
2) super-xbr shows more fine details (it's sharper) than NNEDI16, which seems to be a result of the very heavy edge-amplification that super-xbr does.

With access to your original cropped shot, I am pretty sure that NNEDI16 with finesharp and no LL basically will have all the positives of NNEDI and it will also show more fine details without the heavy ringing.

So it's only good for users where performance matters a lot, but for image quality it seems a step backwards.

I will do some of my own tests with it for a final conclusion.

[JarrettH]

While we're talking about linear light, is linear light dithering (the trade option) a good thing? I see the trade options as more objective improvements

Edit: I think I found my answer, but I didn't realize linear light is so debatable

[mbordas]

88.12 fixed the problem with display resolution being set to 23.969 instead of 23.976 when D3D11/FSE/10bit was enabled. The Custom Resolution Utlility (CRU) is no longer necessary. Thanks!

[JarrettH]

I'm in the more moderate camp for FineSharp. I look for a shot with hair clearly visible, then experiment with settings. I'm not looking for it to be sharper necessarily; what I don't want is for the result to be brightened too much. We want an upscaled original, not enhancement IMO. 1.0 to 1.5 strength is good...depends

[Hyllian]

madVR v0.88.12 released

http://madshi.net/madVR.zip

* added super-xbr image doubling algorithm
* added super-xbr chroma upscaling algorithm


Wow! That was fast! :D

Which anti-ringing are you using in the sxbr implementation? Is it ON in these screenshots?

I agree with you on the impressions. The alchilles heel of sxbr is ringing yet.

[huhn]

Wow! That was fast! :D

Which anti-ringing are you using in the sxbr implementation? Is it ON in these screenshots?

I agree with you on the impressions. The alchilles heel of sxbr is ringing yet.

even nnedi3 shows the ringing so it should be in the source and sxbr just increases the strength of it more than the rest.

[Hyllian]

even nnedi3 shows the ringing so it should be in the source and sxbr just increases the strength of it more than the rest.
In fact. Observing further the images (sxbr ones) I can say that they are indeed using AA, though a soft one. It's possible to reduce a bit the ringing using the aggressive AA from the original sources, though it can't reduce the ringing to the NNEDI3 level.

[MS-DOS]

Looking at these screenshots, I can assume that XBR could be my new favorite if not for that ringing. Going to test it myself. Hyllian, madshi - great job! :)

[iSunrise]

In fact. Observing further the images (sxbr ones) I can say that they are indeed using AA, though a soft one. It's possible to reduce a bit the ringing using the aggressive AA from the original sources, though it can't reduce the ringing to the NNEDI3 level.
Maybe madshi could combine SXBR with his AR-algorithm, which he developed specifically to reduce ringing of the other upscalers. I am not sure about the specifics though, I always wondered why AR is not offered for NNEDI for instance, anyway.

[huhn]

In fact. Observing further the images (sxbr ones) I can say that they are indeed using AA, though a soft one. It's possible to reduce a bit the ringing using the aggressive AA from the original sources, though it can't reduce the ringing to the NNEDI3 level.

jinc level would be awesome.

[Hyllian]

I forgot to mention to madshi that super-xbr can work like a framework for other filters.

In the default implementation it uses sinc filters to filter in the desired directions. The way sxbr work doesn't have to use only sinc filters. You can replace it by any other filter of interest.

Here is a sxbr test I made a month ago using cubic coefficients (instead sinc ones):

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

As you can see, not as sharp as the sinc version, though much less ringing!

So, what I mean is that many results can be obtained with different filters used inside sxbr framework.

obs: for the example above I have used a simple (-1, 9, 9, -1) cubic filter.

[tobindac]

madVR v0.88.12 released

My first impression: super-xbr seems to better than NNEDI3 with 16 taps at producing aliasing free edges. It's also quite sharp and artifact free. However, NNEDI3 looks more "in focus", all the image features are a bit tighter. So I still prefer the overall "look" that NNEDI3 produces. However, super-xbr seems to be the best bang for the buck right now. It's reasonably fast (a bit slower than Jinc and Nedi, but much faster than NNEDI3-16).

Let me know what you think!

A new GPU seems to be able to handle NNEDI3-32 in 1080p content (with only chroma upscaling needs at least). I wonder if that's better than other options.

[Anima123]

Using super-xbr with SuperRes result in quite good quality. For me, super-xbr is sharp enough to let sharpness of SuperRes be 0, with anti-ringing strength set to 0.5.

The test is done with 1024x576 -> 1920x1080. SuperRes's sharpness tend to make the edge of people's face in the video not smooth, which is sometimes very annoying. I thought it was the C-R AR LL downscaling causing this.

[luk008]

Present a frame for every Vsync in D3D11 should be used only if I've presentation glitches without it?

[huhn]

I forgot to mention to madshi that super-xbr can work like a framework for other filters.

In the default implementation it uses sinc filters to filter in the desired directions. The way sxbr work doesn't have to use only sinc filters. You can replace it by any other filter of interest.

Here is a sxbr test I made a month ago using cubic coefficients (instead sinc ones):

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

As you can see, not as sharp as the sinc version, though much less ringing!

So, what I mean is that many results can be obtained with different filters used inside sxbr framework.

obs: for the example above I have used a simple (-1, 9, 9, -1) cubic filter.

you mean it is much better.

[James Freeman]

BUG Report.

88.12 is completely unusable with my system (i7, gtx660), in D3D9 or D3D11; render & present are empty all the time in windowed fullscreen.
Back to 88.11 for now.

[madshi]

While we're talking about linear light, is linear light dithering (the trade option) a good thing?
Yes, most definitely, although the difference is getting progressively smaller the higher the dithering bitdepth is. At 8bit+ probably there's no visible difference, maybe not even a measurable one. At very low bitdepths the difference is pretty high, though.

even nnedi3 shows the ringing so it should be in the source and sxbr just increases the strength of it more than the rest.
That's exactly the case. Probably the images I've chosen for the comparison are not really good choices because of the ringing that's already baked into them. Because super-xbr is much sharper than most other algorithms, it also sharpens the ringing that is already in the source. With a clean source super-xbr should not ring much more than Jinc AR does.

Wow! That was fast! :D

Which anti-ringing are you using in the sxbr implementation? Is it ON in these screenshots?

I agree with you on the impressions. The alchilles heel of sxbr is ringing yet.
I'm using a modified version of my own anti-ringing algorithm. My code is rather long, ugly and slow, but I think it's working reasonably well to differ between wanted and unwanted ringing.

In fact. Observing further the images (sxbr ones) I can say that they are indeed using AA, though a soft one. It's possible to reduce a bit the ringing using the aggressive AA from the original sources, though it can't reduce the ringing to the NNEDI3 level.
You mean AR (anti-ringing), not AA (anti-aliasing), I think? Just clarifying so that there are no misunderstandings.

Your original AR algorithm does reduce ringing a little bit more than my algorithm, but also introduces all kinds of artifacts because it's so agressive. I'll post comparison screenshots later.

A new GPU seems to be able to handle NNEDI3-32 in 1080p content (with only chroma upscaling needs at least). I wonder if that's better than other options.
"Better" is difficult to answer. If you look at the "clown" comparison images, super-xbr in some parts of the image is even better than NNEDI3-256 (e.g. the wheels of the white van), but worse in other parts. I do think that NNEDI3 is overall still the algorithm to beat, but it's also dramatically slower.

I forgot to mention to madshi that super-xbr can work like a framework for other filters.

In the default implementation it uses sinc filters to filter in the desired directions. The way sxbr work doesn't have to use only sinc filters. You can replace it by any other filter of interest.

Here is a sxbr test I made a month ago using cubic coefficients (instead sinc ones):

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

As you can see, not as sharp as the sinc version, though much less ringing!

So, what I mean is that many results can be obtained with different filters used inside sxbr framework.

obs: for the example above I have used a simple (-1, 9, 9, -1) cubic filter.
Looks interesting. Would you mind uploading one of your 3 passes with cubic coefficients instead of sinc? I'm currently simply using your shaders, but haven't really tried to understand how they work in detail yet (due to lack of time). So I'm not quite sure where to replace the coefficients exactly. Must be one of those sinc related calls, but there's more than just one...

Present a frame for every Vsync in D3D11 should be used only if I've presentation glitches without it?
It doesn't hurt to always turn it on, but you might get slightly faster performance leaving it unchecked, if your display refresh rate is higher than the movie frame rate.

BUG Report.

88.12 is completely unusable with my system (i7, gtx660), in D3D9 or D3D11; render & present are empty all the time in windowed fullscreen.
Back to 88.11 for now.
Strange. Can you please try to isolate what is causing the problem? So far nobody else has reported the problem. So it doesn't seem to be a general problem with v0.88.12. E.g. try to reset madVR settings to default. Is it only the render & present queues which are empty? Or also other queues?

Can you please provide the original lighthouse top crop that you used for the comparisons? I want to make some tests, I need the original source of your crop, though.
Sure:

clown.png (http://madVR.com/doom9/clown/clown.png) -|- lighthouse.png (http://madVR.com/doom9/lighthouse/lighthouse.png) -|- lighthouseTop.png (http://madVR.com/doom9/lighthouseTop/lighthouseTop.png)

From what I can see in your comparisons:

1) super-xbr introduces heavy ringing artefacts compared to NNEDI16
2) super-xbr shows more fine details (it's sharper) than NNEDI16, which seems to be a result of the very heavy edge-amplification that super-xbr does.

With access to your original cropped shot, I am pretty sure that NNEDI16 with finesharp and no LL basically will have all the positives of NNEDI and it will also show more fine details without the heavy ringing.

So it's only good for users where performance matters a lot, but for image quality it seems a step backwards.

I will do some of my own tests with it for a final conclusion.
I rather think that super-xbr enhances the ringing that's already in the source while NNEDI3 somehow manages to reduce it a little. It was not my intention to hype super-xbr as a NNEDI3 replacement. Just saying that IMHO it's quite a bit better than Jinc while being only moderately slower than Jinc. super-xbr in some aspects can compete with NNEDI3, in other aspects not.

I have enhanced the squirrel so that hopefully you can see what I mean with heavy artefacts with LL. I just want to make sure we are speaking of the same things.
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?

[Hyllian]

Looks interesting. Would you mind uploading one of your 3 passes with cubic coefficients instead of sinc? I'm currently simply using your shaders, but haven't really tried to understand how they work in detail yet (due to lack of time). So I'm not quite sure where to replace the coefficients exactly. Must be one of those sinc related calls, but there's more than just one...



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.

[XMonarchY]

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 (http://madVR.com/doom9/clown/clown.png) - - | - - super-xbr original AR (http://madVR.com/doom9/clown/clownSuperXBRstrictAR.png) - - | - - super-xbr no AR (http://madVR.com/doom9/clown/clownSuperXBRnoAR.png) - - | - - super-xbr madVR AR (http://madVR.com/doom9/clown/clownSuperXBR.png)

clown - downscaled with bilinear (?) - no ringing artifacts:
unscaled original (http://madVR.com/doom9/clown/clownBox.png) - - | - - super-xbr original AR (http://madVR.com/doom9/clown/clownBoxSuperXBRstrictAR.png) - - | - - super-xbr no AR (http://madVR.com/doom9/clown/clownBoxSuperXBRnoAR.png) - - | - - super-xbr madVR AR (http://madVR.com/doom9/clown/clownBoxSuperXBRselectiveAR.png)

"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]

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?

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]

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]

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]

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.

"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.

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.

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 :thanks:

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.