Closest AVS scripts to Alchemist results

[Mug Funky]

you should un-blend it as well as bobbing if you want motion compensation to be useful at all. otherwise it stays jerky...

also, salfps3 is experimental and doesn't like scenechanges much. it relies on warped edges in a similar way to one of didee's scripts earlier on in the thread, but scenechanges don't necessarily cause warping on the entire frame - the frame will have sizeable chunks of either side of the scenechange left.

feel free to combine it with the masking used in an earlier version of the script though - combining it with the tension masks that motionprotectedfps makes should improve it, but it's not ideal.

[wonkey_monkey]

Does anyone know where I can get the dll to go with motionprotectedfps? From Googling it looks like the author's site no longer exists, although the script is still in Google's cache.

David

[buzzqw]

i have this two link http://www.64k.it/andres/data/avisynth/MotionProtectedFPS.avsi
and http://www.64k.it/andres/data/avisynth/Motion_12Dec05.zip

BHH

[wonkey_monkey]

Thanks! I'd found that mirrored copy of the script, but going to the parent folder showed a list of plugins, and no link to Motion...

David

[wonkey_monkey]

On my computer, mcbob runs at 1fps. Salfps3 runs at about 4fps. But when I combine them, I get (and this is a very approximate figure) 0.008fps - that's 3 minutes for the first frame! When I stepped to the next frame in VirtualDub, it took a more respectable 15 seconds or so, but going to the third frame caused vdub to crash.

Does anyone know why this is happening?

Thanks,
David

[foxyshadis]

Ran out of memory, probably. Normally, you only get 2GB per process, so you might want to heavily restrict your framebuffer (SetMemoryMax) or just try 64-bit avisynth and whatever you can get working there.

[squid_80]

or just try 64-bit avisynth and whatever you can get working there.
Pretty much limited to convertfps at the moment (and it's significantly slower for unknown reasons) but I am working on getting motion.dll ported (inline assembly in header files = ouch).

[wonkey_monkey]

Oops, I must have edited that part out of my post - task manager showed vdub as hovering around the 300mb mark, which about where it gets with mcbob alone. I'm now having some trouble with salfps3 without mcbob, so I'll go back to the drawing board for a while...

David

[krieger2005]

here's my latest attempt:

function salFPS3(...)
...
mt_expand(mode=mt_circle(3))
mt_inflate()
bicubicresize(width*8, height*8,1,0)
crop(0, 0, 720, 480)
...
}

I think the line in red is a failure in your script. I don't find that someone earlier said something about that before. So maybe you could edit your script.

[Mug Funky]

you're probably right. i certainly can't remember what that line is doing there, but it effectively restricts it to NTSC sizes which is not a good thing...

try comment it out and see what happens :)

[krieger2005]

the script need this line. In general it's the same as in "motionprotectedfps" where the mask must be stratched back to the size of the clip (since you resized it before to the original-size/8). If you don't won't to look closer at the problem here is what i think it should be replaced with:
crop(0, 0, input.width(), input.height())

[Didée]

Glancing over the script, I saw that salFPS3 is a bit laborious in some places, and couldn't leave my fingers off ;)

Simplifications:
- crop/resize in one step, instead resizing to 8x8 plus cropping of 1/8x1/8 (as mentioned [p]ages earlier)
- don't use FitY2UV of old MaskTools. New MaskTools has "luma" parameter for mt_merge.
- chroma thresholds in TemporalSoften zero'ed, since the mask has no valid chroma anyway.
- eleminated two colorspace conversions by ditching "MOD16()" & making the resize inherently mod16 by m16().

No biggies, only nitpicking. Perhaps it gains one fps. ;)

What makes me frown a bit is the hard "black/white" thresholding (mt_binarize(80)) in relation to error detection. Conceptually, I'd prefer some softer gradual thresholding, to prevent "effects" in case that the mask should happen to oscillate around the threshold. But that's only me, you know...;)

