GenMotion and DePan plugins for global motion compensation

Originally Posted by Roco

Thank you very much g-force for your interest and your offer, but I cannot post a sample of that material (I wish I could). I was occupied with some other stuff until today so I will know in about 2-3 days what solution will be more suitable (if any) and I will let you know.

No worries. Let me know what you find out!

-G

[thetoof]

Little question about pixaspect=

I use a LOT this very useful script by g-force (turned into a function for convenience) before encoding anamorphic (so I don't resize to square pixel aspect ratio).

function stab (clip orig, float "pixaspect"){
pixaspect=default(pixaspect,1)
orig
temp = last.TemporalSoften(7,255,255,25,2)
Interleave(temp.Repair(last.TemporalSoften(1,255,255,25,2)),last)
DePan(last,data=DePanEstimate(last,trust=0,dxmax=10,dymax=10),offset=-1, pixaspect=pixaspect)
return SelectEvery(2,0)}

It is said in the docs (actually, I saw that in the MVtools docs) that the pixaspect should be 1.094 for standard PAL and 0.911 for standard NTSC.

However, this calculation yields to other values... where did I mess up??

NTSC
720x480 is actually 640x480 (4:3)
y * 720 = 640
y = 0.8888....

720x480 is actually 853.3333x480 (16:9)
y = 1.185185185.....

PAL
720x576 is actually 768x576 (4:3)
y * 720 = 768
y = 1.06666........

720x576 is actually 1024x576 (16:9)
y = 1.42222.....

edit: and (why) is it such a big deal to use pixaspect=1 even if I'm filtering an anamorphic clip??

[kemuri-_9]

Originally Posted by thetoof

It is said in the docs (actually, I saw that in the MVtools docs) that the pixaspect should be 1.094 for standard PAL and 0.911 for standard NTSC.

However, this calculation yields to other values... where did I mess up??

it seems that those calculations are more seeming to be based on a source with a width of 704 not 720
so
640/704 ~ .910
768/704 ~ 1.10

the aspect numbers you posted/quoted result as:
640/.911 ~ 703
768/1.094 ~ 702

so it seems that these are fairly close to being based on 704,
but not quite, so maybe some rounding error?

probably based on 704 to account for cropping on 'typical' overscan (which may or may not actually be true for what you're dealing with)

[Fizick]

about aspect you may read "Analog capture guide" http://forum.doom9.org/showthread.php?t=78797

Fizick, correct me if I'm wrong, but DePan should only need to know about pixaspect for Zoom or Rotation, both of which the script thetoof posted doesn't use.

[Fizick]

g-force, only if rotation is not 0.
So, you are wrong (partially)

I think I understand. I'll try one more time:

Fizick, correct me if I'm wrong, but DePan should only need to know about pixaspect for Rotation, which the script thetoof posted doesn't use. ?!?!

-G

[Fizick]

g-force,
yes, it is correct.

but IMHO, all this aspects is not so important practically

[gaillague]

Hello all,
This is my first post ever and I want to thank the community, but this question is perhaps especially for Fizick.

I have problems with DePanStabilize with the average method method=1
Many parameter do not longer work when i use before mdepan() or mvdepan() for global motion estimation.

eg dxmax,dymax,rotmax,addzoom, zoommax

However they work fine when i use DepanEstimate() for the global motion estimation but it's less interesting for me because there is no rotation estimation.

It seems to me that the average method give a very good deshaking, close to the Vdub Plugin Deshaker.
Unfortunately without all this parameters, it's very hard to tweak precisely the motion stabilization and the zoom.

exemple of non working script

a=last
vectors = a.MSuper().MAnalyse(isb = false,blksize=8)
globalmotion = a.MDepan(vectors)
a1 = a.DePanStabilize(data=globalmotion,method=1,cutoff=0.5,dxmax=0,dymax=0,rotmax=0,addzoom=true)
return a1

thanks in advance

[Fizick]

dxmax=0 (and dymax=0, rotmax=0) should not work for method=1 for any vector source (MDepan, DePanEstimate).
The current code contains division of dx by dxmax, etc
It was unclear for me, how to process special case dxmax=0, etc

[gaillague]

thank you for reply

dxmax=0 (and dymax=0, rotmax=0) was only an (extrem) exemple but dxmax =x (and dymax=y, rotmax=z ) do'nt work too (with method=1 and M(v)Depan as vector source.
The stabilisation works (damn good) but no correction is possible.
The addaptive zoom do'nt work too.

DePanStabilize(data=globalmotion,method=1,dxmax=10,dymax=20,rotmax=0,addzoom=false)
or
DePanStabilize(data=globalmotion,method=1,dxmax=60,dymax=60,rotmax=30,addzoom=true)

are giving absolut identical results.

[Fizick]

gaillague,
Oh, yes, dxmax, etc are disabled for method=1. It seems I did not get good result that time.
But it is not dependent on vector source. DepanEstimate should not work too.
You should wait some more advanced developer for motion stab. Sorry.

[gaillague]

You should wait some more advanced developer for motion stab

I'll wait....
But it is not too annoying, the tool works anyway very fine

In any case,thanks very much for all your work.

[Fizick]

I will fix the doc about dxmax, etc.
But addzoom should work with method=1

[gaillague]

addzoom is not working too
always with method=1 & MDepan as vector source

mvtools2 v 2.4.2
Depan v 1.10.0

[Fizick]

I found that I use DePan v1.10.1, January 27, 2008
Seems, I forget to publish it.
Changes is minimal (fixed bug with blur mode for subpixel=1), but V1.10.0 really does not work with addzoom for some strange reason.
I will upload the update

[gaillague]

Yes it works now
thanks Fizick

[Mini-Me]

Sorry to necro this thread, but is the source code available for Depan/DepanStabilize?
DepanEstimate includes the source with the binary, but Depan/DepanStabilize do not.

Thanks

[Fizick]

Well, i am totally out of avisynth world now.
So, source Depan code is released today. But it was my first plugin, and probably the worst code ever written
Good luck!

[Mini-Me]

Originally Posted by Fizick

Well, i am totally out of avisynth world now.
So, source Depan code is released today. But it was my first plugin, and probably the worst code ever written
Good luck!

Don't worry; I think everyone believes their early code to be the worst code ever written. I'm glad you decided to make it available anyway. Thank you!