Looking for help improving motion estimation for stabilization of animation

[avurgesser]

I am looking for a way to to essentially have DePanEstimate() ignore the center of the frame for the edges.

I am currently transcoding Slayers from DVD to H.264 for my server. When I transcode I tend to do light clean-up at the same time. One significant problem Slayers has is frames that shake back and forth. I have tried various stabilization options I have found in research, but my current problem is they they try to correct foreground shaking. My most recent reject was because a characters laughter was stabilized and this made the background shake!

I have addressed the most recent problem by moving the DePanEstimate() window to the side. The idea is to cut out the center where most foreground animation uses. but I am worried another sceen might put foreground animation in the new window brining the problem back. I think a 98% solution would have the FFT window consider the borders only, but I don't know how to realize that. After all, just blacking out the center would create a ne already stable object there which would distort the FFT analysis.

My current function:

function Stab2 (clip clp,    int "range", float "trust", \
                int "winx",  int "winy", \
                int "wleft", int "wtop", \
                int "dxmax", int "dymax", \
                int "mirror", bool "info" \
                ) {

range  = default(range, 1)
trust  = default(trust, 0)
winx   = default(winx,0)
winy   = default(winy,0)
wleft  = default(wleft,-1)
wtop   = default(wtop,-1)
dxmax  = default(dxmax, 4)
dymax  = default(dymax, 4)
mirror = default(mirror, 16)
info   = default(info, false)

temp = clp.TemporalSoften(7,255,255,25,2)
inter = Interleave(temp.Repair(clp.TemporalSoften(1,255,255,25,2)),clp)
mdata = DePanEstimate(inter,range=range,trust=trust,winx=winx,winy=winy,wleft=wleft,wtop=wtop,dxmax=dxmax,dymax=dymax)

DePan(inter,data=mdata,offset=-1, mirror=mirror, info=info)
SelectEvery(2,0) }

Usage:

ret = ret.Stab2(range=4, winx=32,winy=128, wleft=16, wtop=64, dxmax=6, dymax=6, mirror=0)

[johnmeyer]

1. Deshaker (VirtualDub plugin) has the ability to easily set up ignore areas (ignore outside, or ignore inside of the frame).

2. I don't do any work with animation, but I do know that one of the biggest issues with any sort of animation is the way it repeats fields and frames. These repeats often do not follow any sort of repeatable or predictable pattern. The issue with this is that any sort of frame repeat totally screws up any stabilization, and this is especially true when you have an irregular pattern and even more true if you have some areas where the same frame is repeated 3, 4, or more times in a row.

So, regardless of whether you continue to use Depan along with some sort of mask, or whether you use something else, you have to remove the repeats before you are going to get anything that looks decent.

[jagabo]

For small horizontal shakes, instead of Stab() (or maybe in addition), try QTGMC:

TurnRight().QTGMC(InputType=2, Sharpness=0.5).TurnLeft()

Can you provide a short sample that shows your problem?

[avurgesser]

This is the most recent trouble spot for me. You can see the shifting in the background, but the laughing character fools the motion estimation.

https://drive.google.com/file/d/14H6xkjdobIHVCY8xLUftcIj15xLjxel_/view?usp=share_link

The only filter is deringing from MPEG2Source(). Recommend you view with IVTC. I use AnimeIVTC(mode=2, aa=0, cache=6, bbob=3, degrain=3) to help manage the field blending.

Perhaps a heavy blur on the center of the frame would destroy most foreground details for motion estimation without manufacturing false data. Problem is, I don't know of a filter that only blurs part of a frame. I did consider splicing a composite image of the borders, but the boundary between slices would still create a new, stable temporal artifact.

[Selur]

in this example doesn't it work to just use dymax=0 ?

[jagabo]

Perhaps a heavy blur on the center of the frame would destroy most foreground details for motion estimation without manufacturing false data. Problem is, I don't know of a filter that only blurs part of a frame.

Use Overlay() with an alpha mask. I don't think blurring the center will work. But replacing it with black should:

# input previously cropped to 704x480 with Crop(4,0,-12,-0)

black = BlankClip(last)
alpha = BlankClip(last, width=576, height=480, color=$ffffff).AddBorders(64, 0, 64, 0, color=$000000).ColorYUV(cont_y=50).BilinearResize(44, 30).Spline36Resize(704, 480)
Overlay(last, black, mask=alpha)

Use the result of that for the motion vectors.


[Attachment 69616 - Click to enlarge]

It works ok with the provided sample but there may not be enough detail left at the edges for other shots. Which means you will have to isolate the problematic shots. In which case using dymax=0 would be much easier.

[avurgesser]

If I drop dymax to 0, I think there are other segments that can cause issues. I don't have a better example handy, but DePan info does display some (desirable) vertical adjustment right before the provided cut (a sloppy scene change).

I think jagabo has what I need. I had not thought to exploit resizing artifacts to produce a gradient. That's a nice little hack. This technique can also be applied vertically for more width information. I will need to keep an eye on pans, but that is hardly unique. The resize and alpha did noticeably slow things down, but the rest of my filter chain is so slow I hope I won't notice on the batch job.

inter = Interleave(temp.Repair(clp.TemporalSoften(1,255,255,25,2)),clp)
border = 64
alpha = BlankClip(inter, width=inter.width-2*border, height=inter.height-2*border, color=$ffffff).AddBorders(border, border, border, border, color=$000000).ColorYUV(cont_y=50).BilinearResize(12, 8).Spline36Resize(inter.width, inter.height)
mfilter = Overlay(inter, BlankClip(inter), mask=alpha)
mdata = DePanEstimate(mfilter,range=range,trust=trust,winx=winx,winy=winy,wleft=wleft,wtop=wtop,dxmax=dxmax,dymax=dymax)

Now I just need to think of how to abstract the border math to decent parameters for my "Stab2" function to handle frame sizes other than NTSC (and probably an original name). More resizing improves the gradient, but too much will wash out the solid sections! That can happen later (if ever)

[jagabo]

It might not even be necessary to blur the edges of the mask. That would make it even simpler, just overlay a black box.

It might be useful to have StabInside() and StabOutside() user supplied block coordinates. Or maybe StabMask() with a user supplied mask.

[avurgesser]

I don't understand the FFT comparison mechanism well enough, but I think the gradient is desirable. If you just have a black box, the edge of that represents a significant element that is temporally stable. Having the gradient instead allows the unstable elements to fade instead of wink preserving the FFT differences from the edge better. I would need someone more familiar with what dePanEstimate() is doing to opine.