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

[MysteryX]

Something I've noticed around here is that whenever I'm working on something, there are always some members not just disagreeing but aggressively trying to destroy it.

I worked on SuperRes to improve the upscaling quality and many were saying it was impossible and that it was impossible to get better results than NNEDI3. Turns out it's now the best upscaling method available in Avisynth.

I worked on FrameRateConverter and people were saying it was impossible to accurately detect artifacts to give an output that works most of the time, and that I shouldn't waste any time even trying. I did it and it's working pretty well.

Now I'm hearing the same thing all over again with this. I'm getting used to the pattern. Yes, I know it's impossible. Yes, I know it doesn't make sense based on old concepts. We're doing it anyway. Because we don't operate from the same mental container. I think me and Burdafel have this in common. We don't think outside the box. We just didn't know of the box to begin with. That's more the space we should be thinking from.

[MysteryX]

Getting back on topic, what I'm seeing is that with MvTools, the vector motion data is a lot more important than I thought. Tiny changes to motion vectors data can result in very different results. To the point where RemoveGrain(18) and RemoveGrain(21) produce a considerably different output -- which I know, doesn't make logical sense.

[lansing]

Originally Posted by MysteryX

Watch your language. If you don't like what we're doing, just get the heck out.


Yes that's what I meant by original, perhaps I should have called it "no prefilter", but I think anyone with a brain understood that. I can't compare with original because generated frames don't match source frames.

Please, if you got nothing constructive to say, shut up.

Edit: I renamed it to "no prefilter" to avoid confusing anyone else

If someone else views any screenshot other than mClean(rn=10) to give better results, I'm listening, but please have something to back up what you say. This test is pretty simple: comparing 6 versions of a script to see which gives better results. I don't care about how "things should be done", I only care about concrete results.

What in the blue hell does that have to do with this thread?

Since when does this thread gone from comparing OP's script to other denoisers, to comparing how every denoiser perform inside YOUR filter?

I'm pretty certain that I said more constructive things than someone who have hijacked the thread for the last 5 pages talking about his own stuffs. I didn't see you saying a single word about the obvious problem that is underlying in OP's core smdegrain. To evaluate the quality of filter, you have to look it in both the pros and cons, if the cons exceeded a certain point, then the filter is a no go.

Here's a short scene emphasizing the problem I'm talking about.
snow

[MysteryX]

The conversation of mClean began within the conversation of FrameRateConverter. Budafel stated that he wanted to improve the source to feed into the interpolation. That's definitely not its only use.

Originally Posted by lansing

Here's a short scene emphasizing the problem I'm talking about.
snow

Finally something constructive. You never mentioned this before unless I missed a few posts.

I found previously that KNLMeansCL worked well with artifacts but SMDegrain worked better with grainy videos, kind of like the one you have.

I was wondering whether mClean would replace SMDegrain, and I think that your post answers the question. I suppose SMDegrain is what gives the best result on that clip?

Burdafel, I'm testing your latest version with my 288p VCDs. enh=13, rn=10 is working good. enh=20, rn=12 is too much, in similar proportion to the HD videos. There's little difference between rn=0 and rn=10 but for heavy artifacts rn=0 works better. It seems this filter performs equally well on heavy artifacts or on no-artifacts clips. Which is a good thing when both are in the same frame.

Can you post a sample frame where you say it benefits from high enh?

[MysteryX]

288p clip with denoise, upscale and frame interpolation.

- Deblock_QED
- Deblock_QED + mClean(rn=0)
- KnlMeansCL(D=2, A=2, h=1.8, channels="YUV")



KnlMeans removes a lot more artifacts but kills a lot of details, especially in the curtains.

mClean is again my favorite version, BUT artifact removal is a bit weak. Raising thSAD removes real details instead of removing more artifacts. Is there a way to make it just a little bit stronger? Perhaps lansing's clip has the same issue: mClean is a bit too weak for the job. I'm sure you'll come up with a new feature idea that will fix this.

[lansing]

Originally Posted by MysteryX

The conversation of mClean began within the conversation of FrameRateConverter. Budafel stated that he wanted to improve the source to feed into the interpolation. That's definitely not its only use.

If that was his original intention then he should change the title to something like "a denoiser for better motion vector search for mvtools".

Finally something constructive. You never mentioned this before unless I missed a few posts.

Because I wasn't expecting someone who're writing a filter around smdegrain to not know the fault of smdegrain.

