MVTools-pfmod

[pinterf]

Bugfix release, thanks Seedmanc!
Download MvTools2 2.7.38 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.38)
- 2.7.38 (20181209)
MCompensate: Fix regression in latest v37: overlap=0 crash - ouch, sorry
MAnalyze DCT: FFTW float: quicker postprocess of DCT'd blocks, now is correct for non power-of-2 block sizes e.g. 12 or 24 (no effect on 8x8 for which fast integer DCT is used)
MAnalyze DCT: more consistent handling of post DCT internal normalization for non-square block sizes.

[MysteryX]

I've been out for a while (up the mountains in China) and... wow Pinterf you've been on fire!

[pinterf]

Happy New Year!
New build, a bugfix (thanks ErazorTT for the report) and an MDegrain extension.
Download MvTools2 2.7.39 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.39)

- 2.7.39 (20190102)
- MSuper: fix 16 bits, pel=2, sharp=2, which caused bottom-section artifacts for MDegrain using 8 bit vector origin and 16 bit real clip
- MDegrain1-6,N: Enhanced:
Input clip (and super) format now is fully independent from vector clip's base format (subsampling had to be the same before)
E.g. make motion vector clips from a YV12 source and apply them on a 8-32 bit 4:4:4 input

[StainlessS]

And a Happy New Year to you too sir :)

Small prob in first two (mvtools docs) examples:


# To show the motion vectors ( forward ) :
AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
vectors = MSuper().MAnalyse(isb = false)
MShow(vectors) # implicit last works properly # ERROR:- MShow: Wrong Super Frame Clip


FIXED

AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
Last=MSuper() # Assigns implicit last with Super clip
vectors = Last.MAnalyse(isb = false) # Implicit Last = super, 1st arg
Last.MShow(vectors) # Implicit Last = super, 1st arg


2nd example similar prob isb=true.

[pinterf]

Fixed, thanks

[pinterf]

New build
Download MvTools2 2.7.40 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.40)

A bugfix, thanks to zorr a.k.a. father of "Zopti" (formerly Avisynth Optimizer) for the report.
Another bugfix for the 16 bit MFlowInter version.

Then, perhaps this version a milestone release.
Most filters fully support 8-16 bit and 32 bit float with greyscale, YUV and Planar RGB videos.
MDegrain family, MCompensate, MFlowXX family, MSuper all can handle practically any Avisynth+ input formats.
It was quite a bit of modification, I hope bugs (small or big) will fly elsewhere, at least there won’t be many.

Have fun.

- 2.7.40 (20190212)
- Fix: MFlowInter possible crash with specific parameter and colorspace settings.
- Fix: MFlowInter possible overflow at 16 bit clips (artifacts)
- MFlow, MFlowInter, MFlowFPS, MFlowBlur, MBlockFPS: support all 8-16 and 32 bit float Y, YUV (4:2:0, 4:2:2, 4:4:4) and planar RGB color spaces.
Input clip format is independent from the ones used for getting motion vectors.

[FranceBB]

Thank you, pinterf, very appreciated, as always!
I just tested it with a 10bit yv16 source brought to 16bit yv24 and it works:


FFMpegSource2("test.mov", fpsnum=25000, fpsden=1000)

ConvertBits(16)

Converttoyuv444(matrix="Rec709", interlaced=false)

super=MSuper(pel=1, hpad=0, vpad=0)
backward_1=MAnalyse(super, chroma=false, isb=true, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1 =MAnalyse(super, chroma=false, isb=false, blksize=16, blksizev=16, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, blksizev=8, searchparam=0, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=8, blksizev=8, searchparam=0, search=3)
MBlockFps(super, backward_2, forward_2, num=50000, den=1000, mode=0)


it correctly returns a 16bit 4:4:4 50fps file.
Thank you! :)

[StainlessS]

FranceBB,
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, blksizev=8, searchparam=0, search=3)

search, searchparam, pelsearch

search decides the type of search at every level, searchparam is an additional parameter (step, radius) for this search, and pelsearch is the radius parameter at finest (pel) level.
Below are the possible values for the search type:

...

3 Exhaustive search, searchparam is the radius (square side is 2*radius+1). It is slow, but it gives the best results, SAD-wise.

In MRecalculate, with square side = 1, does that mean that it searches only 1 pixel side to side, up and down, or NONE.

Not sure if problem, just asking. [EDIT: ie, is your MRecalculate a timewasting NOP]

[tormento]

A curiosity came to me about degraining using larger frame span: beside having less noise, can we say the output is more accurate and/or better quality, given same other parameters, as we are evaluating more frames?

[althor1138]

I've been using this function on 2.7.33 and it's always worked. Today I upgraded to the latest 2.7.40 and the output clip is the same as the input clip(nothing has been filtered). I've sifted through the new readme and couldn't figure what's changed to make it not work. If some kind soul could take a look below and point out what is wrong I'd greatly appreciate it. Using avs+ r2772 mt x64 btw.

EDIT: I had to revert back to 2.7.34 before the function started working as expected.

EDIT2: starting with 2.7.35 and up it works in yv12 yv24 colorspace but not yuy2.

EDIT3: Ah but it works with yv16 as well. So I guess yuy2 was dropped? In any case, problem solved. Sorry to bother you all.

#Motion Compensated Temporalsoften
function TSMC(clip input, int "tradius", int "mthresh", int "lumathresh", int "blocksize")
{
tradius=default(tradius,5)

mthresh=default(mthresh,70)

lumathresh=default(lumathresh,255)

blocksize=default(blocksize,4)

prefilt=input.blur(1.58)
super=MSuper(input, pel=2,mt=false)
superfilt=MSuper(prefilt,pel=2,mt=false)

multivectors=Manalyse(superfilt,multi=true,delta=tradius,mt=false)
multivectors2=Mrecalculate(superfilt,multivectors,thsad=mthresh,tr=tradius,mt=false,blksize=blocksize,overlap=2)
mc=Mcompensate(input,super,multivectors2,thsad=mthresh,mt=false,tr=tradius,center=true)
dnmc=mc.temporalsoften(tradius,lumathresh,lumathresh,15,2)
decimate=selectevery(dnmc,tradius * 2 + 1,tradius)
return(decimate)
}

