mClean spatio/temporal denoiser v3.2 (01 March 2018)

[lansing]

Originally Posted by burfadel

I found knlmeamscl to cause detail or edge sharpness loss. Denoising is ineffective if it also limits visual fidelity.

Here's the general order of sophistication of algorithm we have for spatial denoiser in avisynth now:
knlmeanscl>dfttest>fft3dfilter>removegrain

There's really no debate on its effectiveness, it's better than removegrain because it just has a better algorithm, end of debate.

As for chroma, it's just the sigma settings. There's a couple of things I haven't added for that yet also.

There's no point to tweak for chroma denoising because we cannot see them like 99% of the time. And I doubt that you tweak them by ExtractU/V+blown up brightness, so why even bother.

In addition to that, fft3dfilter's chroma denoise will desaturate color, people even use it as a derainbow alternative, so the best way to "fix" the problem is not use it.

The texture like noise isn't removed so much in that anime image, also remember you can set renoise to 0. Noise removal doesn't have to be absolute, some noise can be visually pleasing watching at a normal distance, without those overly flat surfaces. This of course depends on the type and quality of noise. mClean is temporally stabilised which is why it is relatively bandwidth friendly with renoise.

It's more like the removegrain inside mclean reached its limit than it chooses not to remove the grain.

[Groucho2004]

I'm also quite puzzled by the "loss of details" comments regarding KNLMeansCL. My experience with it (or any NLMeans algorithm) is the exact opposite. Maybe increasing the search window ("a") will yield better results.

[MysteryX]

Originally Posted by Groucho2004

Maybe increasing the search window ("a") will yield better results.

I've always been using KNLMeans with D=2, A=2

[MysteryX]

I did another test on a very grainy video take with my camera. In this case, KNLMeans wasn't doing a good job and I instead opted for SMDegrain.

Original / SMDegrain / mClean v1.3c / mClean v1.7c


I lowered enh from 27 to 22. v1.3c does lose considerable details with such grains, and v1.7c does a lot better here. Much better output than SMDegrain.

I don't mind tweaking enh to what suits me best, but what is more of a problem is having to calculate its dynamic value before altering its value. You divine height by 40 for its default value. Perhaps it could set the division factor or something like that.

It's not giving the plastic effect, but it's not falling far. Without renoise, it would look like a plastic doll.

I can definitely use this instead of SMDegrain. v1.7c isn't giving as consistent results with low-quality VCDs though.

Note: the clip above is rather static. Animated scenes may give different results.



Here, unfortunately, it's blurring out my shirt.

[SaurusX]

Originally Posted by MysteryX

I've always been using KNLMeans with D=2, A=2

I've found that changing the S value to S=1 also preserves more fine details. Star fields and the like. The higher the A value in combination with S=1, the better it seems to do.

That being said, I use D=1,A=3,S=1. Bumping up D to 2 can introduce encoding errors when you combine it with a lot of other temporal filters. The end effect seems to be minimal, especially for animated content.

EDIT FROM THE FAR FUTURE: Now I use D=3, A=1, S=1. S for the same reasons as before. A higher D does a better job of eliminating Gaussian random noise and keep details. A lower A provides less smoothing of large flat areas. I only increase A if I find that after removing the white noise with a high D that what's left behind is an uneven orange-peel or mottled look.

[burfadel]

If you can think if a better way to scale enh, since the greater the resolution the higher it needs to be. I've made some performance improvements to the script, and it also uses less memory. I've still got some tweaking to do on it. I've discovered search 0, 1, and 2 don't seem to be optimised, which makes sense, default 4 is practically faster. I wonder if optimisations from x265 could be incorporated, I think it will help with speed. Ideally STAR search should be ported and made default, it's as fast as UMH search in x265, sometimes faster, and provided results like exhaustive. The default search range in MVTools is quite small, a ported optimised STAR search would not only likely be faster but produce more accurate and nicer results. Remember the search algorithms in MVTools2 have been there for 10+ years, are unlikely fully optimised, and are the principle thing that is required by most functions. Other functions like MDegrain rely on it indirectly, but would still benefit hugely.

[burfadel]

Updated first post to v1.8. Speed improvements, memory use reduction, and better quality.

[Atak_Snajpera]

I did another test on a very grainy video take with my camera. In this case, KNLMeans wasn't doing a good job and I instead opted for SMDegrain.

This does not look like very grainy video to me! This is example of very grainy video

[burfadel]

Is that grain changing every frame or is it consistent? If consistent the noise is basically a texture, so removal of that noise you are potentially removing detail. Spatial denoisers work on pixels or area of pixels as either a blank implementation, effectively acting as a blur, or difference between pixels to determine whether it should be removed. Temporal denoisers work by difference between frames, ideally in this case you track the movement over the temporal radius. Spatial denoisers were traditionally preferenced because they are generally fast and can be good at damping and softening static noise at the risk of losing detail. No denoiser can be perfect, because you are fundamentally changing the picture.

What did you think of v1.8? The results are 'quite different'. I might have to chase up a couple of things in MVTools2 with PinterF, the issues don't effect the output of v1.8, they're just bugs I found along the way that should be simple fixes.

[burfadel]

Originally Posted by ChaosKing

@burfadel will you port this script to vapoursynth too? I find it quite effective against heavy noise, with better "color stabilising" than smdegrain. (at least for my anime source)

Sorry I didn't answer this question earlier, I forgot about it . I have no idea about Vapoursynth, the syntax is different and the workings of some of the commands is also different. mClean is still in development, it would be time consuming to maintain the changes between the two.