I was wondering whether mClean would replace SMDegrain, and I think that your post answers the question. I suppose SMDegrain is what gives the best result on that clip?

No! It's the complete opposite! That's the reason I don't use smdegrain, don't you see that mclean(smdegrain) is wiping out half of the snow which are details? Where is your logical sense?

For the OP, he'll eventually need to make a decision between quality and performance, just like what he had been adviced. If he is not to fix the core problem of his denoiser (like right now), then his script is going to be just another variation of smdegrain no matter how many fancy post processing he add. If he IS to fix it, he must also realize that someone had already done that 9 years ago. Why even bother reinventing the same thing...
MCTD

[burfadel]

Yes, most often it is a tradeoff of performance and speed. You are limited by the speed of the filters used, so the best idea would be to find new ways of dealing with that. Most filter scripts use the same process for Chroma and Luma. I use the most ideal solution for these. MVtools does not do a good job on Chroma, but does on Luma. FFT3DFilter is similar on Luma as KNLMeansCL, but is great on Chroma. KNLMeansCL on chroma isn't the most efficient option.

In terms of the post processing, remoise is quite differet to the other options out there, it's perceptual based intended for motion, so still shots may not represent the trueness of it. In terms of sharpening, it is detail orientated and works on the inverse of the areas that renoise works on. The actual sharpen method itself is a unsharp filter. I haven't seen the solution I used elsewhere, it's ultra simple and super fast though . Most other filters use external scripts. mClean doesn't deblock, unless I find a differing solution to what is out there it probably won't! Any other solutions can run separately afterwards. That said, there would be some benefit from internalising something like deblock_QED and simplifying it, because applying renoise and the sharpening after it would be beneficial. There's also another filter I would consider simplifying and incorporating it for the same reason, but ultimately any filters such as these will have simplified parameters. Most of the extra parameters or changing settings serves little or no benefit, and any change they do provide is usually in relation to another setting... so you can apply it as one setting that scales the individual settings. There are some useful things in MCTemporalDenoise, I saw those earlier . At the moment I haven't borrowed from that script, but I probably will in the future and simplify where necessary. It's why I originally referred to it as an all-in-one script that I wanted to keep as simple as possible. Make the best script that I can do, and only then apply the best features from the other scripts and simplify their parameters. This is also inclusive of leveraging any advancements in Avisynth or respective filters, as well as accepting different solutions that people offer. I'll of course mention the respective other scripts when utilsing portions of their code.

As an all-in-one I also intended it to be a prefilter for FrameRateConverter or anything else, MysteryX knows this .

[feisty2]

Since u guys been bitching about NLMeans a lot, y'all should know "h" is not the only hyperparameter? "s" is another major parameter that has to be carefully tweaked, default "s=4" is def a no go for ur shitty vcd garbage, make it 1 and gradually increase it till it feels rite

[lansing]

Originally Posted by burfadel

Yes, most often it is a tradeoff of performance and speed. You are limited by the speed of the filters used, so the best idea would be to find new ways of dealing with that.

Yes, that would require ideas for a new algorithm, not by using 10+ years old filters like what you're doing right now. Even then, the law between quality vs performance is not going to change, better quality is going to take longer processing time.

All the talk you said about your post processings are not reflecting on your result because your core denoising method (smdegrain) is giving you crappy input. All I'm seeing right now are the artifacts created by your smdegrain and artifacts created your mask.

[MysteryX]

Originally Posted by lansing

If that was his original intention then he should change the title to something like "a denoiser for better motion vector search for mvtools".

It's not only for that, as Burdafel already explained clearly enough.

Originally Posted by lansing

mclean(smdegrain) is wiping out half of the snow which are details

I can't even know that from the clip you sent, as I don't have the original. Next time I would suggest posting individual frames before and after so we can see the difference.

Originally Posted by lansing

To evaluate the quality of filter, you have to look it in both the pros and cons, if the cons exceeded a certain point, then the filter is a no go.

That's where you and I fundamentally disagree. You're here to destroy. We're here to create.

If someone works on something that gives bad results, I'll point the flaws so that at the very least he will learn and improve himself from it. You'll just go in with a knife in his back to destroy him and his ideas. If you succeed, it's unlikely that member will bring anything else in the future. Luckily, there are many resilient members on this forum. I guess many are used to this dynamic (which isn't only you), as I see several people wait late in their development cycle until their script is solid before exposing it to public -- where it often gets torn apart.

