New toy: MVTools version with true motion compensation

[Fizick]

By the way, when i try to increase speed of MVTools, i found that "searchparam" of MVAnalyse is really =2 by default. The documentation says, that it is =1.

[Didée]

Hah, interesting finding about searchparam's default!

Originally Posted by Fizick

What you made it is post-processing.

Yes. As is deblocking.

But if we will use this "cured" compensated frame for noise reduction, it will have exactly same pixels values in this cured regions as current frame. Strange denoising.

Fizick, did you actually *look* at my sample? Ideally with switching forth-back between "source" and "compensated(PP)", at some 200% or 400% zoom?

[Fizick]

I understand, that is is not full pixels equivalence, but we must not use it anyway

[Didée]

"We must not" ?? Which god has decided so?

If you think the result will be better with using some UltraSmearyMegaBlurryDeblocking for that purpose, well, I won't hold you back from doing so


But I'll tell you the findings I've come to so far, in respect to denoising:

When using a broad repair for badly compensated blocks, then at best you'll only be able to flatten down the block's content ... together with the detail that might have been in before. But things might even get worse, since the content of the "bad" block might happen to be completely unrelated, in which case deblocking will not help, but create a smeary mess.

However when repairing with Repair(reference,4) plus alittle additional sharpening, you effectively get the content of the original block, BUT with a sort of "noise-of-its-own". That's because the bad block's pixels might be brighter or darker than those of the original block, which is a random relation. Then, sharpening the rather flat result of Repair(4) thereof will recreate a reasonable representation of the original block from the compensated-and-repaired one, but with "another kind" of noise. And this is perfectly suited for denoising.

But let's stop the arguing, do whatever you consider to be the best. I've dropped my point (to not get accused of "hiding the miracles" somewhen later), and - penultimate argument - it is already working on my side, rather nicely.

[Fizick]

let's stop.

[Fizick]

v.0.9.11.1 (Released 06.11.2005)
Added half-pel support to MVFlow.
Increased quant limit to 60 in DeBlock for very strong deblocking.
Corrected documentation.

http://www.avisynth.org/fizick/mvtools/

[scharfis_brain]

is it possible for you to add a motion blurrer based on mvFlow() ?
possible parameters like
blurlength: 0 - no blur ; 0.5 blur for the half the duration of a frame; 1 - blur for the duration of one frame ; 2 - blur over the duration of 2 frames
precision: 1 - do nothing; 2 - two pixels; 10 - pixels etc...

maybe you could leave out the precision parameter, if you are drawing lines of 'blurlength' (vectorlength*blurlength) instead of pixels, so there would never occur any ghosting.

[Fizick]

scharfis_brain,
I will think about blur.
Now MVFlow is used mstly for compensation.
I have a plan to add motion interpolation (bi-directional and masked), probably MVFlowInter function.

About your request about YUY2. You do not get me answer, do you need in YUY2 motion estimation or in YUY2 compensation only?

[scharfis_brain]

I'd be glad, if you could implement the YUY2 space

Estimation can be done in YV12 space. (of course, YUY2 would be a nice-to-have, too )
But for compensation YUY2 is a must, when dealing with field-stuff.

[sh0dan]

Really great to see the features I miss in this great tool. I do however get deallocation crashes using this script:

highquality=true
source=last
vectors_b = source.MVAnalyse(isb = false, lambda = 1000, pel = (highquality) ? 2: 1)
vectors_f = source.MVAnalyse(isb = true, lambda = 1000, pel = (highquality) ? 2: 1)
inter12=mvinter(source, vectors_f, vectors_b, time=12.0, thSCD2=70, thSCD1=100)
inter25=mvinter(source, vectors_f, vectors_b, time=25.0, thSCD2=70, thSCD1=100)
inter75=mvinter(source, vectors_f, vectors_b, time=75.0, thSCD2=70, thSCD1=100)
inter88=mvinter(source, vectors_f, vectors_b, time=88.0, thSCD2=70, thSCD1=100)
interleave(source,inter12,inter25,inter75,inter88)
temporalsoften(2,255,255,5,2)
selectevery(5)

Source is 624x352. (This is btw a very good motion blur)

Regarding YUY2, using YV16 in 2.6 will probably be easier since it's planar. There are however a lot of "width / 2" and "height / 2", instead of the PVideoFrame->GetRowSize(PLANAR_U) & PVideoFrame->GetHeight(PLANAR_U), which will make adding new colorspaces harder.

[Manao]

YUY2 or YV16 will be the same, since internal data will need to be planar anyway ( nobody in their right mind would work on interleave data for ME / interpolation / compensation ).

