madVR - high quality video renderer (GPU assisted)

[Ver Greeneyes]

Those should be the default flush settings. For now I'd kindly ask you to postpone this bug until all the new bugs introduced by v0.88.17 are solved, if you don't mind. Otherwise it's just too much atm. I can handle only so many bug reports at a time.Sure, that's fine. I can just use the D3D11 path anyway.

[ryrynz]

So this is an "old" issue and was not caused by the recent changes in v0.88.17?


Yeah probably as old as the d3d 11 implementation in MadVR.

[Akeno]

New bug with the 88.20. Seems like the OSD is reporting incorrect render times. Render time is lower than what it was in previous updates with the exact same settings (I'm not using SuperRes). It reports even lower render times when I go from NNEDI3 16 -> 32 but the dropped frames and presentation glitches counter begin to rise.

[leeperry]

How do you expect madshi to react? Believe 20 other people that say A looks more satisfying and agree with madshi's findings or with 2-3 other people that don't agree, but they also don't show why they don't agree
It's 4 guys(or was it 6?) that got HQ forced and barely anyone reported on the 0.19 SR options IIRC so your "20 other people" seems pretty far stretched.

I tried yesterday late at night on my usual 720p material and this afternoon again on different kinds of SD material just to be sure that my impressions didn't change and then I saw that post that pretty much synthesized exactly what I saw so I thought I would +1 it, nothing more.

I also came to the conclusion this afternoon that sxbr+AS seem to look equally good(or even better?) than SR in .15 with 3@0.42 but I would need to finetune their strengths(sxbr75+AS 0.5 atm), madshi made clear that SR would take a route I'm not interested in so again I can either give up on SR altogether(as it's literalling been going downhill since .16 for me) or remain stuck in .15-land. I haven't really decided yet, yes it takes several test sessions on different kinds of material before making a decision.

If I had access to the script as a text file or could fire up SR from PotPlayer as a PS script, this wouldn't be much of a hassle but I do realize that madshi's work on mVR is already a gift, he's not too keen on sharing his work with the competition, he primarly codes mVR for his own use and he's already extremely kind to share it with us...so I need to adapt my needs to what he's willing to offer(and PQ is stellar anyway :devil:).

Huh? This release re-introduced "HQ off" for you. I'm confused how that would kill SuperRes for you? Instead of saying "thank you" for adding a tweak *just for you*, you continue to whine, and you don't do screenshots, as I asked you to multiple times already. You're not very motivating atm.
Yes my bad where are my manners sorry, TYVM for taking the time to make the change http://forum-images.hardware.fr/icones/smilies/jap.gif. I sure would fancy the same kind of kludge to change the sxbr strength to be honest ^^

I wasn't able to use versions since .16 due to HQ SR being forced so I'm basically going from .15 to .19 and yes this new build is a total show stopper for me as far as SR is concerned, HQ or not.

Screenshots? I'm sure you did a whole bunch of them when deciding that HQ=off looks horrible to you? Or did you toggle it while playing movie content? My point is that for all I know screenshots wouldn't prove anything and I would waste hours looking at microscopic pixels differences. It really only matters in motion IMHO and the differences I'm seeing are not content dependent to the least. At the end of the day what matters if that SR looks good to you and that I can also keep on being stunned by mVR, I seem willing to give up on SR as our views towards it would appear to drastically diverge. No worries.

I've already told you that if that is your opinion, I want proof, in the form of screenshots. Put up or shut up!! :p
Oh totally, I was only +1 another post so the guy wouldn't be alone in the middle of the ocean of posts here and considered to be a misfit of some kind.

I hope that at least some of those stuttering issues are resolved now
I definitely got random stuttering while seeking with .19 in PotP that didn't occur with .15 on W7SP1/HD7850/13.12/8bit DX9, will try the new build then :)

:thanks:

[Nevilne]

So you literally can't show any proof

[Ver Greeneyes]

madshi, I took debug logs for the 'repeated frames show very old frames' thing, comparing d3d9 and d3d11 windowed mode, though I don't know if they show anything. Just let me know when you have time to look at them.

[tFWo]

Can you show a couple of screenshots which show why you prefer HQ off? Please post the original image (PNG is fine) together with the upscaled & SuperRes'ed results. The original image is important, so we can reproduce your results here, and maybe fine tune the algorithm. Thanks!


I'm off on vacation for next two weeks so I'm doing this at the last moment before going. :)

original
http://www84.zippyshare.com/v/CDsDqi9P/file.html

hq strength 1 radius 0.70
http://abload.de/img/seventhhqjpjxy.png

nohq strength 1 radius 0.70
http://abload.de/img/seventhnohqaejzk.png

It's hard to compare because strength 1 for nohq is too strong.

As I said radius does help. But HQ still has that almost softer than original look with slight ringing around numbers. White is spilled into black area, black is spilled into white area.

NoHQ doesn't have that problem even on higher strengths. But as I said even strength 1 is too strong for my taste.

[Deim0s]