So far I haven't seen any case where mClean degraded an image in any significant way. Perhaps your snow clip but I haven't seen the effect yet, nor what settings you used. If there is image deterioration, renoise should alleviate it.

--------------------------------

Putting that aside,

Burdafel, from what I've tested so far, it does a good job with subtle noise removal. Perfect as a prefilter, but a bit weak as a full-blown denoiser. Whether it works as a degrainer remains to be tested (perhaps on HD camera footage).

I'm not concerned about performance. There is however a trade-off between denoising and preserving details, and here the main focus was on preserving details, but perhaps there could be an effective "strength" setting.

Originally Posted by feisty2

Since u guys been bitching about NLMeans a lot, y'all should know "h" is not the only hyperparameter? "s" is another major parameter that has to be carefully tweaked, default "s=4" is def a no go for ur shitty vcd garbage, make it 1 and gradually increase it till it feels rite

Thanks, I'll definitely test it out!

P.S. I never bitch. Maybe if someone really crosses the line, and even then it's not bitching.

[burfadel]

Grain, both good and bad, is the main target. Artifacts are much harder as they're also effectively detail. I'll look for the happy balance.

[lansing]

Originally Posted by MysteryX

So far I haven't seen any case where mClean degraded an image in any significant way. Perhaps your snow clip but I haven't seen the effect yet, nor what settings you used. If there is image deterioration, renoise should alleviate it.

You don't see it because you have eye problem as it was proven here, and you have a history of seeing invisible stuff. All your feedbacks are bullshit that were based on who knows what you saw.

The snow clip is a very good example exposing the problem of smdegrain.

original


mclean()


The difference is so obvious, the filter is altering any moving object trying to smooth out the motion, in this case, it's wiping out the snow.


Here the filter is wiping out the detail on anything that moves:

original


mclean()

You're here to destroy. We're here to create.

If someone works on something that gives bad results, I'll point the flaws so that at the very least he will learn and improve himself from it.

This is so funny, I AM the one that's pointing out the flaws, not you! You can't even see the flaws because of your eye problem! You can't even see the artifacts that were created by the mask who know existed for how long.

[MysteryX]

Also post the script settings you use.

Posting on PostImage.io has the advantage of taking little space here and allowing to easily open in full-screen to compare images.