edit: one resizer was wrong, corrected.
edit2: compatible with AS < v2.57.
function salFPS3(
\ clip input, float FPS,
\ int "mode", int "protection", int "protection2",
\ int "iterate", int "reset", int "initialise")
{
mode = default(mode, warp)#fast)
protection = default(protection, 80)
protection2= default(protection2,20)
iterate = default(iterate, 2)
reset = default(reset, 50)
initialise = default(initialise, 6)

originalFPS = input.framerate()
input

mp = FindMotion(iterate = iterate, reset = reset,
\ initialise = initialise)
p = MotionFPS(FPS,mode,Motion = mp)
p_edge = mt_edge(mode="prewitt",thy1=protection2,thy2=0).MotionFPS(FPS,mode,Motion = mp)
maskp = mp.SumStretchFPSMask(FPS, protection)

mn = FindMotion(iterate = iterate, reset = reset,
\ initialise = initialise, from = next)
n = MotionFPS(FPS,mode,Motion = mn, source = next)
n_edge = mt_edge(mode="prewitt",thy1=protection2,thy2=0).MotionFPS(FPS,mode,Motion = mn, source=next)
maskn = mn.SumStretchFPSMask(FPS, protection, source = next)

eps = 0.0001
maskp
assumeFPS(originalFPS)
CombineFPS(FPS, maskp, maskn.Invert())
bilinearresize(input.width(), input.height(), 0,0, eps+width/8.,eps+height/8. )
mpro=last

mt_merge(p_edge, n_edge, last, luma=true, u=3, v=3)

mt_lut(yexpr="128 x 128 - abs 112 / 128 * - 2 *") # 112/128* added to roughly compensate for the inherent
# clamping formerly done by the (now missing) ConvertToRGB.
mt_inpand()
bicubicresize(m16(width/8.),m16(height/8.),1/3.,1/3.)
mt_binarize(protection2,false)
temporalsoften(1,255,0,255)
mt_binarize(80,false)
mt_expand(mode=mt_circle(3))
mt_inflate()
bicubicresize(input.width(), input.height(), 1,0 )
tehmask=last

mt_merge(p, n, mpro, luma=true, u=3, v=3)

mt_merge(last,input.blendfps(FPS,aperture=FPS/float(input.framerate()))
\,tehmask, luma=true, u=3,v=3)
}

function m16(float x) {x<16?16:int(round(x/16.0)*16)}

[Pookie]

Perhaps it gains one fps

That might mean a 100% speedup in performance in some cases:D

[Mug Funky]

thanks Didée :)

good to know about the luma merge thing. i'll have to check that out, as i use that a lot.

and i'm not surprised it was a bit laborious in parts, considering it's mostly a semi-blind copy of clouded's original script.

i was just about to post an updated version of the script that supported other-than NTSC sizes, but looks like you've beaten me to it :)

[edit]

btw, the hard threshold probably should be ditched in favour of some sort of soft one, but i suspect then the metrics would have to be better :) certainly motion can get a bit jarring on local fast/complex motion, but a soft threshold would have it's own problems (like triple-edged moving objects... i suppose this happens with a hard threshold as well, but it would happen more otherwise).

[zambelli]

Another great thread, guys. This is the kind of stuff we all keep coming back to Doom9 for. :)

Does using MCBob have any advantage for standards conversion over TDeint that most people seem to be using?

[Mug Funky]

it has a marginal benefit in vertical sharpness, but unless you're going from say 50i to 60p there will be almost no visual difference, but a big speed hit :) certainly if you're going from interlaced to interlaced, the only noticable differences will occur on sharp moving graphics, and this difference will be very minor (slight up and down motion by about half a pixel, a few times a second). even this is completely invisible on a CRT.

[Chainmax]

