Dogway's Filters Packs

[tormento]

Do you have MaxCLL and maxFALL info?
The original PQ stream has the following characteristics:

ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 2 h 4 min
Bit rate : 95.3 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.479
Stream size : 82.9 GiB
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primar : BT.2020
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Le : 369 cd/m2
format_identifier : HDMV
Source : 00003.m2ts
Maybe I can try with EOTFi_2084(), you can also try with avsresize and fmtconv.
How?
Usually for HDR I run a measurement with madMeasureHDR so one can get more accurate values.
Never heard of that, thanks. I will give it a try.
It's a basic linear scaling.
How to behave, instead, when we have a HLG or PQ, i.e. hybrid log or full log? I don't think that is linear anymore.

[Dogway]

Sorry I have been having a look at transfers, see, looks like my EOTFi_2084() functions might need some work but I just created the method C tonemapper from BT.2446. By default works better than fmtconv mapping (less blown outs).

You can try the next (play with lws and lwd params). EDIT: Those params don't seem to be doing anything, might be reported to cretindesalpes'

ConvertBits(32)
fmtc_resample (css="444")
fmtc_matrix (mats="2020", matd="rgb")
fmtc_transfer (transs="PQ",transd="linear",lws=1000,lwd=100)
TM_2446C(cs_in="2020",cs_out="709",EOTFi="1886")


Here is TM_2446C (will update soon in TransformsPack):
# BT.2446 Method C tonemapper
# Input must be HDR linear RGB, output is full range SDR gamma RGB (EOTFi gamma encoded)
function TM_2446C (clip c, string "cs_in", string "cs_out", string "EOTFi", float "k1", float "k3", bool "show") {
c
isy = isy(c)
fs = propNumElements("_ColorRange") > 0 ? \
propGetInt ("_ColorRange") == 0 : true
props = color_propGet(c)
cs_in = Default (cs_in, props[2])
cs_out = Default (cs_out, "709")
EOTF = Default (EOTFi, "1886")
k1 = Default (k1, 1) # SDR white level to HDR reference white (diffuse white) ratio. Details on BT.2408 Annex 4
k3 = Default (k3, 0.52) # How much birght detail you want to keep in

cs_out = color_Fuzzy_Search (cs_out)[0]
EOTF = color_Fuzzy_Search (EOTF)[2]

# De-saturation coefficient to avoid hue shifts
a = 0.04 # Should be between 0.01 and 0.33
Cross= [ 1-2*a, a, a, \
a, 1-2*a, a, \
a, a, 1-2*a]

c
if (!isy) {
MatrixClip(Cross)
RGB_to_XYZ(cs_in)
XYZ_to_Yxy()
}

k1 = k1
ip = 58.5 / k1 / 100. # Inflection point of the tonemapper, usually just above skin tones (80% SDR which maps to 58.5 nits over 100 nits SDR display)
ipr = 1. / ip
k3 = k3
k2 = k1 * (1 - k3) * ip
k4 = k1 * ip - k2 * log(1 - k3)

# From BT.2446-0 Section 5 (Method C)
ex_lut(Format("x {ip} < x {k1} * x {ipr} * {k3} - log {k2} * {k4} + ?"),UV=1)

if (!isy) {
Yxy_to_XYZ()
XYZ_to_RGB(cs_out)
MatrixClip(MatrixInvert(Cross))
}

s_gam = moncurve_coef(EOTF)
moncurve_r(s_gam[0],s_gam[1], false, false)

if (sh) {
w = c.width()
h = c.height()
sw = nmod(w/5.) sh = min(h,sw)
plt = GradientLinear(last,zoom=1, precision=4, positive=true, smooth=true, tv_range=false)
plt = plt.ExtractY().TM_2446C(k1=k1,k3=k3,EOTFi=EOTF)
plt = HistoCurve(plt,size=2,gradient=false).BicubicResize(sw,sh,0.262015,0.368993)
plt = plt.ConvertToPlanarRGB()
plt = Merge(PadBorders(plt,w-sw,0,0,h-sh))
ex_merge(plt,BoxMask(w-sw,w,0,sh),UV=3)
} }


You might also need to update XYZ_to_Yxy() to avoid NaN:
function XYZ_to_Yxy (clip XYZ, clip "Y", clip "Z", bool "fulls") {

isy = isy(XYZ)
bi = BitsPerComponent(XYZ)
fs = Default (fulls, true)

clp = !isy ? ExtractClip(XYZ) : nop()
X = !isy ? clp[0] : XYZ
Y = !isy ? clp[1] : Y
Z = !isy ? clp[2] : Z


if (isy) {

xl = Expr(X, Y, Z, "x 0 <= 0.3805 x dup y z + + / ?", optSingleMode=false)
yl = Expr(X, Y, Z, "y 0 <= 0.3769 y dup x z + + / ?", optSingleMode=false)
[Y, xl, yl]

} else {

Expr(X, Y, Z, "y", "x 0 <= 0.3805 x dup y z + + / ?",\
"y 0 <= 0.3769 y dup x z + + / ?", optSingleMode=true, format=PixelType(XYZ)) } }

[tormento]

Sorry I have been having a look at transfers
Thanks for your work. ;)

But how would that help me to expand luma range after that I already used a cube to SDR or HLG? :)

[Dogway]

For a post-fix just use ex_levels(), I don't know how it behaves with HLG though, I haven't worked much with HDR.


If for any reason you want to post-fix it, simply use ex_levels(), something like ex_levels(0,1,200,0,255).)

[guest]

Hey guy's,

This is probably a bit off topic, but I need to be able to add an audio delay call to my video scripts.

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\MedianBlur2\MedianBlur2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=8,thSAD=800,thSADC=400,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)
DelayAudio(1)

This doesn't work :(

[Dogway]