Everyone who had *new* problems, introduced by v0.88.17, please test this new build and let me know if your problems are fixed.
I have problems with builds after 0.88.16.
Examples and dump below:
OSD (SD MPEG-2) (http://i.imgur.com/9OfF6LE.png)
dump (http://rghost.ru/6FPPfFfVP)

OSD (720p - presentation glitches when step forward/backward) (http://i.imgur.com/MLSeQPU.png)
dump (http://rghost.ru/6R2HSLGc5)

Win 7 SP1 Pro x64
ASUS GTX770 2Gb
ASUS VG278H 120 Hz
MPC-HC x64 latest nightly build
LAV x64 latest nightly build

[ryrynz]

So you literally can't show any proof
I don't think you've been here on enough to know quite how Max's testing methodology works.. [emoji57]

His super vision defies all screenshot proof justifying it. He sees things us mere mortals cannot. [emoji1]

[jewshawn2]

I am reporting a bug that was introduced since v0.88.17.

In order for OBS (Open Broadcaster Software) to capture video in Potplayer with madVR, you have to use "Game Capture" source. I was told by someone on the OBS forum that this uses OpenGL to capture video. And it is the only method to capture video with madVR as the renderer.

Since v0.88.17 video capture using OBS (both versions) and Potplayer causes unwatchable jittery/stuttering video. The video looks perfectly fine on screen. But the OBS capture window shows jittery video. v0.88.16 was the last release that worked fine.

The bug can be reproduce on both of my PCs using the default madVR settings and default PotPlayer settings. However, if I use a different video player like MPC-HC x64 or bsplayer with madVR the video capture in OBS is fine. But when I adjust volume level the OSD causes stuttering video in the capture window.

I don't expect this bug report to get a lot of attention since it's very specific but I still wanted to report it for documentation purposes. I hope other forums members can reproduce the bug and verify my claims.

These were the changes introduced to madVR, perhaps one of these changes broke functionality between madVR, Potplayer, and OBS:
v0.88.17
* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected

My setup:

madVR v0.88.17 thru v0.88.20

x64 bit Potplayer [1.6.55124] 2015/07/10

x64 OBS Multiplatform 0.11.1

x64 OBS Original 0.652b

x64 Win 7 / Nvidia 8800 GTS

[leeperry]

He sees things us mere mortals cannot.

I guess tFWo hit the nail for me but nice try buddy, I didn't care enough to bother trying that's all...especially when strength 1 is already so darn sharp with HQ off making screenshots comparisons most shaky.

I mean how anyone could prefer HQ enabled is already beyond my comprehension and I'm running a Sammy LED LCD TV, the biggest sales on the market by far AFAIK. It doesn't take a screenshot for either me or tFWo to see that we hate HQ, but maybe he also has supervision I'll give you that http://forum-images.hardware.fr/images/perso/braysse.gif

[James Freeman]

madVR v0.88.20 released

* changed OSD rendering logic all over again
Everyone who had *new* problems, introduced by v0.88.17, please test this new build and let me know if your problems are fixed.


Sorry, problem still exists. :(
Testing with full power (P0 state) to avoid misinterpretation of the stuttering,
D3D11, FSE, still has unreported stuttering, Only in FSE.
All other modes are OK.

Overlay is fixed in this one.

[Akeno]

I guess tFWo hit the nail for me but nice try buddy, I didn't care enough to bother trying that's all...especially when strength 1 is already so darn sharp with HQ off making screenshots comparisons most shaky.

I mean how anyone could prefer HQ enabled is already beyond my comprehension and I'm running a Sammy LED LCD TV, the biggest sales on the market by far AFAIK. It doesn't take a screenshot for either me or tFWo to see that we hate HQ, but maybe he also has supervision I'll give you that http://forum-images.hardware.fr/images/perso/braysse.gif
Offtopic: You seem to have a problem understanding that people have different preferences than you. You've failed to provide any evidence to justify your claims and madashi still gave you the option to disable HQ. Don't just piggyback on tFWo's work while acting superior about it.

Ontopic: Are their any benefits to using madVR x64 over x32? ReClock doesn't have an x64 version but I'm starting to seriously wonder if I'm just wasting resources as I don't use the media speedup/down option and I'm satisfied with just feeding audio through DirectSound.

[ryrynz]

Offtopic: You seem to have a problem understanding that people have different preferences than you. You've failed to provide any evidence to justify your claims and madashi still gave you the option to disable HQ. Don't just piggyback on tFWo's work while acting superior about it.


If it's import enough to him he'll make the effort. He's certainly aware he has special preferences. Madshi deals with the requests appropriately so don't worry about it.


Ontopic: Are their any benefits to using madVR x64 over x32? ReClock doesn't have an x64 version but I'm starting to seriously wonder if I'm just wasting resources as I don't use the media speedup/down option and I'm satisfied with just feeding audio through DirectSound.

There are benefits on the performance side of things. If you're potentially ditching reclock and have no other 32 bit filters active then definitely move to 64 bit.

[JohnLai]

Got a new display and trying to create a 3DLUT using madTPG + dispcalGUI + Argyll.

Have a problem here.....
First, I run madTPG with 'stay on top' + 'use fullscreen + disable videluts + disable 3dluts.
I specifically make sure the 'Image Area' slider is moved to the right max 100%. (So that the tiny gray box is way larger.) 'Background' slider is moved to left max 1%.


Then, I run dispcalGUI and set up stuff normally, finally click 'calibrate and profile'.

madTPG finally runs its pattern in full screen.....but the color square patches is way too small in the middle of screen? I thought I already set the image area slider to max size? Is this a known bug?

EDIT: there is 'ArgyllCMS Patches' being displayed at top left corner of the screen. The patches are very small and I noticed the 'image area' slider being reset back to 1%

EDIT2 : each time madTPG loads new batch of patches from displaygui, the 'image area' slider being reset to 1%

EDIT3 : Any idea to keep the 'image area' from being reset?

EDIT4 : Found this -P0.5,0.5,10,10 argument for dispcal, but after 3rd or 4th batch of patches, it resets back to 1% again.

[Siso]

New bug with the 88.20. Seems like the OSD is reporting incorrect render times. Render time is lower than what it was in previous updates with the exact same settings (I'm not using SuperRes). It reports even lower render times when I go from NNEDI3 16 -> 32 but the dropped frames and presentation glitches counter begin to rise.

+1 for the incorrect render times, seems overlay mode is fixed tho :)

[sneaker_ger]

My back-forth jumping problems in window mode (old path) appear to be fixed by v0.88.20.

[madshi]

New bug with the 88.20. Seems like the OSD is reporting incorrect render times. Render time is lower than what it was in previous updates with the exact same settings (I'm not using SuperRes). It reports even lower render times when I go from NNEDI3 16 -> 32 but the dropped frames and presentation glitches counter begin to rise.
Ok, will have a look at that.

I also came to the conclusion this afternoon that sxbr+AS seem to look equally good(or even better?) than SR in .15 with 3@0.42
If you remember, I actually told you that you should try AdaptiveSharpen if you liked the look of LQ SuperRes, because AdaptiveSharpen and LQ SuperRes have a similar look. But then you replied with:

> I'm not interested in running another sharpening filter
> on top but thanks for the advice

My point is that for all I know screenshots wouldn't prove anything and I would waste hours looking at microscopic pixels differences.
Different sharpening algorithms and HQ vs LQ SuperRes produce quite noticable differences, if you use a sharp image for testing. Easy to see in screenshots for everybody.

madshi, I took debug logs for the 'repeated frames show very old frames' thing, comparing d3d9 and d3d11 windowed mode, though I don't know if they show anything. Just let me know when you have time to look at them.
I'll let you know.

I'm off on vacation for next two weeks so I'm doing this at the last moment before going. :)

original
http://www84.zippyshare.com/v/CDsDqi9P/file.html

hq strength 1 radius 0.70
http://abload.de/img/seventhhqjpjxy.png

nohq strength 1 radius 0.70
http://abload.de/img/seventhnohqaejzk.png

It's hard to compare because strength 1 for nohq is too strong.

As I said radius does help. But HQ still has that almost softer than original look with slight ringing around numbers. White is spilled into black area, black is spilled into white area.

NoHQ doesn't have that problem even on higher strengths. But as I said even strength 1 is too strong for my taste.
Yeah, thanks for the screenshots. One problem with such screenshots is that we don't really know what to shoot for. How *should* the image really look like? Ideally we would have a high resolution version of the same image, so we can double check which of the upscaling algos and sharpening/post-processing algos comes nearest to the high res version. Since we don't have that, judging which image looks better is highly subjective. I can see that the LQ (= noHQ) version looks noticeably sharper, but also introduces the typical "sharpened" look, like Unsharp Masking, AdaptiveSharpen, LumaSharpen etc do. Which is a look I don't like.

I have problems with builds after 0.88.16.
Examples and dump below:
OSD (SD MPEG-2) (http://i.imgur.com/9OfF6LE.png)
dump (http://rghost.ru/6FPPfFfVP)

OSD (720p - presentation glitches when step forward/backward) (http://i.imgur.com/MLSeQPU.png)
dump (http://rghost.ru/6R2HSLGc5)

Win 7 SP1 Pro x64
ASUS GTX770 2Gb
ASUS VG278H 120 Hz
MPC-HC x64 latest nightly build
LAV x64 latest nightly build
Does that still occur with v0.88.20?

I am reporting a bug that was introduced since v0.88.17.

In order for OBS (Open Broadcaster Software) to capture video in Potplayer with madVR, you have to use "Game Capture" source. I was told by someone on the OBS forum that this uses OpenGL to capture video. And it is the only method to capture video with madVR as the renderer.

Since v0.88.17 video capture using OBS (both versions) and Potplayer causes unwatchable jittery/stuttering video. The video looks perfectly fine on screen. But the OBS capture window shows jittery video. v0.88.16 was the last release that worked fine.

The bug can be reproduce on both of my PCs using the default madVR settings and default PotPlayer settings. However, if I use a different video player like MPC-HC x64 or bsplayer with madVR the video capture in OBS is fine. But when I adjust volume level the OSD causes stuttering video in the capture window.

I don't expect this bug report to get a lot of attention since it's very specific but I still wanted to report it for documentation purposes. I hope other forums members can reproduce the bug and verify my claims.

These were the changes introduced to madVR, perhaps one of these changes broke functionality between madVR, Potplayer, and OBS:
v0.88.17
* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected

My setup:

madVR v0.88.17 thru v0.88.20

x64 bit Potplayer [1.6.55124] 2015/07/10

x64 OBS Multiplatform 0.11.1

x64 OBS Original 0.652b

x64 Win 7 / Nvidia 8800 GTS
I see. I think this is likely to be a bug in OBS. But maybe I can find a solution, nevertheless.

Sorry, problem still exists. :(
Testing with full power (P0 state) to avoid misinterpretation of the stuttering,
D3D11, FSE, still has unreported stuttering, Only in FSE.
All other modes are OK.
Ok.

Got a new display and trying to create a 3DLUT using madTPG + dispcalGUI + Argyll.

Have a problem here.....
First, I run madTPG with 'stay on top' + 'use fullscreen + disable videluts + disable 3dluts.
I specifically make sure the 'Image Area' slider is moved to the right max 100%. (So that the tiny gray box is way larger.) 'Background' slider is moved to left max 1%.


Then, I run dispcalGUI and set up stuff normally, finally click 'calibrate and profile'.

madTPG finally runs its pattern in full screen.....but the color square patches is way too small in the middle of screen? I thought I already set the image area slider to max size? Is this a known bug?

EDIT: there is 'ArgyllCMS Patches' being displayed at top left corner of the screen. The patches are very small and I noticed the 'image area' slider being reset back to 1%

EDIT2 : each time madTPG loads new batch of patches from displaygui, the 'image area' slider being reset to 1%

EDIT3 : Any idea to keep the 'image area' from being reset?

EDIT4 : Found this -P0.5,0.5,10,10 argument for dispcal, but after 3rd or 4th batch of patches, it resets back to 1% again.
madTPG has APIs that allow the calibration software to control all aspects of madTPG. It seems that ArgyllCMS/dispcal overwrite the "image area" choice you've made in the madTPG GUI. There's nothing I can do about that. You would have to talk to the ArgyllCMS/dispcal developers. I'm sorry, I wish I could be more helpful. But if the calibration software uses the APIs then I must obey. Otherwise the APIs would serve no purpose.

Generally, for ArgyllCMS/dispcal related topics, your best thread for support is this one:

http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms.html

My back-forth jumping problems in window mode (old path) appear to be fixed by v0.88.20.
Cool, at least some good news.

[ashlar42]

Hi madshi, thanks for all the incredible work you offer for free to us all. :)

Do you have an ETA of sort (asking about months time range, not specific dates) for rendering subtitles on black bars? I love madVR quality but yesterday, while watching a 2:35 movie I really missed the opportunity to shift the subs where they wouldn't bother the picture.

Thanks.

[JohnLai]

madTPG has APIs that allow the calibration software to control all aspects of madTPG. It seems that ArgyllCMS/dispcal overwrite the "image area" choice you've made in the madTPG GUI. There's nothing I can do about that. You would have to talk to the ArgyllCMS/dispcal developers. I'm sorry, I wish I could be more helpful. But if the calibration software uses the APIs then I must obey. Otherwise the APIs would serve no purpose.

Generally, for ArgyllCMS/dispcal related topics, your best thread for support is this one:

http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms.html



When 'use fullscreen' of madtpg is disabled, the 'image area' slider doesn't get reset at all.

This is weird....
I was able to finish calibration on 3 monitors without the 'image area' getting reset to 1% if the madtpg 'use fullscreen' is disabled.

[baii]

Hi madshi, thanks for all the incredible work you offer for free to us all. :)

Do you have an ETA of sort (asking about months time range, not specific dates) for rendering subtitles on black bars? I love madVR quality but yesterday, while watching a 2:35 movie I really missed the opportunity to shift the subs where they wouldn't bother the picture.

Thanks.

Use mpc-hc build in sub renderer(or renderer other than xysub filter) as a current work around. It don't have all the fancy feature though ~

[XMonarchY]

I am confused about SR HQ settings. Which SR settings are considered HQ for both Chroma Upscaling and Upscaling Refinement? At the moment, I set Chroma Upscaling SR to passes = 4, strength = 1, softness = 0, then I set Upscaling Refinement SR to strength = 1 and radious = 0.66. Are the SR settings I just listed using considered HQ? I do not use any sharpening through madVR because I am kind of forced to use TV's slight sharpening, considering my setup.

[Deim0s]

Does that still occur with v0.88.20?
Yes. In v0.88.20, performance is even worse than *18, *19.

[leeperry]

If you remember, I actually told you that you should try AdaptiveSharpen if you liked the look of LQ SuperRes, because AdaptiveSharpen and LQ SuperRes have a similar look. But then you replied with:

> I'm not interested in running another sharpening filter
> on top but thanks for the advice

Different sharpening algorithms and HQ vs LQ SuperRes produce quite noticable differences, if you use a sharp image for testing. Easy to see in screenshots for everybody.

You're completely right, I assumed that SR was using the same kind of revolutionary CSI-like techniques as what intelligence agencies use or what nvidia got CUDA accelerated a while ago: http://www.motiondsp.com/products/IkenaForensic
reconstruct the characters on a license plate using Ikena’s super-resolution (which combines the best information from multiple frames of video)
Then I assumed that SR in mVR was using the implementation Shiandow explained (http://forum.doom9.org/showpost.php?p=1721618&postcount=94) but you then told me that it wasn't, so at this point I do not know what SR in mVR *really* does.....and in the end sxbr+AS would very much appear to fit my needs as well....still need to run more tests on that, though.

I also thought that you meant I should use AS together with SR and I certainly don't see it working, especially in HQ mode as 1 is utterly oversharp in LQ and I hate the look of HQ as much as you seemingly hate LQ.....Also, two seperate knobs for the number of passes and strength are very much required IMO but you're the boss and what matters is your own satisfaction.

Yeah, thanks for the screenshots. One problem with such screenshots is that we don't really know what to shoot for. How *should* the image really look like?
Exactly what I feared and at the end of the day it might very well be purely subjective and/or display-dependent, but that doesn't change anything to the fact that 1 was way oversharpened and completely unusable in LQ mode using .19.

rendering subtitles on black bars?
PotP does it, using keyboards shortcuts at that and it also has an option to do it automatically.

[James Freeman]

I apologize for the intrusive question but, how important is this new OSD speed up anyway?
Seems to do more harm than good...

[madshi]

Do you have an ETA of sort (asking about months time range, not specific dates) for rendering subtitles on black bars?
I do not give ETAs, sorry. I'm a CIH user myself, though, so can be rest assured that I'd like to see that feature myself.

When 'use fullscreen' of madtpg is disabled, the 'image area' slider doesn't get reset at all.

This is weird....
I was able to finish calibration on 3 monitors without the 'image area' getting reset to 1% if the madtpg 'use fullscreen' is disabled.
Well, as I said, I don't know which madTPG APIs ArgyllCMS is calling, so it's hard for me to comment on any of this. And as I said, your best hope for getting useful feedback about ArgyllCMS related topics is that AvsForum thread I linked.

I am confused about SR HQ settings. Which SR settings are considered HQ for both Chroma Upscaling and Upscaling Refinement? At the moment, I set Chroma Upscaling SR to passes = 4, strength = 1, softness = 0, then I set Upscaling Refinement SR to strength = 1 and radious = 0.66. Are the SR settings I just listed using considered HQ? I do not use any sharpening through madVR because I am kind of forced to use TV's slight sharpening, considering my setup.
SuperRes for chroma upscaling is not up-to-date, and not up for "discussion" yet. SuperRes for upscaling refinement is always HQ now. You can just change the strength (usually the more the better, but more also costs more GPU power). Don't change the radius unless you know what you're doing.

Yes. In v0.88.20, performance is even worse than *18, *19.
Oh dear... :(

Exactly what I feared and at the end of the day it might very well be purely subjective and/or display-dependent, but that doesn't change anything to the fact that 1 was way oversharpened and completely unusable in LQ mode using .19.
The reason for that is that LQ mode sucks. Big time. But more about that (and the scientific background) in my next post (just writing it).

I apologize for the intrusive question but, how important is this new OSD speed up anyway?
Very important. More important for some media players than others, though.

Sorry, problem still exists. :(
Testing with full power (P0 state) to avoid misinterpretation of the stuttering,
D3D11, FSE, still has unreported stuttering, Only in FSE.
All other modes are OK.
FWIW, can you try setting the flush setting for "after intermediate render steps" to "flush & wait (sleep)"? Does that help? Probably not, but it would be important to know for me.

[madshi]

I've decided to make a big screenshot comparison post to compare the different upscaling and sharpening / post-processing options we have now. In order to make all this more "scientific", I've decided that we need a "ground truth" image to compare to, because that's the only way to properly judge if an algorithm produces good results or not. If we don't have a ground truth to compare to, all our evaluations are somewhat subjective. So here comes:

GroundTruth (http://madVR.com/doom9/castle/CastleBig.png) -|- 50% downscaled (http://madVR.com/doom9/castle/CastleSmall.png)

50% downscaled image (Catmull-Rom LL AR):
http://madVR.com/doom9/castle/CastleSmall.png

So what we're going to do is take the 50% downscaled image, scale it back up, sharpen / post process it, and then we compare to the original ground truth. This way we can objective judge which upscaling algorithm and which post-processing produces the best results, by getting nearest to the original ground truth image.

I've selected this specific image because it contains both small and big geometical features (windows, roofs, etc), and a lot of nature (trees etc). So it's a good image to showcase different weaknesses of the various algorithms.

Let's start with comparing different scaling algorithms without any post-processing:

Bilinear (http://madVR.com/doom9/castle/ScalingAlgos/CastleBilinear.png) -|- Catmull-Rom (http://madVR.com/doom9/castle/ScalingAlgos/CastleCatmullRom.png) -|- Lanczos4 (http://madVR.com/doom9/castle/ScalingAlgos/CastleLanczos4.png) -|- Jinc (http://madVR.com/doom9/castle/ScalingAlgos/CastleJinc.png) -|- super-xbr (http://madVR.com/doom9/castle/ScalingAlgos/CastleSuperXbr.png) -|- NNEDI3 (http://madVR.com/doom9/castle/ScalingAlgos/CastleNNEDI3.png) -|- GroundTruth (http://madVR.com/doom9/castle/CastleBig.png)

Obviously, Bilinear is very bad. It's soft and has aliasing. Catmull-Rom is better, but still has some aliasing and it's still softer than the other algos. Jinc and Lanczos4 are somewhat comparable. Lanczos4 is a bit sharper, but Jinc has a bit less aliasing, so no clear winner between these two, I guess. super-xbr is sharper and has less aliasing than either of these, but the trees look less natural compared to Lanczos4 or Jinc. E.g. look at the tree which covers the bottom left of the castle. It looks more like an oil painting in the super-xbr image. NNEDI3 wins by a mile, I would say. It's more focused and has less artifacts than super-xbr. Trees are ok, not as oily as in the super-xbr image. I used 256 neurons in this comparison, though, which is probably not fair. Anyway...

Next step, let's compare different sharpening/post-processing algorithms, applied via Upscaling Refinement after image doubling with NNEDI3-256:

NNEDI3 (http://madVR.com/doom9/castle/ScalingAlgos/CastleNNEDI3.png) -|- NNEDI3+AdaptiveSharpen(0.8) (http://madVR.com/doom9/castle/Sharpening/CastleNNEDI3AdaptiveSharpen.png) -|- NNEDI3+FineSharp(4.0) (http://madVR.com/doom9/castle/Sharpening/CastleNNEDI3FineSharp.png) -|- NNEDI3+SuperRes(4) (http://madVR.com/doom9/castle/Sharpening/CastleNNEDI3HqSuperRes.png) -|- GroundTruth (http://madVR.com/doom9/castle/CastleBig.png)

To my eyes FineSharp comes nearest to the ground truth here. FineSharp manages to increase the perceived detail level and to make the image appear sharper, without making it look artificial. On the other hand, it also sharpens the heck out of any artifacts that might be in the original source or produced by the scaling algorithm. NNEDI3 did make some mistakes, and FineSharp gladly makes them even more obvious. SuperRes is near to FineSharp in detail level and sharpness, but at the same time manages to hide all artifacts caused by NNEDI3. So SuperRes is not only a good sharpener, but also manages to repair errors of the upscaling algorithm. AdaptiveSharpen also manages to sharpen the image (of course), but IMHO it moves the image further away from the original image, instead of bringing it nearer. E.g. the trees seem to lose detail when using AdaptiveSharpen, which is pretty bad.

Now let's make the same comparison, but using super-xbr instead of NNEDI3:

super-xbr (http://madVR.com/doom9/castle/ScalingAlgos/CastleSuperXbr.png) -|- super-xbr+AdaptiveSharpen(0.8) (http://madVR.com/doom9/castle/Sharpening/CastleSuperXbrAdaptiveSharpen.png) -|- super-xbr+FineSharp(4.0) (http://madVR.com/doom9/castle/Sharpening/CastleSuperXbrFineSharp.png) -|- super-xbr+SuperRes(4) (http://madVR.com/doom9/castle/Sharpening/CastleSuperXbrHqSuperRes.png) -|- GroundTruth (http://madVR.com/doom9/castle/CastleBig.png)

Again FineSharp and SuperRes produce a similar look, but FineSharp here mercilessly puts our nose on every small problem super-xbr might have with this image, making directional interpolation artifacts stand out like a sore thumb. AdaptiveSharpen is a bit more forgiving, but again, it reduces perceived details in the trees and moves the overall image look away from the ground truth. SuperRes clearly wins here. It moves the image nearer to the ground truth, and at the same time fixes (or at least improves) many of the super-xbr artifacts.

So my judgement so far would be that SuperRes is the best post-processing algorithm, which brings the upscaled image nearer to the ground truth, and at the same time repairs some of the errors introduced by the (different) weaknesses of the upscaling algorithms. Based on that, here's another comparison, comparing different upscaling algorithms, followed by SuperRes:

Bilinear+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleBilinearHqSuperRes.png) -|- Jinc+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleJincHqSuperRes.png) -|- super-xbr+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleSuperXbrHqSuperRes.png) -|- NNEDI3+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleNNEDI3HqSuperRes.png) -|- GroundTruth (http://madVR.com/doom9/castle/CastleBig.png)

What we can see here is that SuperRes works well even when using Bilinear upscaling. However, SuperRes does *not* remove aliasing artifacts caused by the upscaling algorithm. E.g. look at the roof edges of the left two towers. Both Bilinear and Jinc have aliasing problems there. super-xbr and NNEDI3 have not. Because of this reason, my recommendation would be to use either super-xbr or NNEDI3, followed by SuperRes, for best image quality. The difference between super-xbr and NNEDI3 is pretty small, if you follow it up with SuperRes with high strength. So using super-xbr should save some precious GPU performance. Using Jinc+SuperRes might be an option, too, but you'll likely get more aliasing problems compared to super-xbr+SuperRes.

-------

Finally, let's talk about HQ vs LQ SuperRes. In v0.88.15 there was an option to use HQ downscaling or not. Newer versions hard coded this to use HQ downscaling. But some users still prefer having HQ downscaling disabled. So let's compare HQ vs noHQ (= LQ) SuperRes:

super-xbr (http://madVR.com/doom9/castle/ScalingAlgos/CastleSuperXbr.png) -|- super-xbr+SuperRes(HQ) (http://madVR.com/doom9/castle/LqVsHq/CastleSuperXbrHqSuperRes.png) -|- super-xbr+SuperRes(HQ)+AdaptiveSharpen (http://madVR.com/doom9/castle/LqVsHq/CastleSuperXbrHqSuperResAdaptiveSharpen.png) -|- super-xbr+SuperRes(LQ) (http://madVR.com/doom9/castle/LqVsHq/CastleSuperXbrLqSuperRes.png) -|- GroundTruth (http://madVR.com/doom9/castle/CastleBig.png)

What you can see here is that SuperRes HQ brings the super-xbr upscaled image much nearer to the ground truth. Obviously some details must be lost through the 50% downscaling + upscaling process, but the overall look of the image is very very near to the ground truth. Compare to that super-xbr+SuperRes(LQ). It looks terrible in comparison, IMHO. It actually moves the super-xbr upscaled image *away* from the ground truth. But for users who (for some reason that I don't understand) prefer the SuperRes(LQ) look, you can get it with v0.88.20, too, by using SuperRes(HQ) and adding some AdaptiveSharpen on top. The end result is near to SuperRes(LQ), but with a better quality. SuperRes(HQ)+AdaptiveSharpen has a similar look for SuperRes(LQ), but with less artifacts and a more natural looking image. It's still far away from the ground truth, though, so I don't recommend using it.

Now I guess the SuperRes(LQ) prefering users will argue that the strength I used for SuperRes(LQ) was *way* too high (I've actually used strength 4, which means 8 passes with the old strength value of 1.0). However, argueing that the strength was too high is beside the point. Why? Let me explain:

SuperRes is by design an iterative algorithm. Which means that it's designed in such a way that we're *supposed* to run multiple passes of the algorithm. The first pass does a lot of changes, the 2nd pass still does some, but less. Every further pass still changes something, but the amount of changes gets less with every further pass. At some point, after running "X" passes, the image will be fully converged into the "final SuperRes" image, and running any more passes will not change anything, anymore. Most of these iterative algorithms ideally aim to be run with as many passes as needed to get to the converged image. We're usually supposed to execute one pass after the other, until there are no further changes done to the image.

So if we want to test if the SuperRes algorithm is any good, ideally we should run a million passes, to get to the fully converged SuperRes image. And then we can judge if we like that final image or not. The LQ vs HQ screenshots above are not fully converged, but they're probably 90% there. So they do allow us to judge whether we like the direction into which SuperRes is going. I think most of us will agree that the direction LQ is going is away from the ground truth, while HQ is going nearer to the ground truth (at least with this specific test image).

With LQ, the users who prefer it are asking for lower strength and passes settings. Why? Because they don't like the look of the fully converged SuperRes LQ image themselves. Which is a clear indication that something is wrong. They like low strength settings because they don't like the full uglyness of the fully converged SuperRes LQ setting.

In contrast to that, using HQ brings us nearer to the ground truth, and there each added pass (with full strength) is actually beneficial. So when using HQ SuperRes, we can give users the simple recommendation to use as high a strength as their GPU power allows. The more the better.

-------

Let me finish by saying that all of the above is of course only *one* test image. Results could in theory vary with other test images. I would like to encourage anyone who is interested in this kind of comparisons to repeat the same tests I've done, with a different test image. But please make sure you have a ground truth to compare to, because only that allows us to objectively judge. Otherwise all we can say is subjective mumbo-jumbo, and every user will have different preferences.

-------

Comments welcome!

[Anima123]

Would you suggest that SuperRes been used right after image-doubling and before final scaling to the target screen resolution, to get scientifically better image quality?

What kind harm can be if applying SuperRes after scaled to screen resolution, does it vary by the scaling algorithm used?

Edit: I understand the convergence you are talking about, but shouldn't the convergence rate be related to the strength SuperRes applied? I guess that's part of reason somebody prefer lower strength, more passes than the contrary. It also can explain why some people like the LQ version with lower strength.

[madshi]

In my test I've downscaled 50% and then doubled image resolution to get back to 100%. So there was no further scaling needed after image doubling. I think this is the fairest test. Of course in real life you often need to scale to "odd" target resolutions. I would recommend to activate "refine the image only once after upscaling is complete", when using SuperRes. If image doubling is then followed by some more up- or downscaling, SuperRes will wait for all scaling operations to complete and only afterwards do its work on the fully scaled image. SuperRes does not really care much about whether it runs after image doubling, or after scaling to an "odd" target resolution. It works well in either case.

If you use a lower strength setting, you need more passes to get to the fully converged image. But the final result should be identical. leeperry believes that 3 passes with 0.65 strength looks better than 2 passes with 1.00 strength, but I call that a myth (I believe he sees what he expects to see, and not what is really there - sorry leeperry!), until it gets proven by screenshots.

[Akeno]

Adaptive Sharpen: Seems pretty destructive when it comes to real life material. It works a lot better for anime material where there aren't as many fine details and is the most ideal image enhancer.

FineSharp: Feels unusable at this point due to the extreme artifacts it produces, although I suppose there would be no problem with a nearly 100% clean source.

LumaSharpen: I can't see a reason to use it personally. It just isn't as noticeable as the other algorithms but maybe my settings are wrong.

SuperRes: NNEDI3 and Super-XBR look damn near identical outside of a tiny artifacts in s-xbr. LQ is also extremely painful to look at. It looks oversharpened and looks slightly pixelated in the edges of the windows.

-----
My system can't run both NNEDI and SuperRes in tandem. My personal choice therefore depends on the material that I intend to watch. Anime material (and CG to a degree) suffers little from Adaptive Sharpen which does a number on live material. I was initially put off by s-xbr but it seems that SuperRes alleviates most of my worries.

On a side note, madshi, you recommend 32 Neurons as a minimum for luma doubling due to artifacts with 16. My system can't run 32 with 30fps material but I haven't noticed anything wrong with 16. Could you elaborate on what kind of artifacts there are or post some pictures?

[JarrettH]

I love the smooth contours of super-xbr :)

I think we've gone a little overboard obsessed with sharpening. Doubling already increases sharpness and super-xbr needs no enhancement IMO.

Would it be possible to add super-xbr at 75 to this comparison?

Super-xbr definitely looks sharp, and when you compare it to the original, it retains the blinding white brightness reflected from the castle.

[Gagorian]

madshi are you familiar with the DarbeeVision Darblet used amongst HT enthusiasts? I've been quite happy with the sharpening it provides (at low strength). I wonder if there's any similar algorithm available to run on the GPU?

[har3inger]

Thanks very much for providing that comparison post, madshi. It gives us a better idea of what to look for from SuperRes and must have taken a lot of time to write up.

[baii]

I seem to get periodic frame drop (by either 1 or 2 frame on osd) when playing interlaced material in dx11 windowed mode. I don't seem to notice all(or any) the frame drop by eye(which is normal I think, consider it is 60fps video.., don't have that kind of eye xd). Would this be a osd glitch or real frame drop?
It is fine in dx11 fse or dx9.
I had play with all the vync/seperate device options, but none helps.
Configuration is win8.1, Amd dxva de-interlance, reclock, 30i material, 59/60hz screen. Tested in recent .14 and .20.

Sent from my 306SH

[ryrynz]

I think we've gone a little overboard obsessed with sharpening.

Indeed. I'm waiting for denoising TBH.

[har3inger]

I have found a bug with 30 fps content with the latest .20 build. OSD reported render times are well under 2 ms (which is impossible for my hardware specs: last version reports render times ~28ms for same settings), but cranking up settings will caused dropped frames while the OSD reports <20ms render times. This is a cosmetic bug with no functional problems that I can see. Problem didn't occur in .19 and earlier. No rendering time calculation errors with 24 fps content. Don't have access to any other framerate content to test.

Windows 8.1 x64, mpc-hc x64, madvr x64, LAV filters 65.0. Image upscale jinc ar, chroma bicubic 75 ar. No image doubling.

[Della]

Outstanding post Madshi. I now have a clear, visual understanding of the various options.
Thank you.

[pirlouy]

You may have lost a lot of time writing this, but for a lurker, this is the kind of post I like to read. Images for us to judge, and your comments/POV on this. Definitively a good post. It avoids endless discussions without proof. And it allows us to choose accordingly.

[MS-DOS]

Thanks for the great post, madshi.

However, using 256 neurons for NNEDI3 as "the best option" may not be a good idea. I've recently found an example where 256 neurons cause a very notable artifact:

Original (http://i.imgur.com/3WdMEzF.png) -|- NNEDI3 128 (http://i.imgur.com/lR9JwQD.png) -|- NNEDI3 256 (http://i.imgur.com/LwqFbVV.png)

See a tiny white vertical line above Ramzesss word right between "m" and "z" ? It's not present on the original image, nor with any neuron count below 256.

[MistahBonzai]

I've decided to make a big screenshot comparison post to compare the different upscaling and sharpening / post-processing options we have now. In order to make all this more "scientific", I've decided that we need a "ground truth" image to compare to, because that's the only way to properly judge if an algorithm produces good results or not...

-------

Comments welcome!

That was Crème de la Chem to this OCD pixel peeping vidiot! I really appreciate your dedication and the hard work you put into this project. And that was another application of icing on the cake. Yup, truly outstanding.

[Hyllian]

I've decided to make a big screenshot comparison post to compare the different upscaling and sharpening / post-processing options we have now. In order to make all this more "scientific", I've decided that we need a "ground truth" image to compare to, because that's the only way to properly judge if an algorithm produces good results or not. If we don't have a ground truth to compare to, all our evaluations are somewhat subjective. So here comes:

Bilinear+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleBilinearHqSuperRes.png) -|- Jinc+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleJincHqSuperRes.png) -|- super-xbr+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleSuperXbrHqSuperRes.png) -|- NNEDI3+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleNNEDI3HqSuperRes.png) -|- GroundTruth (http://madVR.com/doom9/castle/CastleBig.png)


-------

Comments welcome!

Congrats for the amazing post! I confess I was a non-believer of SuperRes, but now I can see the light! :eek: It's almost as good as waifu2x-castle (http://i.imgur.com/HVSijXK.jpg).

It's just me or the sxbr+sres = nnedi3+sres? I can't spot a difference in a still, so in motion it should be even harder.

How many passes did you use for SuperRes in these examples?

EDIT: even bilinear+sres is almost identical to the others, with slightly worse aliasing!

[RyuzakiL]

Congrats for the amazing post! I confess I was a non-believer of SuperRes, but now I can see the light! :eek: It's almost as good as waifu2x-castle (http://i.imgur.com/HVSijXK.jpg).

It's just me or the sxbr+sres = nnedi3+sres? I can't spot a difference in a still, so in motion it should be even harder.

How many passes did you use for SuperRes in these examples?

EDIT: even bilinear+sres is almost identical to the others, with slightly worse aliasing!


see? that's what i've been using for (S-XBR+SuperRes) ever since the feature got introduced. I don't know why there are these NEDDI3 256 Fanatics/cult out there who always claim the holy grail for Picture Quality when the Madshi's Screenshots speaks for themselves. When performance is still important before Picture Quality (where NNEDI3 really lacks and burns precious GPU resources).

S-XBR+SuperRes = NNEDI3+SuperRes but very light on GPU load, Ergo you can build a HTPC with a cheaper GPU (less heat and power consumption) but at the same time still can use better MAdvr settings like this time (S-XBR+SuperRes).

[leeperry]

TYVM for the comparisons, I'll try my luck this week with running the same procedure but with NNEDI16/32 and 3@0.42 LQ SR in .15 coz comparing NNEDI256 to über-sharp LQ SR in .19 is kinda putting things out of context IMVHO, only one way to find out anyway and your testing procedure makes a heck lot of sense indeed gg :)

You don't seem too keen on telling us what SR does in mVR but it's not a "dumb" sharpener as it would appear? Does it take previous frames in account like the vmotion stuff and as the name implies?

[RyuzakiL]

It seems the said config is very good PQ/Performance wise for processing 1080pHQ Source.

I'm really interested on doing Madshi's Format of Picture/Screenshot comparison series.

But for the life of me, i cannot grab a screenshot on DX11 FSE10bit mode?

or i should switch to DX11 Windowed FS 8bit mode?

[leeperry]

But for the life of me, i cannot grab a screenshot on DX11 FSE10bit mode?
Yeah I'm also not too sure how to make screenshots in PotP, you'll apparently need to disable exclusive mode and press the <printscreen> key on your keyboard.

[MistahBonzai]

Yeah I'm also not too sure how to make screenshots in PotP, you'll apparently need to disable exclusive mode and press the <printscreen> key on your keyboard.
Yup - black images are not that informative:(

If working with MPC-HC these procedures will enable you to capture specific frames. I have to believe that there is a way to seek by frame in most video players..

This procedure saves the onscreen image assuming you are *not* in exclusive mode.

Uncheck "enable automatic fullscreen exclusive mode" in MadVR "general settings".
Open video in MPC-HC.
Pause video.
<Ctrl>+<g>
specify desired frame - example Frame: (2000, 23.976)
<alt>+<print screen>
Paste into video editor.


This procedure saves the image from the MPC-HC image renderer and not from MadVR
Open video in MPC-HC.
Pause video.
<Ctrl>+<G>
specify desired frame - example Frame: (2000, 23.976)
<Alt>+<i>
Select either jpg or png.
Save to the perefered folder.

Note: More than anything I would like a way to do MadVR screen shots from MPC-HC

[James Freeman]

D3D11,FSE unreported stutter
FWIW, can you try setting the flush setting for "after intermediate render steps" to "flush & wait (sleep)"? Does that help? Probably not, but it would be important to know for me.

Nope. Still stutters.

[QBhd]

For PotPlayer Video==>Video Capture.... Or just use Ctrl+Alt+E to grab the screen frame. Might want to go the menu route first to make sure you save as bmp or png. Ctrl+E will grab the source frame.

QB

[madshi]

Thanks for the positive feedback, guys! Happy to hear you like my comparison post! :)

Adaptive Sharpen: Seems pretty destructive when it comes to real life material. It works a lot better for anime material where there aren't as many fine details and is the most ideal image enhancer.
Yeah, I wasn't meaning to say that AdaptiveSharpen should never be used. It could be useful to sharpen overly soft sources, or simply to add some "pop". However, "Upscaling Refinement" was always planned by me to post-process an upscaled image in such a way that it gets nearer to the ground truth. So, I would say that for this specific purpose I would not recommend AdaptiveSharpen.

I'm not fully sure yet if the split with "image enhancements" and "upscaling refinement" will stay as it is. I've had the idea that I could probably modify FineSharp and AdaptiveSharpen so that they have the same effectiveness/strength when applied after upscaling compared to before upscaling. Sharpening after upscaling generally looks better. So it's possible the "image enhancements" may run after scaling in a future version, too (maybe with a trade quality option to perform it before scaling). But I don't know for sure yet.

FineSharp: Feels unusable at this point due to the extreme artifacts it produces, although I suppose there would be no problem with a nearly 100% clean source.
IIRC Didée also wrote it with very clean sources in mind. IMHO FineSharp does an amazing job considering its speed and simplicity. But requiring a perfectly clean source is of course problematic.

LumaSharpen: I can't see a reason to use it personally. It just isn't as noticeable as the other algorithms but maybe my settings are wrong.
There's a reason why I didn't include it in the comparison. LumaSharpen is very fast, but other than that I wouldn't recommend to use it.

On a side note, madshi, you recommend 32 Neurons as a minimum for luma doubling due to artifacts with 16. My system can't run 32 with 30fps material but I haven't noticed anything wrong with 16. Could you elaborate on what kind of artifacts there are or post some pictures?
Well, 16 neurons is ok, too, for many sources. It's just that it has a lot more aliasing in some situations (edge angles?) compared to 32. It depends on the situation, though. Often 16 neurons is just as good as 32 neurons.

I think we've gone a little overboard obsessed with sharpening. Doubling already increases sharpness and super-xbr needs no enhancement IMO.
Indeed. I'm waiting for denoising TBH.
Well, you guys would probably like it if madVR could magically turn any downscaled image back into its original high res image, wouldn't you? So that's exactly what I'm aiming at. If you look at the screenshots, the "sharpening" applied by SuperRes brings us nearer to the ground truth, which can only be considered a good thing, no?

That said, yes, some algorithms to clean up bad sources would be great. But I prefer to do one thing right first, before switching to the next thing.

Would it be possible to add super-xbr at 75 to this comparison?
Possible, yes, but I don't think it's worth the effort. super-xbr 75 is similar to super-xbr 100, just a bit softer with some less ringing. Should make no difference to directional artifacts.

madshi are you familiar with the DarbeeVision Darblet used amongst HT enthusiasts? I've been quite happy with the sharpening it provides (at low strength). I wonder if there's any similar algorithm available to run on the GPU?
I've not seen Darbee myself yet. But I've been told it does this:

> It's a frame-delayed unsharp mask. So if there's no
> movement in the scene, it's just plain unsharp mask.
> If there's a lot of movement, it's a random artifact
> generator. If there's a little movement, like on a slow
> pan or a helicopter shot, it's an unsharp mask that is
> more aggressive on one side of a detail and less
> aggressive on the other side, adding a little shadow.

So for still images, it should be somewhat similar to AdaptiveSharpen. One big disadvantage of current Darbee implementations is that if you let the display upscale (e.g. 4K display), Darbee is applied before upscaling. That's like applying AdaptiveSharpen in "image enhancements". It's effective, but ugly. You'd get better quality doing it after upscaling. But AFAIK current Darbee implementations don't have the power to do 4K.

Anyway, personally I'm not really a fan of the look that unsharp mask style sharpening produces. To my eyes it looks like fat lines get even fatter. It seems to "bloat up" the image somehow, adding more contrast and pop, but making the image look more artificial. You can see some of that in my screenshot comparison post when comparing AdaptiveSharpen to FineSharp. The look which AdaptiveSharpen produces is typical for unsharp mask style sharpening.

I seem to get periodic frame drop (by either 1 or 2 frame on osd) when playing interlaced material in dx11 windowed mode. I don't seem to notice all(or any) the frame drop by eye(which is normal I think, consider it is 60fps video.., don't have that kind of eye xd). Would this be a osd glitch or real frame drop?
It is fine in dx11 fse or dx9.
I had play with all the vync/seperate device options, but none helps.
Configuration is win8.1, Amd dxva de-interlance, reclock, 30i material, 59/60hz screen. Tested in recent .14 and .20.
So it occurs with .14, too? Might be that your GPU is near its power limit, and using DX11 windowed mode just pushes it over the edge sometimes. Don't know for sure. It's probably a real drop. You might not see it during scenes where there's not a lot of motion. Is it a natively interlaced source (e.g. sports)? Or is it telecined film? In the latter case you could force madVR's film mode. That way GPU power reduces by a factor of 2.5x, while producing smoother playback (no 3:2 judder).

However, using 256 neurons for NNEDI3 as "the best option" may not be a good idea. I've recently found an example where 256 neurons cause a very notable artifact:

Original (http://i.imgur.com/3WdMEzF.png) -|- NNEDI3 128 (http://i.imgur.com/lR9JwQD.png) -|- NNEDI3 256 (http://i.imgur.com/LwqFbVV.png)

See a tiny white vertical line above Ramzesss word right between "m" and "z" ? It's not present on the original image, nor with any neuron count below 256.
Yes, I see it. I'm not sure if 256 neurons are generally a bad idea, though. NNEDI3 is not artifact free. In my experience any neuron number can produce artifacts in some images, where a different neuron count might not produce an artifact. There might be situations where 128 neurons produce an artifact and 256 neurons do not. Anyway, 256 neurons is so expensive, most users won't have the GPU power for that, anyway. In any case, it's probably better to use a much lower neuron count and run some SuperRes passes afterwards.

I confess I was a non-believer of SuperRes, but now I can see the light! :eek: It's almost as good as waifu2x-castle (http://i.imgur.com/HVSijXK.jpg).
waifu2x is quite amazing. It does clearly beat NNEDI256+SuperRes, when looking at the geometrical features in the castle image. However, I think SuperRes reproduces the trees better. All those "clever" upscaling algorithms often mess up trees and nature. SuperRes somehow manages to reproduce a more natural look there. Would be interesting to see how waifu2x+SuperRes would look like. With a bit of luck, it might combine the best of NNEDI3+SuperRes and waifu2x.

Anyway, Shiandow has estimated that waifu2x is probably at least 100x slower than NNEDI3-256, maybe more. So it's not suitable for real time video playback in the next 7 years at least, I would say.

It's just me or the sxbr+sres = nnedi3+sres? I can't spot a difference in a still, so in motion it should be even harder.

How many passes did you use for SuperRes in these examples?
It's not just you. They're almost identical. There's one artifact, though, which super-xbr has (and NNEDI3 has not), which SuperRes doesn't fully remove. See red circle here:

http://madVR.com/doom9/temp/CastleSuperXbr.png (http://madVR.com/temp/CastleSuperXbr.png)

This specific geometrical configuration seems to be difficult. Even waifu2x has problems with this. Not on this specific tower, though. But if you look at the smaller right most tower, waifu2x is not perfect with the same geometrical configuration there. NNEDI3 handles that better, but NNEDI3 has small problems in other areas.

The screenshots were created with 8 SuperRes passes.

TYVM for the comparisons, I'll try my luck this week with running the same procedure but with NNEDI16/32 and 3@0.42 LQ SR in .15 coz comparing NNEDI256 to über-sharp LQ SR in .19 is kinda putting things out of context IMVHO, only one way to find out anyway and your testing procedure makes a heck lot of sense indeed gg :)
Glad to hear you like my testing procedure. I tried to find a way to make things less subjective, to increase the chances that we may end up on the same page.

You don't seem too keen on telling us what SR does in mVR but it's not a "dumb" sharpener as it would appear? Does it take previous frames in account like the vmotion stuff and as the name implies?
No, it only looks at one frame at a time. It pretty much does what Shiandow explained in that post you quoted earlier. But Shiandow's explanation was for the old SuperRes algo (where we still had number options for anti-aliasing and anti-ringing etc). The new algorithm is based on some newer scientific papers. It works like this:

0) Let e.g. super-xbr upscale the OI (original image). Result: UI (upscaled image).
1) Downscale the UI back to the same size as the OI (using: LQ=Bilinear; HQ=Bicubic).
2) Substract the OI from the downscaled UI, which gives us a sort of "error" image (EI) in the size of the OI.
3) Modify the UI in a clever way, by making use of the EI, to reduce the error.

Steps 1) to 3) is one SuperRes pass. If you want 2 SuperRes passes, you simply perform 1,2,3) twice.

All the magic happens in 3). And this code totally changed from the old to the new SuperRes algorithm. The other parts mostly remained unchanged. The old SuperRes code introduced aliasing and ringing, which is why Shiandow had added extra anti-aliasing and anti-ringing algos. The new SuperRes algorithm doesn't (or shouldn't) produce aliasing, anymore, and not as much ringing as the old code, so that's why there's no anti-ringing and anti-aliasing code in the new algorithm, anymore. I did add my own anti-ringing code in, though.

I'm really interested on doing Madshi's Format of Picture/Screenshot comparison series.
Yes, please!

I've done all stuff in windowed mode. I've selected a ground truth image which in 100% view exactly fit in the media player in windowed mode, to make things easier for me. The ground truth is already a downscaled image from an even larger original image. So I could choose the exact size I wanted to have for the ground truth.

Please make sure you downscale using madVR with AR (anti-ringing). Don't downscale using an image/photo editor, unless it also has AR (I'm not aware of any that has).

Nope. Still stutters.
Ok, thanks.

[Braum]

Yeah I'm also not too sure how to make screenshots in PotP, you'll apparently need to disable exclusive mode and press the <printscreen> key on your keyboard.
It works that way, but you can also setup your own keybord shortcuts (but still need to disable FSE :/).

http://img11.hostingpics.net/pics/869947Sanstitre.png