I agree that this particular clip reacts badly. Then it would be useful to see how it behaves with other denoisers. If you want to contribute, I would suggest posting sufficient relevant data:
- plugins/settings used
- screenshot
- comparison with other relevant denoisers
- your observation or conclusion in regards to the test ("this is BS" isn't a technical conclusion)

Sending the source of a difficult clip like that one could also be useful for Burdafel to work with. I developed FrameRateConverter using the worst videos I had for interpolation.

Every personal attacks might come back to you as big headaches -- better stick to a technical conversation.

[MysteryX]

Also Burdafel, if you need some custom algorithm written in C++, I can help with that (at least CPU version without assembly opt)

[Groucho2004]

Originally Posted by MysteryX

Burdafel

That makes 7 times you got his moniker wrong.

[StainlessS]

Originally Posted by Groucho2004

That makes 7 times you got his moniker wrong.

I think I've been guilty of same thing a number of times, Burfadel just dont sound as good Burdafel, maybe an name change is in order

EDIT: To below, perhaps I have not posted wrong name, but I have definitely been using that name mentally.

[Groucho2004]

Originally Posted by StainlessS

I think I've been guilty of same thing a number of times, Burfadel just dont sound as good Burdafel, maybe an name change is in order

Couldn't find a single instance. Maybe someone else who's name you butchered? Like Grouchy?

Actually, Grouchy is fine with me, has a nice ring to it.

[MysteryX]

Originally Posted by StainlessS

Burfadel just dont sound as good Burdafel, maybe an name change is in order

Agree

Groucho, every time I see your name I'm thinking of Schtroumpf Grognon

[burfadel]

Originally Posted by lansing

You don't see it because you have eye problem as it was proven here, and you have a history of seeing invisible stuff. All your feedbacks are bullshit that were based on who knows what you saw.

The snow clip is a very good example exposing the problem of smdegrain.

original


mclean()


The difference is so obvious, the filter is altering any moving object trying to smooth out the motion, in this case, it's wiping out the snow.


Here the filter is wiping out the detail on anything that moves:
...

This is so funny, I AM the one that's pointing out the flaws, not you! You can't even see the flaws because of your eye problem! You can't even see the artifacts that were created by the mask who know existed for how long.

Dont get mixed up between SMDegrain and MDegrain, SMDegrain is a script using MDegrain as it's base .

When removing grain you inevitably will remove what perceptually is detail. It's why adding the right type and amount of grain can make the image appear clearer and less flat. In this case, what appears to be detail that is removed due to the grain structure appearing as texture is actually most likely noise.

I've put together a test script with options for Mdegrain 3 through 6. This is adjusted by changing value of 'm'. If none is specific, the default 2 is used (MDegrain2), if you select 6 it will use MDegrain6, which is slower and should be overkill!

Additionally to that, there's an option 'recalc'. Default is false. If true, Mrecalculate will be used. This is a viable option speed wise if it has better quality .

There's also an option for search method, applied to recalculation. Reason for this is exhaustive search may be too slow for Analysis stage, but fine for recalculation due to the recalculation only being done for bad vectors. This will only have affect if recalc=true.

Finally, there's an option for DCT. Again, this is for recalc only as this is where it would most likely be beneficial and has less of an impact on speed. If false (default) it uses the default DCT value which is 0. If true, it uses DCT value 4. Value 4 is preferable over 1 due to speed, and it maintains most of the benefits of 1.

So, play around with these test functions and let me know what you like best. The renoise function will work differently for each setting, so you may also want to use rn=0 to see just the Mdegrain process, or rn=12 (for instance) to see how it responds in relation to noise removed.

This is just a test for differences, which one performs the best for you. As an added test, I changed the rfilter value for 4, if using just mCleanT() this will be the only difference between this script and mClean.

Function is mCleanT(), T for Test.
m: 2 through 6. MDegrain function. Default is 2, which uses MDegrain2 function. Options 3-6 will use MDegrain3, MDegrain4, MDegrain5, or MDegrain6
recalc: True/false. Default is false. Recalculate vectors when set to true. Setting to true will also activate search and dct options if specified
search: True/false. Fefault is false, which uses the mClean setting of 5 (UMH search). If set to true, will enable exhaustive search (3) for the recalculation (with recalc=true)
dct: True/false. Default is false where dct 0 is used. If true dct 4 is used for recalculation (with recalc=true)

If you like feel free to adjust the searchparam values.

Those black spots when using mClean obviously shouldn't be there. Is it possible to upload a 10 second clip to Onedrive, Google drive, Mediafire etc? That way I can investigate and resolve that.

# mClean Test spatio/temporal denoiser
# Version: 1.3c_2 (29 August 2017)
# By burfadel

### TEST ONLY ###
### NOTE: Function name is mCleanT ###

#  +++ Required plugins +++
# Latest RGTools, MVTools2, Masktools2, FFT3DFilter by Pinterf
# Latest Modplus, only required if using sharpening overboost (enh settings 101 and 102)
# Requires latest fftw.dll to be installed as instructed on the website - http://www.fftw.org


function mCleanT(clip c, int "thSAD", int "blksize", int "blksizeV", int "overlap", int "overlapV", int "enh", int "rn", int "outbits", int "m", bool "recalc", bool "dct", bool "search", int "cpu")
{
    defH        = Max (C.Height, C.Width/4*3)     # Resolution calculation for auto blksize settings
    thSAD       = Default (thSAD, 450)     # Denoising threshold
    blksize     = Default (blksize, defH<360 ? 8 : defH<750 ? 12 : defH<1200 ? 16 : defH<1600 ? 24 : 32)     # Horizontal block size for MDegrain2
    blksizeV    = Default (blksizeV, blksize)     # Vertical block size for MDegrain2, default same as horizontal
    overlap     = Default (overlap, blksize>4?(blksize/4+1)/2*2:0)     # Horizontal block overlap
    overlapV    = Default (overlapV, blksize>4?(blksizeV/4+1)/2*2:0)     # Vertical block overlap
    enh         = Default (enh, 13)     # Detail enhancement (detail orientated sharpen) strength
    rn          = Default (rn, 10)     # ReNoise strength from 0 (disabled) to 20
    outbits     = Default (outbits, c.BitsPerComponent)     # Output bits, default input depth
    calcbits    = c.BitsPerComponent == 8 ? 12 : c.BitsPerComponent
    calcbits    = outbits > calcbits ? calcbits : outbits
    m           = Default (m, 2)     # MDegrain steps
    recalc      = Default (recalc, false)     # Process recalc
    dct         = Default (dct, false)     # To use DCT=4 or not on recalc
    search      = Default (search, false)     # If true uses exhaustive search on recalc
    cpu         = Default (cpu, 4)     # Threads for fft3dfilter


    Assert(isYUV(c)==true, """mClean: Supports only YUV formats (YV12, YV16, YV24)""")
    Assert(isYUY2(c)==false, """mClean: Supports only YUV formats (YV12, YV16, YV24)""")
    Assert(isYV411(c)==false, """mClean: Supports only YUV formats (YV12, YV16, YV24)""")
    Assert(enh>=0 && enh<=102, """mClean: "enh" ranges from 0 to 102""")
    Assert(rn>=0 && rn<=20, """mClean: "rn" ranges from 0 to 20""")
    Assert(outbits>=8 && outbits<=16, """mClean: "outbits" ranges from 8 to 16""")
    Assert(m>=2 && m<=6, """mClean Test: "m" ranges from 2 (default) to 6""")
    dct = (dct==true) ? 4 : 0
    search = (search==true) ? 3 : 5

# Spatio/temporal chroma noise filter
filt_chroma  =  fft3dfilter (c, bw=blksize*2, bh=blksizeV*2, ow=overlap*2, oh=overlapV*2, sharpen=0.12, bt=3, ncpu=cpu, dehalo=0.3, sigma=2.35, plane=3)

# Temporal luma noise filter
super      =  c.MSuper (chroma=false,hpad=16, vpad=16, rfilter=4)
super2     =  c.MSuper (chroma=false, hpad=16, vpad=16, levels=1, rfilter=4)
bvec6      =  (m==6) ? MAnalyse (super, chroma=false, delta = 6, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=13) :nop
bvec5      =  (m>=5<=6) ? MAnalyse (super, chroma=false, delta = 5, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=11) :nop
bvec4      =  (m>=4<=6) ? MAnalyse (super, chroma=false, delta = 4, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=9) :nop
bvec3      =  (m>=3<=6) ? MAnalyse (super, chroma=false, delta = 3, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=7) :nop
bvec2      =  MAnalyse (super, chroma=false, isb = true, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=5)
bvec1      =  MAnalyse (super, chroma=false, isb = true, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=3)
fvec1      =  MAnalyse (super, chroma=false, isb = false, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=3)
fvec2      =  MAnalyse (super, chroma=false, isb = false, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=5)
fvec3      =  (m>=3<=6) ? MAnalyse (super, chroma=false, isb = false, delta = 3, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=7) :nop
fvec4      =  (m>=4<=6) ? MAnalyse (super, chroma=false, isb = false, delta = 4, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=9) :nop
fvec5      =  (m>=5<=6) ? MAnalyse (super, chroma=false, isb = false, delta = 5, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=11) :nop
fvec6      =  (m==6) ? MAnalyse (super, chroma=false, isb = false, delta = 6, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=13) :nop

bvec6      =  (recalc==false) ? bvec6 : (m==6) ? MRecalculate (super2, bvec6, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=13, dct) :nop
bvec5      =  (recalc==false) ? bvec5 : (m>=5<=6) ? MRecalculate (super2, bvec5, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=11, dct) :nop 
bvec4      =  (recalc==false) ? bvec4 : (m>=4<=6) ? MRecalculate (super2, bvec4, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=9, dct) :nop
bvec3      =  (recalc==false) ? bvec3 : (m>=3<=6) ? MRecalculate (super2, bvec3, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=7, dct) :nop
bvec2      =  (recalc==false) ? bvec2 : MRecalculate (super2, bvec2, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=5, dct)
bvec1      =  (recalc==false) ? bvec1 : MRecalculate (super2, bvec1, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=3, dct)
fvec1      =  (recalc==false) ? fvec1 : MRecalculate (super2, fvec1, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=3, dct)
fvec2      =  (recalc==false) ? fvec2 : MRecalculate (super2, fvec2, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=5, dct)
fvec3      =  (recalc==false) ? fvec3 : (m>=3<=6) ? MRecalculate (super2, fvec3, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=7, dct) :nop
fvec4      =  (recalc==false) ? fvec4 : (m>=4<=6) ? MRecalculate (super2, fvec4, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=9, dct) :nop
fvec5      =  (recalc==false) ? fvec5 : (m>=5<=6) ? MRecalculate (super2, fvec5, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=11, dct) :nop
fvec6      =  (recalc==false) ? fvec6 : (m==6) ? MRecalculate (super2, fvec6, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=13, dct) :nop

clean      =  (m==2) ? c.MDegrain2 (super, bvec1, fvec1, bvec2, fvec2, thSAD=thSAD, plane = 0) :nop
clean      =  (m==3) ? c.MDegrain3 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, thSAD=thSAD, plane = 0) :clean
clean      =  (m==4) ? c.MDegrain4 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, bvec4, fvec4, thSAD=thSAD, plane = 0) :clean
clean      =  (m==5) ? c.MDegrain5 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, bvec4, fvec4, bvec5, fvec5, thSAD=thSAD, plane = 0) :clean
clean      =  (m==6) ? c.MDegrain6 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, bvec4, fvec4, bvec5, fvec5, bvec6, fvec6, thSAD=thSAD, plane = 0) :clean

