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

[Khun_Doug]

I downloaded avsmeter and ran avsmeter -avsinfo. All the plugins list as 32 bit and look correct. I can attach the listing here if the information would be considered useful. Bottom line is the same results and error. This filter simply refuses to function with the defaults (no parameters), or any parameter as long as sharp is true. The error is the same, invalid arguments to function mt_clamp. But I tested other filters that use mt_clamp and there are no faults or script crashes. I have even gone so far as changing dgdecode.dll to ffms2.dll, and then trying a different source. Results are the same.

Any other suggestions or debugging tips are welcome.

[StainlessS]

Just a simple tip, can use RT_Stats RT_Debug() or RT_DebugF() to show progress,
eg

IntVar=42
RT_DebugF("OK here at step 1 (some IntVar = %d)",IntVar)
IntVar=SomeFunc()
RT_DebugF("OK here at step 2 (some IntVar = %d)",IntVar)

Need DebugView (Google) to view debug output.
or here:- https://docs.microsoft.com/en-us/sys...oads/debugview

[Khun_Doug]

StainlessS, the problem is resolved. I posted the information on the MCTD forum in the event someone else hits that error in the future. Now I can get back to the original thing; that was to compare mClean to MCTD. And now I have another tool in the grab bag.

[MysteryX]

The latest version is throwing me: "MDegrainX: clip and super clip have different bit depths" at line 128

[MysteryX]

I'm also getting much better results with MCTemporalDenoise than with mClean. It accomplishes the same goal, packing the various cleaning functions together to give optimal results, and doesn't have the shape and color distortion problems I had with mClean.

[MysteryX]

If used as a prefilter with FrameRateConverter, mClean was working nicely while MCTemporalDenoise introduces some artifacts. I think MCTemporalDenoise gives better image stabilization and output quality, at the cost of slightly shifting some motions causing artifacts with FRC, while mClean seems to better respect the vectors of the source image.

[Khun_Doug]

Now that I finally have an MCTD that is functional I have been able to do some comparisons between MCTD and mClean, and also included tests with SMDegrain. When using MCTD I chose the setting of medium. On my worst test cases, the material with the highest amount of noise, only mClean does a good job of cleaning and denoising while maintaining detail. Is it perfect? No. But MCTD and SMDegrain could not clean those worst cases and carried along a noticeable amount of noise.

The largest drawback I found with MCTD was the way it added a milky or smokey haze to the output. At first I ignored it and kept watching the output looking for artifacts, distortion, etc. But that haze becomes some obvious in certain scenes that there is no avoiding it. I purposely did side by side tests (with StackHorizontal) between the source and mClean, and the source and MCTD.

What I gleaned from the tests, so far, is that material that is not overly noisy, SMDegrain was my best choice. With some variations of its parameters I was able to significantly remove noise. But as I already stated, in the worse examples, mClean handled the task, and do so very well.

One other point worth mentioning is that mClean and SMDegrain work very well with SetFilterMTMode. The very best I was ever able to get with MCTD was SetFilterMTMode (4, force=true).

[lansing]

Originally Posted by Khun_Doug

only mClean does a good job of cleaning and denoising while maintaining detail.

No it doesn't. With mdegrain being the core for temporal denoising, both mclean and smdegrain will alter details on moving object, that's how it is.

Originally Posted by Khun_Doug

The largest drawback I found with MCTD was the way it added a milky or smokey haze to the output.

MCTD doesn't produce haze, you may have another issue with outdated filters.

Originally Posted by Khun_Doug

What I gleaned from the tests, so far, is that material that is not overly noisy, SMDegrain was my best choice. With some variations of its parameters I was able to significantly remove noise. But as I already stated, in the worse examples, mClean handled the task, and do so very well.

For videos with heavy spatial noise, you will need to look at KnlmeansCL or the commercial Neat Video.

[MysteryX]

I find KnlMeansCL to give a lot blurrier results than mClean or MCTD. I guess we have to choose: blurrier or slight distortions.

Truth is various types of noise and videos will look better with either one of these 4: KnlMeansCL, MCTD, mClean or SMDegrain. So in my software I'm probably best to allow the user to select any one of them.

[Khun_Doug]

I agree on the blurred results from KNMeansCL. I tried FluxSmooth but it only handles the lightest amount of noise. The thing that caught my eye, quite by surprise actually, was the way mClean handles old B&W films where the brightness would flicker. I have one film that is really bad where the faces of the actors actually has brightness fluctuations. The mClean helped smooth that away and really stabilized the entire video. But I think having all of these as user choices rather than force just one is a wise decision.

The one thing to consider also is whether there needs to be sharpening after the noise filter. I haven't found the need for sharpening with mClean. With SMDegrain I set ContraSharp to true. I have too little experience with MCTD to know whether it needs additional sharpening. FluxSmooth definitely does need sharpening. My favorite choice is mSharpen. The option on that filter to have the areas highlighted so you can see what the filter is seeing is extremely helpful.

[SaurusX]

