EZdenoise

[takla]

Temporal denoiser. Requires MvTools2 (https://github.com/pinterf/mvtools/releases)

Options explained:

thSAD = Controls how much noise is picked up, with higher values picking more noise. The default should be good enough for modern content (Blu-ray sources). Very noisy videos will require a higher value. Or use ShowMe() (more info below). Default: 150
thSADC = Noise threshold, but for Chroma. Default: The same value as thSAD
TR = Temporal Radius: How many frames to analyze (previous and next), higher values remove more noise at the cost of speed. Default: 3
BLKSize = Blocksize: lower values increase quality at the cost of speed. Should be a power of two (https://en.wikipedia.org/wiki/Power_of_two#First_64_powers_of_two) for optimal performance. Default: 8
Overlap: How many overlaps each block should have. A value of 4 is optimal and avoids possible blocking (https://encodingwissen.de/_images/x264_deblocker.jpg).
Chroma: Accepts true or false. Only enable this if your video has a lot of noise. It is much slower if set to true. Default: true
out16: Accepts true or false. out16=true outputs 16bits which is good if you want to use more filters after EZdenoise. Only works with 8bit inputs. Default: false


Changelog:


- Added EZdenoise for VapourSynth (https://www.mediafire.com/file/3abkiruq7weod68/EZdenoise_for_VapourSynth.zip/file)
For optimal performance, use this libmvtools.dll (https://github.com/Akatmks/vapoursynth-mvtools-pr/actions/runs/17664592612/artifacts/3992845122) (Requires you to login with a GitHub account or else the link 404s)

- EZdenoise v5 (https://www.mediafire.com/file/sm3gwt798v0km7v/EZdenoise_v5.zip/file)
Added Ternary operator (thanks @DTL) to avoid using UV planes, when Chroma is set to "False".
Set Chroma to "True" by default.

- EZdenoise v4
Hardcoded "Falloff" parameter.
Added "out16" parameter (which only supports 8bit sources).
Using out16=true is 15% faster than using ConvertBits(16), because MAnalyse now respects the bit depth of the input.
Previous versions had MAnalyse run at 16bit (if ConvertBits(16) was used) which didn't improve image quality and only wasted performance.

- EZdenoise v3
Added "Falloff" parameter.
Previously, thSAD2's would be (thSAD/2), which was probably too low.
This version uses (thSAD*0.9).
There should be no reason for you to change the new default.

- EZdenoise v2
Changed chroma=true to chroma=false which is also what BM3D defaults to.
This change increases speed by ~50%.
Also added a variable for pel.
Using anything but the default value of 1 is placebo, but hey, it is there if you want it.

- Added ShowMe()
Can be used to more easily find a good thSAD value.
(Look at the top left corner during preview with AvsPmod)
(Ignore any value directly after a scene change)
ShowMe() should be placed right after your Source filter.
(Crop black bars, if present.)

Example:

LWLibavVideoSource("C:\Users\Admin\Documents\INPUT.mkv")
Crop(0, 140, -0, -140)
ShowMe()

I recommend you average multiple scenes for your choosen value.

[kedautinh12]

Can you upload to another sever??

[takla]

The images? Sure.

https://drive.google.com/drive/folders/1XrpGByKo9YaclXszfINogBkW72ABgBp8?usp=sharing

[kedautinh12]

I mean EZdenoise.zip but it been approved by admin

[guest]

I mean EZdenoise.zip but it been approved by admin

OK, your suggestion worked, but I still don't know what this means:-

EZdenoise().

I guess that's where you add the parameters to how you want it to filter.

So my next question is...how & what do I need to add to "denoise" a little stronger ??

[kedautinh12]

That script based MVTools2.dll so that script use MVTools2's parameter. I think you need read MVTool2 parameter's description

[guest]

That script based MVTools2.dll so that script use MVTools2's parameter. I think you need read MVTool2 parameter's description

OK.

But I added a few things between the (), and it definitely changes :)

[VoodooFX]

So my next question is...how & what do I need to add to "denoise" a little stronger ??

function EZdenoise(clip Input, int "thSAD", int "thSADC", int "TR", int "BLKSize", int "Overlap")
{
thSAD = default(thSAD, 150)
thSADC = default(thSADC, thSAD)
TR = default(TR, 3)
BLKSize = default(BLKSize, 16)
Overlap = default(Overlap, BLKSize/2)

Super = Input.MSuper(pel=1)
Multi_Vector = Super.MAnalyse(Multi=True, Delta=TR, BLKSize=BLKSize, Overlap=Overlap)

Input.MDegrainN(Super, Multi_Vector, TR, thSAD=thSAD, thSAD2=thSAD/2, thSADC=thSADC, thSADC2=thSADC/2)
}

http://avisynth.nl/index.php/MVTools

[takla]

OK, your suggestion worked, but I still don't know what this means:-

EZdenoise().

I guess that's where you add the parameters to how you want it to filter.

So my next question is...how & what do I need to add to "denoise" a little stronger ??

Uhm, did you not read anything I wrote in the op, like, at all?? All your questions are already answered there...

[lansing]

This is just smdegrain

[takla]

This is just smdegrain

No it's not. SMDegrain is just mvtools with some extras. And SMDegrain has garbage default values. This here is just mvtools with good default values.

[gispos]

No it's not. SMDegrain is just mvtools with some extras. And SMDegrain has garbage default values. This here is just mvtools with good default values.

So the same thing with better default settings but without extras. The extras then cost extra. :D
Peace, a little fun must be.:)

[takla]

So the same thing with better default settings but without extras. The extras then cost extra. :D
Peace, a little fun must be.:)

Exactly SMDegrain is also just a version of mdegrain from mvtools. Just like EZdenoise.

But what SMDegrain does not achieve with ~640 lines, EZdenoise achieves with just 13 lines.

I made this script because I got fed up with the garbage default settings SMDegrain comes with, because these settings cause artefacts on my testclips. And in the process I've learned which settings are the most important and which are basically just placebo (pel=2 for example).

Such processing power is much better spend on blksize and tr.

[Selur]

Has anyone tried to use svpflow1/svpflow2 as alternative to mvtools for gpu accelleration?
(https://www.svp-team.com/wiki/Manual:SVPflow)

[takla]

Added EZdenoise v2

Changed chroma=true to chroma=false which is also what BM3D defaults to. This change increases speed by ~50%.
Also added a variable for pel. Using anything but the default value of 1 is placebo, but hey, it is there if you want it.

[kedautinh12]

Can you share another link?? I think link will be approved very long time to wait by admin :D

[kedautinh12]

I think github is expect :D

[takla]

I think github is expect :D

https://www.mediafire.com/file/89y8y2tv6pibrpi/EZdenoise_v2.zip/file

[kedautinh12]

Ok. Don't say thank cause someone will report me to admin and they will ban me :D

[hello_hello]

takla, here's a function I've been using. It's basically EZDenoise with more options. It might give you some ideas for v3.

MDegrainNL.zip (https://files.videohelp.com/u/210984/MDegrainNL.zip)

Trumotion is disabled by default as it tends to cause blurring.
YUV is expanded from limited range to full range for MAnalyse, but there's an argument to change that.
There's also an argument for specifying a bitdepth for the MAnalyse clip. If you're working with a high bitdepth source and you're in a hurry you can reduce the bitdepth of the search clip.
Multithreading with avstp.dll is disabled by default as it's not compatible with Avisynth+'s multithreading, but there's a line in the function for specifying the path to avstp.dll, so if it's set correctly, avstp.dll is automatically loaded when MT=true.

I mainly use it for light denoising so the defaults aren't the same, but obviously you can change them.

[takla]

hello_hello Thanks for the heads-up. I'll check it out.

From what I remember of my past testings:


TrueMotion=False: I think this caused some artefacts on my test clip. Nonetheless, I'll rerun some tests for this.
YUV full range: I remember looking into this but I couldn't find a way to implement it. I also remember I asked pinterf to add an internal syntax for it for mvtools on github, to which he reaponded, iirc, that is does not make a difference (not the exact words). So questionable if it helps, but I'll run some tests.
High Bit Depth: I guess having a different bit depth for MAnalyse could be a speedup? I will see if the speedup justifies the additional setting.
MT=False: It didn't make a difference in my case because I don't use avstp.dll anyways. If I do release another version I could add this, yes.

[DTL]

"Changed chroma=true to chroma=false which is also what BM3D defaults to. This change increases speed by ~50%."

It is good to add to documentation: Using chroma=false in MAnalyse may result in different colors blended blocks (with close luma values). Though it is rare enough. Disabling chroma in MDegrain typically cause great degrading of degrain ratio (increase MPEG out speed with same crf in x264 for example).

If you need the more 'faster' modes - you can also set overlap to 0. It may increase speed to several times in compare with default blocksize/2 but will add some blockiness at some areas (typically with fast moving low detailed motion like fire/smoke).

[StainlessS]

Overlap = 0 is of course faster but quality of result is quite bad in comparison, suggest at least Overlap=2.
Gettin' the wrong answer faster is not always the best way to go.

EDIT: Although I believe in days (hopefully) long gone, some Cray Computers used to sacrifice [EDIT: a lot of] precision/correctness for speed.
(they may have gotten the wrong answers, but they did it incredibly quickly)

[takla]

DTL I don't see how chroma would be affected when it is never processed?

And I have to agree with StainlessS here. Personally, I'd never use overlap=0. It destroys quality. Some speed-ups make sense, like chroma=false for HD sources.

hello_hello
So I ran some tests

TrueMotion=false: It indeed is slightly sharper. But I doubt I could see the difference with a lossy encode. It also is ~18% slower. Not really a good quality to speed ratio.
MAnalyse: No measurable speed difference for me with it being 8bit instead of 16bit like everything else
YUV=full: It made like 1MB difference for 600 1080p frames with lossless ffv1. Checking still frames with 200% zoom, I couldn't see any difference.

[DTL]

"how chroma would be affected when it is never processed?"

In the EZdenoise_v2 user can enable chroma processing. But it have not separation of chroma for MAnalyse only or for MAnalyse + MDegrain. So it either lowest quality or lowest speed. There possible in-between way with chroma enabled for degraining but disabled for MVs search. It is faster with higher quality in compare with totally disabled chroma. Also with enabled chroma for MAnalyse and typical YV12 data format there is many posts about useful increasing scaleCSAD value of MAnalyse param from default 0 to 1 or may be even 2 (max currently allowed). Adjusting of scaleCSAD if almost free for speed/performance but may visibly change degraining quality (output MPEG speed). Adjusting scaleCSAD may require re-tune of thSAD param.

May be it is better to make some 'presets' in the input param so user can not think of more and more input params and its values but simply select from a set of pre-defined speed/quality presets ? The current combination of MAnalyse+Mdegrain allow to create about 10 or many more different speed/quality presets easily. Even with left to user-input 'required' control values like tr and thSAD.
So the discussion will be mostly about internal script params for each preset. And not scare user of the script with tons of params to setup.

I see currently low-experienced users are much more like to set some one 'human-readable' named preset instead of thinking of lots of magic numerical params. User may need a year of everyday thinking and experimenting to get more experienced and level-up in the numerical params setup of 'complex denoiser'. The x264 encoder with tons of params also have some named speed/quality presets.

[takla]

Ohh I see. Ok. I'll run some more tests.
And yes, I've been thinking about presets. It also came to my mind when I tested your MVtools fork.
optSearchOption & optPredictorType is what I'm talking about. They could be merged into a "Preset" syntax.

[hello_hello]

hello_hello
So I ran some tests
TrueMotion=false: It indeed is slightly sharper. But I doubt I could see the difference with a lossy encode. It also is ~18% slower. Not really a good quality to speed ratio.

I'll confess I've never compared speed until now. I just compared the two visually and went with what I think looked best.
Having said that, I ran a few quick tests using AVSMeter and a few different MDegrainNL settings (changing TR and BLKSize), with and without TrueMotion, and the result was a consistent 1% faster when TrueMotion was enabled, but I was only testing using a SD source and my computer's a bit old.

MAnalyse: No measurable speed difference for me with it being 8bit instead of 16bit like everything else

Once again, just testing using a SD source and an old PC, but according to AVSMeter....

38.49fps
ConvertBits(16)
MDegrainNL(MT=true, TR=2, SearchBits=8)
Trim(1000,1999)

30.19fps
ConvertBits(16)
MDegrainNL(MT=true, TR=2)
Trim(1000,1999)

20.47fps
ConvertBits(16)
MDegrainNL(MT=true, BLKSize=8, TR=2, SearchBits=8)
Trim(1000,1999)

17.61fps
ConvertBits(16)
MDegrainNL(MT=true, BLKSize=8, TR=2)
Trim(1000,1999)

What difference it makes to the degraining, I'll confess I haven't checked, as I rarely work with high bitdepth sources.
If the above is any indication maybe as the block size decreases the speed increase decreases too.

YUV=full: It made like 1MB difference for 600 1080p frames with lossless ffv1. Checking still frames with 200% zoom, I couldn't see any difference.

I couldn't tell you in file size, but I was degraining some noisy animation when I tried the YUV=full thing, and I thought it offered a slight improvement. Not anything you'd probably notice until you compared still frames, but I figured it's virtually free so I kept it.

[takla]

hello_hello
TrueMotion=false is 5.6% slower in my testings. But I'm testing with actual encodings and I'd recommend you do the same.

On SearchBits, my CPU (Ryzen 9 3900x) still has plenty of room to spare even with Prefetch(12) and when encoding FFV1. I think that is why I don't see any speed difference from there.

[hello_hello]

hello_hello
TrueMotion=false is 5.6% slower in my testings. But I'm testing with actual encodings and I'd recommend you do the same.

What happened to 18%?

On SearchBits, my CPU (Ryzen 9 3900x) still has plenty of room to spare even with Prefetch(12) and when encoding FFV1. I think that is why I don't see any speed difference from there.

Yes, it sounds like FFV1 encoding is the bottleneck, but that's why it's better to test things individually.

[takla]

What happened to 18%?


Sorry forgot to say, 5.6% slower with ColorBarsHD(1920, 1080) and ~18% slower with an actual video file.

[takla]

Updated OP.
Did some more tests. EZdenoise is now literally twice as fast as BM3D_CPU all while retaining more details. Amazing.

And for future reference, I will only ever test speed with real videos, using real encodings with FFMPEG. No more ColorBars etc.

[DTL]

"Chroma: I recommend you only enable this if your video has visible chroma noise. It is much slower if set to true."

It is good to separate chroma in MAnalyse from chroma in MDegrain. If some speedup is important and quality is not visibly degraded chroma may be disabled for MAnalyse. But if disabling chroma in MDegrain (it uses chroma from MSuper) is greatly reduce degraining. So it may be better to have 2 control params - chroma for analyse and chroma for degrain. For best quality - both enabled. For best speed - both disabled. Though they are not freely controlled. Valid is only 3 of 4 combinations:
Chroma analyse false, chroma degrain false.
Chroma analyse true, chroma degrain true.
Chroma analyse false, chroma degrain true.
Chroma analyse true, chroma degrain false. - invalid.

[takla]

In my testings, using lossless FFV1, looking at single frames, there was no difference between Chroma=True/False.
So the only difference for me was speed.
I also tested different true/false configurations of super & analyse and concluded, that having two settings instead of one wasn't worth it.
Even if chroma=false in theory removes less noise (which I cannot see in my testings), using a lossy encoding removes noise too and so the challenge becomes to remove just enough noise and leave some for the video encoder or else it will not distribute enough bits for very fine details.

[lansing]

The filter basically did nothing to the video, it is not removing any temporal noise or spatial noise at all.

[takla]

The filter basically did nothing to the video, it is not removing any temporal noise or spatial noise at all.

Then you must have done something wrong. Or the default settings aren't strong enough? Give me a 10 second clip of the video and I'll see what I can do for you.

[lansing]

Then you must have done something wrong. Or the default settings aren't strong enough? Give me a 10 second clip of the video and I'll see what I can do for you.

Here's a dvd sample (https://www.mediafire.com/file/y8xaqoozziw6g52/test_stream.m2v/file)

[DTL]

It looks internal default thSAD of 150 too low for medium noise SD footages. The old mvtools default is about 400. It is the main param that user must adjust for each given footage to get best ratio of denoise/blur. Unfortunately currently there is no auto-adjustment implemented.

[takla]

Here's a dvd sample (https://www.mediafire.com/file/y8xaqoozziw6g52/test_stream.m2v/file)

Original
https://i.ibb.co/fkbDmhr/RAW.png

Denoised
https://i.ibb.co/5FTLFmr/02.png

I used frame 72 as the screenshot.

Exact parameters used:

LWLibavVideoSource("C:\Users\Admin\Downloads\1234.ts")
Crop(2, 4, -2, -0)
Spline36Resize(720, 540)
EZdenoise(thSAD=400, TR=4, Chroma=true)
Prefetch(12, 48)


As already pointed out by DTL, you need a higher thSAD value for videos with this much noise. And I'd also recommend using Chroma=true because, in this case, it very much does improve denoising.

Note: Images were taken with EZdenoise_v3

[takla]

Updated to v3
Added "Falloff" parameter.
Previously, thSAD2's would be (thSAD/2), which was probably too low.
Newest version uses (thSAD*0.9).
There should be no reason for you to change the new default.

[DTL]

One possible way to estimate initial thSAD value is to get MVs for single frame delta and add MShow(showsad=true) and run through footage a bit. It will show 2 numbers at the top left corner and first number is the mean SAD of blocks in frame. So initial thSAD for denoise should be as bit higher (like mean SAD * 1.2..1.5).

I typically use like this:

super = MSuper(pel=1, mt=false)
forward_vec1 = MAnalyse(super, isb = false, chroma=false, delta = 1, mt=false)
MShow(super, showsad=true, forward_vec1, thSCD1=2000, thSCD2=2000)


For the very high noise levels it something required to set higher thSCD values or the filters stop working (all frames and blocks detected as scene change). Default common mvtools params are thSCD1 (int, 400) , thSCD2 (int, 130). But to process very high noise levels footages increasing required.

You may add it as service function MeasureSAD().

So typical workflow is:
1. Run MeasureSAD() function to look for mean SAD of footage.
2. Setup initial EZdenoize param of thSAD ~ mean SAD * 1.5
3. Adjust TR param to get initial required speed/denoise ratio.
4. Make recursive adjustments of thSAD and TR to finetune denoise/blur/speed ratios.

For this test anime sample mean SAD is about 180..190 so the minimum working thSAD to start MDegrain working should be about 200..250+.

[lansing]

You'll need to put your file on some file hosting site, it takes ages to get approve in the forum if you uploaded as attachment.

[DTL]

So small scripts possibly faster to post in text form. v3 is possibly equal to posted in https://forum.doom9.org/showthread.php?p=1969764#post1969764 .

[takla]

You'll need to put your file on some file hosting site, it takes ages to get approve in the forum if you uploaded as attachment.

https://www.mediafire.com/file/twbbjt8qcs7q2ef/EZdenoise_v3.zip/file

[lansing]

One possible way to estimate initial thSAD value is to get MVs for single frame delta and add MShow(showsad=true) and run through footage a bit. It will show 2 numbers at the top left corner and first number is the mean SAD of blocks in frame. So initial thSAD for denoise should be as bit higher (like mean SAD * 1.2..1.5).

I typically use like this:

super = MSuper(pel=1, mt=false)
forward_vec1 = MAnalyse(super, isb = false, chroma=false, delta = 1, mt=false)
MShow(super, showsad=true, forward_vec1, thSCD1=2000, thSCD2=2000)


For the very high noise levels it something required to set higher thSCD values or the filters stop working (all frames and blocks detected as scene change). Default common mvtools params are thSCD1 (int, 400) , thSCD2 (int, 130). But to process very high noise levels footages increasing required.

You may add it as service function MeasureSAD().

So typical workflow is:
1. Run MeasureSAD() function to look for mean SAD of footage.
2. Setup initial EZdenoize param of thSAD ~ mean SAD * 1.5
3. Adjust TR param to get initial required speed/denoise ratio.
4. Make recursive adjustments of thSAD and TR to finetune denoise/blur/speed ratios.

For this test anime sample mean SAD is about 180..190 so the minimum working thSAD to start MDegrain working should be about 200..250+.

It's pointless going through all that work for a mediocre result. There's a limit in MDegrain on how much noise can be removed, just like from my sample video. Turn up thSAD all you want and there are still going to grain on the image.

[takla]

There's a limit in MDegrain on how much noise can be removed, just like from my sample video. Turn up thSAD all you want and there are still going to grain on the image.

Yeah no sh!t. And I wouldn't call the result mediocre. I was conservative with the TR value because I don't know what CPU you have or how much speed matters to you. If you really want to remove ALL grain, use Topaz Video Enhance AI (https://topazlabs.com/downloads/)

[takla]

Here you go:

Topaz Video Enhance AI v2.6.4 using Artemis Medium Quality v13 (Note: Medium Quality refers to the source material)
https://i.ibb.co/rtsXTzv/topaz.png

Using my AMD Radeon RX 5700 GPU I get about 16 FPS on that type of video.

And here is EZdenoise again, this time with TR8 and settings as before:

https://i.ibb.co/Sd68pdP/TR8.png

I get about 90 FPS with my AMD Ryzen 3900X CPU. Pretty darn good for being over 5 times as fast, if you ask me.

[kedautinh12]

Here you go:

Topaz Video Enhance AI v2.6.4 using Artemis Medium Quality v13 (Note: Medium Quality refers to the source material)
https://i.ibb.co/rtsXTzv/topaz.png

Using my AMD Radeon RX 5700 GPU I get about 16 FPS on that type of video.

And here is EZdenoise again, this time with TR8 and settings as before:

https://i.ibb.co/Sd68pdP/TR8.png

I get about 90 FPS with my AMD Ryzen 3900X CPU. Pretty darn good for being over 5 times as fast, if you ask me.

Your EZdenoise support live action???

[takla]

Your EZdenoise support live action???

You mean real time denoising? Yeah, if your CPU is good enough. With default settings at 1920x1080 8bit I get about 44 FPS

Or you mean if EZdenoise supports real world videos, and not just anime? Of course it does.

[kedautinh12]

Yeah, real world

[lollo2]

Here my quick attempt with TemporalDegrain2; a KNLMeansCL post processing may be more appropriate than dfttest I used:

https://ibb.co/MDZBcFK

TemporalDegrain2(degrainTR=8, postFFT=3, postsigma=6)

Comparison with takla's EZdenoise: https://imgsli.com/MTEwNjE5; with given settings TD2 removes more noise but uses post processing, so the comparison may not be accurate.

Comparizon with Topaz VEAI: https://imgsli.com/MTEwNjE3; with given settings TD2 removes more noise but blurs the edges more; changing its setting, TD2 can perform better.

Thanks takla for EZdenoise, for sure is competitive and is worth a try (for live action Topaz is not adequate)