clean      =  calcbits != clean.BitsPerComponent ? clean.ConvertBits(calcbits) : clean
c          =  calcbits != c.BitsPerComponent ? c.ConvertBits(calcbits) : c

# Masks for spatial noise reduction and noise independent detail enhancement
noised      =  mt_makediff (clean, c, u=1, v=1)
noise       =  mt_binarize (clense(mt_makediff(mt_binarize(noised, u=1, v=1), mt_edge(sharpen(clean, 0.85), "prewitt", u=1, v=1), u=1, v=1), grey=true), u=1, v=1)

# Spatial luma denoising
clean2      =  mt_merge (clean, removegrain(clean, 18, modeU=-1, modeV=-1), noise, u=1, v=1)

# Unsharp filter for spatial detail enhancement
clsharp     =  (enh>0<=100) ? mt_adddiff (mt_makediff(clean, blur(clean, 0.80*(enh/100), 0.50*(enh/100)), u=1, v=1), clean2, u=1, v=1) : clean
clsharp     =  (enh>=101<=102) ? mt_adddiff (mt_makediff(clean, gblur(clean, enh-100), u=1, v=1), clean2, u=1, v=1) : clsharp

# If selected, combining ReNoise
renoise     =  (rn==0)    ? nop : tweak(temporalsoften (noised, 4, 255, 0, scenechange=0, mode=2), cont=1.010+(0.020*(rn/20)), bright=1.01+(0.04*(rn/20)))
clean2      =  (rn>0<=20) ? mergeluma (clean2, mt_adddiff(clean2, renoise, u=1, v=1), 0.3+(rn*0.035)) : clean2