You need to load the audio first, use ffaudiosource() or other loader.
You can then "merge" video and audio streams and filter both in-line
AudioDub(video, audio).DelayAudio(1)

Try open a thread next time if it's not related to my filters.

[tormento]

know how it behaves with HLG though, I haven't worked much with HDR.
Perhaps it's time to. :p

[Dogway]

It's important but other things more important first like gamut compression which actually there's not a single solution in AviSynth (nor VS I think). I'm also implementing new things yet to be seen elsewhere like full ACES implementation and OpenDRT, to name a few yet to come.

As I said HDR is a target for TransformsPack 2.0, I'm not even in 1.0 yet and still there are some important additions like 2084 EOTF, some HDR models, the 2446 TM. I've been busy making GetNative in AVS+ and other things, color science is a field in construction, a moving target.

[tormento]

I've been busy making GetNative in AVS+ and other things, color science is a field in construction, a moving target.
And we are so thankful for your work. :)

[kedautinh12]

I meet error with ex_bob(nnedi3=true) when deinterlaced video, Screenchange repeat

my sample: https://drive.google.com/file/d/1TqPZyX0HfjdTCO3PNyhslgYxV87C4EUI/view?usp=sharing

[Dogway]

Do you get any error? It works fine here, schene change and all. Try other clip to check it's an issue with the source.

[kedautinh12]

Do you get any error? It works fine here, schene change and all. Try other clip to check it's an issue with the source.

i seen it's repeat in screenchange. Please check from frame 2992

My scripts:
LWLibavVideoSource("C:\Users\ADMIN\Downloads\Lie - No Sleeves.mpg")
ex_bob(nnedi3=true)

[Dogway]

That's LWLibavVideoSource not setting field parity switch correctly to frame props. Use DGSource and works fine (ex_bob() honors frame props over GetParity() )

[kedautinh12]

That's LWLibavVideoSource not setting field parity switch correctly to frame props. Use DGSource and works fine (ex_bob() honors frame props over GetParity() )

Ok, so i will use tfm with L-Smash:D

[guest]

You need to load the audio first, use ffaudiosource() or other loader.
You can then "merge" video and audio streams and filter both in-line
AudioDub(video, audio).DelayAudio(1)

Try open a thread next time if it's not related to my filters.

Hi Dogway, I wasn't sure where to post a question like this, but I think why I did is that the DelayAudio(1) works with this script :-

Loadplugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
video=MDegrain1(video,super,bv1,fv1,thSAD=400)
when adding these lines:-

#Return
DelayAudio(1)

or

#AVSameLength
DelayAudio(1)

but not with this one :-

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\MedianBlur2\MedianBlur2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=8,thSAD=800,thSADC=400,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)

Keep in mind that these are scripts used by RipBot264...so they're a little different.

I do have a couple of "work around" options, but it would be nice to know why it works with one & not the other.

[LeXXuz]

Well, here is something I'm really scratching my head on.

I'm still struggling with a bluring effect with SMDegrain in moving areas which really disturbs the overall look of the picture.
To elaborate: I've uploaded four samples of a short scene. Original, 2x denoised with SMDegrain (thSAD 400 and 200) and denoised with DFTtestMC.

Here are comparison screenshots in exactly that order:
https://abload.de/thumb/test_orgslebc.png (https://abload.de/image.php?img=test_orgslebc.png)https://abload.de/thumb/test_enc_thsad4003peom.png (https://abload.de/image.php?img=test_enc_thsad4003peom.png)https://abload.de/thumb/test_enc_thsad2008udrz.png (https://abload.de/image.php?img=test_enc_thsad2008udrz.png)https://abload.de/thumb/test_enc_dftmc6eie2.png (https://abload.de/image.php?img=test_enc_dftmc6eie2.png)

And here are the short clips those screenshots are taken from:
Original: https://send.cm/d/EYfK
SMD-400: https://send.cm/d/EYfN
SMD-200: https://send.cm/d/EYfP
DFTmc: https://send.cm/d/EYfT

Notice how blury/smooth the faces of the actors become as soon as they move their heads.
And how crisp and detailed they become again once they hold still.
Compared to dfttest (and the original of course), the effect is pretty strong with SMDDegrain, even with a quite low thSAD of 200
which does not denoise the movie properly anymore as it's too weak. But that blur still remains.