I can do the YUY2 adaptation. Not quite yet ( I'll be rather busy till sunday ), but after that, I'll have some free time. It's "almost" "just a matter" of changing "nHeight / 2" by "nHeightUV" ( I won't use the PvideoFrame->*, because width & height are needed at initialization time anyway, and because the core is made as much as possible to be independant from avs 2.5 ).

[mg262]

FWIW, kassandro wrote some Planar2Interleaved and Interleaved2Planar functions that might save you a little time here. I think they're part of RemoveGrain.

[Fizick]

Manao,
We must use not-squared blocks for YUY2 (YV16) chroma (4x8 ?)

sh0dan,
I will try to find a bug.
But I reaaly want to remove MVInter and replace it by MVFlowInter tomorrow.

[Fizick]

v0.9.12
Added MVFlowInter function. MVInter function will be removed in next release (it is worse).
Changed scale of ml parameter for kind=2 of MVMask to more optimal default.
Fixed small bug in Bilinear.asm (strange pixels near right border for pel=2).

[Mug Funky]

mvflowinter is looking good! just upconverting something to 100fps to check it out.

it'd be cool to have an mvfps style function though - trying to calculate appropriate time values for turning 60/1.001 fps to 50 fps is doing my head in. i was thinking about doing it with a scriptclip, but i'm sure disaster lies in that direction.

[scharfis_brain]

59.94 <-> 50 conversions can be made easily by calculating approx 300 fps (59.94*5) or exactly 300 fps (50*6) and then do changefps afterwards.
the remaining stutter of the 1000/1001 thing can be neglected, cause it will only be a 'stutter' of 1/300 sec.

[scharfis_brain]

I am running in big trouble with mvflowinter()

loadplugin("d:\x\mvtools0912.dll")
loadplugin("d:\x\tdeint.dll")
loadplugin("d:\x\DGDecode.dll")

#load interlaced video
mpeg2source("D:\FORUM\castellandw\PALMPEG2Clip.d2v",cpu=4)

i=tdeint(mode=1,type=3,link=0,mthreshl=7,ap=25)

vf=mvanalyse(i,isb=false,blksize=4,lambda=1000,lsad=1000,pnew=100,plen=0,pel=2)
vb=mvanalyse(i,isb=true ,blksize=4,lambda=1000,lsad=1000,pnew=100,plen=0,pel=2)

a17=mvflowinter(i,vb,vf,time=16.7,ml=100)
a20=mvflowinter(i,vb,vf,time=20.0,ml=100)
a33=mvflowinter(i,vb,vf,time=33.3,ml=100)
a40=mvflowinter(i,vb,vf,time=40.0,ml=100)
a50=mvflowinter(i,vb,vf,time=50.0,ml=100)
a60=mvflowinter(i,vb,vf,time=60.0,ml=100)
a67=mvflowinter(i,vb,vf,time=66.7,ml=100)
a80=mvflowinter(i,vb,vf,time=80.0,ml=100)
a83=mvflowinter(i,vb,vf,time=83.3,ml=100)

#interleave(i,a20,a40,a60,a80).changefps(50) # NTSC2PAL
interleave(i,a17,a33,a50,a67,a83).changefps(59.94,linear=false) #PAL2NTSC

It immediately closed VDub on open without any error message.

when I commented out the lines a20, a40, a60, and a80 it ran for a while but closed VDub after approx 50 frames linear acces after jumping to a random time in the video file.

but nontheless, the interpolation results are pretty good. A little bit lesser wobbling on occlusions and it is read for usage in an standards conversion script.

btw.: can you code in an error protection for appearing and vanishing logos and subtitles? Cause mvflowinter makes a funny kind of interpolation out of it

[Fizick]

scharfis_brain,
what is your system config?

Some words about 1.001:
Internally i use time not as float but as byte integer, so gradations are from 0 to 256.

[scharfis_brain]

My system configuration:
AthlonXP 1600+ with 768MB RAM
running WindowsXP SP2
and currently AVS 2005-May-05 without plugin-autoloading

[Fizick]

Firstly try remove unused a20, a40, a80 lines.
At construction stage MVFlowinter creates huge arrays.
MVTools eat many memory generally.
Also try latest more stable AViSynth.

I must ask Manao, why 10 frames per mvclip is created.
And why MVtools strore compensated frames (large!) in vector clips. In my opinion, we must compensate in various Compensation functions. For example in MVDlow I do not use pre-compensation info. Also often it is better to estimate pre-filtered clip, but compensate original source. So, probably mode=0 in MVompensate is almost unusable. What anybody think about it?