# Combining spatial detail enhancement with spatial noise reduction using prepared mask
filt_luma   =  mt_merge (clean2, clsharp, mt_invert(mt_convolution(noise, u=1, v=1), u=1, v=1), u=1, v=1)

# Converting bits per channel
filt_luma   =  outbits < filt_luma.BitsPerComponent ? ConvertBits(filt_luma, outbits, 1) : filt_luma
filt_chroma =  filt_chroma.BitsPerComponent <> filt_luma.BitsPerComponent ? ConvertBits(filt_chroma, BitsPerComponent(filt_luma)) : filt_chroma

# Combining result of luma and chroma cleaning
return mergechroma (filt_luma, filt_chroma)
}

Let me know how it goes .

[lansing]

Originally Posted by MysteryX

Also post the script settings you use.

Posting on PostImage.io has the advantage of taking little space here and allowing to easily open in full-screen to compare images.

I agree that this particular clip reacts badly. Then it would be useful to see how it behaves with other denoisers. If you want to contribute, I would suggest posting sufficient relevant data:
- plugins/settings used
- screenshot
- comparison with other relevant denoisers
- your observation or conclusion in regards to the test ("this is BS" isn't a technical conclusion)

Sending the source of a difficult clip like that one could also be useful for Burdafel to work with. I developed FrameRateConverter using the worst videos I had for interpolation.

Every personal attacks might come back to you as big headaches -- better stick to a technical conversation.

There is nothing "difficult" about the snow clip, it's just an example demonstrating the typical behavior(con) of smdegrain. This is what was expected to get from the filter, apply it on any clip and you will get the same problem.

If the OP was to build the script around smdegrain, the very first thing he should had done was to write some logic to protect against its problem, that is how you build stuff. You build a solid core first, then you add the fancy stuffs, not the other way around.

As for comparison, this is a smdegrain only problem, so any other temporal denoisers is not going to have it, just as expected. The closest one that can relate to is MCTD, since it also built around smdegrain.

original


mctd()


And it has done the protection.