EZdenoise

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

Originally Posted by takla

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.

Originally Posted by takla

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.

Originally Posted by takla

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]

Originally Posted by 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.

What happened to 18%?

Originally Posted by takla

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]

Originally Posted by hello_hello

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]

Originally Posted by lansing

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]

Originally Posted by takla

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

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

Originally Posted by lansing

Here's a dvd sample

Original


Denoised


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