I’d be curious to see the knlmeanscl settings they people are using and having blurred results. From my testing the “a” parameter value plays the largest part in the blurring by removing low frequency noise, mottling, or subtle color differences in the video. Anything higher than 1 is going to smudge out the finer subtle details. But maybe that’s desired in situations. That value is a smoother. An “s” value greater than 1 tends to wink out pinpoint noise like star fields similar to the filter dedot(). That said, it’s my go-to denoiser due to its preservation of details with the correct settings for the source.

[MysteryX]

Does the latest version work for anyone? I still get this error:

"MDegrainX : clip and super clip have different bit depths"

[Khun_Doug]

I use mClean 3.2 quite a lot on older SD and HD material that have a goodly amount of grain and noise. I never hit that error with mClean. It could be that you have an outdated plug-in. I only ever processed 8 bit material so it is possible that higher bit-depth material may have a problem.

The best tool I found for checking plug-in information is AVSmeter. Look for duplicate plug-ins and check the versions.

[Khun_Doug]

Burfadel, do you have any plans to further tweak or modify this script? I keep hitting a problem where cropped sources have a visible line of distortion on the right side of the frames/clips. I have verified that if I crop further in, the distortion disappears. But I shouldn't need to crop off borders beyond the black (or noise).

Just to be sure the cropping was correct I tried a different filter that does a similar job. The line of distortion is not created in the output.

Could this be something related to divisible width? For example, does the source need to be a multiple of 2, 4, 8?

[StainlessS]

You could probably say what dimensions cause problem, and what fixes it.

This looks a little strange to me

padX       =  c.width%8 == 0 ? 0 : (16 - c.width%8)
padY       =  c.height%8 == 0 ? 0 : (16 - c.height%8)

Try changing all 8's to 16's and see what happens.

[Khun_Doug]

I think those modulo divisions are exactly where the fault lies. I was using 1436X1080. Everything else works fine but there is this line of corrupted pixels near the entire right edge. I changed the 8's to 16's and the corrupted pixels are gone. Just to be on the safe side I left the original lines but commented out, and added corrected versions of the lines.

padX = c.width%16 == 0 ? 0 : (16 - c.width%16)
padY = c.height%16 == 0 ? 0 : (16 - c.height%16)

If burfadel is around I would feel happy if he could confirm this as the culprit and fix.

Thanks for help!

[Mawazi]

Originally Posted by MysteryX

The latest version is throwing me: "MDegrainX: clip and super clip have different bit depths" at line 128

I was getting the same error. I updated mvtools2 to https://github.com/pinterf/mvtools/r...with-depans.7z and that cleared up the problem.

[ChaosKing]

Thanks to Wolfberry there is now a Vapoursynth version of mClean https://forum.doom9.org/showthread.php?t=175614

[Selur]

blksize    =  sc==8 ? 8 : ((defH/sc)/360)>1.5 ? 16 : ((defH/sc)/360)>0.8 ? 12 : 8

Is blksize 12 correct?

Analyze: the block size must be 2x2, 4x4, 8x4, 8x8, 16x2, 16x8, 16x16, 32x16, 32x32, 64x32, 64x64, 128x64, 128x128, 256x128, or 256x256

no mention of 12x...

Cu Selur

[StainlessS]

Changelog from Version 2.7.31

2.7.19.22 (20170525)

New: [MMask] Support any planar input video formats e.g. greyscale, Planar RGB.
Input clip can even be of different bit depth or format from vector's original format
For kind==5 where U and V is filled, the greyscale option is not allowed
Mod: [MMask] Faster: request source frame only for kind=5.
Fix: [MxxxxFPS,MMask]: MakeVectorOcclusionMaskTime garbage in bottom blocks (30 hrs of debugging)
Fix: [MMask] bottom padding garbage for padded frame dimension
Fix: [MMask] proper 10+ bits scene change values (for default: 1023, 4095, 16383, 65535. Was: 65535)
Parameter is still in 8-bit range
Fix: [MRecalculate] prevent overflow during thSAD scaling in 16 bits or large block sizes (32, 48...)
Fix: [DepanEstimate] Sometimes giving wrong motion instead of scene change detection
Fix: [MAnalyze] Possible overflow in MAnalyze 8 bit, block size 48x48 and above.
Overflow-safe predictor recalc for big block sizes
New: [General] Add block size 12x3 for SAD, allow 6x24
List of available block sizes
64x64, 64x48, 64x32, 64x16
48x64, 48x48, 48x24, 48x12
32x64, 32x32, 32x24, 32x16, 32x8
24x48, 24x24, 24x32, 24x12, 24x6
16x64, 16x32, 16x16, 16x12, 16x8, 16x4, 16x2
12x48, 12x24, 12x16, 12x12, 12x6, 12x3 <<<<<<<<<<<<<<<<<<<<<
8x32, 8x16, 8x8, 8x4, 8x2, 8x1
6x24, 6x12, 6x6, 6x3
4x8, 4x4, 4x2
3x6, 3x3
2x4, 2x2
Mod: [Internal] Reorganized 10-16 bit SAD simd intrinsics, faster 8-12% for BlkSize 12-32

EDIT: Selur, where did you find this

128x64, 128x128, 256x128, or 256x256