search

Jaded-Encoding-Thaumaturgy / vs-denoise

VapourSynth denoising, regression, and motion compensation functions
MIT License
18 stars 6 forks source link

List of various MVTools based denoising functions #70

Closed NSQY closed 1 year ago

NSQY commented 1 year ago

VS implementations will be towards the bottom of sub-lists when an AVS ver exists as I am making the general assumption that they are outdated compared to their AVS(+) counterparts.

https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/Filters.md#spatio-temporal-denoisers http://avisynth.nl/index.php/External_filters#Spatio-Temporal_Denoisers

adworacz commented 1 year ago

For potential contributors interested in implementing some of the above listed functions, where would be the right place to do so? It looks like potentially funcs.py at first glance.

For context, I'm the one who updated TemporalDegrain2 in Hybrid's G41Fun (as it was the only place I saw that looked maintained).

And answering the question from the other issue - yes, I work with live action and anime.

Setsugennoao commented 1 year ago

Hello, thanks for the interest. I think for future proofing it'd make sense to create a degrain.py.

If you do open PR, know I unfortunately won't be available for review this week.

adworacz commented 1 year ago

Thanks for the details!

And no worries on timing at all. My own time is limited, so it may be a while before I can even contribute a PR, let alone would hope to have it reviewed.

adworacz commented 1 year ago

Just an FYI, I’ve started the TemporalDegrain2 port. Nothing to submit just yet, and I’ve got a ways to go, but the MVTools class definitely helps to shrink thinks nicely.

adworacz commented 1 year ago

Bit of an implementation question that I'd like advice on before I go making big changes.

I need to separate out the building of super clips from the analyze method. It's often common to run analysis once, get the vectors, and then reuse them for several different MVTools operations, each of which calculates its own super clip.

You can see an example of this in the first degraining step of TemporalDegrain2:

https://github.com/Selur/VapoursynthScriptsInHybrid/blob/master/G41Fun.py#L2440-L2449

I've already started to detach the super_render clip from the vectors object, but right now all supers are calculated in the analyze method.

My instinct is to create a new super method that just builds the super_render clip, since the super_search and super_recalc clips are only used in the analyze method.

Then we can lazy calculate the super_render clip similar to how the get_vectors_bf method operates today.

This gets a little sticky due to how the arguments for super_render, super_search, and super_recalc are shared today:

https://github.com/adworacz/vs-denoise/blob/403ba02a24e90b997c73fd63c31461d89e954ff2/vsdenoise/mvtools.py#L1044-L1057

So we could calculate all of these in one main super method, with the ability to only calculate the super_render clip via some parameter to said method.

What are y'alls thoughts here?

Setsugennoao commented 1 year ago

Hmmm that's a thing I thought about yeah.

I think you should make a PR in which we can talk about it more. It's an important part so I want to make sure everything's covered.

adworacz commented 1 year ago

Roger. I'll mess around with a few approaches and come up with something that seems reasonable and submit a PR to start.

adworacz commented 1 year ago

Okay, I've made a pretty decent attempt, see https://github.com/Irrational-Encoding-Wizardry/vs-denoise/pull/84

I'm actually relatively happy with how it turned out. We're saved from any performance penalty when calculating supers that we don't use due to Vapoursynth's script evaluation at runtime.

adworacz commented 1 year ago

Do we want to add SMDegrain to the list?

I know that HolyWu's havsfunc has SMDegrain, and is pretty much the defacto. Wasn't sure if we wanted to port it to here, especially taking advantage of the newer LFT/DCTFlicker support in vsrgtools since Dogway added it to the AVS version.

NSQY commented 1 year ago

Do we want to add SMDegrain to the list?

I spoke to @Setsugennoao about this, there is MVToolsPresets.SMDE() but I would prefer if there were explicit SMDegrain and CMDegrain functions exposed to the user.

LightArrowsEXE commented 1 year ago

Do we want to add SMDegrain to the list?

I spoke to @Setsugennoao about this, there is MVToolsPresets.SMDE() but I would prefer if there were explicit SMDegrain and CMDegrain functions exposed to the user.

This might be something we'd want users to implement in their own funcs perhaps? If that is the direction setsu wants to take it, I can write a wrapper in lvsfunc at a later date.

adworacz commented 1 year ago

Hmm, I could see that, but its interesting that it would apply to SMDegrain but not something like TemporalDegrain2/xClean/etc.

As an aside, it might be worth adding Spotless to this list as well. Looking at the older VS version, it should be trivial to port to this package:

adworacz commented 1 year ago

Also, just to prove I'm not full of BS, I've pretty much finished the TemporalDegrain2 implementation, which you can find on my branch here: https://github.com/adworacz/vs-denoise/blob/temporalDegrain2/vsdenoise/degrain.py#L18

I plan on rebasing it and submitting it soon (hopefully tonight). It still needs more documentation, and maybe a few more features, but it's at feature parity with the old G41Fun version and actually provides a number of very useful features.

It's also faster and higher quality, which I wasn't expecting. Especially if you combine it with DFTTest to replace fft3dfilter, you get a very nice speed boost while having better quality. I might look into making that the default going forwards, as fft3dfilter is just dog slow these days in comparison.

adworacz commented 1 year ago

TemporalDegrain2: https://github.com/Irrational-Encoding-Wizardry/vs-denoise/pull/90

There's still some minor improvements that can be made, but it's a pretty solid start.

adworacz commented 1 year ago

Thanks for merging temporal_degrain. Sorry for the radio silence, I've been traveling these past few weeks and unable to review it.

Just before I took off for another trip, I was able to pull down the latest code and compare it against the original implementation I submitted. I did notice some key difference in output though, so the refactor changed some things. I not sure what changed just yet, and it will be another week or so before I can step through the code to identify the source of differences.