[lansing]

Originally Posted by burfadel

What did you think of v1.8? The results are 'quite different'. I might have to chase up a couple of things in MVTools2 with PinterF, the issues don't effect the output of v1.8, they're just bugs I found along the way that should be simple fixes.

Like I said before, you should have test it yourself before posting, or you would have known that the black dot artifacts was brought back again a couple of version ago.

And I don't really notice any speed improvement, same old 14fps on my 4770k with a 1080 blankclip script

BlankClip(length=10000, width=1920, height=1080, pixel_type="yv12")
killaudio()
mclean()
prefetch(8)

AVSMeter 2.6.2 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, x86_64) (0.1.0.0)

Number of frames:                10000
Length (hh:mm:ss.ms):     00:06:56.667
Frame width:                      1920
Frame height:                     1080
Framerate:                      24.000 (24/1)
Colorspace:                       YV12

Frames processed:               656 (0 - 655)
FPS (min | max | average):      1.115 | 85451 | 14.22
Memory usage (phys | virt):     1935 | 2145 MiB
Thread count:                   33
CPU usage (average):            72%

Time (elapsed):                 00:00:46.121

Press any key to exit...

[burfadel]

I did do testing before posting, doesn't meant I can come across all issues. The speed thing you noticed is peculiar, in all testing that I did it was noticeably faster for me consistently, as well as using less memory.

Same test as you, except length is 1000. CPU usage is lower becuase I set prefetch(8) on a 16 thread machine.

mClean 1.7c:

AVSMeter 2.6.5 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, x86_64) (0.1.0.0)

Number of frames:                 1000
Length (hh:mm:ss.ms):     00:00:41.667
Frame width:                      1920
Frame height:                     1080
Framerate:                      24.000 (24/1)
Colorspace:                       YV12

Frames processed:               1000 (0 - 999)
FPS (min | max | average):      1.885 | 21560 | 21.32
Memory usage (phys | virt):     1792 | 2136 MiB
Thread count:                   53
CPU usage (average):            41%

Time (elapsed):                 00:00:46.9

mClean 1.8:

AVSMeter 2.6.5 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, x86_64) (0.1.0.0)

Number of frames:                 1000
Length (hh:mm:ss.ms):     00:00:41.667
Frame width:                      1920
Frame height:                     1080
Framerate:                      24.000 (24/1)
Colorspace:                       YV12

Frames processed:               1000 (0 - 999)
FPS (min | max | average):      1.783 | 26352 | 25.53
Memory usage (phys | virt):     1515 | 1536 MiB
Thread count:                   37
CPU usage (average):            36%

Time (elapsed):                 00:00:39.170

It's faster for me and uses less memory than mClean 1.7c. Also the CPU usage is less.

Of course it's a bit counter-intuitive to test a temporal filter, particularly one that uses MVTools2, on a blank clip .

[tebasuna51]

In previous versions (at least until 1.4) there are the line:

blkSize = Default (blkSize, DefH<360 ? 8 : DefH<750 ? 12 : DefH<1200 ? 16 : DefH<1600 ? 24 : 32) # Horizontal block size for MDegrain4

In mClean 1.8 the line is:

blkSize = Default (blkSize, defH>480 ? 12 : defH>1200 ? 16 : defH >=2600 ? 32 : 8) # Horizontal block size for MDegrain4

Are you sure about that sintax?

I think than defH>1200 ? 16 : defH >=2600 ? 32 never work, is always 12 for defH>480.

[Groucho2004]

Originally Posted by burfadel

Of course it's a bit counter-intuitive to test a temporal filter, particularly one that uses MVTools2, on a blank clip .

You can always use synthetic, random grain like this:

colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(24000, 1001).trim(0, 999)
addgrain(var = 100.0)

[Sharc]

mClean Version 1.8, AVS+ 32 bit:
I'm getting from avisynth a "System exception - Illegal Instruction .... line 117" which is
clean = clean.dctfilter (1,1,1,1,1,1,0.50,0)
My dctfilter version is 0.5.0.0.

Any suggestion what could be wrong?

[burfadel]

If you run dctfilter by itself does it do the same thing? What CPU do you have?

[manolito]

What about this post by tebasuna51?
https://forum.doom9.org/showthread.p...28#post1819328

IMO he is absolutely right, the logic in the 1.8 version of the script is faulty.


Cheers
manolito

[burfadel]

Originally Posted by manolito

What about this post by tebasuna51?
https://forum.doom9.org/showthread.p...28#post1819328

IMO he is absolutely right, the logic in the 1.8 version of the script is faulty.


Cheers
manolito

Possibly? I see what you mean though, I'll fix that for the next version.

Currently I'm trying to work out the most ideal way to work a new quality feature. It's ideal in almost all situations and frames, it's trying to work the remaining situations that is the tricky part. It resolves the issue on the snow clip that was posted . I've tried basically everything simple, so I might have to look at another approach which will still be faster than v1.7c but take some of the gains of v1.8, in addition to taking some of the gains as a result of the feature itself. Hopefully it will be worth it though .

[Sharc]

Originally Posted by burfadel

If you run dctfilter by itself does it do the same thing? What CPU do you have?

Problem solved, thanks.
By mistake I copied both the DCTFilter.dll and the DCTFilter_avx2.dll into the avisynth plugins folder.

[MysteryX]

v1.8 seems to give a little bit more of a plastic effect, and it shifts the image slightly to the left, which may be the cause of the 1st problem if luma/chroma aren't aligned