[pinterf]

New build, includes an important fix for YUY2 users who experienced troubles after 2.7.35.

Download MvTools with Depans 2.7.41 (https://github.com/pinterf/mvtools/releases/tag/2.7.41)

Now with 2x2 DLL versions, compiled with v142 and v141_xp toolset. XP users please use the latter.

Planar RGB support for DepanStabilize is the first mod that I made for myself. I'm using it in my neverending (neverstarting) 8mm film restoration project to have a stabilized intermediate file in the same format (I have RGB source) for better days when I'll have more time for do further filtering.

MvTools2 2.7.41 (20190502)

Fix: regression since 2.7.35: MSuper chroma for non-planar YUY2 (Thanks to mkauf)
Project moved to Visual Studio 2019, v141_xp and v142 toolset

Depan 2.13.1.4 (20190502)
DepanStabilize planar RGB 8-16 bits support: Generate motion vectors with mvtools MDepan, use it for DepanStabilize. Input clip can be planar RGB.
add missing roundings to some internal interpolation calculations

DepanEstimate 2.10.0.3 (20190502)
simple rebuild

[tormento]

New build, includes an important fix for YUY2 users who experienced troubles after 2.7.35.
In the documentation, overlap.png is present from FFT3DFilter one ;)

[FranceBB]

Now with 2x2 DLL versions, compiled with v142 and v141_xp toolset. XP users please use the latter.

