madVR - high quality video renderer (GPU assisted)

[madshi]

Similar to your sample image, Jinc3 anti-ringing shows those sharp bright/dark residual ringing specks, and soft dark residual ringing around edges of fonts rendered by xy-VSFilter on 720p video. This isn't surprising, since not unlike your test image, fonts are extremely sharp high-contrast vector shapes. The overall Jinc3 anti-ringing result on 720p is softer with more ringing than Spline36 anti-ringing. When upscaling 360p, Jinc3 anti-ringing more clearly shows it's major advantage of lacking aliasing, but it's still softer than Spline36 anti-ringing, and seems to have around 10x more residual ringing around the edges of fonts and other hard edges.
Can you make a few BMP/PNG screenshots of the original unscaled video from different scenes/movies, where upscaling with Jinc AR shows these artifacts, and where Spline36 looks better to your eyes? Having those PNG screenshots would allow me to reproduce the issue on my PC and to try to fine tune the AR algorithm to fix the problem. PNG screenshots might actually be more practical for this than movie samples.

Linear light scaling seems to average ~10% faster rendering times on my GT440 DDR5 with this build. Would anything you changed reduce the serious aliasing + ringing which linear light scaling caused when upscaling, or should that be pretty much unchanged in this build (i.e. should I spend time re-testing)?
It's only faster. Quality should be unchanged. Meaning I don't recommend using it for upscaling. The only thing I consider it useful is maybe when downscaling with a relatively large downscaling factor.

[leeperry]

:thanks: for the new builds, they're working amazingly well as usual!

BTW, is your AR mod a big secret or is there any way it could make it to ffdshow somehow? 'coz I SuperSample my Avisynth script to death in ffdshow and once you've tasted AR, you're basically doomed :scared:

