clip_limited = vs_clip_chroma_stabilizer(clip, deviation=deviation)
for i in range(1, max_steps):
clip_limited=vs_clip_chroma_stabilizer(clip_limited, deviation=deviation)
# calculate motion mask
org = clip
clipMask = clip
clipMask = clipMask.resize.Bicubic(format=vs.GRAY8, matrix_s="470bg", range_s="limited")
clipMask = vs.core.motionmask.MotionMask(clip=clipMask, th1=tht, th2=tht, tht=tht) # pixels with abs(diff) < tht will be black (static parts)
clipMask = vs.core.std.InvertMask(clip=clipMask) # invert so that static parts are white (weight=1)
# merge in YUV color space
clipMask = clipMask.resize.Bicubic(format=vs.YUV444PS, matrix_s="470bg", range_s="limited")
clip_limited = clip_limited.resize.Bicubic(format=vs.YUV444PS, matrix_s="470bg", range_s="limited")
clip = clip.resize.Bicubic(format=vs.YUV444PS, matrix_s="470bg", range_s="limited")
clip = vs.core.std.MaskedMerge(clipa=clip, clipb=clip_limited, mask=clipMask) # MotionMask
# restore RBG24 color space
clip = clip.resize.Bicubic(format=vs.RGB24, matrix_in_s="709", range_s="limited", dither_type="error_diffusion")
clipMask = clipMask.resize.Bicubic(format=vs.RGB24, matrix_in_s="709", range_s="limited", dither_type="error_diffusion")
org = org.resize.Bicubic(format=vs.RGB24, matrix_in_s="709", range_s="limited", dither_type="error_diffusion")
I confirm you, that this filter is flawd. As been written (or tested) to work in an narrow range of "tht=10"
Here the mask with tht=10:
Here the inverted mask:
If I increase "tht" the inverted mask becomes "white", this is not what I want. The expectation is that by increasing "tht" the moving parts will be considered "static", but the filter is unable to get this result.
It is not clear the reason of such difference in speed, but being a "temporal" filter, it is penalized if applied with other filters in the same pipeline.
I don't know if you are able to observe the same decrease in speed, but if so, It could be worth making available in Hybrid, as a post-post process filter also "dd_video_stabilizer".
I agree that calling:
1. ddeoldify
and then
2. dd_video_stabilizer does make sense
does seem like better approach.
I'm really reluctant to add dd_video_stabilizer since, it's the whole thing gets more and more unusable.
This would add another 14+ ui elements,...
Would it make sense to remove color_stabilizer, color_limiter from ddeoldify
(this would remove the possiblity to use color_stabilizer for ddeoldiy and ddcolor separately) and then call
1. ddeoldify(..)
and then
2. dd_video_stabilizer(..) in case color_stabilizer, color_limiter or color_smoothing is enabled
?
Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
The more conservative approach is to don't touch the GUI, but in the case is enabled "color_limiter" it can be run separately using dd_video_stabilizer(..) after ddeoldify(..).
For the moment is better enable this separate process only for "color_limiter".
I'm still working on a Vapoursynth version "color_stabilizer" which is not introducing gray frames.
In the case I will be able to find a working solution, it would be better run this version of filter separately like "color_limiter" because is a temporal filter.
The GUI It's more rational, I like it.
Also the speed is good.
Thanks,
Dan
In the next days I will release a new version (only to you), where I will clean up the ddeoldify filter, by removing the post process filters and probably will rename "dd_video_stabilizer" in "ddeoldify_stabilizer".