Quote:
Originally Posted by zorr
No, didn't try that one but I did try one which had a similar problem area. I didn't get very far with that one (had something else to do). I think those would benefit from the MCompensate trick to make the errors less horrible looking. 
I took a glance and that one really looks like the worst case - the fence looks like it's moving into opposite direction than the rest of the scene. There's no way MVTools algorithms can figure out that it should actually move the other way. Perhaps the only chance is to use the DePan filter to detect the global motion and generate the fence part and combine it using the Stripe mask. Maybe. |
mcompensate is used in jm_fps and a number of similar related interpolation functions - it really doesn't help with that one. It does help with mark's clip, the 2nd scene's "paper window" (the right side of the frame) is basically clean with default jm_fps settings. But the wooden background is not on the left - the problem is object boundary demarcation vs. background .
Yes that fence clip is very difficult - but it is possible in other programs with some motion tracking to help guide the motion estimation and mattes. It just would be nice to have a cleaner starting point - less work to do in other programs - that's why I'm asking about zopti. Maybe there is some mvtools2 setting I'm missing (I've tested quite a few)
Speaking of cleaner starting points - the newer DNN methods tend to produce cleaner object edges than mvtools2 . Especially DAIN and RIFE. DAIN is very slow , but RIFE is usable with a decent GPU. Both run on python, it would be nice to see a vapoursynth version. They still "fail" on things like "picket fences" and those situations that all optical flow fails on - but 3 area it generally does better than mvtools2: 1) cleaner object edges, 2) y-axis rotational movements (such as a spin) 3) organic movements like flag waving, water. That's with the default publically distributed models; you could probably train custom models for specific things "picket fence"
Besides the slower speed, another downside is DAIN/RIFE are 2x, 4x... interpolators. But I've found if you use RIFE or DAIN followed by mvtools2, the results are significantly better than just mvtools2 alone , when you have a situation where you need to interpolate a non pow2 rate
Quote:
Originally Posted by feisty2
if you like the result of MCompensate, have you tried MBlockFPS (with overlap > 0)? It doesn't have the "liquefying" artifacts like those Flow functions.
BlockFPS has been overlooked for many years because it wasn't very useful in the original avisynth MVTools (cannot handle overlapped blocks), but that restriction has been lifted from the VS MVTools since forever.
|
I didn't know vpy version of mblockfps was different. I have tried smoothfps/smoothfps2 and several similar variants that all use mblockfps with mrecalculate , instead of mflowfps, but I've always used them in avisynth . I'll play with the vpy version and report back if there are interesting findings