My other XP computer says "thank you". :D
By the way, v141_xp is still there in Visual Studio 2019, but this time Microsoft clearly stated that is deprecated, sadly (I noticed it when I upgraded from Visual Studio 2017 to 2019): Picture (https://i.imgur.com/MHi6hEv.png)

Anyway, thank you, Ferenc, your work is always very appreciated.

[Dreamject]

Sorry, can you write or give an instruction how to use this and can it be used for SVP parameters , I ported SVPgenerator to clear avs (I'm newbe in avs and not a coder, script can be stupid) and wanna know can I adapt it https://forum.doom9.org/showthread.php?t=176268

[real.finder]

is it ok to use convertbits() with Msuper super clip?

[pinterf]

is it ok to use convertbits() with Msuper super clip?
I'm not 100% sure. There is a hack (as a result of lacking frame properties) with the VideoInfo structure, super clip passes padding and plane handling information through a pointer which is stuffed into num_audio_samples videoinfo field. And audio_samples_per_second if set to zero.

If this videoinfo information is copied between filters _and_ the source MSuper instance is not freed up (the memory for this extra clip info is allocated there inside), you can do with a super clip whatever you want (except size modification)

[real.finder]

I'm not 100% sure. There is a hack (as a result of lacking frame properties) with the VideoInfo structure, super clip passes padding and plane handling information through a pointer which is stuffed into num_audio_samples videoinfo field. And audio_samples_per_second if set to zero.

If this videoinfo information is copied between filters _and_ the source MSuper instance is not freed up (the memory for this extra clip info is allocated there inside), you can do with a super clip whatever you want (except size modification)

well, in last update of SMDegrain it's seems work

[magnetite]

Does MDegrain make use of multithreading? I didn't see it on the mtmodes.avsi list, so I wasn't sure.

[pinterf]

Reports itself as MT_MULTI_INSTANCE automatically.

[StainlessS]

Is this an mvtools2 bug for Occlusion Mask ?


Function VectorTest(Int "Delta",Float "Time",Int "MaskT",Int "BlkSz",Int "XStep",Bool "Align",Bool "HFlip",String "CS") {
/*
VectorTest(), An MvTools2::MFlowInter folly. by StainlessS @ Doom9 : https://forum.doom9.org/showthread.php?t=175373

Req AVS+ or GSCript, GRunt, MvTools2, RT_Stats v1.43+
Avs v2.58, Avs/+ v2.60.

Delta, Default 1. As for MvTools2
Time, Default 50.0, As for MvTools2
MaskT, Default 3, As for MvTools2::MMask(kind=MASK_TYPE), 0=Motion, 1=Sad, 2=Occlusion, 3=Horizontal, 4=Vertical, 5=ColorMap
BlkSz, Default 4, As for MvTools2
XStep, Default 8, Motion per frame of synthesized clip.
Align, Default True, Aligns forward vector frame n+Delta to n. False show frame n of forward vector.
HFlip, Default False, False, Animate from Right to Left, else Left to Right.
(Right to Left is less confusing, same direction that the frames come in from).
CS, Avs v2.5 defaults "YV12" else "Y8".

Returns RGB32 clip.
*/
Function MTyp(Int n) {Return " Type="+Select(n,"Motion","Sad","Occlusion","Horizontal","Vertical","ColorMap")}
myName="VectorTest: "
IsAvsPlus=(FindStr(UCase(versionString),"AVISYNTH+")!=0) HasGScript=RT_FunctionExist("GScript")
HasGrunt=RT_FunctionExist("GScriptclip") HasMvTools2=RT_FunctionExist("MSuper") Is26=VersionNumber>=2.6
Assert(IsAvsPlus||HasGscript,myName+"Essential AVS+ or GScript installed")
Assert(HasGrunt,myName+"Essential GRunt installed") Assert(HasMvTools2,myName+"Essential MvTools2 installed")
Delta=Default(Delta,1) Time=Default(Time,50.0) MaskT=Default(MaskT,3) BlkSz=DefaulT(BlkSz,4)
XStep=Default(XStep,8) Align=Default(Align,True) HFlip=Default(HFlip,False)
CS=Default(CS,Is26?"Y8":"YV12")
OLap=(BlkSz>=4)?BlkSz/2:RT_Undefined
# OLap=RT_Undefined # EDIT: Fixes Weirdness
FuncS="""
Function Fn(clip c,Int Delta,Float Time,Int XStep,Bool Align,Bool HFlip,String mType) {
c n=current_frame
Hit=(Height-20)/5
if(Align) {
Steps=640/XStep
x=((n+1)*XStep) + (Delta*XStep/2)
x=Min(x,(Steps-1)*XStep)
x=HFlip?x:639-x
cF=RT_YPlaneMin(n=n,x=x,y=Round(2.5*Hit)+20,w=1,h=1)-128
cB=RT_YPlaneMin(n=n,x=x,y=Round(3.5*Hit)+20,w=1,h=1)-128
Z=c.BlankClip(width=1,height=1,Color=$FFFFFF,Length=1)
OverLay(Z,x=x,y=Round(2.5*Hit)+20)
OverLay(Z,x=x,y=Round(3.5*Hit)+20)
Subtitle(RT_String("@x=%d FGrey=128%+d : BGrey=128%+d",x,cF,cB))
} else {
Subtitle("Align=False, Colors NOT shown")
}
Subtitle(String(n,"SRC[n=%.0f] (1st interp srcS)") , Y=0.5*Hit+20,Align=5)
Subtitle(String(n+Delta,"SRC[n+Delta=%.0f] (2nd interp srcE)") , Y=1.5*Hit+20,Align=5)
(Align)
\ ? Subtitle(String(n+Delta,"FVEC[n+DELTA=%.0f]")+mType+ " (Aligned)" , Y=2.5*Hit+20,Align=5)
\ : Subtitle(String(n,"FVEC[n=%.0f]")+mType , Y=2.5*Hit+20,Align=5)
Subtitle(String(n,"BVEC[n=%.0f]")+mType , Y=3.5*Hit+20,Align=5)
Subtitle(string(n+Delta*Time/100.0,"MFlowInter Predicted @ [%.2f]") , Y=4.5*Hit+20,Align=5)
Return Last
}
Wid=640 Hit=64 Steps=Wid/XStep
White=BlankClip(width=WID,height=HIT,Length=1,Color=$FFFFFF,Pixel_type=CS) Black=White.BlankClip srcS=Black.BlankClip(Length=0)
For(i=1,Steps-1) { W=White.Crop(0,0,i*XStep,0) K=Black.Crop(0,0,Wid-W.Width,0) Frm=StackHorizontal(K,W) srcS=srcS++Frm }
srcS=(HFlip)?srcS.FlipHorizontal:srcS
srcE=SrcS.Loop(0,0,Delta-1) # Delete Delta frames, end interp src
super=srcS.MSuper(pel=2,hpad=16,vpad=16)
fvec =MAnalyse(super, isb=false, blksize=BlkSz, overlap=OLap, delta=Delta, truemotion=true)
bvec =MAnalyse(super, isb=true, blksize=BlkSz, overlap=OLap, delta=Delta, truemotion=true)
inter=srcS.MFlowInter(super, bvec,fvec, time=Time)
mbv=srcS.MMask(bvec,kind=MaskT) mfv=srcS.MMask(fvec,kind=MaskT)
mfv=(Align)?mfv.Loop(0,0,Delta-1):mfv # Align, Delete DELTA frames from start, align n+delta with n
TXT=SrcS.BlankClip(Height=20,Length=1,Color=$404040)
StackVertical(TXT,srcS,SrcE,MFV,MBV,Inter)
mType=mTyp(MaskT)
ARGS = "Delta,Time,XStep,Align,HFlip,MType"
Last.GScriptClip("Fn(last, "+ARGS+")", local=true, args=ARGS)
DIR=(HFlip) ? " : ---->" : " : <----"
TXT=TXT.Subtitle(String(Delta,"Delta=%.0f")+String(Time," : Time=%.2f")+
\ String(BLKSZ," : BLKSZ=%.0f")+String(XSTEP," : XSTEP=%.0f")+" : ALIGN="+String(ALIGN)+" : HFlip="+String(HFlip)+DIR)
return StackVertical(TXT,Last)
"""
IsAvsPlus?Eval(FuncS):GScript(FuncS)
Return Last.ConvertToRGB32
}

# 0=Motion, 1=Sad, 2=Occlusion, 3=Horizontal, 4=Vertical, 5=ColorMap

VectorTest(Delta=2,MaskT=2,Align=FALSE)


Frame 41 (normal, no FWD vector Occlusion mask weirdness)
https://i.postimg.cc/qM2NNFDg/41.jpg (https://postimages.org/)

Frame 42
https://i.postimg.cc/RZ3b1cf3/42.jpg (https://postimages.org/)

Frame 43
https://i.postimg.cc/3rnLPLF4/43.jpg (https://postimages.org/)

Frame 44
https://i.postimg.cc/1XtKmQrg/44.jpg (https://postimages.org/)

Frame 45 (back to normal again)
https://i.postimg.cc/SsQ6dh5Z/45.jpg (https://postimages.org/)

Forward vectors go through a 4 frame cycle, normal, a bit wierd, very weird, a bit weird, back to normal again.
Backward vectors no weirdness.
EDIT: Weirdness above Type on the FVEC line.

EDIT: I've observed similar occlusion weirdness in clip where occlusion appears near top of frame where seemingly sky is pretty much uniform grey [greyscale clip].

EDIT: Changed to ALIGN=False and re-upped images.

EDIT: Above script was only really intended for Horizontal motion mask examination.

EDIT: I suspect that weirdness might be connected with overlap.

EDIT:
If you change this

OLap=(BlkSz>=4)?BlkSz/2:RT_Undefined


OLap=RT_Undefined

Weirdness disappears [EDIT: And occlusions get fatter and then slimmer as clip progresses though the 4 frame cycle, for both FWD and BWD masks]

EDIT: I still dont have much clue how that occlusion stuff works.

EDIT: I note that author of YFRC

# Author: RunForLife(Oleg Yushko) http://videomontazh.com.ua
# http://avisynth.nl/index.php/YFRC

uses only backwards Occlusion mask, here posted mod as YFRC2() by RaffRiff42:- https://forum.doom9.org/showthread.php?p=1804170

Below, both SAD masks used, but only BAK backward Occlusion mask.

## "EM" - error or artifact mask
EM = C.MMask(bak, ml=190, kind=1) [** kind=SAD *]
EM = EM.Overlay(
\ C.MMask(fwd, ml=190, kind=1).DeleteFrame(0),
\ opacity=0.5, mode="lighten")

EM = EM.Overlay(
\ C.MMask(bak, ml=64, kind=2).mt_inpand, [** kind=occlusion *]
\ opacity=0.5, mode="lighten")

[StainlessS]

Further to above, a bit more weirdness.

Actually, weirdness on forward vectors when movement from right to left, but on backward vectors when movement left to right.

Here script to show more masks over several frames.

script (requires V.C. Mohan Grid plug if SHOWGRID=true)

MASKT=2 # 0, 2, 3 ONLY : 0=Motion, 2=Occlusion, 3=Horizontal motion
HFLIP=true # Direction, true=Left to right
XSTEP=8 # Movement step size per frame of white movement moving over black
BLKSZ=4 # MAnalyse BlkSize
Weird=true # Show Weird Occlusion masks
SHOWGRID=true # Show Grid, Req V.C. Mohan Grid Plugins.
#####################
##### END Config ####
#####################
CS="YV12"
Wid=960
Hit=48
DELTA=2
TIME=50.0
Steps=Wid/XStep
White=BlankClip(width=WID,height=HIT,Length=1,Color=$FFFFFF,Pixel_type=CS)
Black=White.BlankClip srcS=Black.BlankClip(Length=0)
For(i=1,Steps-1) {
W=White.Crop(0,0,i*XStep,0) K=Black.Crop(0,0,Wid-W.Width,0) Frm=StackHorizontal(K,W) srcS=srcS++Frm
}
srcS=(HFlip)?srcS.FlipHorizontal:srcS
srcE=SrcS.Loop(0,0,Delta-1) # Delete Delta frames, end interp src
OLap=(Weird)?2:Undefined
super=srcS.MSuper(pel=2,hpad=16,vpad=16,chroma=false)
fvec = MAnalyse(super, isb=false, blksize=BlkSz,Overlap=OLap,delta=Delta, truemotion=true,chroma=false)
bvec = MAnalyse(super, isb=true, blksize=BlkSz,Overlap=OLap,delta=Delta, truemotion=true,chroma=false)
inter= srcS.MFlowInter(super, bvec,fvec, time=Time).Greyscale
mfv0 = srcS.MMask(fvec,kind=MaskT).Greyscale # n
mfvS1= mfv0.DuplicateFrame(0) # n-1
mfv1 = mfv0.DeleteFrame(0) # n+1
mfv2 = mfv1.DeleteFrame(0) # n+2
mfv3 = mfv2.DeleteFrame(0) # n+3
mfv4 = mfv3.DeleteFrame(0) # n+4
mbv0 = srcS.MMask(bvec,kind=MaskT).Greyscale # n
mbvS1= mbv0.DuplicateFrame(0) # n-1
mbv1 = mbv0.DeleteFrame(0) # n+1
mbv2 = mbv1.DeleteFrame(0) # n+2
mbv3 = mbv2.DeleteFrame(0) # n+3
mbv4 = mbv3.DeleteFrame(0) # n+4
DIR=(HFlip) ? " : ---->" : " : <----"
TXT=SrcS.BlankClip(Height=20,Length=1,Color=$404040).Subtitle(String(Delta,"Delta=%.0f")+String(Time," : Time=%.2f")+
\ String(BLKSZ," : BLKSZ=%.0f")+String(XSTEP," : XSTEP=%.0f")+" : HFlip="+String(HFlip)+DIR)
StackVertical(srcS,SrcE,Inter,mfvS1,mbvS1,mfv0,mbv0,mfv1,mbv1,mfv2,mbv2,mfv3,mbv3,mfv4,mbv4)

COL=$FF00FF
(SHOWGRID)?grid(Lineint=8,Color=COL,bColor=COL,vbColor=COL):NOP
mType=mTyp(MaskT)
ARGS = "Delta,Time,XStep,HFlip,MType"
Last.GScriptClip("Fn(last, "+ARGS+")", local=true, args=ARGS)

Return StackVertical(TXT,Last).ConvertToRGB32

Function MTyp(Int n) {Return " Type="+Select(n,"Motion","Sad","Occlusion","Horizontal","Vertical","ColorMap")}

Function Fn(clip c,Int Delta,Float Time,Int XStep,Bool HFlip,String mType) {
c n=current_frame
Hit=Height/15
Steps=Width/XStep
x=((n+1)*XStep) + (Delta*XStep/2)
x=Min(x,(Steps-1)*XStep)
x=HFlip?x:Width-1-x
Subtitle(String(n,"SRC[n=%.0f] (1st interp srcS)") , Y=0.5*Hit,Align=5)
Subtitle(String(n+Delta,"SRC[n+Delta=%.0f] (2nd interp srcE)") , Y=1.5*Hit,Align=5)
Subtitle(string(n+Delta*Time/100.0,"MFlowInter Predicted @ [%.2f]") , Y=2.5*Hit,Align=5)
Subtitle(String(n-1,"FVEC[n-1=%.0f]")+mType,Y=3.5*Hit,Align=5)
Subtitle(String(n-1,"BVEC[n-1=%.0f]")+mType,Y=4.5*Hit,Align=5)
Subtitle(String(n+0,"FVEC[n+0=%.0f]")+mType,Y=5.5*Hit,Align=5)
Subtitle(String(n+0,"BVEC[n+0=%.0f]")+mType,Y=6.5*Hit,Align=5)
Subtitle(String(n+1,"FVEC[n+1=%.0f]")+mType,Y=7.5*Hit,Align=5)
Subtitle(String(n+1,"BVEC[n+1=%.0f]")+mType,Y=8.5*Hit,Align=5)
Subtitle(String(n+2,"FVEC[n+2=%.0f]")+mType,Y=9.5*Hit,Align=5)
Subtitle(String(n+2,"BVEC[n+2=%.0f]")+mType,Y=10.5*Hit,Align=5)
Subtitle(String(n+3,"FVEC[n+3=%.0f]")+mType,Y=11.5*Hit,Align=5)
Subtitle(String(n+3,"BVEC[n+3=%.0f]")+mType,Y=12.5*Hit,Align=5)
Subtitle(String(n+4,"FVEC[n+4=%.0f]")+mType,Y=13.5*Hit,Align=5)
Subtitle(String(n+4,"BVEC[n+4=%.0f]")+mType,Y=14.5*Hit,Align=5)
Return Last
}


Here showing white motion coming in from the left.

Mask=2, Occlusion (weirdness on backward vectors)
https://i.postimg.cc/xCzLmY02/M2.jpg (https://postimages.org/)

Mask=0, Motion (its a bit faint) [relevant for frame n, bvec n+0 and fvec n+delta(2)]
https://i.postimg.cc/vTyx6Vqr/M0.jpg (https://postimages.org/)

Mask=3, Horizontal Motion [relevant for frame n, bvec n+0 and fvec n+delta(2)]
https://i.postimg.cc/wM93BdMF/M3.jpg (https://postimages.org/)

Src frame 24 has stepped 2 * 8 pixels at frame 26, each little mark on grid are 8 pixels apart.

[manolito]

Can you tell if only the pinterf-mod versions are affected by this "weirdness", or is it also present in the latest Fizick version mvtools-v2.5.11.22 ?

[StainlessS]

Thanks for taking an interest Mani,
And Yip, it does same in Avisynth v2.60, mvtools2 from mvtools-v2.5.11.22.zip (avs version 2.60 dll dated 26/Apr/2016).

just add Gscript wrapper as this [where not Avs+]


GScript("""
For(i=1,Steps-1) {
W=White.Crop(0,0,i*XStep,0) K=Black.Crop(0,0,Wid-W.Width,0) Frm=StackHorizontal(K,W) srcS=srcS++Frm
}
""")


Can you reproduce.

EDIT: I think the first script in post #520 should work as is (with Avs+ OR GScript, and at least version v2.60 standard, +Grid for 2nd script)

EDIT:
EDIT: I still dont have much clue how that occlusion stuff works.

EDIT: I note that author of YFRC

# Author: RunForLife(Oleg Yushko) http://videomontazh.com.ua
# http://avisynth.nl/index.php/YFRC

uses only backwards Occlusion mask, here posted mod as YFRC2() by RaffRiff42:- https://forum.doom9.org/showthread.php?p=1804170

Below, both SAD masks used, but only BAK backward Occlusion mask.

## "EM" - error or artifact mask
EM = C.MMask(bak, ml=190, kind=1) [** kind=SAD *]
EM = EM.Overlay(
\ C.MMask(fwd, ml=190, kind=1).DeleteFrame(0),
\ opacity=0.5, mode="lighten")

EM = EM.Overlay(
\ C.MMask(bak, ml=64, kind=2).mt_inpand, [** kind=occlusion *]
\ opacity=0.5, mode="lighten")


I think above, that backward Occlusion mask should be mixed first with backward SAD mask, same for forward, and then those two mixed together.
(Dont know how MysteryX does it [EDIT: FrameRateConverter], I havnt looked)

[pinterf]

When you visualize the vectors (a have put that line right after your vector generation lines, you can see that the forward vectors are not uniform at the top and right lines.

[...]
mbv=srcS.MMask(bvec,kind=MaskT)
mfv=srcS.MMask(fvec,kind=MaskT)
return StackVertical(MShow(super,fvec).SubTitle("MShow fvec"),MShow(super,bvec).SubTitle("MShow bvec"))

Then change block size to 8, BlkSz=8, (default is 4 in your test script), then you can see other strange things

[StainlessS]

Mod to VectorTest script as per Pinterf observation.

Function VectorTest(Int "Delta",Float "Time",Int "MaskT",Int "BlkSz",Int "XStep",Bool "Align",Bool "HFlip",String "CS") {
/*
VectorTest(), An MvTools2::MFlowInter folly. by StainlessS @ Doom9 : https://forum.doom9.org/showthread.php?t=175373

Req AVS+ or GSCript, GRunt, MvTools2, RT_Stats v1.43+
Avs v2.58, Avs/+ v2.60.

Delta, Default 1. As for MvTools2
Time, Default 50.0, As for MvTools2
MaskT, Default 3, As for MvTools2::MMask(kind=MASK_TYPE), 0=Motion, 1=Sad, 2=Occlusion, 3=Horizontal, 4=Vertical, 5=ColorMap
BlkSz, Default 4, As for MvTools2
XStep, Default 8, Motion per frame of synthesized clip.
Align, Default True, Aligns forward vector frame n+Delta to n. False show frame n of forward vector.
HFlip, Default False, False, Animate from Right to Left, else Left to Right.
(Right to Left is less confusing, same direction that the frames come in from).
CS, Avs v2.5 defaults "YV12" else "Y8".

Returns RGB32 clip.
*/
Function MTyp(Int n) {Return " Type="+Select(n,"Motion","Sad","Occlusion","Horizontal","Vertical","ColorMap")}
myName="VectorTest: "
IsAvsPlus=(FindStr(UCase(versionString),"AVISYNTH+")!=0) HasGScript=RT_FunctionExist("GScript")
HasGrunt=RT_FunctionExist("GScriptclip") HasMvTools2=RT_FunctionExist("MSuper") Is26=VersionNumber>=2.6
Assert(IsAvsPlus||HasGscript,myName+"Essential AVS+ or GScript installed")
Assert(HasGrunt,myName+"Essential GRunt installed") Assert(HasMvTools2,myName+"Essential MvTools2 installed")
Delta=Default(Delta,1) Time=Default(Time,50.0) MaskT=Default(MaskT,3) BlkSz=DefaulT(BlkSz,4)
XStep=Default(XStep,8) Align=Default(Align,True) HFlip=Default(HFlip,False)
CS=Default(CS,Is26?"Y8":"YV12")
OLap=(BlkSz>=4)?BlkSz/2:RT_Undefined
# OLap=RT_Undefined
FuncS="""
Function Fn(clip c,Int Delta,Float Time,Int XStep,Bool Align,Bool HFlip,String mType) {
c n=current_frame
Hit=(Height-20)/5
if(Align) {
Steps=640/XStep
x=((n+1)*XStep) + (Delta*XStep/2)
x=Min(x,(Steps-1)*XStep)
x=HFlip?x:639-x
cF=RT_YPlaneMin(n=n,x=x,y=Round(2.5*Hit)+20,w=1,h=1)-128
cB=RT_YPlaneMin(n=n,x=x,y=Round(3.5*Hit)+20,w=1,h=1)-128
Z=c.BlankClip(width=1,height=1,Color=$FFFFFF,Length=1)
OverLay(Z,x=x,y=Round(2.5*Hit)+20)
OverLay(Z,x=x,y=Round(3.5*Hit)+20)
Subtitle(RT_String("@x=%d FGrey=128%+d : BGrey=128%+d",x,cF,cB))
} else {
Subtitle("Align=False, Colors NOT shown")
}
Subtitle(String(n,"SRC[n=%.0f] (1st interp srcS)") , Y=0.5*Hit+20,Align=5)
Subtitle(String(n+Delta,"SRC[n+Delta=%.0f] (2nd interp srcE)") , Y=1.5*Hit+20,Align=5)
(Align)
\ ? Subtitle(String(n+Delta,"FVEC[n+DELTA=%.0f]")+mType+ " (Aligned)" , Y=2.5*Hit+20,Align=5)
\ : Subtitle(String(n,"FVEC[n=%.0f]")+mType , Y=2.5*Hit+20,Align=5)
Subtitle(String(n,"BVEC[n=%.0f]")+mType , Y=3.5*Hit+20,Align=5)
Subtitle(string(n+Delta*Time/100.0,"MFlowInter Predicted @ [%.2f]") , Y=4.5*Hit+20,Align=5)
Return Last
}
Wid=640 Hit=64 Steps=Wid/XStep
White=BlankClip(width=WID,height=HIT,Length=1,Color=$FFFFFF,Pixel_type=CS) Black=White.BlankClip srcS=Black.BlankClip(Length=0)
For(i=1,Steps-1) { W=White.Crop(0,0,i*XStep,0) K=Black.Crop(0,0,Wid-W.Width,0) Frm=StackHorizontal(K,W) srcS=srcS++Frm }
srcS=(HFlip)?srcS.FlipHorizontal:srcS
srcE=SrcS.Loop(0,0,Delta-1) # Delete Delta frames, end interp src
super=srcS.MSuper(pel=2,hpad=16,vpad=16)
fvec =MAnalyse(super, isb=false, blksize=BlkSz, overlap=OLap, delta=Delta, truemotion=true)
bvec =MAnalyse(super, isb=true, blksize=BlkSz, overlap=OLap, delta=Delta, truemotion=true)
inter=srcS.MFlowInter(super, bvec,fvec, time=Time)
mbv=srcS.MMask(bvec,kind=MaskT)
mfv=srcS.MMask(fvec,kind=MaskT)

return StackVertical(MShow(super,fvec).SubTitle("MShow fvec"),MShow(super,bvec).SubTitle("MShow bvec")) ### RETURN EARLY

mfv=(Align)?mfv.Loop(0,0,Delta-1):mfv # Align, Delete DELTA frames from start, align n+delta with n
DIR=(HFlip) ? " : ---->" : " : <----"
TXT=SrcS.BlankClip(Height=20,Length=1,Color=$404040)
StackVertical(TXT,srcS,SrcE,MFV,MBV,Inter)
mType=mTyp(MaskT)
ARGS = "Delta,Time,XStep,Align,HFlip,MType"
Last.GScriptClip("Fn(last, "+ARGS+")", local=true, args=ARGS)
TXT=TXT.Subtitle(String(Delta,"Delta=%.0f")+String(Time," : Time=%.2f")+
\ String(BLKSZ," : BLKSZ=%.0f")+String(XSTEP," : XSTEP=%.0f")+" : ALIGN="+String(ALIGN)+" : HFlip="+String(HFlip)+DIR)
return StackVertical(TXT,Last)
"""
IsAvsPlus?Eval(FuncS):GScript(FuncS)
Return Last.ConvertToRGB32
}

# 0=Motion, 1=Sad, 2=Occlusion, 3=Horizontal, 4=Vertical, 5=ColorMap

VectorTest(Delta=2,MaskT=2,HFlip=false,BlkSz=8,Align=True)


frame 41 [EDIT: BVEC looks correct-ish, but is it twice as wide as it should be ???, maybe white moving left, and black moving right, sort of ]
https://i.postimg.cc/mrDGTWcZ/vt41.jpg (https://postimages.org/)

frame 42
https://i.postimg.cc/dtjMdVrt/vt42.jpg (https://postimages.org/)

frame 43
https://i.postimg.cc/1RDbh3Wc/vt43.jpg (https://postimages.org/)

frame 44
https://i.postimg.cc/FzvWs0Pb/vt44.jpg (https://postimages.org/)

frame 45 [EDIT: BVEC looks correct-ish, but is it twice as wide as it should be ???, maybe white moving left, and black moving right, sort of ]
https://i.postimg.cc/MpHsT6YL/vt45.jpg (https://postimages.org/)

'curiouser and curiouser' cried Alice.

EDIT: Frame 41 (top one) cropped and point resized a bit

Crop(288,112,34,-14)
PointResize(width*16,height*16)

https://i.postimg.cc/HnHYRfs9/Vectortest-Copy-01.jpg (https://postimg.cc/CBPpfr8R)

[MeteorRain]

Bump.

I took a few hours having a quick scan in the source code.

MCTD is basically MDegrain(lots of MAnalyze()), so to increase the speed, a very quick test would be to run MAnalyze in parallel. I suppose mvtools cannot run under multi-threading mode yet because it crashed right away.

I'm thinking maybe I should plan to backport VapourSynth-mvtools instead of trying to clean up the original code.

How much difference are there (apart from the synth platform) between the 2 code base?

[tormento]

How much difference are there (apart from the synth platform) between the 2 code base?
From a user POV (and that's why I stopped using VS), mdegrain goes up to 6 (I wish I had up to 9, that I use A LOT on heavily grained old BW sources) and there is mdegrain N too.

[Boulder]

Bump.

I took a few hours having a quick scan in the source code.

MCTD is basically MDegrain(lots of MAnalyze()), so to increase the speed, a very quick test would be to run MAnalyze in parallel. I suppose mvtools cannot run under multi-threading mode yet because it crashed right away.

I'm thinking maybe I should plan to backport VapourSynth-mvtools instead of trying to clean up the original code.

How much difference are there (apart from the synth platform) between the 2 code base?
I'm not sure if pinterf has already included the changes the SVP project has made in MAnalyse, the VS version should contain them.

[tormento]

MvTools with Depans 2.7.41
Is there any reason why mdegrainN is less efficient than mdegrainX, where x=1…6? I am not talking about speed but about denoising.

I was doing some tests on noise vs details preservation and I panned from mdegrain4 to mdegrain9 as tr=4…9 parameter in SMDegrain. It was the only parameter I changed. The table speaks for itself:

tr=4 5.237,20 kb/s
tr=5 5.116,45 kb/s
tr=6 5.021,69 kb/s
tr=7 5.067,22 kb/s <- at this point there is a regression
tr=8 5.008,13 kb/s
tr=9 4.963,75 kb/s

I have tried different thsad values and I have found the same pattern.

Any idea?

[pinterf]

I'm not sure if pinterf has already included the changes the SVP project has made in MAnalyse, the VS version should contain them.
Those changes are incorporated (stop analyzing and gathering further SAD if the given threshold is already reached)

[pinterf]

Bump.

I took a few hours having a quick scan in the source code.

MCTD is basically MDegrain(lots of MAnalyze()), so to increase the speed, a very quick test would be to run MAnalyze in parallel. I suppose mvtools cannot run under multi-threading mode yet because it crashed right away.

I does run in mt, and for historical reasons it still have its internal mt (need external avstp.dll and mt=true).
I wonder about the crash details it's been a long while since I received report on it.


I'm thinking maybe I should plan to backport VapourSynth-mvtools instead of trying to clean up the original code.

How much difference are there (apart from the synth platform) between the 2 code base?

VS started from an earlier mvtools version. My version took an mvtools version which worked on x64 (original one never had x64 version) this one had internal mt in many functions, which I told you about (mt flag).

Then came .a 22 version from Fizick (still only for YV12 and YUY2), so both VS and my fork had to be updated our already heavily changed sources with those changes.

Then my version was updated with finer block sizes, float support, made motion vector formats independent from the format of the clip applied on (use mv from 8 bit search and apply on 16 or 32 bit clip in MDegrain, huge save in time) 4-6 versions of MDegrain (it's MDegrainN that has internal mt). And others which I cannot remember without looking at the 2.7 changelog.

edit:
plus differences:
MDegrain: out16 parameter, which outputs 16 bit result from 8 bit input
scaleCSAD parameter in MAnalyze (which has internal mt as well), basically chroma SAD is made consistent between 4:2:0, 4:2:2 and 4:4:4 format but you can fine tune it.

[pinterf]

Is there any reason why mdegrainN is less efficient than mdegrainX, where x=1…6? I am not talking about speed but about denoising.

I was doing some tests on noise vs details preservation and I panned from mdegrain4 to mdegrain9 as tr=4…9 parameter in SMDegrain. It was the only parameter I changed. The table speaks for itself:

tr=4 5.237,20 kb/s
tr=5 5.116,45 kb/s
tr=6 5.021,69 kb/s
tr=7 5.067,22 kb/s <- at this point there is a regression
tr=8 5.008,13 kb/s
tr=9 4.963,75 kb/s

I have tried different thsad values and I have found the same pattern.

Any idea?
MDegrainN falls back to native MDegrain1,2,3... when the thSad and thSad2 parameters are the same, try with different ThSad2 if it differs even by one, it will call original MDegrainN

[tormento]

MDegrainN falls back to native MDegrain1,2,3... when the thSad and thSad2 parameters are the same
Please explain me more about this fallback.

If it falls back, shouldn’t I have the same results? And it falls back, to which MDegrain?

[pinterf]

E.g. MDegrainN with tr=3 will be redirected to MDegrain3 (different code) if ThSad2 = ThSad. Over 6 since there is no matching MDegrain7, it remains in the original MDegrainN code.

[tormento]

E.g. MDegrainN with tr=3 will be redirected to MDegrain3 (different code) if ThSad2 = ThSad. Over 6 since there is no matching MDegrain7, it remains in the original MDegrainN code.
Ok but my question was totally different. :p

Why over 6 is there a regression in efficiency? You can clearly see the step up in bitrate from 6 to 7.

[pinterf]

The codes are different a bit, MDegrainN is full generic code capable of handling many clips. I cannot remember now in which part it is different from normal MDegrain. (Internal accuracy, processing order?)
Try comparing MDegrainN(tr=6) with MDegrain6, how much is the difference? (and force using the N version by giving a slightly different ThSad2 param)

[tormento]

Try comparing MDegrainN(tr=6) with MDegrain6, how much is the difference? (and force using the N version by giving a slightly different ThSad2 param)
SMDegrain use internally different values already:

thSAD=default( thSAD, 300 )
thSAD2=int(thSAD/2)

so the values of tr>6 use MDegrainN code.

[real.finder]

For me, I am completely satisfied with MVTools-pfmod

the only thing that missed is float clip motion analysis, but since not all other filters work with float clip as f3kdb or there are even many filters still in 2.5 era, I think MVTools-pfmod is ok as it, and also I didn't note any MT problem

[tormento]

For me, I am completely satisfied with MVTools-pfmod
Perhaps a single, generic and optimized MDegrainN would be the best thing.

Why are there different version for the same function?

Lot of plugins have different working ranges but there is one plugin only for all of them.

[real.finder]

Perhaps a single, generic and optimized MDegrainN would be the best thing.

Why are there different version for the same function?

Lot of plugins have different working ranges but there is one plugin only for all of them.

for avs/avs+ it's only one now (MVTools-pfmod) since it has all features of the others

in vs there are 2, and since I don't use vs so I don't care :)

[tormento]

for avs/avs+ it's only one now (MVTools-pfmod) since it has all features

I mean having MDegrain1...MDegrain6 and MDegrainN.

[real.finder]

I mean having MDegrain1...MDegrain6 and MDegrainN.

that features :D

I think we talked a lot about this before

[tormento]

that features :D



I think we talked a lot about this before



Wouldn’t be easier to maintain and optimize a single generic function instead of 7 or 4 in the case of VS?

[real.finder]

Wouldn’t be easier to maintain and optimize a single generic function instead of 7 or 4 in the case of VS?

which one in vs? the main one is MDegrain1...MDegrain3 IIRC

anyway, MDegrain1...MDegrain6 is faster than use MDegrainN with 1-6

that why it's features

[pinterf]

For me, I am completely satisfied with MVTools-pfmod

the only thing that missed is float clip motion analysis, but since not all other filters work with float clip as f3kdb or there are even many filters still in 2.5 era, I think MVTools-pfmod is ok as it, and also I didn't note any MT problem
Why need motion analysis in float? In most cases you cannot even separate 8 bit results from 10 or 16 bit results. Do the motion analysis fast, in 8 or 10 bits. Then apply it on the 32 bit float clip. MDegrain, MFlow, etc.. all work with float. You can even do it on RGB, while motion analysis can be done on the YUV ceonverted clip. I have a feeling that 32 bit float is not even enough for SAD, it has only 23 significant bits afaik, while mvtools is using 32 or 64 bits for summing up SADs. I think it is more interesting to examine the effect of mv precision if we put motion vectors to floating point.
And we are talking about precision? What is the base data we are working on? It's not even a linear one. Did anybody do tests on making vectors from a more linear 16 bit data converted from a 8 or 10 bit source? We do averaging, resizing, adding and subtracting and interpolating on gamma distorted videos. I think it's not the float clip-based analysis which is the bottleneck.

[real.finder]

Why need motion analysis in float? In most cases you cannot even separate 8 bit results from 10 or 16 bit results. Do the motion analysis fast, in 8 or 10 bits. Then apply it on the 32 bit float clip. MDegrain, MFlow, etc.. all work with float. You can even do it on RGB, while motion analysis can be done on the YUV ceonverted clip. I have a feeling that 32 bit float is not even enough for SAD, it has only 23 significant bits afaik, while mvtools is using 32 or 64 bits for summing up SADs. I think it is more interesting to examine the effect of mv precision if we put motion vectors to floating point.
And we are talking about precision? What is the base data we are working on? It's not even a linear one. Did anybody do tests on making vectors from a more linear 16 bit data converted from a 8 or 10 bit source? We do averaging, resizing, adding and subtracting and interpolating on gamma distorted videos. I think it's not the float clip-based analysis which is the bottleneck.

maybe it's needed in extreme cases https://forum.doom9.org/showpost.php?p=1906890&postcount=168

[pinterf]

Yep, I've read it, I'd like to know more about those edge cases, I admit there can be cases but I could only see that the script is SMDegrain, which is not mvtools alone. Or SMDegrain was only demonstrating the speed difference?
O.K. then questions will come: In what part was it better? Was the result visually more appealing in general? Or did it have better noise reduction, or it did better interpolation in MFlow or in a similar filter?

(for myself: ) If the reason was of having a full floating point mvtools, I'd interested in the real reason (which we may even cannot tell without debug output):
having float (or double?) SAD collecting, finer motion vectors or only just being the clip float in the denoising or whatever process?
(Note that integer VS-mvtools version cannot handle float clip with doing mv prediction from a 8-16 bits clip, in avs mvtools float speed penalty is not that much).

Poor ChaosKing :), he just said what he experienced;
I really wanted to ask him about these things that came into my mind but I felt tired to really go into deeper analysis. (The topic is indeed an interesting one)

[ChaosKing]

With better quality I meant less artifacts :D
I know I posted comparison pics somewhere, but I can't find it.

And since mvtools-sf only supports 32bit precision (and mvtools does not), we can't know if it is just a "better" implementation or because it is more "precise".

I remember one scene where this problem can be observed. I will try to make a test with vs and avs mvtools soon.

EDIT
The edge case was observed with smdegrain.

[StainlessS]

Chaos, Was trying to find your images, and have seen links to zopti thread, perhaps in there somewhere.
Any of these images familiar:- https://www.google.com/search?source=univ&tbm=isch&q=%22chaosking%22+near+(%22mvtools%22+%26+%22smdegrain%22)&sa=X&ved=2ahUKEwjF8ZTp3InpAhXIUxUIHUo9BokQsAR6BAgHEAE&biw=1920&bih=886

[MeteorRain]

I does run in mt, and for historical reasons it still have its internal mt (need external avstp.dll and mt=true).
I wonder about the crash details it's been a long while since I received report on it.

I didn't try MT or avstp. I was simply trying to parallelize GetFrame() call in MDegrain to fetch multiple upstream MAnalyze results. I got some incorrect pointers to read but I didn't dig deeper.

I just checked the code, it was marked as MT_MULTI_INSTANCE, so it cannot be run in multi-threading.