I tested different prefilters, played around with the gamma ramp with different settings for ex_luma_rebuild() and even ex_retinex(),
increased accuracy with blocksize and pel, increased temporal radius up to 24 (which btw doesn't do really much else than just killing speed). Nothing seems to help.

To outrule anything else I dumbed down both scripts to the simplest content:

AVS Script used with SMDegrain:

#
SetMemoryMax(32768)
SetCacheMode(0)
#
LoadPlugin("...\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("...\test_org.mkv")
#crop
#resize
#
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\masktools2-v2.2.30\x64\masktools2.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\mvtools-2.7.45\x64\mvtools2.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\RgTools-v1.2\x64_LLVM_build\RgTools.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\vinverse-0.9.3\x64\Release\vinverse.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\vsTCanny-1.1.8\x64\Release\vsTCanny.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\BM3DCUDA_AVS-test9\x64\BM3D_VAggregate_AVS.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\BM3DCUDA_AVS-test9\x64\BM3DCPU_AVS.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\BM3DCUDA_AVS-test9\x64\BM3DCUDA_AVS.dll")
#
Import("...\MeGUI (x64)\tools\avisynth_plugin\ResizersPack.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\ExTools.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\SharpenersPack.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\GradePack.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\TransformsPack - Main.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\TransformsPack - Models.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\TransformsPack - Transfers.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\SMDegrain.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\mtmodes.avsi")
#
ConvertBits(16)
SMDegrain(tr=6, thSAD=400, contrasharp=false, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=false, blksize=16, pel=2, Str=5.0, Amp=0.03, prefilter=6, chroma=true, plane=4)
Prefetch(32,32)
Return(Last)


AVS Script used with DFTtestMC from real.finder:

#
SetMemoryMax(32768)
SetCacheMode(1)
#
LoadPlugin("...\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("...\test_org.mkv")
#
LoadPlugin("...\tools\avisynth_plugin\neo-dfttest_rf-fix\64\neo-dfttest.dll")
LoadPlugin("...\tools\avisynth_plugin\masktools2-v2.2.30\x64\masktools2.dll")
LoadPlugin("...\tools\avisynth_plugin\mvtools-2.7.45\x64\mvtools2.dll")
LoadPlugin("...\tools\avisynth_plugin\RgTools-v1.2\x64_LLVM_build\RgTools.dll")
#
Import("...\tools\avisynth_plugin\dfttestMC_and_MC_things.avsi")
Import("...\tools\avisynth_plugin\Zs_RF_Shared.avsi")
Import("...\tools\avisynth_plugin\mtmodes.avsi")
#
ConvertBits(16)
dfttestMC(Y=true, U=true, V=true, thSAD=400, MCContrasharp=false, rStr=1.0, MC=5, sstring="0.0:4 0.5:9 1.0:16")
Prefetch(32,32)
Return(Last)


I may have misunderstood the entire concept of mc denoising,
but (beside better noise removal on moving objects) - shouldn't a motion compensated denoiser prevent exactly this from happening?

[Boulder]

Have you tried pel=4, or blksize=32 (or both)? Could be related to motion detection, and your settings make it average 6 frames so it will get blurry if ME is not good.

[LeXXuz]

Have you tried pel=4, or blksize=32 (or both)? Could be related to motion detection, and your settings make it average 6 frames so it will get blurry if ME is not good.

Tried all block- and pixel sizes. Isnt it temporal radius not diameter? Anyway, like I wrote even very high tr doesn't change anything. If in doubt, try the source material yourself. ;)

[Boulder]

Temporal radius, yes - which means it will average (weighted averaging) blocks over 6 frames. So lowering that might be better, but it will do less denoising.

[DTL]

I may have misunderstood the entire concept of mc denoising,
but (beside better noise removal on moving objects) - shouldn't a motion compensated denoiser prevent exactly this from happening?

It may be limitations of 'simple' degrain script based on old mvtools.

Attempt to keep more skin details on moving face require very low thSAD of about 80. But to keep removing noise on other areas it is require to apply different MDegrain settings to different frame areas. So with old mvtools it may exist in other more complex degrain scripts with masked processing of moving and static areas with different MDegrain settings.

It looks the motion tracking is not very good on rotating head (it is really other transform not supported by mvtools at all and partially working on some simple projections of rotating subject by translate-only support in mvtools). Also it may be even worse with prefiltering washing out last low-contrast details to work on by motion search engine.

With more new version of mvtools (03.08.22 build - https://github.com/DTL2020/mvtools/releases/tag/r.2.7.46-a.15 )

and some tweaking of 'base very low thSAD' with additional adjustments with total mvtools degrain part of script

tr=6
super=MSuper(mt=false, chroma=true, pel=2)
multi_vec=MAnalyse (super, multi=true, blksize=8, delta=tr, overlap=0, search=3, searchparam=2, chroma=true, optSearchOption=1, mt=false)
MDegrainN(last,super, multi_vec, tr, thSAD=80, thSAD2=70, mt=false, wpow=4, thSCD1=400, adjSADzeromv=0.4, adjSADcohmv=0.7, thCohMV=2, MVLPFGauss=1.1, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=3)


result keeps better skin details

https://drive.google.com/file/d/1JQ5pR0rKcb6jjdo5jt2x2ukscXFuHP9W/view?usp=sharing

while still provide some help to MPEG 264 encoder (crf=18 degrained version 7.1Mbit/s, source not degrained 9.6Mbit/s).

It have many new params to play with but it may be completely not degraining for other scenes of the complete movie (like using higher ISO speed film or higher gain camera setting and others). So it is only params adjusted per current scene.

Also if it is natural movie with long enough frame exposure time the textures of moving subjects are also more or less damaged by motion blur. So keeping best possible details on moving subjects typically not possible because cinema shooters not like very small shutter speeds - it uses very few light from scene (require very powerful lighting) and also may create very visible jitter (on non smooth-motion displays).

"I tested different prefilters, played around with the gamma ramp with different settings for ex_luma_rebuild() and even ex_retinex(),
increased accuracy with blocksize and pel, increased temporal radius up to 24 (which btw doesn't do really much else than just killing speed). Nothing seems to help."

First to save from blurring you need to have one of 2 things:
1. Perfect motion compensation
or
2. Protection from too bad blending (using thSAD or any other ways like masking or other).

1. Is far from possible with current mvtools with translate motion estimation and compensation only but even translate not tracked perfectly with real not very contrast and detailed sources and damaged by random noise.
So first is good to adjust motion search as best as possible for given source. As I see at the rotating head of the left male talent the motion is tracked about good only on low-left part of face and much worse at the upper part of face (above eyes). To see the result of motion search and to make adjustments to MAnalayse the MShow can be used. So I make test script for MAnalyse tuning -


LoadPlugin("ffms2.dll")
LoadPlugin("mvtools2-pint.dll")
#LoadPlugin("mvtools2.dll")

FFMpegSource2("test_org.mkv")

ConvertToYV24()

prefilt=GeneralConvolution(0, "
-0 -0 -1 -0 -0
-0 -1 -2 -1 -0
-1 -2 17 -2 -1
-0 -1 -2 -1 -0
-0 -0 -1 -0 -0", auto=true, luma=true, chroma=true)

#prefilt=Blur(1)
#prefilt=last

super = MSuper(prefilt, mt=false, pel=2)
super_std = MSuper(mt=false, pel=2, hpad=32, vpad=32)
forward_vec1 = MAnalyse(super, blksize=8, isb = false, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = 1, truemotion=false, pzero=0, pnew=0, levels=2, mt=false)
MShow(super_std,forward_vec1, showsad=true, thSCD1=1000, scale=2)

I set penalties to zero so EXA search can test all possible locations for best SAD value without skipping low SAD enchancements. The temporal and trymany are subject to more testing. Also limit levels to 2 to try to avoid too far bad MVs.

It tests 3 different pre-processing modes to try to help to MAnalyse: low-pass (blur) prefiltering, no-prefiltering, and high-pass (sharp) prefiltering (using GeneralConvolution because Blur(-arg) adjusts mostly too high frequencies).
The results for medium head-rotation frame 37 are
https://ibb.co/hKsTLPR - blur prefilter
https://ibb.co/cQWK6Hz - no prefilter
https://ibb.co/gz1fzL1 - sharp prefilter (also greatly increase median SAD)
The sharp prefiltering looks like a bit better - at least it saves from gross error vertical MVs on horizontally rotated head at some blocks (near lips for example).

It may be good to see the MVs after temporal low-pass filtering to better understand real processing data inside new MDegrainN with MVLPF additional processing but to view with MShow it require to do either some script to process MStoreVect data or separated new filter for mvtools with output of processed MVs in compatible with MShow format.

So tried more encoding using 'sharp' prefiltering with

LoadPlugin("mvtools2.dll")
LoadPlugin("ffms2.dll")

FFmpegSource2("test_org.mkv")

ConvertToYUV420(matrix="Rec709")

prefilt=ConvertToYV24().GeneralConvolution(0, "
-0 -0 -1 -0 -0
-0 -1 -2 -1 -0
-1 -2 17 -2 -1
-0 -1 -2 -1 -0
-0 -0 -1 -0 -0", auto=true, luma=true, chroma=true).ConvertToYV12()

super = MSuper(prefilt, mt=false, pel=2)
super_std = MSuper(mt=false, pel=2)

tr=12

multi_vec=MAnalyse(super, blksize=8, multi=true, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = tr, truemotion=false, pzero=0, pnew=0, levels=2, mt=false, overlap=4)
MDegrainN(last,super_std, multi_vec, tr, thSAD=90, thSAD2=80, mt=false, wpow=4, thSCD1=500, adjSADzeromv=0.4, adjSADcohmv=0.7, thCohMV=2, MVLPFGauss=1.1, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=0)


The interpolated overlap of mode 3 fails at some frame with grid structure - so I set full 4x 'classic' overlap - it uses more real searched MVs and possibly better in quality.
thSAD (and all other absolute th-s like thSAD2 and thSCD*) depends on prefiltering so not compatible with previous encoding and need to be re-adjusted for each prefiltering type/settings.
https://drive.google.com/file/d/12iBU3QtnJ6TuhtLb3UYnPUwXk-d1rUUS/view?usp=sharing
The x264 with crf18 also looks eats some details from skin texture - the frame number 37 looks better at script output - https://ibb.co/Jn9sxmM

The DFTtestMC looks uses too high denoise settings so degrade skin textures more.
Also you can apply some sharpening plugin (non-linear for fine details) to make residual texture details after degraining better visible.

[LeXXuz]

Temporal radius, yes - which means it will average (weighted averaging) blocks over 6 frames. So lowering that might be better, but it will do less denoising.

If that is true then the term radius is very misleading, if not wrong. A radius of n should process (2n+1) frames not just n. At least thats what my mathematical understanding tells me.

I did so many tests over the past 2 years, I can say for certain that any tr value above 6 rarely gives better results in forms of better denoising and smaller output. I've compared countless sources with a tr value of 6,12 and 18 and the difference in filesize of the entire encode was always less than 5%, very often even less than 1% whereas the encoding time more than doubled. I was not able to see real differences in a direct comparison of 2 1080p windows on a calibrated 40" UHD screen standing less than 1m before me on my desk. Pointless and a waste of energy imho.

[Boulder]

If that is true then the term radius is very misleading, if not wrong. A radius of n should process (2n+1) frames not just n. At least thats what my mathematical understanding tells me.

I did so many tests over the past 2 years, I can say for certain that any tr value above 6 rarely gives better results in forms of better denoising and smaller output. I've compared countless sources with a tr value of 6,12 and 18 and the difference in filesize of the entire encode was always less than 5%, very often even less than 1% whereas the encoding time more than doubled. Pointless and a waste of energy imho.

Yes, my small mistake of not writing "forward and backward". The effect probably diminishes close to zero due to the weighing with blocks from nearby frames contributing much more than the ones which are several frames away. I always use radius 1 with MDegrain, but then again, I only tend to press the noise or grain down a bit and not remove it.

[DTL]

"radius of n should process (2n+1) frames not just n. "

Yes - tr=6 mean it uses 12 ref frames for current frame. So it is radius symmetrical around current frame (for realtime denoisers with very small delay it may be non-symmetrical). So at the scene change it have drop of number of usable frames to n/2 and drop of denoising effect. Same is before scene change at the frames scene_change_number-n. Some people see it and make notes.

"the weighing with blocks from nearby frames contributing much more than the ones which are several frames away. "

It greatly depends on thSAD2 value and type of movement (transform) around block. If block is static and not changed or only translate move (same lighting and so on) - so it continue to contribute to output with the weight depending of thSAD and block_SAD. So for non-changed areas of the scene the tr may cover all frames in the cutscene. Though some users not like the effect of uneven noise-reduction when static areas are very clean and transformed shows more and more noise. But MPEG coder very like large clean areas and visibly decrease file size.

[LeXXuz]

It may be limitations of 'simple' degrain script based on old mvtools...


Thanks DTL. I really appreciate the time and effort you put into testing this out. :thanks:

I have to find some quite time to occupy myself with your script in way more detail. Right now this feels a little bit over my head.

It's a pitty. Mvtools can really produce amazing results when used for denoising. But so many times I carefully tested out parameters with many different scenes and was very satisfied. Then I encoded the entire film and when watching the result, I stumbled upon at least the same amount of scenes that really looked bad.

Again, Dogway once asked me if I prefer a completely clean look. I do. Because I think only a correctly denoised picture is worth keeping over the original. Anything just half-hearted denoised looks much worse than the source and belongs into the recycle bin. Just my 2 cents of course.

[DTL]

" Then I encoded the entire film and when watching the result, I stumbled upon at least the same amount of scenes that really looked bad."

Unfortunately there still no 'auto-adjust' of the main params like thSAD on the each cutscene. And the typical mix of cutscenes from different film ISO or types with different grain level cause either some scenes not good degrained or some scenes too blurred where there is a small. In theory it is possible to create some 'simple auto' mode on the same ideas as scene detect is created - to calculate mean value of the SAD of the all (valid) frames in current frame pool (in tr-scope) and to set thSAD in given % of this value (like from 80 to 150%). And call this param like 'low-med-high' noise reduction adjustment. But it not work good in all cases. May be need more complex statistical analysys like SAD-histogram (probability or % of SAD values on vertical vs SAD value on horizontal axis) and make tests what good thSAD value corresponds to a series of histogram looking. May be not mean SAD but close to the lowest historgam edge (the min possible SAD even on flat blocks are limited by current noise level). But this auto-algo may fail if frame is padded and some blocks will have zero SAD. So may be need to check only some center of the frame area skipping some safe-borders. This also can fail if the frame is letterboxed and so on.

[guest]

Hi Dogway,

I have encountered a new problem when trying to encode a HDR UHD file.

AVSMeter displays an error with Line 239 of SMDegrain

https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain%20v3.5.4d/SMDegrain%20v3.5.4d.avsi#L239

And I don't know what to do.

This is my script :-

#Custom
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\MedianBlur2\MedianBlur2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)


but I don't get the error with this script :-

#Custom
Loadplugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
video=MDegrain1(video,super,bv1,fv1,thSAD=400)

Mediainfo :-

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L6.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 5 min 0 s
Bit rate : 15.8 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.079
Stream size : 565 MiB (72%)
Title : GalenMao@HDSky
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : BT.2020
Mastering display luminance : min: 0.0020 cd/m2, max: 1000 cd/m2

[Dogway]

Hi TDS, I was having a break from AviSynth for a few days. That line just uses nmod(), ResizersPack is now mandatory as per line 22 (https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain%20v3.5.4d/SMDegrain%20v3.5.4d.avsi#L22). Try to load it.

As for LeXXuz's "issue", smearing of shades or low frequency detail is a known side effect of MDegrain. SMDegrain comes bundled with other denoisers (motion compensated), check the 'mode' argument, Dfttest is not implemented though, probably I should. In any case for these cases I made the LFR and DCTFlicker args. Give them a try, they use a mix of low freq sharpened prefilter with a final low freq recovery. DCTFlicker denoises remnant low freq "noise".
I will have a closer look when I get time.

[guest]

Hi TDS, I was having a break from AviSynth for a few days. That line just uses nmod(), ResizersPack is now mandatory as per line 22 (https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain%20v3.5.4d/SMDegrain%20v3.5.4d.avsi#L22). Try to load it.

Hi Dogway, thanks for getting back to me about this, I just added ResizersPack to that script, and it's working :)

I've done a little bit of investigation, and this dependency on ResizersPack was introduced in 3.5.4d.

So thankyou VERY much :)

[LeXXuz]

As for LeXXuz's "issue", smearing of shades or low frequency detail is a known side effect of MDegrain. SMDegrain comes bundled with other denoisers (motion compensated), check the 'mode' argument, Dfttest is not implemented though, probably I should. In any case for these cases I made the LFR and DCTFlicker args. Give them a try, they use a mix of low freq sharpened prefilter with a final low freq recovery. DCTFlicker denoises remnant low freq "noise".
I will have a closer look when I get time.

I usually use LFR on film material, I wasn't sure for DCTFlicker though. I've used it for my DVD transcodes but not for HD so far as I was uncertain if I should use it with HD or not.

I have no experience with any of the other denoiser modes. Anything you could recommend from that lot to try out? :)

[DTL]

"smearing of shades or low frequency detail "

The skin details are not shades and not low spatial frequency - they are low contrast fine details typically. So when contrast of texture is comparable or lower the typical noise amplitude - the chance of bad motion tracking is big and thSAD-protection from bad blending is bad.

I think the tr-value inside MDegrainN may be also made 'dynamic' to protect from too many bad and smoothing blends on some selected blocks. It is very easy in current blending engine of MDegrain, only required some function to provide current tr-value for current block being processed by final blending.
The rules of tr-value modulation may be based for example on the 'classic' skin-DTL method in video cameras based on the colour tone (some range of Hue in HSB model) or may be on the 'contrast' of block. But typically the noise is more visible on 'low contrast' areas like clear sky or windows and so on. So may be method of dynamic tr-value applying need to use several ideas.
Also the wpow-value can be dynamic too - it will be close to additional modulation of thSAD.

[Boulder]

Would it be possible to have the DCTFlicker part as a separate function? It might be quite useful in some cases by itself.

[anton_foy]

I usually use LFR on film material, I wasn't sure for DCTFlicker though. I've used it for my DVD transcodes but not for HD so far as I was uncertain if I should use it with HD or not.

I have no experience with any of the other denoiser modes. Anything you could recommend from that lot to try out? :)

Try the "temporalsoften" mode it is great! Also to retain more shadow detail you can try what I suggested to you earlier in this thread. Or by cranking up gamma with levels then denoise then pull back gamma with levels. :)

Like this:
Levels(0,1.47,255*256,0,255*256)
#denoiser#
Levels(0,0.68,255*256,0,255*256)

earlier post (https://forum.doom9.org/showpost.php?p=1971371&postcount=1313)

[Dogway]

I usually use LFR on film material, I wasn't sure for DCTFlicker though. I've used it for my DVD transcodes but not for HD so far as I was uncertain if I should use it with HD or not.

I have no experience with any of the other denoiser modes. Anything you could recommend from that lot to try out? :)

TemporalSoften is one I tend to use for very grainy sources, it fixes the sticky fizz-grain issues. You can also try medianT, STWM or ML3D, I give some recommendations in ex_median() header.
I'm planning to add DFTTest as well if you see value in it, but I have to come with fixed freq weights, I will have a look at what is the general consensus on that.
In general terms if you are applying strong denoising (high thSAD or tr) motion compensation delivers more temporal congruence than motion occlusion.

Would it be possible to have the DCTFlicker part as a separate function? It might be quite useful in some cases by itself.

To be honest I wanted a reliable temporal denoiser and couldn't come with anything better than SMDegrain itself, so in SMDegrain DCTFlicker is just another (very optimized) call to SMDegrain. A wannabe DCTFlicker filter is ex_LFR(), it passes only high frequency details of 'c' clip to 'ref' clip with a given cutoff. In this case DCTFlicker uses the "shift-back-by-one (http://forum.doom9.org/showthread.php?p=1539241)" trick, it works to some degree only so it's not as versatile as in SMDegrain.

"smearing of shades or low frequency detail "

The skin details are not shades and not low spatial frequency - they are low contrast fine details typically. So when contrast of texture is comparable or lower the typical noise amplitude - the chance of bad motion tracking is big and thSAD-protection from bad blending is bad.


Low contrast fine details can be interpreted as noise by MDegrain. Since details are small maybe refining subpixel detection can improve motion vectors for these. Something like pel>1 and subpixel 4 for nnedi3 or subpixel 3 for blackman, on top of LFR.

[LeXXuz]

Try the "temporalsoften" mode it is great! Also to retain more shadow detail you can try what I suggested to you earlier in this thread. Or by cranking up gamma with levels then denoise then pull back gamma with levels. :)

Like this:
Levels(0,1.47,255*256,0,255*256)
#denoiser#
Levels(0,0.68,255*256,0,255*256)

earlier post (https://forum.doom9.org/showpost.php?p=1971371&postcount=1313)

Thanks anton_foy. But it's not shadow detail that troubles me in this movie, it's movement of fine skin detail. See sample videos.
Isn't raising the gamma like that a little bit too much, regarding that SMDegrain already raises gamma/brightness quite a lot for the prefiltered clip? And is this really reversible? Won't you lose high brightness detail through clipping?


TemporalSoften is one I tend to use for very grainy sources, it fixes the sticky fizz-grain issues. You can also try medianT, STWM or ML3D, I give some recommendations in ex_median() header.
I'm planning to add DFTTest as well if you see value in it, but I have to come with fixed freq weights, I will have a look at what is the general consensus on that.
In general terms if you are applying strong denoising (high thSAD or tr) motion compensation delivers more temporal congruence than motion occlusion.

TemporalSoften produced a much smaller output file size with the very same settings. (I just added mode="TemporalSoften" to the SMDegrain call). So I guess I may have to tweak some more settings for that mode?

I used DFTtestMC before I started denoising with SMDegrain and I put it in just for comparison. It does a better job regarding the blur Mdegrain produces in this scene, but it also has its cons as well. Overall I'd say SMDegrain with Mdegrain produced more satisfying results than DFTtestMC did. I never used DFTtest anymore after I started denoising with SMDegrain. I'd say if you implement it I would only use it for some special cases anyway.



Low contrast fine details can be interpreted as noise by MDegrain. Since details are small maybe refining subpixel detection can improve motion vectors for these. Something like pel>1 and subpixel 4 for nnedi3 or subpixel 3 for blackman, on top of LFR.

I did that scene with pel=2 and subpel=3 plus LFR=300. Raising LFR too much leaves too much residual noise again. The only thing that helped in that scene was lowering the thresholds considerably. But that was unsatisfying for the entire movie. I guess the only way to go is scene based thresholds/denoising.

It's up to you guys to tinker something semi-automatic for that, as this clearly exceeds my knowledge and abilities in Avisynth. But like DTL already mentioned; any automated process will have its downsides with situations where it may fail. But I think it is still worth a try as it may still be better than a fixed setting for an entire movie.

Damn, I really regret I did not take those lectures in digital image processing when I was in university. :(

[Dogway]

@LeXXuz: I could analyze your source. I don't think DFTTestMC looks better overall, yes, some middle frequency detail is preserved but everything above and below is very blurry.
Your initial settings were way too overboard, specially with prefilter=6.
To compare apples to apples your DFTTestMC line should roughly match:
SMDegrain(tr=5, thSAD=300)
This retains some middle frequency better. If you pair it with LFR it preserves some more. And with pel=2 some more again.
SMDegrain(tr=5, thSAD=300, pel=2, subpixel=3, LFR=true)
Following you can add some post-sharpening like ex_unsharp() it sharps two frequencies at the same time, the top-most and the following (half-rate) emphasizing mid-freqs.
ex_unsharp(0.5,safe=true)
or for all the bells and whistles:
LSFplus(strength=50, preset="LSF", Lmode=3, soft=-2, soothe=false, smode=3)
But probably internal contrasharp=true is good enough as it won't sharpen already sharp edges and also accounts for all frequencies.

EDIT: Looks like we were posting at the same time. I also implemented DFTTest as a 'mode' option, not a fan of it though (more blur).

[DTL]

Low contrast fine details can be interpreted as noise by MDegrain.

MDegrain do not know anything about noise. The noise-reduction is 'side-effect' of the MDegrain operation. MDegrain only perform 'compensation' of movement based on MVs from MAnalyse and blends compensated blocks with weight derived from relation of block SAD vs thSAD.

So MDegrain do not know anything about noise and fine texture details. The smearing of fine texture details is issue of 2 steps:
1. Low contrast fine texture details are masked by noise so MAnalyse can not output correct motion vector for correct motion compensation. It can point to completely wrong position far form real. Because of random noise nature the lowest SAD may be really far from real block's position. It may looks strange at first how SAD with wrong position may be lower in compare with 'real' position - but the motion search do not search for 'ideal not-noised block' vs noised ref frames. It search of current frame noised block vs noised blocks in ref frames. So the search result may be from small to great error in motion vector. So I also have some ideas about more complex 'statistical' approach of multi-pass MAnalyse/MDegrain operations so the second searches may be search more noise-reduced block vs noised ref blocks and may produce less search errors.

2. The errorneous motion vector with low contrast texture can not produce high enough block-SAD so the only protection engine from bad blends based on relation between block-SAD vs thSAD can not prevent this bad compensated block from being used into blending operation (the weight of bad compensated block is not zero). So the result of blending of incorrectly compensated block is degradation of low contrast textures. Because of mixing blocks from different 'real' positions with different 'real' textures. So the only current way to decrease this issue is set thSAD as low as possible (but it may significantly decrease 'noise-reduction effect' over total frame).

Some possible idea is to use motion (and may be skin tone-colour) mask and combine degrained clips with different thSAD settings via motion/colour mask so the moving (and/or skin-tone-coloured) areas will be taken from lower-thSAD processed clip (saved more fine details) and other frame areas will come from higher-thSAD processed clip with better denoised. So the total complexity of frame to MPEG encoder will be lower with better saving of fine skintone details.

"Since details are small maybe refining subpixel detection can improve motion vectors for these."

The more real improvement may be much more complex - like moving from blocks-based motion search to objects-oriented motion analysis (of many transforms - not only translate). So if motion analyse engine will detect object as head and detect if it is natural moving rotating head at neck - it finally can create more correct motion vectors for block-based frame tesselation and compensating-blending denoising engine. It still looks like far future of motion-analysis software (of HW engines).
Currently in MAnalyse we have very simple begining of 'motion field correlation' approach based on attempt to analyse neibour blocks (3 of current block) found motion vector and use it as higly-weighted (first in order) predictor and protection with new-penalty from possibly better SAD position. But it is very limited in number of used for analysis blocks and if starting found blocks are not good - the error may be propagated to next blocks in search operation. No multi-pass search currently to make more complex analysis of motion field of large enough areas (covered by many blocks like 10 or 100 or more).

Addition: It may be interesting to make MAnalyse accepting 2 input clips - one for ref frames and one for current frame. So it can be tested how it perform with 'prefiltered' current source frames and with searching inside non or different 'prefiltered' frames. Currently with 1 input clip (super) MAnalyse can only search of current and ref frames from same clip. It may limit best performance. So if current frame is 'low-pass' prefiltered it may look better as current frama but the 'low-pass' prefiltered ref frames looks too low detailed to the motion search of blocks with low contrast fine textures may fail more. Or may be 'current-super' clip may be already 'prefiltered' with MAnalyse/MDegrain with lower settings and so on.

"Under-the-noise" detail recovering on the complex moving targets is the very complex process. For large static areas sometime the block size may be set to 'very large' (like 64x64 or more) and it will be less sensitive to noise. But for complex moving targets with more or less equally moving areas of small size this approach not work too. So it looks required some 'recursive' noise reduction with progressive refining of shape/view of low contrast texture small block severily damaged by noise. It definitely require many frames 'statistical analysis' to found most probable shape/view of block.

[anton_foy]

Thanks anton_foy. But it's not shadow detail that troubles me in this movie, it's movement of fine skin detail. See sample videos.
Isn't raising the gamma like that a little bit too much, regarding that SMDegrain already raises gamma/brightness quite a lot for the prefiltered clip? And is this really reversible? Won't you lose high brightness detail through clipping?

I process in 16bit so just by push and pullback the gamma I never noticed any degradation but someone else here might know that better.
Yes the movement bit is tricky and I would think to use spatialfiltering (fft3d/knlmeansCL...) -> mvtools/mdegrain like temporaldegrain does which preserves motion really good. But I like a simplified version since TD2 it is really slow for me for UHD. Have you tried using fft3d bt=0 for kalman filtering as a prefilter? I got good results but it is slower than the other bt-modes and does not filter spatially as much.

[anton_foy]

Dogway do you have a suggestion for an edge mask/mask to only detect "hard"/"distinct" edges? What I mean is for it to ignore fine details and only cover the larger edges. The prewitts are good to detect the harder edges (even the big blurry ones) but also picks up alot of finer detail. I was thinking I have to downscale, blur, ex_edge, inpand, expand x2 and upscale but maybe you have a better idea? Trying to get rid of ringing and compression artefacts and was thinking to use neo_f3kdb with the mask.

[Dogway]

@anton_foy: Tune the 'lo' arg in ex_edge(), it clips low values. The best modes are the ones that use the Euclidean distance method like qprewitt, sobel, kroon... frei-chen is also good for noisy sources.

[LeXXuz]

Dogway does the show feature of SMDegrain work with UHD?

I got an error message:
StackHorizontal: image hights don't match in line 587 and 651 of SMDegrain.avsi

Video resolution is 3840x2076.

[anton_foy]

Dogway does the show feature of SMDegrain work with UHD?

I got an error message:
StackHorizontal: image hights don't match in line 587 and 651 of SMDegrain.avsi

Video resolution is 3840x2076.

Uhd usually is 3840x2160 so maybe need padding, smdegrain, cropping?

[anton_foy]

@anton_foy: Tune the 'lo' arg in ex_edge(), it clips low values. The best modes are the ones that use the Euclidean distance method like qprewitt, sobel, kroon... frei-chen is also good for noisy sources.

Thank you, it looks like from your picture chart of ex_edge that "max" is most suitable mode for this? But I have not been able to try yet.

[Dogway]

@LeXXuz: Strange, it's working for me. Is SMDegrain updated? what's your call?
@anton_foy: Try frei-chen first, adjusting 'lo' arg.

[LeXXuz]

@LeXXuz: Strange, it's working for me. Is SMDegrain updated? what's your call?


I think the version I have is still based on 3.5.2d. I tweaked quite a few things of contrasharp and prefilters 6 & 7 to my liking. That's why I avoided updating for now.

Anyhow, I helped myself with just a quick downsize to 1080p before calling SMD. Just wanted to check brightness levels of the prefiltered clip, so resolution wasn't really that important. :)

[kedautinh12]

All plugins of Dogway is affect each other. If you update, you need update all plugins

[LeXXuz]

SMDegrain: Is 6 the tr-limit with mode=temporalsoften? With tr>6 performance drops significantly.

[Dogway]

Merge back the changes, the UHD 'show' issues were fixed in 3.5.3 I think.
TemporalSoften max radius is 7, but from 6 onwards SMDegrain uses the 'multi' codepath of MVTools. Maybe that's the reason, that's why I warned with a "# MDegrainN is slower, so avoid >6 at possible"

[LeXXuz]

Merge back the changes, the UHD 'show' issues were fixed in 3.5.3 I think.
TemporalSoften max radius is 7, but from 6 onwards SMDegrain uses the 'multi' codepath of MVTools. Maybe that's the reason, that's why I warned with a "# MDegrainN is slower, so avoid >6 at possible"

Thanks Dogway. :) I saw that line but I was uncertain, so I thought I'd better ask. :)
I'll update my tweaked script to the latest version. :thanks:

[DTL]

Since details are small maybe refining subpixel detection can improve motion vectors for these. Something like pel>1 and subpixel 4 for nnedi3 or subpixel 3 for blackman, on top of LFR.

I got one more idea - make one more switch to MAnalyse to make 'reverse' motion search from ref to current frame. And make MDegrain accept this second reverse-search MVclip.

So the MDegrain can analyse if forward and backward motion vectors for some area are in good coherency. If not - treat this area as unstable and lower the weight for ref blocks for this frame. It will decrease degraining effect but keep more details at this block/area. So it may additionally protect from blurring when motion search is not good. Though for onCPU ME it will make processing speed visibly lower (may be not twice because MDegrain also takes some visible time).
Now need to find some math how to check 'quality of reversability' of motion vector from different tesselation grid because back-search of motion vectors will use again standard tesselation grid and the coordinates even of ideally reversed vectors will not be equal.

Also already made the new testversion accepting different 'super' clip as source for 'current' frames clip so will try to check the 'progressive-refining' of current-clip using a sequence of MDegrain with tr from 1 to N (with linear step like 1,2,3,..N or 1,2,4,8,..N) and decreasing thSAD from max to about initial/2 to degraning 'current' clip and use it as a 'current-source' for MAnalyse for later iterations. In theory if 'current' clip become more and more denoised the SAD of blocks vs noised blocks will decrease to about 1/2 of initial because for equal blocks (ideally compensated) with only noise added:
SAD for noised vs noised block = block - block + noise+noise = noise*2
SAD for clean vs noised block = block - block + noise + 0 = noise
SAD for clean vs clean block = block - block = 0

So any multi-pass processing scripts with several MDegrain in a sequence need to adjust thSAD for next steps using any cleaned by first MDegrain clips to lower values to keep 'details' to about equal level or if use equal thSAD it will cause more degraining but also may cause more details blurring.

[anton_foy]

I got one more idea - make one more switch to MAnalyse to make 'reverse' motion search from ref to current frame. And make MDegrain accept this second reverse-search MVclip.

So the MDegrain can analyse if forward and backward motion vectors for some area are in good coherency. If not - treat this area as unstable and lower the weight for ref blocks for this frame. It will decrease degraining effect but keep more details at this block/area. So it may additionally protect from blurring when motion search is not good. Though for onCPU ME it will make processing speed visibly lower (may be not twice because MDegrain also takes some visible time).
Now need to find some math how to check 'quality of reversability' of motion vector from different tesselation grid because back-search of motion vectors will use again standard tesselation grid and the coordinates even of ideally reversed vectors will not be equal.

Also already made the new testversion accepting different 'super' clip as source for 'current' frames clip so will try to check the 'progressive-refining' of current-clip using a sequence of MDegrain with tr from 1 to N (with linear step like 1,2,3,..N or 1,2,4,8,..N) and decreasing thSAD from max to about initial/2 to degraning 'current' clip and use it as a 'current-source' for MAnalyse for later iterations. In theory if 'current' clip become more and more denoised the SAD of blocks vs noised blocks will decrease to about 1/2 of initial because for equal blocks (ideally compensated) with only noise added:
SAD for noised vs noised block = block - block + noise+noise = noise*2
SAD for clean vs noised block = block - block + noise + 0 = noise
SAD for clean vs clean block = block - block = 0

So any multi-pass processing scripts with several MDegrain in a sequence need to adjust thSAD for next steps using any cleaned by first MDegrain clips to lower values to keep 'details' to about equal level or if use equal thSAD it will cause more degraining but also may cause more details blurring.

Very interesting! I would like to try that approach but with mvtools motion compensated temporalsoften since it keeps more detail than mdegrain but removes more noise. Maybe this new version is something for you to try Dogway? Zopti on top of that...:D