If ppl wanna try another kind of dithering, they can always give the SmoothLevels() Avisynth script a go: it does Floyd Steinberg dithering (http://forum.doom9.org/showthread.php?p=1468213#post1468213). I posted comparisons against mVR a while ago and what looks best for me on a 10bit CRT is a combination of both, but apparently for ppl on a (6bit TN?) LCD, it looked bandy as hell. As usual there's no BEST.

[Duffy Moon]

Thanks for the new build madshi. I was getting a blank screen after changing files but it's all fixed now.

Keep up the good work.

Edit: I just tried a DVD and it crashed MPC-HC when it got to the main menu screen.

[6233638]

Overall though, I still personally don't see Jinc's increased ringing and softness compared to Spline as a great compromise, just to eliminate aliasing. On the other hand, if you were able to bring residual ringing down to Spline36 anti-ringing levels without increasing softness further, it would suddenly become a compelling option for upscaling low-res and DVD content IMHO.It's always a balance between ringing, sharpness and aliasing, and which bothers you the most is personal preference.

For me, I want as little ringing and aliasing as possible, which is why I tend to fall back on SoftCubic 80. (without the anti-ringing filter) This had the lowest amount of aliasing of the filters before Jinc came along (well, SoftCubic 100 did, but it's too soft even for me) and almost no ringing, but obviously it's very soft.

I've been having a closer look over this again tonight, and it seems that if your primary concern is to have the least amount of ringing in the image, without sacrificing sharpness, Catmull-Rom anti-ring easily bests the other choices. (but you have aliasing, as with most filters)

The only resamplers with less ringing than that are Mitchell-Netravali anti-ring (soft, aliased) and SoftCubic 80. (very soft, low aliasing)


Jinc has the lowest amount of aliasing of any of the resamplers (significantly less in some cases) and compared to SoftCubic, the previous best, it's considerably sharper. But this comes at the expense of still being softer than the "sharp" choices, and having a moderate level of ringing. The only other option with "good" aliasing handling is Lanczos 8, and there are significant ringing problems there.


There's actually about the same amount of ringing with Jinc as there is with Spline - it's slightly lower intensity, with a slightly wider radius. (which is better in my opinion) The difference is that the anti-ringing filter seems to clean up Spline more than Jinc right now.

[madshi]

The difference is that the anti-ringing filter seems to clean up Spline more than Jinc right now.
Samples welcome. PNG screenshots (using the media player's screenshot functionality, so no scaling is performed) would be ideal.

[madshi]

BTW, is your AR mod a big secret or is there any way it could make it to ffdshow somehow? 'coz I SuperSample my Avisynth script to death in ffdshow and once you've tasted AR, you're basically doomed :scared:
I've explained the basic algorithm in this thread:

http://forum.doom9.org/showthread.php?t=145358

I'm constantly tweaking the algorithm, though, to find the right balance between supressing ringing and not introducing new artifacts, so that thread is not fully up-to-date on my current algorithm. I'm not sure how fast my AR algorithm would run on a CPU, but I guess with a decent CPU it should work just fine. However, performance should be quite a bit slower than "simple" scaling without AR.

Thanks for the new build madshi. I was getting a blank screen after changing files but it's all fixed now.
Glad to hear that.

Edit: I just tried a DVD and it crashed MPC-HC when it got to the main menu screen.
Did you get a crash report? DVD playback is not officially supported by madVR yet. If the crash is in MPC-HC (and not in madVR) then there's not so much I can do. If the crash is in madVR, I can have a look. If the crash is in madVR, you should get a crash box, allowing you to send a bug report to me.

[cyberbeing]

When upscaling, I value sharpness with nice an crisp fine contrast the most. All algorithms with less sharpness than Bicubic 60, are too soft for my eyes. After my minimum level of sharpness is known, next on my priority list come reduction of artifacts.

Without madVR anti-ringing, all algorithms for more ringing than Spline64 I find unacceptable. With madVR anti-ringing, I don't want to see any obvious bright or dark ringing on close examination. madVR anti-ringing does a marvelous job eliminating ringing with Spline36. Lanczos3 is the absolute maximum amount of ringing I'm willing to accept with madVR anti-ringing.

When it comes to aliasing, Lanczos3 anti-ringing is probably slightly better than Spline36 anti-ringing. Though on close examination I always notice increased ringing of Lanzcos3 before I notice increased aliasing of Spline36.

This currently makes Spline36 anti-ringing my preferred option for general luma upscaling.

I want to like Jinc for is nice anti-aliased look, but it falls below my preference for minimum sharpness. The only way I'd personally be willing to balance that loss in sharpness, is if it had no more ringing than Spline36 anti-ringing. The only way I'd personally be willing to balance the present amount of ringing with Jinc anti-ringing, is if it had significantly more sharpness. Unfortunately neither are currently the case.

the anti-ringing filter seems to clean up Spline more than Jinc right now.
I'd agree that this most likely the current problem I have with Jinc.

@madshi I'll try to provide you some unscaled screenshots which show a noticeable Spline/Jinc anti-ring difference within the next week.

[Jong]

Any chance the frame drop/repeat estimate is wrong in the latest builds? Maybe only when using Reclock?

The same 720p video with 82.5, shows days between repeats/drops but 1-3 mins in 84.3. Yet, no drops or glitches actually happen. :confused:

[Ver Greeneyes]

Yeah, after the experiments with Sigmoidization my expectations are that your shaders will also improve some test images and make things worse in other test images. It seems to me that all color space manipulations have this effect. But we can try. Maybe if you've got in running in MPC-HC we could test it there before trying it in madVR. Because if it isn't convincing in MPC-HC then I could save the time to try it in madVR.
Well, I got it working in MPC-HC but I have no idea if it's even possible to make a shader that performs the scaling for it (at least without modifying the source code - presumably that bilinear filter shader is in there somewhere). There's pre-scaling shaders and post-scaling shaders but no "unscaled input, scaled output" option. So it would only allow us to test the bilinear and bicubic scaling algorithms that are built in.

At any rate, I have to fix those artifacts first. Going to see if I can debug that today.

[NicolasRobidoux]

Mathias:
A few pointers. (Feel free to ignore or postpone.)

-----

With EWA used with a windowed-Jinc filter, you generally can vary the
deblur quite a bit with fairly predictable results: push the deblur
down and the sharpness and jaggyness increase. What this means is that
you should not feel "bound" by my suggestions for deblurs. My guess is
that the deblur that helps you make it interact best with AR is likely
to be the best deblur. I don't use AR or a similar method, and I
don't like 4-lobe methods, so in general my advice comes from a
different experiential context. But I can extrapolate.

-----

With this being said:

There are "special" deblurs.

First, there are "special" deblurs for people who value sharpness a
lot. Such deblurs probably should be used with a different windowing
than Jinc (that is, Jinc-windowed Jinc is probably not gospel here),
but I have not sorted this out yet.

Given that most of your interest lies with the 3- and 4-lobe methods,
I focus on those here.

The "sharp" deblurs are:

The one that gives EWA Lanczos Radius 3, that is, the one that gives
an EWA Lanczos 3 disk that always fits inside the tensor Lanczos 3
square: 0.9264075766146068

The one that gives EWA Lanczos Radius 4, that is, the one that gives
an EWA Lanczos 4 disk that always fits inside the tensor Lanczos 4
square: 0.9431597994328477

Such values will not give you the awesome antialiasing that EWA
LanczosSharp is "famous" for, but they may strike a better balance
between sharpness and jaggyness than tensor Lanczos methods, at least
with moderate numbers of lobes.

-----

Then, there are the deblurs for people who want to minimize jaggyness
without too much sharpness impact, but still with quite a bit.

Here, the plot gets a bit more complicated, because of how I guess
your AR filter works. Basically, the two different versions of the EWA
LanczosSharp (bad name, in retrospect; the point is that it's sharper
than the one with deblur = 1) differ in whether they try to minimize
the change in the closest grid line (that's the "old" version) or the
change over all grid lines (that's the "new" version). (I omit the fine print.)

It turns out that the old version is likely to be better with AR, the
new one, without AR.

Without AR:

With 3 lobes: 0.9891028367558475

With 4 lobes: 0.9870395083298263

With AR:

With 3 lobes: 0.9812505644269356

With 4 lobes: 0.9885991596850774

These values may change slightly when I rerun the numerical
computations that give them with a higher precision library. (Or I may
find it makes no difference, or I may find that I made a programming
mistake.)

In any case, they are all pretty close to each other, and pretty close
to 1, to the extent that other things---LUTs, original scanlines being
staggered, and most importantly, interaction with AR---probably have
more of an impact on results than choosing one over the other.

-----

So: There are values that are, in a sense, slightly better than
neighbouring ones, but going away quite a bit from these values may
give you something that you like better or that works better with AR.
With EWA, most deblurs are "good". But in different ways.

[nlnl]

@nlnl,

try this one:

http://madshi.net/madVRnlnl.rar

Does it fix the problem?

No, it does not :(
Please, have a look at the log and freeze report:
https://dl.dropbox.com/u/43376972/madvrnlnl_log_freez%2013-10-12.zip

Thanks!

[Duffy Moon]

Did you get a crash report? DVD playback is not officially supported by madVR yet. If the crash is in MPC-HC (and not in madVR) then there's not so much I can do. If the crash is in madVR, I can have a look. If the crash is in madVR, you should get a crash box, allowing you to send a bug report to me.

Sadly no, I didn't. I thought the only difference between when it worked and when it didn't was the new madVR build, but it may have been the latest beta of LAV filters or some clash with DSLibdvdnav.

Edit: It was the latest LAV beta - mindbomb has the same issue.

[6233638]

Samples welcome. PNG screenshots (using the media player's screenshot functionality, so no scaling is performed) would be ideal.Looking at it closer, it seems that the issue is that Jinc ends up with hard-edged ringing, rather than more ringing, which stands out more.

The text in this image (http://www.abload.de/img/sm-inv6njf7.png) shows it quite well. (at this point, it seems like "artificial" tests display these kinds of errors much easier than films)


I was wondering how you tweak the anti-ringing filter though? Is it that you have the filter constructed, and you are now tweaking values, or is it more complex than that?

If it's changing values, it seems like it might be useful to have a test build with a quickly thrown-together UI where we can adjust them ourselves. It's not that I don't think you are doing a good job, I just wonder if it might be better to have a larger group of people work on that, so that you can focus on other areas of madVR's development.

But then, it also seems that the values NicolasRobidoux is posting for the Jinc/EWA Lanczos etc. are very specific, so I don't know if that also applies to the anti-ringing filter.

[wiFFy]

v0.84.3 performs worse than v.0.84.2. Started dropping frames when I updated madVR.

Rendering times in 0.84.3 upscaling 720p to 1080p:
chroma lanczos3 ar, luma jinc3 ar. Rendering time 45ms Constantly dropping frames.
chroma lanczos3 ar, luma lanczos8 ar. Rendering time 37ms ok. Queues are constantly full.

Rendering times in 0.84.2 upscaling 720p to 1080p:
chroma lanczos3 ar, luma jinc3 ar. Rendering time 39ms ok. Queues are constantly full.
chroma lanczos3 ar, luma lanczos8 ar. Rendering time 33ms ok. Queues are constantly full.

madVR settings:

Windowed mode, delay playback start until render queue is full, delay playback start after seeking too, windowed overlay disabled, disable desktop composition, use a separate device for presentation, CPU queue size 20, GPU queue size 12, backbuffers 8, when and how shall the GPU be flushed: don't flush, flush & wait (sleep), don't flush, don't flush, trade quality for performance: all off.

Running on Intel HD 4000 ulv (laptop model), driver version 9.17.10.2849, windows 8 x64. Software decoding with lav.

[NicolasRobidoux]

But then, it also seems that the values NicolasRobidoux is posting for the Jinc/EWA Lanczos etc. are very specific, so I don't know if that also applies to the anti-ringing filter.I reiterate: Although there are values that can be argued to be "special", with EWA you can treat deblurs as if it's just a slider.
So: Yes I have special values. But they are not special enough that they should get in the way of what you a) like or b) works best with Mathias' AR or c) what works best given the rest of the toolchain.

[Fullmetal Encoder]

DVD playback is not officially supported by madVR yet.

My favorite part of that post :sly:

Thanks madshi, for all of your contributions! Jinc and your AR are very impressive indeed.

[Bandito]

when is madVR going to get sharpening filters?

[NicolasRobidoux]

...
The text in this image (http://www.abload.de/img/sm-inv6njf7.png) shows it quite well. (at this point, it seems like "artificial" tests display these kinds of errors much easier than films)
...
OK: Maybe I'll learn to love 4-lobe windowed Jinc methods, at least when using the "Radius = number of lobes" deblur. Here is the result of enlarging 7x with no colorspace or sigmoidization shenanigans with EWA Spline (meaning cubic B-spline windowing; this is the old ImageMagick "Cubic" filter and window) windowed Jinc 4 lobe with deblur set so that the radius is 4:
http://web.cs.laurentian.ca/nrobidoux/misc/madVR/robot/EWASplineJincRadius4.png
I'm not saying this scheme is the be all and end all. But the fact that it is the very first "Radius 4" EWA windowed-Jinc I tried with the level of understanding I now have about these things should tell you something.
(Of course, it does not have the "antialiasing EWA LanczosSharp is famous for": This is a fairly sharp low halo variant.)

[Tornado15550]

I'm disappointed that there is still NO 64-bit version of madVR available. Madshi, are you planning to take care of this soon? This is because I do not intend on further using 32-bit media players on a 64-bit version of Windows.

[Damien147]

Why it's bugging you so much?If you search the thread you'll see previous conversations ending at the point of even if...there won't be any real advantage.

[Duffy Moon]

I'm disappointed that there is still NO 64-bit version of madVR available..

there won't be any real advantage.

Additionally, it would take a lot of madshi's time to develop and then support. I think most of us agree that his time is better spent perfecting the 32-bit version first.

[burfadel]

Seek bar doesn't show for me (d3d fullscreen on secondary monitor), and the seek bar in mpc-hc doesn't do anything with madvr...

[mandarinka]

madVR v0.84.3 released
(...)
* maybe fixed: black screen after switching display mode

Sadly it doesn't seem to be, at least for me. (A8-3850 CPU/GPU, Windows 8 preview, 64-bit, latest AMD drivers I think).

P.S. I'm fresh to MadVR, so I may be missing something.

[ryrynz]

v0.84.3 performs worse than v.0.84.2. Started dropping frames when I updated madVR.


Drop your GPU queue size down to 4.

That being said, your really giving the HD4000 a workout with those settings, one small change here and there could cause dropped frames.
Keep in mind that quality is often preferred over performance in MadVR and if things get improved there may be a performance trade off.
Your settings may need to be changed to accommodate new versions as your basically at the limit of what the HD4000 can handle.

[Thunderbolt8]

I'm disappointed that there is still NO 64-bit version of madVR available. Madshi, are you planning to take care of this soon? This is because I do not intend on further using 32-bit media players on a 64-bit version of Windows.bye bye.

[NicolasRobidoux]

I'm going to leave this alone for a while (I'm sure Mathias can do with a break from my interventions), but indeed EWA cubic B-spline windowed Jinc Radius 4 (which is a 4 lobe method) is one of my better low halo but reasonably sharp EWA methods. It's OK with text-like things, if you don't mind some blockiness. The one suggested in "The Recommendations" when halo bothers you, namely EWA quadratic B-spline windowed Jinc 3-lobe (with no, or very very slight, deblur) is less jaggy, but more blurry. So I think that many people may prefer the 4-lobe version.
This being said, madVR has a decent anti-ringing system, that gets improved all the time, so this may not matter here.
-----
P.S.
Since I ended up talking about it, here is the result with EWA quadratic B-spline windowed Jinc 3 lobe with no deblur (and no sigmoidization or colorspace shenanigans):
http://web.cs.laurentian.ca/nrobidoux/misc/madVR/robot/EWAQuadraticJinc.png
And I may as well add "classic" EWA LanczosSharp:
http://web.cs.laurentian.ca/nrobidoux/misc/madVR/robot/EWALanczosSharpClassic.png

[wiFFy]

Drop your GPU queue size down to 4.Thanks for your reply. Whups, for some reason I forgot to mention that "delay playback start until render queue is full" and "delay playback start after seeking, too" are selected, so playback starts with full queues anyway. Changing GPU queue to 4 doesn't really change much as far performance is concerned. I'll edit my original post so there is no more confusion concerning that.

I did a little more testing and noticed that 720p to 1080p upscaling runs without dropped frames using lanczos3 without ar for chroma and jinc3 ar for luma. With lanczos3 ar for chroma and jinc3 without ar for luma it's too slow and it keeps dropping frames. Same goes for lanczos3 ar for chroma and jinc3 ar for luma with all "trade quality for performance" settings enabled.

That being said, your really giving the HD4000 a workout with those settings, one small change here and there could cause dropped frames.That's quite correct.:) According to GPU-Z gpu load is between 89% and 96% using v0.84.2 with lanczos3 ar for chroma and jin3 ar for luma. With v0.84.3 using the same settings gpu load is between 95% and 100%. I think that that hd4000 desktop model would have actually survived these changes from v.0.84.2 to v.084.3. If you got time, take a look at this article. (http://www.anandtech.com/show/5878/mobile-ivy-bridge-hd-4000-investigation-realtime-igpu-clocks-on-ulv-vs-quadcore) It pretty much explains why I would rather not drop my gpu queue too low when gpu load is reaching maximum.
Keep in mind that quality is often preferred over performance in MadVR and if things get improved there may be a performance trade off.
Your settings may need to be changed to accommodate new versions as your basically at the limit of what the HD4000 can handle.I'm hoping that with time we will get configurable antiringing as I think madshi has suggested and I could find some settings that my gpu can handle. I would really hate to completely lose antiringing with these settings.

I think I will keep using the v0.84.2 for now.

[ryrynz]

Thanks for your reply. Whups, for some reason I forgot to mention that "delay playback start until render queue is full" and "delay playback start after seeking, too" are selected, so playback starts with full queues anyway. Changing GPU queue to 4 doesn't really change much as far performance is concerned. I'll edit my original post so there is no more confusion concerning that.


It did for me on my HD4000, I could run your luma and chroma settings (both with AR) okay from 720 to 1080 upscaling.


I did a little more testing and noticed that 720p to 1080p upscaling runs without dropped frames using lanczos3 without ar for chroma and jinc3 ar for luma.


I was going to suggest this also, removing AR from chroma gives you a good 10% or so extra GPU on the HD4000, every little bit helps.

I think I will keep using the v0.84.2 for now.

Or overclock your HD4000, RAM speed may play a part as well.. I'm going to test that.

[wiFFy]

I keep editing my posts way too slow to keep up with you.:D
It did for me on my HD4000, I could run your luma and chroma settings (both with AR) okay from 720 to 1080 upscaling.Hmm, I need to recheck that.

Or overclock your HD4000, RAM speed may play a part as well.. I'm going to test that.
I don't think that the hd4000 ulv is overclockable. Atleast MSI Afterburner and Intel extreme tuning utility don't allow changing clockrates. Just to be clear, I'm running madvr on this laptop. (http://www.asus.com/Notebooks/Superior_Mobility/ASUS_ZENBOOK_UX32VD/)

Also it's already rather crippled memory bandwidth wise, since it's running on single channel. there is 2gb soldered to motherboard so there went my dual channel when I changed the original 2gb+2gb configuration to 2gb+8gb.

There is also the Geforce GT 620m, but as far as I've tested, it's completely useless when it comes to running madVR.

[ryrynz]

I don't think that the hd4000 ulv is overclockable. Atleast MSI Afterburner and Intel extreme tuning utility don't allow changing clockrates. Just to be clear, I'm running madvr on this laptop. (http://www.asus.com/Notebooks/Superior_Mobility/ASUS_ZENBOOK_UX32VD/)


Ahh performance may not be identical to my system then (Desktop i5 3570K). I did some benching and RAM speed does help for example setting Jinc 3 AR on luma and Lanczos 8 AR for chroma with my RAM at 1066Mhz 9-9-9-24
for a 30 second clip (720 to 1080 upscaling) I dropped 62 frames and delayed 281.

Setting it to 1600Mhz 9-9-9-24 that went down to 38/239, the command rate had an impact as well further impact as well dropping that to 32 dropped frames over 30 seconds.

But the biggest performance increase I had was overlocking the HD4000 to 1400Mhz which resulted in zero dropped and delayed frames so it's a shame the Intel extreme tuning utility doesn't work for you.

[strumf666]

Is it normal for madvr auto resolution matching to switch to 23,98Hz for 25p sources instead for 50Hz (my projector doesn't support 25p)? If it is, is there a way to bypass/force it?

[madshi]

Any chance the frame drop/repeat estimate is wrong in the latest builds? Maybe only when using Reclock?
I've not changed anything in any code related to that. I've only decreased the OS timer interval, but that should help rather than hurt these calculations. These estimations take a looooong time to settle down. Maybe you just need to wait a little bit longer? Or is the different behaviour between the 2 madVR versions 100% reproduceable? Does madVR estimate frame *drops* or *repeats*? FWIW, repeats are estimated, but not actually counted during playback. So if there are repeats, you will not see it in the OSD stats.

Looking at it closer, it seems that the issue is that Jinc ends up with hard-edged ringing, rather than more ringing, which stands out more.

The text in this image (http://www.abload.de/img/sm-inv6njf7.png) shows it quite well. (at this point, it seems like "artificial" tests display these kinds of errors much easier than films)
Ouch. Such computer graphics are terribly hard to handle for the anti-ringing filter. Basically any content which has a lot of "one color pixel next to totally different color pixel next to another totally different color pixel" is hard to handle correctly. I would be dead easy for me to make madVR work great for these type of computer graphics, but then real videos would suffer. Well, maybe I should try to analyze the type of content first and then switch between 2 different anti-ringing filters? I don't know. Will think about that...

I was wondering how you tweak the anti-ringing filter though? Is it that you have the filter constructed, and you are now tweaking values, or is it more complex than that?
It's much more complex than that. I'm playing around with different algorithms, even multi-pass shaders instead of single-pass shaders etc...

v0.84.3 performs worse than v.0.84.2. Started dropping frames when I updated madVR.

Rendering times in 0.84.3 upscaling 720p to 1080p:
chroma lanczos3 ar, luma jinc3 ar. Rendering time 45ms Constantly dropping frames.
chroma lanczos3 ar, luma lanczos8 ar. Rendering time 37ms ok. Queues are constantly full.

Rendering times in 0.84.2 upscaling 720p to 1080p:
chroma lanczos3 ar, luma jinc3 ar. Rendering time 39ms ok. Queues are constantly full.
chroma lanczos3 ar, luma lanczos8 ar. Rendering time 33ms ok. Queues are constantly full.
There are only 2 things which changed performance in v0.84.3:

(1) Linear light scaling, which should be slightly faster now.
(2) Jinc AR, which might be slightly slower now.

I'm still working on Jinc AR, it might get even slower in a future build, the algorithm is not totally finalized yet. It's unfortunate that it was fast enough for you in v0.84.2 and is just a tiny bit too slow in v0.84.3 now, but I can't stop optimizing it just because the optimization costs 3% more performance or something like that. Quality is more important than a couple percent performance.

All other filters (e.g. Lanczos AR) should perform identical. They haven't changed at all from v0.84.2 to v0.84.3.

when is madVR going to get sharpening filters?
Are you talking about custom pixel shader support, similar to what MPC-HC supports for EVR? Or are you talking about a dedicated sharpening algorithm implemented in madVR, with comparable quality to good AviSynth sharpening scripts? Both might come some day, but custom pixel shader support will likely come first.

I'm disappointed that there is still NO 64-bit version of madVR available. Madshi, are you planning to take care of this soon? This is because I do not intend on further using 32-bit media players on a 64-bit version of Windows.
No, I'm not planning to create a 64bit version soon. Maybe some day, but not anytime soon. The reason? Because the possible benefit is not big enough compared to the development time it would cost me.

Seek bar doesn't show for me (d3d fullscreen on secondary monitor), and the seek bar in mpc-hc doesn't do anything with madvr...
You do have the seekbar enabled in the madVR settings, yes? Do you have the "D3D Fullscreen" option activated in the MPC-HC "output" renderer settings? Try deactivating that.

Sadly it doesn't seem to be, at least for me. (A8-3850 CPU/GPU, Windows 8 preview, 64-bit, latest AMD drivers I think).
Please describe your exact problem in detail.

OK: Maybe I'll learn to love 4-lobe windowed Jinc methods, at least when using the "Radius = number of lobes" deblur. Here is the result of enlarging 7x with no colorspace or sigmoidization shenanigans with EWA Spline (meaning cubic B-spline windowing; this is the old ImageMagick "Cubic" filter and window) windowed Jinc 4 lobe with deblur set so that the radius is 4:
http://web.cs.laurentian.ca/nrobidoux/misc/madVR/robot/EWASplineJincRadius4.png
Looks quite good for this one test image, at least.

Let me double check, just to be safe. This image was created with the following parameters:

filter: B-Spline 4-taps
window: Jinc 4-taps, 0.9431597994328477

Is that correct? Is the filter exactly the same one used for tensor scaling? But you feed the true distance (sqrt(distx^2 + disty^2) into the B-Spline filter, is that correct?

That was one thing I was wondering about, anyway: Can you use any normal tensor filter (like B-Spline, Mitchell, Bicubic, whatever), combine it with Jinc windowing and then feed the true distance into the tensor filter? Or do the normal filters have to be modified to be able to handle "true distance -> weight"? Or do you feed the x and y distance separately in to the filter, just like you would with tensor upscaling, and then just add the Jinc window on top?

Thanks!

[madshi]

Is it normal for madvr auto resolution matching to switch to 23,98Hz for 25p sources instead for 50Hz (my projector doesn't support 25p)? If it is, is there a way to bypass/force it?
3 questions:

(1) What is the list of display modes you entered into the madVR display mode switcher?
(2) What does the madVR debug OSD (Ctrl+J) say about the "movie fps (says source filter)"?
(3) What is the exact file name of the movie you want to play?

[strumf666]

(1) 1080p23, 1080p24, 1080p50, 1080p60
(2) 25fps - from memory
(3) will check when I get from work.

It's the expendables 2 1080p rip, russian source. It's dropping approx. 1 frame per second if refresh is set to 23,98Hz but plays smoothly when I set it to 50Hz.

It's does happen with other 25p sources too, but I rarely stumble upon them.

[burfadel]

Thanks :) It was because I left D3D fullscreen on! Seek bar works perfectly now. Maybe a ticket should be submitted for MPC-HC, so the D3D option is greyed out when using madVR :)

With the internal decoder, when going on to the next video, the screen is black until you exit exclusive mode but the audio plays. Video comes back once in windowed mode, and is still there when back in exclusive mode. If the internal decoder is disabled, and ffdshow is used instead (for example), the video plays as it should when the next video plays. This really isn't a big issue since I can use ffdshow, but thought I'd mention it :)

[nlnl]

Quote:

@nlnl,

try this one:

http://madshi.net/madVRnlnl.rar

Does it fix the problem?
No, it does not
Please, have a look at the log and freeze report:
https://dl.dropbox.com/u/43376972/madvrnlnl_log_freez%2013-10-12.zip

Thanks!

madshi
madvrnlnl.ax build does not fix the problem, but 84.3 does!
Thanks!
BTW can not activate debug mode using 84.3.

[mandarinka]

Sadly it doesn't seem to be, at least for me. (A8-3850 CPU/GPU, Windows 8 preview, 64-bit, latest AMD drivers I think).

P.S. I'm fresh to MadVR, so I may be missing something.


Please describe your exact problem in detail.

When switching between window and fullscreen, the screen goes black for an instant after the switch to FS. Only for an short instant and not immediately, for a short while the video plays before the black screen. When the video comes back, the OSD message indicating that exclusive mode is used appears, so I guess that's the cause.

As said, this is from test on a Windows 8 release preview install, so it might not be worth to investigate yet, until the RTM version is out and Catalyst drivers are more mature.

I only follow this thread from time to time (since I didn't use MadVR so far). So this might be a known behaviour or simply an unavoidable thing, NVM me in that case. It isn't that annoying if the 3 second delay is disabled, too. When I saw that mention of the black screen in the changelog, I was under the impression that the mention refers to the issue I was seeing.

[noee]

As said, this is from test on a Windows 8 release preview install, so it might not be worth to investigate yet, until the RTM version is out and Catalyst drivers are more mature.

The latest AMD drivers for Win8 seem quite solid in single monitor setup, but dual-mon is just not right yet if you're running the second monitor at a different refresh rate than the first. It might also be the new feature that puts the taskbar on that second monitor (this can be disabled). Don't know if it's Win8 or just the drivers so far, but I cannot get reliable behavior with Win8 on dual-mon with refresh rate changing and FSE with either of my Llano machines. Look for the coming 12.9 drives to coincide with the Win8 "release", supposedly will address "dual-mon" issues. You could try the beta drivers now to see if there's any improvement.

[strumf666]

Is it normal for madvr auto resolution matching to switch to 23,98Hz for 25p sources instead for 50Hz (my projector doesn't support 25p)? If it is, is there a way to bypass/force it?
3 questions:

(1) What is the list of display modes you entered into the madVR display mode switcher?
(2) What does the madVR debug OSD (Ctrl+J) say about the "movie fps (says source filter)"?
(3) What is the exact file name of the movie you want to play?

(1) 1080p23, 1080p24, 1080p50, 1080p60
(2) 25fps - says source filter
(3) avshd-expendables1080p.mkv

It's the expendables 2 1080p rip, russian source. It's dropping approx. 1 frame per second if refresh is set to 23,98Hz but plays smoothly when I set it to 50Hz.

It's does happen with other 25p sources too, but I rarely stumble upon them.

Added missing info.

[NicolasRobidoux]

...
Let me double check, just to be safe. This image was created with the following parameters:

filter: B-Spline 4-taps
window: Jinc 4-taps, 0.9431597994328477
...Mathias: It's going to take me a while to answer your questions making sure that there is absolutely no confusion, in part because we speak slightly different technical languages.
-----
If I use the ImageMagick -define filter:verbose=1 option to "spy" into the filtering, I get this:convert small.png -define filter:verbose=1 -define filter:filter=Jinc -define filter:lobes=4 -define filter:window=Spline -define filter:blur=.9431597994328477 -distort Resize 700% EWASplineJincRadius4.png
# Resize Filter (for graphing)
#
# filter = Jinc
# window = Cubic
# support = 4.24106
# window-support = 4.24106
# scale-blur = 0.94316
# practical-support = 4
# B,C = 1,0

0.00 1.0472
0.01 1.04701
0.02 1.04646
0.03 1.04554
0.04 1.04425
0.05 1.0426
0.06 1.04059
0.07 1.03822
0.08 1.03549
0.09 1.0324
0.10 1.02897
0.11 1.02518
0.12 1.02105
0.13 1.01657
0.14 1.01176
0.15 1.00662
0.16 1.00114
0.17 0.995345
0.18 0.989228
0.19 0.982798
0.20 0.976058
0.21 0.969016
0.22 0.961677
0.23 0.954048
0.24 0.946133
0.25 0.93794
0.26 0.929475
0.27 0.920745
0.28 0.911757
0.29 0.902518
0.30 0.893036
0.31 0.883317
0.32 0.87337
0.33 0.863201
0.34 0.852819
0.35 0.842232
0.36 0.831447
0.37 0.820472
0.38 0.809317
0.39 0.797988
0.40 0.786495
0.41 0.774845
0.42 0.763047
0.43 0.75111
0.44 0.739042
0.45 0.726852
0.46 0.714548
0.47 0.702138
0.48 0.689632
0.49 0.677038
0.50 0.664364
0.51 0.65162
0.52 0.638813
0.53 0.625952
0.54 0.613045
0.55 0.600101
0.56 0.587129
0.57 0.574136
0.58 0.56113
0.59 0.548121
0.60 0.535115
0.61 0.522121
0.62 0.509147
0.63 0.496201
0.64 0.483289
0.65 0.47042
0.66 0.457601
0.67 0.444839
0.68 0.432141
0.69 0.419515
0.70 0.406967
0.71 0.394505
0.72 0.382133
0.73 0.36986
0.74 0.35769
0.75 0.345631
0.76 0.333688
0.77 0.321867
0.78 0.310173
0.79 0.298612
0.80 0.287189
0.81 0.275909
0.82 0.264777
0.83 0.253797
0.84 0.242973
0.85 0.232311
0.86 0.221814
0.87 0.211485
0.88 0.201329
0.89 0.191349
0.90 0.181548
0.91 0.17193
0.92 0.162496
0.93 0.15325
0.94 0.144195
0.95 0.135331
0.96 0.126662
0.97 0.118189
0.98 0.109914
0.99 0.101838
1.00 0.093963
1.01 0.0862892
1.02 0.0788179
1.03 0.0715497
1.04 0.064485
1.05 0.0576241
1.06 0.0509672
1.07 0.0445141
1.08 0.0382647
1.09 0.0322184
1.10 0.0263747
1.11 0.0207329
1.12 0.015292
1.13 0.0100509
1.14 0.00500834
1.15 0.000163021
1.16 -0.00448675
1.17 -0.00894254
1.18 -0.0132062
1.19 -0.0172799
1.20 -0.0211654
1.21 -0.0248651
1.22 -0.0283815
1.23 -0.0317169
1.24 -0.034874
1.25 -0.0378553
1.26 -0.0406637
1.27 -0.0433022
1.28 -0.0457738
1.29 -0.0480813
1.30 -0.0502282
1.31 -0.0522175
1.32 -0.0540527
1.33 -0.0557372
1.34 -0.0572742
1.35 -0.0586675
1.36 -0.0599205
1.37 -0.0610369
1.38 -0.0620204
1.39 -0.0628745
1.40 -0.0636032
1.41 -0.06421
1.42 -0.0646989
1.43 -0.0650737
1.44 -0.0653381
1.45 -0.0654959
1.46 -0.0655512
1.47 -0.0655075
1.48 -0.065369
1.49 -0.0651393
1.50 -0.0648222
1.51 -0.0644217
1.52 -0.0639414
1.53 -0.0633851
1.54 -0.0627566
1.55 -0.0620595
1.56 -0.0612976
1.57 -0.0604744
1.58 -0.0595936
1.59 -0.0586587
1.60 -0.0576731
1.61 -0.0566404
1.62 -0.0555638
1.63 -0.0544468
1.64 -0.0532926
1.65 -0.0521043
1.66 -0.0508854
1.67 -0.0496384
1.68 -0.0483668
1.69 -0.0470733
1.70 -0.0457607
1.71 -0.044432
1.72 -0.0430897
1.73 -0.0417366
1.74 -0.040375
1.75 -0.0390076
1.76 -0.0376367
1.77 -0.0362645
1.78 -0.0348934
1.79 -0.0335253
1.80 -0.0321625
1.81 -0.0308069
1.82 -0.0294602
1.83 -0.0281242
1.84 -0.0268009
1.85 -0.0254917
1.86 -0.0241979
1.87 -0.0229214
1.88 -0.0216633
1.89 -0.0204249
1.90 -0.0192074
1.91 -0.018012
1.92 -0.0168396
1.93 -0.0156912
1.94 -0.0145677
1.95 -0.0134699
1.96 -0.0123984
1.97 -0.011354
1.98 -0.0103372
1.99 -0.00934828
2.00 -0.00838814
2.01 -0.00745659
2.02 -0.00655429
2.03 -0.00568133
2.04 -0.00483784
2.05 -0.00402394
2.06 -0.00323964
2.07 -0.00248501
2.08 -0.00175991
2.09 -0.00106439
2.10 -0.000398309
2.11 0.000238611
2.12 0.000846515
2.13 0.00142575
2.14 0.00197648
2.15 0.00249902
2.16 0.00299377
2.17 0.003461
2.18 0.00390145
2.19 0.00431509
2.20 0.00470278
2.21 0.00506479
2.22 0.00540162
2.23 0.00571386
2.24 0.00600208
2.25 0.00626698
2.26 0.00650877
2.27 0.00672836
2.28 0.0069262
2.29 0.00710303
2.30 0.00725933
2.31 0.00739585
2.32 0.00751322
2.33 0.00761204
2.34 0.00769305
2.35 0.00775688
2.36 0.00780397
2.37 0.00783547
2.38 0.00785152
2.39 0.00785306
2.40 0.00784068
2.41 0.00781506
2.42 0.00777683
2.43 0.00772663
2.44 0.00766511
2.45 0.00759289
2.46 0.00751058
2.47 0.00741883
2.48 0.00731821
2.49 0.00720935
2.50 0.00709278
2.51 0.00696912
2.52 0.0068389
2.53 0.00670271
2.54 0.00656106
2.55 0.00641448
2.56 0.00626344
2.57 0.0061085
2.58 0.00595007
2.59 0.00578869
2.60 0.00562475
2.61 0.00545873
2.62 0.00529103
2.63 0.00512206
2.64 0.0049522
2.65 0.00478184
2.66 0.00461131
2.67 0.00444097
2.68 0.00427118
2.69 0.0041022
2.70 0.00393435
2.71 0.0037679
2.72 0.00360313
2.73 0.00344026
2.74 0.00327957
2.75 0.00312123
2.76 0.00296548
2.77 0.00281249
2.78 0.00266243
2.79 0.00251546
2.80 0.00237176
2.81 0.00223144
2.82 0.00209459
2.83 0.00196137
2.84 0.00183185
2.85 0.00170611
2.86 0.00158422
2.87 0.00146625
2.88 0.00135223
2.89 0.00124221
2.90 0.00113622
2.91 0.00103426
2.92 0.000936347
2.93 0.000842474
2.94 0.000752636
2.95 0.000666805
2.96 0.000584958
2.97 0.000507055
2.98 0.000433064
2.99 0.000362925
3.00 0.000296587
3.01 0.000233983
3.02 0.000175052
3.03 0.00011972
3.04 6.79069e-05
3.05 1.95334e-05
3.06 -2.5486e-05
3.07 -6.7241e-05
3.08 -0.000105827
3.09 -0.000141332
3.10 -0.000173861
3.11 -0.000203509
3.12 -0.000230387
3.13 -0.00025458
3.14 -0.000276216
3.15 -0.00029538
3.16 -0.000312196
3.17 -0.000326749
3.18 -0.00033917
3.19 -0.000349544
3.20 -0.000357989
3.21 -0.000364599
3.22 -0.000369494
3.23 -0.000372758
3.24 -0.000374508
3.25 -0.000374839
3.26 -0.000373844
3.27 -0.000371624
3.28 -0.000368268
3.29 -0.000363867
3.30 -0.000358517
3.31 -0.000352298
3.32 -0.000345301
3.33 -0.000337607
3.34 -0.000329289
3.35 -0.000320409
3.36 -0.000311066
3.37 -0.000301317
3.38 -0.000291229
3.39 -0.000280864
3.40 -0.000270291
3.41 -0.000259545
3.42 -0.000248694
3.43 -0.000237803
3.44 -0.0002269
3.45 -0.000216013
3.46 -0.000205228
3.47 -0.000194554
3.48 -0.000184026
3.49 -0.000173676
3.50 -0.000163535
3.51 -0.000153635
3.52 -0.000144008
3.53 -0.000134645
3.54 -0.000125595
3.55 -0.000116858
3.56 -0.000108441
3.57 -0.000100368
3.58 -9.26422e-05
3.59 -8.52692e-05
3.60 -7.82537e-05
3.61 -7.1605e-05
3.62 -6.53032e-05
3.63 -5.9361e-05
3.64 -5.37823e-05
3.65 -4.8556e-05
3.66 -4.36636e-05
3.67 -3.91173e-05
3.68 -3.48964e-05
3.69 -3.09978e-05
3.70 -2.74054e-05
3.71 -2.41083e-05
3.72 -2.1095e-05
3.73 -1.83746e-05
3.74 -1.58858e-05
3.75 -1.36731e-05
3.76 -1.16617e-05
3.77 -9.89684e-06
3.78 -8.31668e-06
3.79 -6.94366e-06
3.80 -5.72873e-06
3.81 -4.68372e-06
3.82 -3.77891e-06
3.83 -3.01256e-06
3.84 -2.37097e-06
3.85 -1.83769e-06
3.86 -1.39463e-06
3.87 -1.04208e-06
3.88 -7.5514e-07
3.89 -5.36571e-07
3.90 -3.62735e-07
3.91 -2.38204e-07
3.92 -1.46614e-07
3.93 -8.73773e-08
3.94 -4.61199e-08
3.95 -2.28118e-08
3.96 -9.10535e-09
3.97 -2.47706e-09
3.98 -1.23499e-09
3.99 -0
4.00 0
Now, this report truncates floating point values to make them more easy to read, and it actually does not show the LUT itself, just a sampling of the LUT at decimal positions (the LUT, of course, contains a number of values equal to a power of 2).
What it shows is that the "radial weight function" is the product of

a standard B-spline cubic which is stretched by a factor of 2 so it has radius 4 instead of 2 (if I was using this as a tensor windowing function, I'd get a square of "radius" 4 instead of the standard 2, which actually gives a square of width=height=2*4=8, which in my terminology gives a method which is 8 taps in each direction, for a total of at most 64 values used to compute an output pixel value; with EWA, less values are used because they have to be inside the circle inscribed in the square) (this is the window function)

and of

a standard Jinc 4-lobe function shrunk by 0.94316... so that it has radius 4 as well. (this is the windowed truncated low pass filter)

At every point, the LUT is the product of the values of these two functions.

------

For reference:

When using plain (deblur=1) EWA Jinc-windowed Jinc 4-lobe, instead of the stretched B-spline we use the stretched first lobe of Jinc so that it's radius matches exactly the radius of the unstretched and unshrunk Jinc 4-lobe disc (which has radius equal to the 4th root of the Bessel function J_1 divided by the number pi), and you multiply that by the unstretched and unshrunk 4-lobe Jinc.

When using tensor Lanczos 4 (Sinc-windowed Sinc 4-lobe), instead of the stretched B-spline we use the stretched first lobe of the Sinc function, stretched by a factor of 4 because its first root is 1 and the fourth root of Sinc is 4, and we multiply that by the unstretched and unshrunk Sinc 4-lobe function.

-----

If it helps, I can "verbose" the stretched B-spline function and the shrunk Jinc 4-lobe separately so you can see the LUTs. Just ask.

-----

I'll do my best to clarify things further in future posts.

P.S. I had to fix an horrid error in the "number of taps" discussion above, demonstrating that coffee must come before arithmetic.

[NicolasRobidoux]

As you can see, the LUT values are minuscule starting at about 3. I don't know for sure how necessary it is to keep the really small ones. Given that you use LUTs, maybe you should chop somewhere. I know how to estimate where you could chop to ensure that, say, you get a max difference in the final result of about 1 in sRGB (say), either with math or code. But, really, you you don't need me for that: Chop and check.
This being said, chopping may not be the best thing to do, because although the outer coefficients are small, they "grab" a lot of pixel values: The edge of the pizza has more area than the center.
P.S. I'd chop between 3.05 and 3.06. I can figure exactly where.
P.S. So, I'm giving you a 3-lobe method in 4-lobe clothing (kinda).
P.S. Actually, it may or may not be worthwhile to chop, because I imagine the computation is data-bound, not flop-bound, and radius 4 uses (at most) 8 scanlines to compute any output value (just like tensor Lanczos 4), and radius 3.05 uses at most 7, for a difference of 1 scanline. Also, about 1/3 of the pixels with non-zero weights are in that "tail". So, they may (or may not) add up to something. (I think that you would say that radius 4 is 8-tap, and radius 3.05 is 7-tap? Our terminologies are not quite aligned, I think.)

[kasper93]

Maybe a ticket should be submitted for MPC-HC, so the D3D option is greyed out when using madVR :)

It should be greyed out when using madVR. This option always cause bad things. If you search this thread you will find more problem regarding this option. It's annoying when we accidentally turn it on and spend some minutes(if you are lucky) on thinking why on earth madVR is not working :D

Well, madVR support in mpc-hc should be reviewed, starting from moving it higher on renderers list (it's in the end for no apparent reason). DVB doesn't work well with madVR. And many more random issues...

All that is minor things and for "pro-user" like me :p there is easy to avoid any problems, but it may be confusing for regular user.

[NicolasRobidoux]

Mathias:
Unsolicited advice: It is likely to be much harder to put together a decent AR with an EWA method than with an interpolatory tensor method like tensor Lanczos or Ginseng.
Given that EWA methods need AR less (partly because they take care of the checkerboard mode pretty well on their own), maybe this should become back burner.
-----
Note that I've not taken the time to learn how you AR works.

[wiFFy]

There are only 2 things which changed performance in v0.84.3:

(1) Linear light scaling, which should be slightly faster now.
(2) Jinc AR, which might be slightly slower now.

I'm still working on Jinc AR, it might get even slower in a future build, the algorithm is not totally finalized yet. It's unfortunate that it was fast enough for you in v0.84.2 and is just a tiny bit too slow in v0.84.3 now, but I can't stop optimizing it just because the optimization costs 3% more performance or something like that. Quality is more important than a couple percent performance.

All other filters (e.g. Lanczos AR) should perform identical. They haven't changed at all from v0.84.2 to v0.84.3.

After a good night's sleep I started testing again. I managed to push rendering time down to 35ms while upscaling 720p to 1080p with lanczos3 ar for chroma and jinc3 ar for luma. So it is all good now.

[6233638]

Ouch. Such computer graphics are terribly hard to handle for the anti-ringing filter. Basically any content which has a lot of "one color pixel next to totally different color pixel next to another totally different color pixel" is hard to handle correctly. I would be dead easy for me to make madVR work great for these type of computer graphics, but then real videos would suffer. Well, maybe I should try to analyze the type of content first and then switch between 2 different anti-ringing filters? I don't know. Will think about that...I am not concerned with how that sort of thing looks, I just thought it was a good illustration of the problem. (I would probably use Catmull-Rom anti-ring with that type of content)


It's much more complex than that. I'm playing around with different algorithms, even multi-pass shaders instead of single-pass shaders etc...I suspected it might be that. Far beyond me then.

Any chance the frame drop/repeat estimate is wrong in the latest builds? Maybe only when using Reclock?

The same 720p video with 82.5, shows days between repeats/drops but 1-3 mins in 84.3. Yet, no drops or glitches actually happen. :confused:If you are using ReClock, I find it best to use the "Clean-up clock timings database" option when you update drivers, which usually solves this. Even so, it usually manages to avoid dropping frames.

[NicolasRobidoux]

...
Let me double check, just to be safe. This image was created with the following parameters:

filter: B-Spline 4-taps
window: Jinc 4-taps, 0.9431597994328477

Is that correct? Is the filter exactly the same one used for tensor scaling? But you feed the true distance (sqrt(distx^2 + disty^2) into the B-Spline filter, is that correct?When we use EWA, the LUT is fed the distance (or its square, for efficiency---no square root---and to get more dense data near the center).
What the LUT should contain is the product of the value of the window function at a certain distance times the value of the truncated low pass filter at the same distance.

"Spline" (obtained with Cubic with B=1, C=0 in the ImageMagick internals, but it's just the cubic B-spline applied to x/2 instead of x to stretch its support to 4, given that it's normal support is 2) windowing is also called "Parzen windowing" in ImageMagick. The name Parzen comes from statistics, where it's used more than elsewhere. When used in a DSP or in statistics, the way the spline is stretched is often slightly different than when resampling. In image resampling, you generally want the resulting LUT to smoothly go to zero as it approaches its last values.

So, instead of using it with "x" in one pass and "y" in the other pass as it's done with tensor methods, you just use the cubic B-spline radially, which means that it gives you a window function that resembles a Gaussian surface, except that it "smoothly dies" at radius 4 (the Gaussian surface goes on forever).

-----

A really really quick crash course in windowed filtering in image resampling:

Basically, you start with a good low pass filter:

Sinc, if you will do two orthogonal passes to go from 1D to 2D (whether you actually implement this as a two pass operator is besides the point; what matters is that you get the same result than if you were doing this as two passes, one vertically and one horizontally, in whatever order)

Jinc, if you will use EWA (one radial pass in 2D).

Now, these filters have infinite extent (they are "IIR"). Not practical, and actually not very good. So we want to chop them somehow to get a "FIR" filter.

If you chop anywhere else than at a root, you'll have a discontinuous kernel, and this will introduce discontinuities in the surface implicit to upsampling (the surface is obtained by enlarging using a "very very large" ratio). These discontinuities introduce very ugly artifacts.

So, we want to chop at a root, that is, at an integer for Sinc, and at a root of the appropriately scaled Bessel J_1 function (there is a scaling by pi involved) for Jinc.

This is not enough to prevent ugly artifacts (unless the support is impractically large), because the "kernel" hits the root where the chopping occurs at an angle, and the slope discontinuity of the kernel as it goes to the stretch where it is identically zero (this stretch goes all the way to infinity) also leaves artifacts.

To prevent artifacts, we do not only want to chop at a root, we want the slope of the resulting kernel to be zero as well at the location where we chop.

Now, this is impossible if all we do is chop, because Sinc and Jinc do not have "double roots", meaning locations where the curve is horizontal as it hits zero.

So we must do more than chop, and this means changing the shape of the kernel.

In addition, we want to change the shape "smoothly". If we're two brutal in the way we change the shape of Sinc or Jinc, we lose the good low pass filtering properties.

That is, we want to "morph" the chopped Sinc or Jinc into something that has a zero slope where we chop.

The way to do this is to multiply the chopped Sinc or Jinc by a function which smoothly goes from a nonzero value at 0 to zero where we chop. The name given to this function is "windowing function". It is used to "window the Sinc (or Jinc)". Without going into more math than necessary, this ensures that the new function that results from this multiplication is both zero and has a slope of zero where we chop.

Now, some window functions (Hamming, in particular) are not zero at the "end of their extent". IMHO, they are not suitable for image upsampling. Kaiser, with some choices of the key parameters, is "almost" zero where we chop it, so it's kind of a border case. But with some parameter choices, the Kaiser window is far from zero where we chop it, and again this means that I don't recommend it. The Bartlett (Triangle) window is zero at the edge of its extent, but it has a slope discontinuity at zero, which is must moving the slope discontinuity from the edge to the center. Also not recommended. All the other "standard" ImageMagick window functions (everything is tweakable, so you can break things if you want!) fix things so that the resulting kernel (the product of the possibly scaled chopped Sinc or Jinc, and the possibly scaled "first lobe" of the window function) is continuous and has a continuous slope, even where it links to the stretch in which it is exatly equal to zero, stretch which goes all the way to infinity. (The "kernel" is what you put in the LUT.)

I won't go into why I thought that the cubic B-spline a.k.a. Parzen window would work well with Jinc 4-lobe deblurred so the radius of the EWA disc has radius exactly 4 (diameter = 8). As always, the proof is in the pudding.

If this is all very confusing, have a quick look at the ImageMagick Examples, explanation of what this is about, or google "window function". Note however that window functions are used slightly differently in image resampling than in standard DSP filtering.

[NicolasRobidoux]

...
That was one thing I was wondering about, anyway: Can you use any normal tensor filter (like B-Spline, Mitchell, Bicubic, whatever), combine it with Jinc windowing and then feed the true distance into the tensor filter? Or do the normal filters have to be modified to be able to handle "true distance -> weight"? Or do you feed the x and y distance separately in to the filter, just like you would with tensor upscaling, and then just add the Jinc window on top?
...I am not totally sure I understand the questions. Here is an attempt at answering:
Very roughly, one can understand image resampling as 3 steps:
1) Pre-filter (remove some of the high frequency modes)
2) Resample (evaluate at the new locations)
3) Post-filter (USM, for example)
Very roughly, windowing does the pre-filtering, and we merge 2) and 3) by only applying the chopped ideal low pass filter (Sinc or Jinc) centered at the sampling location.
The neat thing, however, is that by multiplying the Sinc and Jinc weights by the weights of the window function, we can do 1), 2) and 3) using one single convolution-type operation. And almost certainly get a better result than if we were doing the steps separately.
-----
P.S. on my last "lecture":
Lanczos filters use the first lobe of the low pass filter (Sinc or Jinc) to window the chopped multi-lobe filter. No more and no less.
Conceptually elegant.
Necessarily better? No.

[NicolasRobidoux]

Mathias:
I'm not sure my "crash course" is very clear or well written.
Ask questions.
I'll try to make things clear, because if they are, you may be able to understand better why things are put together the way they are, and this may guide effective use.

[Pat357]

After a good night's sleep I started testing again. I managed to push rendering time down to 35ms while upscaling 720p to 1080p with lanczos3 ar for chroma and jinc3 ar for luma. So it is all good now.
How did you do that ?
Think also about other readers/users that might have an identical problem : I guess that such posts wont help them...

[madshi]

(1) 1080p23, 1080p24, 1080p50, 1080p60
(2) 25fps - from memory
(3) will check when I get from work.

It's the expendables 2 1080p rip, russian source. It's dropping approx. 1 frame per second if refresh is set to 23,98Hz but plays smoothly when I set it to 50Hz.
If you upload a madVR debug log (please zip it) I should be able to tell you what's going wrong.

Maybe a ticket should be submitted for MPC-HC, so the D3D option is greyed out when using madVR :)
It should be greyed out when using madVR. This option always cause bad things.
I removed it myself from MPC-HC a long time ago, but then got complaints from some madVR users because they used it and found it to be important, so I put it back in.

With the internal decoder, when going on to the next video, the screen is black until you exit exclusive mode but the audio plays. Video comes back once in windowed mode, and is still there when back in exclusive mode. If the internal decoder is disabled, and ffdshow is used instead (for example), the video plays as it should when the next video plays. This really isn't a big issue since I can use ffdshow, but thought I'd mention it :)
I'll check if I can reproduce that here.

BTW can not activate debug mode using 84.3.
What happens if you try?

When switching between window and fullscreen, the screen goes black for an instant after the switch to FS. Only for an short instant and not immediately, for a short while the video plays before the black screen. When the video comes back, the OSD message indicating that exclusive mode is used appears, so I guess that's the cause.
Sometimes Windows does weird things, sometimes GPU drivers do weird things, when entering or leaving fullscreen exclusive mode. There's probably not much I can do about it. As long as it only for a short instant, I guess we'll have to live with it for now. If it annoys you too much, you can try getting along without fullscreen exclusive mode. Unfortunately AMD doesn't support the new madVR overlay mode, though, so maybe you do need fullscreen exclusive mode to get a perfectly smooth playback experience, don't know...

Unsolicited advice: It is likely to be much harder to put together a decent AR with an EWA method than with an interpolatory tensor method like tensor Lanczos or Ginseng.
Given that EWA methods need AR less (partly because they take care of the checkerboard mode pretty well on their own), maybe this should become back burner.
The Jinc AR algorithm is already working quite nicely for normal video sources. Those ugly notches in the original version of the Jinc AR algorithm are already fixed in the current madVR version. The only problem left is that the AR algorithm sometimes leaves a bit too much ringing in the source. This mostly only happens with computer graphics and sharp subtitles. I already have a fix for computer graphics. Just waiting for some more screenshots from 6233638 and cyberbeing, so I can apply some more tweaks to the AR algorithm.

It's true that the AR algorithm is more complex for Jinc compared to the tensor methods, but then the Jinc AR algorithm also has greater potential because being able to look around you in a circle gives you more information than just looking left/right (or up/down).

When we use EWA, the LUT is fed the distance (or its square, for efficiency---no square root---and to get more dense data near the center).
What the LUT should contain is the product of the value of the window function at a certain distance times the value of the truncated low pass filter at the same distance.
Yes, that much was clear to me.

"Spline" (obtained with Cubic with B=1, C=0 in the ImageMagick internals, but it's just the cubic B-spline applied to x/2 instead of x to stretch its support to 4, given that it's normal support is 2) windowing is also called "Parzen windowing" in ImageMagick. The name Parzen comes from statistics, where it's used more than elsewhere. When used in a DSP or in statistics, the way the spline is stretched is often slightly different than when resampling. In image resampling, you generally want the resulting LUT to smoothly go to zero as it approaches its last values.
Ah, I understand. Apart from the x/2 stretching it's the same filter used in tensor resampling, though, correct?

So, instead of using it with "x" in one pass and "y" in the other pass as it's done with tensor methods, you just use the cubic B-spline radially, which means that it gives you a window function that resembles a Gaussian surface, except that it "smoothly dies" at radius 4 (the Gaussian surface goes on forever).
I understand, thanks.

Basically, you start with a good low pass filter:

Sinc, if you will do two orthogonal passes to go from 1D to 2D (whether you actually implement this as a two pass operator is besides the point; what matters is that you get the same result than if you were doing this as two passes, one vertically and one horizontally, in whatever order)

Jinc, if you will use EWA (one radial pass in 2D).

Now, these filters have infinite extent (they are "IIR"). Not practical, and actually not very good. So we want to chop them somehow to get a "FIR" filter.

If you chop anywhere else than at a root, you'll have a discontinuous kernel, and this will introduce discontinuities in the surface implicit to upsampling (the surface is obtained by enlarging using a "very very large" ratio). These discontinuities introduce very ugly artifacts.

So, we want to chop at a root, that is, at an integer for Sinc, and at a root of the appropriately scaled Bessel J_1 function (there is a scaling by pi involved) for Jinc.

This is not enough to prevent ugly artifacts (unless the support is impractically large), because the "kernel" hits the root where the chopping occurs at an angle, and the slope discontinuity of the kernel as it goes to the stretch where it is identically zero (this stretch goes all the way to infinity) also leaves artifacts.

To prevent artifacts, we do not only want to chop at a root, we want the slope of the resulting kernel to be zero as well at the location where we chop.

Now, this is impossible if all we do is chop, because Sinc and Jinc do not have "double roots", meaning locations where the curve is horizontal as it hits zero.

So we must do more than chop, and this means changing the shape of the kernel.

In addition, we want to change the shape "smoothly". If we're two brutal in the way we change the shape of Sinc or Jinc, we lose the good low pass filtering properties.

That is, we want to "morph" the chopped Sinc or Jinc into something that has a zero slope where we chop.

The way to do this is to multiply the chopped Sinc or Jinc by a function which smoothly goes from a nonzero value at 0 to zero where we chop. The name given to this function is "windowing function". It is used to "window the Sinc (or Jinc)". Without going into more math than necessary, this ensures that the new function that results from this multiplication is both zero and has a slope of zero where we chop.
I think I knew these things, too, although I might not have been able to explain them this nicely.

Now, some window functions (Hamming, in particular) are not zero at the "end of their extent". IMHO, they are not suitable for image upsampling. Kaiser, with some choices of the key parameters, is "almost" zero where we chop it, so it's kind of a border case. But with some parameter choices, the Kaiser window is far from zero where we chop it, and again this means that I don't recommend it. The Bartlett (Triangle) window is zero at the edge of its extent, but it has a slope discontinuity at zero, which is must moving the slope discontinuity from the edge to the center. Also not recommended. All the other "standard" ImageMagick window functions (everything is tweakable, so you can break things if you want!) fix things so that the resulting kernel (the product of the possibly scaled chopped Sinc or Jinc, and the possibly scaled "first lobe" of the window function) is continuous and has a continuous slope, even where it links to the stretch in which it is exatly equal to zero, stretch which goes all the way to infinity. (The "kernel" is what you put in the LUT.)

I won't go into why I thought that the cubic B-spline a.k.a. Parzen window would work well with Jinc 4-lobe deblurred so the radius of the EWA disc has radius exactly 4 (diameter = 8). As always, the proof is in the pudding.
I knew most of the resampling internal stuff. I think the key thing I was unsure of was this:

Normally B-Spline is a filter used for 1D resampling. So you feed in the x-distance in the first pass and the y-distance in the 2nd pass. Now that you're using B-Spline for EWA windowing, I was wondering whether you could use the very same B-Spline filter, but feed in the radial distance. I wasn't sure this would work because normally you don't feed a radial distance into B-Spline. But it seems it does work, when scaled properly. Well, I guess it makes sense. And why would it not work? I'll give this a try sooner or later...

Thanks for your help, once again!