Deshaker Comparison

[ajp_anton]

Had not heard of DePan.dll (http://avisynth.org.ru/depan/depan.html). Does anyone have experience with this and how it compares with Deshaker?

Features and limitations


#2 may be a deal-breaker. The first part of the footage for the most part only has slight rotation; no zooming and only minor panning.I use it with rotation as well. I think it's a limitation of DePanEstimate, but like I said, I use MDepan for motion estimation, and DePanStabilize supports rotation. And as pinterf also said, just use MDepan.
@pinterf A 64-bit port is very welcome here!

c = source
vectors = c.msuper().manalyse(isb = false)
mdata = mdepan(c,vectors, zoom=true, rot=true)
depanstabilize(c, data=mdata, dxmax=..., dymax=..., rotmax=...)

[MysteryX]

Could you post a sample of it?

[pinterf]

I use it with rotation as well. I think it's a limitation of DePanEstimate, but like I said, I use MDepan for motion estimation, and DePanStabilize supports rotation. And as pinterf also said, just use MDepan.
@pinterf A 64-bit port is very welcome here!
Just be patient :) Basically it is ready but I have to move it to github and needs final polishing. I started this port because I liked to have a full 64 bit 8mm film restoring workflow, then it became my 16 bit learning sandbox. So expect weeks rather than days for release.

[MysteryX]

I played around with Deshaker's advanced settings.
- Rolling Shutter changed from 88% to 80% (not sure what's the right value here)
- Scale changed from Half to Full
- Use Pixels changed from Every 4th to All
- Skip frames if less than X% of blocks are ok changed from 8 to 0
- Edge compensation: none
- Fill borders with previous and future frames: 30/30

>> Deshaker (High) (https://mega.nz/#!nB5UzDgT!fCfGbr80Ta3JzVoqiMVY0aUyqd9s7YoWPpNYrV0jz8I)

Of course Pass 1 is a lot slower, but the result is quite good. Here there is no zooming and the border reconstruction isn't bad at all. The "soft borders" option causes the reconstruction to make those borders blurred; I kind of liked the small girl appearing like a ghost but I don't find that option practical.

One issue with this video is the large pole on the left that is moving faster than the rest of the picture. Its motion must be excluded.

I'd say the best with Deshaker is to use no zoom and to fill borders with previous and future frames. It works fine in most cases, and here there is some ugly distortion at the top of the pole while recreating borders. Import the full non-zoomed video into Adobe Premiere and you can zoom manually to hide the borders that don't look good. I think that's the best way to preserve almost all the video.

[poisondeathray]

I've never seen a good "automatic" edge fill option. IMO it's unusable in any software - better to crop & scale

Warp stabilizer has edge synthesis and mercalli has sort a blur/bleed/mirror, and there are other non stabilizer options for filling in missing information - but none of them are consistently good or usable for video, or at least require manual work to "fix" some or a lot of areas (either covering with patches that you can use with motion tracking; or "zooming" manually as you suggested). I can post the Adobe edge synthesis example, but it's just as bad as deshaker's, same problems with artifacts, flickering, perspective distortions. I suppose some people don't mind it, but I really dislike it

[shekh]

IMO border filling is good to fill gaps that are only few frames long. Better filling however can survive longer and bigger gaps.

[real.finder]

Alright I might be able to do something with Deshaker and MP_Pipeline. I created a function in my program to convert the script into multiple processes with a single call at the end, and it will re-insert the audio to match the video, even if applying trimming or changing the playback speed. Ah... the joys of auto-generating scripts.

From here I'll be able to implement it nicely; unless someone find another plugin doing a better job. So far this one works best.


P="Encoder\"
LoadPlugin(P+"MP_Pipeline.dll")
SetMemoryMax(1)

MP_Pipeline("""
### inherit start ###
P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"Dither.dll")
Import(P+"Dither.avsi")
LoadPlugin(P+"masktools2.dll")
LoadPlugin(P+"VDubFilter.dll")
LoadVirtualDubPlugin(P+"deshaker.vdf", "deshaker", preroll=0)
LoadPlugin(P+"SmoothAdjust.dll")
file="TestimonialAndreas.MOV"
### inherit end ###

LWLibavVideoSource(file, cache=True)
AssumeFPS(22.7771998405457, true)
Trim(1438, 0)
Dither_convert_8_to_16()
SmoothLevels16(preset="pc2tv")
Dither_convert_yuv_to_rgb(output="rgb32", matrix="709", noring=true, lsb_in=True, mode=6)
### prefetch: 3, 3
### ###
deshaker("19|2|30|4|1|0|1|0|640|640|1|2|1000|1000|1000|1000|4|0|0|2|8|30|300|4|Preview_Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|15|15|5|15|1|1|30|30|0|0|0|0|1|0|0|10|1000|1|88|1|1|20|5000|100|20|1|0")
ConvertToYV12(matrix="Rec709")
### prefetch: 30, 30
### ###
""")

SourceFps=23.9759998321533
A=BlankClip(1,1,1).AudioDub(LWLibavAudioSource(file, cache=True))
Blank=BlankClip(int(A.AudioDuration*SourceFps), 4, 4, "YV12", SourceFps)
A=AudioDub(Blank, A)
A=A.Trim(1438, 0)
A=A.AssumeFPS(22.7771998405457, true)
AudioDub(last, A)


off-topic but I see you like mp_pipeline, and you know c++ as well :sly:

could you look at this? https://github.com/SAPikachu/MP_Pipeline/issues/1#issuecomment-219327119

[MysteryX]

off-topic but I see you like mp_pipeline, and you know c++ as well :sly:

could you look at this? https://github.com/SAPikachu/MP_Pipeline/issues/1#issuecomment-219327119
A bit off-topic, but MP_Pipeline is the kind of plugin that would benefit from being written in C#. C# could be very useful for utility plugins dealing with multi-threading, multi-processing and other complex task, when no assembly code or complex binary data manipulation is necessary. Now that I'm familiar with how plugins work, I'll see if I can get the .NET plugin sample to work with AviSynth+.

[real.finder]

A bit off-topic, but MP_Pipeline is the kind of plugin that would benefit from being written in C#. C# could be very useful for utility plugins dealing with multi-threading, multi-processing and other complex task, when no assembly code or complex binary data manipulation is necessary. Now that I'm familiar with how plugins work, I'll see if I can get the .NET plugin sample to work with AviSynth+.

the same Author already did http://forum.doom9.org/showthread.php?t=144663

and before mp_pipeline, if c# was a good idea for mp_pipeline then why the Author didn't do it?

[MysteryX]

Ah... even if .NET libraries are supported, they must be loaded through AvsFilterNet; not practical for the user. A better option would be for AviSynth+ to provide an interface for .NET plugins.

[feisty2]

A bit off-topic, but MP_Pipeline is the kind of plugin that would benefit from being written in C#. C# could be very useful for utility plugins dealing with multi-threading, multi-processing and other complex task, when no assembly code or complex binary data manipulation is necessary. Now that I'm familiar with how plugins work, I'll see if I can get the .NET plugin sample to work with AviSynth+.

<thread> <mutex> <atomic> <future> and stuff have been parts of C++ STL since C++11, you don't actually have to go multi-threading by calling those complex and non-portable OS APIs no more