How feasible would it be to add a motion analysis tool (similar to DeShaker's 1st pass) to SalFPS3 so that in scenes with motion above a certain threshold the extra frame(s) would be created via blending of the nearest ones? That should reduce artifacting a great deal, right?

[Cunhambebe]

That might be a stupid question (I'm a newbie), but after reading all of this thread, how would I write a script to convert *.tga (TARGA) sequences redered as NTSC at 30 fps to NTSC 24 film, keeping the sequence smooth and not slow. Thanks in advance.
Mark

[Mug Funky]

imagesource("x:\dir\to\imagesequence_%04d.tga",0,147)

converttoyv12()

whicheverscriptyouchoose(fps=24,args)


... that assumes you've got files "imagesequence_0000.tga" up to "imagesequence_0147.tga" in a directory somewhere.

also make sure the images are mod 8 or you'll have problems.

depending on the script you use, you'll get results comparable to optical flow in AE, except not as shit (but the sacrifice is having to step down to 4:2:0 8 bit)

[Cunhambebe]

Thanks so much Mug Funky; I'll give it a try and post the results back as soon as possible. Thanks, really!
Mark

PS: whicheverscriptyouchoose(fps=24,args)

-Which one? Convert to 24, for instance? cvan you give me an example? :) Thanks again.

[Cunhambebe]

This one is not working, definitely:
imagesource("D:\Nova pasta\FightersFinal_FFN0000.tga",0,0300)
ConvertToYv12()
ConvertFPS(24)

Neither this one - says there's an error; it says: Convert FPS requires YUY2 input.

LoadPlugin("C:\avs_plugins\ImageSequence.dll")
CoronaSequence("D:\Nova pasta\FFN.tga",sort=1)
ConvertToYv12()
ConvertFPS(24)

Any ideas?

[wonkey_monkey]

converttoyuy2() instead of converttoyv12().

David

[Cunhambebe]

Thank you very much David. Now the scrit looks like this:
LoadPlugin("C:\avs_plugins\ImageSequence.dll")
CoronaSequence("C:\FightersFinal\FFN0000.tga",sort=1)
ConvertToyuy2()
ConvertFps(24)

There's a warning: Corona Sequence: first picture found cannot be decoded.

So what? Is there anything wrong with my Targa 32 files?
One more thing: I see a lot of people adding ConvertToyuy2(). In may case (not the case above that is a targa sequence) , when I'm converting from MPEG2 to Xvid, it seems the conversion is made through the Chroma. So, I guess, according to what I've read around here, it is not necessary adding ConvertToyuy2(). Is that OK?

Thanks in advance.

[cwk]

Hello all,

I am experimenting with the using MVFps from MVTools within the salFPS scripts in this thread. I cannot get past the call to SumStretchFPSMask. Where does this function come from? I cannot find reference to it in documentation for either MaskTools or Motion.

Thanks,
cwk

[Mug Funky]

it comes from motion.dll, but i'm not sure if it's documented. it was designed specially for the script function "motionprotectedfps", which salfps scripts are derived (hacked) from :)

it makes a mask based on possible discontinuities in the vector field, but i'm not entirely sure how it works.

[Clown shoes]

Can anyone suggest the best way to call salFPS3

My current script is;

import("C:\Program Files\AviSynth 2.5\plugins\mvbob\mvbob.avs")
import("C:\Program Files\AviSynth 2.5\plugins\salFPS3.avs")
QTInput("I:\Crossfire\track 1.mov")
converttoyv12()
mvbob()
salfps3(50)
lanczos4resize(width,576)
assumetff().separatefields().selectevery(4,0,3).weave()


I have some particularly difficult 29.97i footage I'm working with,
that involves lots of very fast motion and quick flashes. Any suggestions as to a better script would be greatly appreciated. :)

[cwk]

Thanks Mug Funky,

I'll take a look.

cwk

[Chainmax]

I am getting a "I don't know what WARP means", pointing to line 6 of salFPS3. Also, I am not sure I'm getting its dependencies right, can someone tell me which are they?

[Mug Funky]

that "warp" part will be in motion.dll. you could hunt it down and remove it from the script - it'll switch to the default mode "warpfast" which will be slightly chunkier but still good when moving.