MVTools

[Arshad07]

Does MVtools works with directshowsource? 'Cause everytime i close the previewer window, my megui crashes.

[ash925]

Originally Posted by Arshad07

Does MVtools works with directshowsource? 'Cause everytime i close the previewer window, my megui crashes.

Yes, it does and no crashes for me.

[Adub]

I can confirm.

[adrianmak]

any x64 version ?

[buletti]

adrianmak: Are you in the possession of a recent Avisynth build (2.5.7+) that supports 64bit? AFIAK there was merely a single custom build 64 bit version back in 2005 which is not available anymore (and probably extremely outdated).
So, as long as there's no 64 bit Avisynth, there's no use for 64 bit plugins..

[Arshad07]

@adrianmak

You can still run x86 s/ws on a x64bit OS.....thats why there's a folder called Program Files (x86) in your C:/

[kemuri-_9]

Originally Posted by buletti

adrianmak: Are you in the possession of a recent Avisynth build (2.5.7+) that supports 64bit? AFIAK there was merely a single custom build 64 bit version back in 2005 which is not available anymore (and probably extremely outdated).
So, as long as there's no 64 bit Avisynth, there's no use for 64 bit plugins..

see squid_80's site for avisynth 2.5.7 x64 and accompanying x64 plugins.
http://members.optusnet.com.au/squid_80/

[Terka]

Fizick,
would phase shift method(s) be helpfull in motion-estimation when added to MVtools?
Are you planning something like this in future versions?
Thank you,
Terka

[Fizick]

Terka,
I make several "planning" to do it. Last time - use phaseshift maximums as a predictors. But I am afraid, iy should be implemented not in MVTools block-based framework.

[Terka]

one question to mrecalulate.
MAnalyse has some default setting, S1.
When using MAnalyse in script, i can select my own settings, S2. Other, not directly specified settings, remains same as S1.
When using MRecalculate, i can select my own settings, S3. Other, not directly specified settings, remains same as S2?

[Fizick]

Terka,
good question. it is not documented.

other remains as undocumented defaults of mrecalculate, which are same values as defaults of manalyse.

[Terka]

thank you for reply.
One more thing, the following doesnot work with latest mvtools2
AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
vectors = MSuper().MAnalyse(isb = true)
MShow(vectors)

[Fizick]

This script is wrong. MShow need in super clip, for example:

AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
MSuper()
vectors = MAnalyse(isb = true)
MShow(vectors)

or

AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
super=MSuper()
vectors = MAnalyse(super, isb = true)
MShow(super,vectors)

I replace source by super to show padding and vectors at padding

[Puncakes]

Hi,

Is the blur I'm getting with Mdegrain3 in darker scenes expected, or have I gone wrong somewhere? I've read over the documentation and after tweaking about every option I could, I wasn't able to get a noticeable change (aside from the overall strength, thsad).

Source: http://i26.tinypic.com/24vk4l0.jpg
Default: http://i25.tinypic.com/kbzvut.jpg
Thsad200: http://i26.tinypic.com/24vk4l0.jpg

VOB Sample: http://www.mediafire.com/?ij2jznzjugy

My script is:

DGDecode_mpeg2source("VTS_03_1.d2v")
tfm(order=0)
src = last
super = src.MSuper()
bvec3 = super.MAnalyse(isb=true, delta=3, overlap=4)
bvec2 = super.MAnalyse(isb=true, delta=2, overlap=4)
bvec1 = super.MAnalyse(isb=true, delta=1, overlap=4)
fvec1 = super.MAnalyse(isb=false, delta=1, overlap=4)
fvec2 = super.MAnalyse(isb=false, delta=2, overlap=4)
fvec3 = super.MAnalyse(isb=false, delta=3, overlap=4)
src.MDegrain3(super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3)

I'm hoping I've missed something that can be corrected, since mdegrain is the only filter I've tested that can remove so much noise/grain with so little blur and artifacts (on the brighter scenes at least).

[onesloth]

Originally Posted by Puncakes

Is the blur I'm getting with Mdegrain3 in darker scenes expected, or have I gone wrong somewhere?

It seemed to me MDegrain2 and 3 got noticeably blurry with 2.4.0.
I don't have 2.3.1 so I haven't done any AB comparisons, though.

[Fizick]

2.4.0 beta (09.01.2009 by Fizick)
MDegrain: Changed degrain weight method to more strong...

Approx:
Old: (thSAD-blockSAD)/thSAD.
new: (thSAD*thSAD - blockSAD*blockSAD)/(thSAD*thSAD + blockSAD*blockSAD)

Assume thSAD=400,
Example 1. current SAD=100, old strength = 0.75, new strength = 0.87.
Example 2. current SAD=200, old strength = 0.5, new strength = 0.60.
Example 3. current SAD=300, old strength = 0.25, new strength = 0.28.
Example 4. current SAD=400, old strength = 0, new strength = 0.


blurring usually indicates wrong vector search...

[Didée]

Ah - thanks for posting the new formula. I ever wondered since it was implemented - - but not enough to start digging through the source code ...

blurring usually indicates wrong vector search...

... and/but: at least part of the story is that same-SAD-everywhere is not very smart: In "flat" areas like sky, skin, nebula etc., SAD usually is rather low, and even ~relatively~ small SAD can mean a big error. In contrast to high-detail / high-contrast areas, where SAD usually is rather big. Really, SAD for "edge-areas" and "non-edge-areas" are like two different worlds ...

Official question: What about taking into account local complexity when evaluating SAD? Aren't there any proven concepts out there for that?

[Sagekilla]

This probably is computationally unfeasible, but how's about how well a region can be compressed? For a given block, run it through your favorite lossless compressor and calculate the % of the original file size. Flat areas would probably give something like (general numbers here) 200 bytes compressed vs 2000 bytes uncomp'd, so it's complexity score would be 0.1.

Like I said, that's probably way too slow to be practical but there's probably a way to do something similar and much faster.

[Fizick]

Didée,
suprisingly, about week ago i found your manifesto about local complexity hidden in non-official mvtools thread
http://forum.doom9.org/showthread.ph...80#post1305680

If anyone has ideas that s/he thinks that would bring a worthwhile improvement, then:
MAKE IT, and SHOW THE PROOF.
Until then, I'll resort to short "nope"-style answers, when indicated.


My answer is - nope. SAD is SAD, and it is evaluated (and must be evaluated) in MAnalyse as is.
Postprocessing and usage of this info (in MDegrain, etc) is other story.
But rigth now I am more interested in more coorct vector field estimation. May be even with variable block size like h264. in tis case SAD may be not so big at edges.

[TSchniede]

This is an issue I have been thinking about myself. Right now we simply don't know if a low SAD means that the match is good or that there isn't much information anyway.
We would want some sort of metric that tells us how reliable our guess on the movement is.
I had hoped this could be an alternative approach for the movement analysis. but so far I haven't found a way to get the concept into a working algorithm. I'm not even sure it is possible to do it in a way that the produced vectors and computation time is better or at least equivalent.