Smart bob filter: DGBob() 1.6.0: Now with slow motion

[neuron2]

Lots of people use SmoothDeinterlacer() by Gunnar Thalin (ported to Avisynth by Xesdeeni). But it is very slow. So I have written my own take on smart bobbing. Like SmoothDeinterlacer(), it attempts with some success to mitigate flutter, but it is much faster than SmoothDeinterlacer().

DGBob() can also be used as a simple deinterlacer (does not create frames from fields). It can also produce a fluid 50% slow motion effect.

It supports RGB, YUY2, and YV12 color spaces.

Please get the filter from my website as linked below. You can find it under Mine/Avisynth. Source code is available there as well.

Feedback will be appreciated.

[Dark-Cracker]

very nice work as always :) smoothdeint it's a very usefull filter happy to see he have now a little brother :)i will test it as soon as possible on PAL material.

Bye

[wotef]

what does the "smart" designate over non-smart bobbing?

[neuron2]

I just described it in my journal, but I will summarize it here.

When you make a frame from a field, you have to create all the missing lines. If you simply interpolated all the missing pixels from the current field, that is a dumb bob, even if you use some fancy interpolation like cubic bsplines. :)

But if you distinguish static from moving areas of the picture, and then interpolate in moving areas, while using the previous field data for static areas, that is a smart bob.

Smart bobbing allows you to retain the original picture detail in static areas.

Really smart bobbers, such as SmoothDeinterlace() and now DGBob() also attempt to mitigate the effects of flutter, which often results from bobbing. Flutter occurs when the field alternation causes detail to be present in one field but not the next. The simplest case is a single-pixel-high horizontal line. Without anti-flutter mitigation, it will disappear in every other bobbed frame.

[sh0dan]

Absolutely brilliant!

So simple - and yet so effective! I'm looking so much forward to the YV12 version!

[neuron2]

Originally posted by sh0dan
Absolutely brilliant!

So simple - and yet so effective! I'm looking so much forward to the YV12 version! Thanks, sh0dan. Coming from you, that is really good for my ego.

Still, it's a first release. It needs a blend mode. And it can be faster with some optimization. I'm going to finish this one off before returning to Decomb 5, because I need it for my swimming videos. :)

[DDogg]

This is good news! Any special secrets or recommendations for a ntsc DV source script using this filter?

[neuron2]

Just be sure to get the field order correct. Please report on your results.

[sh0dan]

@neuron2: You could default to the fieldorder given by GetParity. This would allow users to use assumetff()/assumebff(), as with other filters.
This should also allow for clips with different field orders to be deinterlaced properly.

[mf]

Sweet! :) Now let's see how smart this one is :D. I hope it really will be- I already have some ideas :devil:.

[jorel]

Originally posted by neuron2
Thanks, sh0dan. Coming from you, that is really good for my ego.

Still, it's a first release. It needs a blend mode. And it can be faster with some optimization. I'm going to finish this one off before returning to Decomb 5, because I need it for my swimming videos. :)

oh yes,is faster(too big)!
;)

edited:
sorry, wrong words for big project!

neuron2,receive my excuses.
:o

manono, thanks for advise.
;)

[manono]

Hi jorel-

I know you sometimes have difficulty expressing yourself in English, and there's certainly no shame in that. But you have to be real careful with what you say so that it isn't taken the wrong way. To me that comment, besides adding nothing to the discussion, comes off as a completely gratuitous insult to one of the most valuable and respected members of this site. Didn't you get into trouble with some previous comments, and isn't that why you haven't been around for awhile? If you really were just joking, I'd say it was in bad taste and not at all funny. Please watch what you say in the future, unless you just don't care any more. In which case, I'm sure someone will be only too happy to put you out of your misery. Perhaps an apology is in order before it's too late.

[JohnMK]

Is it easier to program within the YUY2 colorspace than in YV12?

[sh0dan]

@JohnMK: Both have their own advantages. YV12 is "cleaner", as you don't have components mixed, whereas some operations are easier on YUY2, as you have chroma and luma at the same place.

[bilu]

Originally posted by sh0dan
@neuron2: You could default to the fieldorder given by GetParity. This would allow users to use assumetff()/assumebff(), as with other filters.
This should also allow for clips with different field orders to be deinterlaced properly.

How effective is this? Does it work nicely on both AVI and MPEG-2 sources? Does it return information on every frame or just at beginning?

What a nice contribuition to this thread (http://forum.doom9.org/showthread.php?s=&threadid=55203) it may be ( I hope ).


Bilu

[scharfis_brain]

Hello. Are there plans to build in some threshold-parameters for deinterlacing?
At this time I am not able to get comb-free videos with dgbob.
Small or low-contrast objects are not deinterlaced.
It seems, like there is a temporal mask, which needs some time to apply the new picture contents.

(Sorry, I can't describe this better with my actual english knowledge)

btw. I can't attach a Picture here :(

[neuron2]

Originally posted by JohnMK
Is it easier to program within the YUY2 colorspace than in YV12? Deinterlacing is harder in YV12 due to the vertical chroma subsampling. You can finesse that by deinterlacing the planes independently, but that is theoretically inadequate. To do it right, you have to couple the motion maps of the luma and chroma planes. All these problems don't arise for YUY2. But as sh0dan correctly points out, other applications are easier and faster in YV12.

[neuron2]

Originally posted by scharfis_brain
Hello. Are there plans to build in some threshold-parameters for deinterlacing? Sure, I can expose them to the user. I just chose hard-coded values for the first version. There are two thresholds. The first is equivalent to dthreshold in Decomb 4. It is already set very low, 4 or 5 IIRC. The more problematic one is the one that compares the pixels in the previous and following fields. If their difference is within this threshold I say the corresponding pixel in the current frame is static and I weave it. The problem is that if you make that one too low, you start losing your flutter mitigation (because normal noise variance starts making pixels get bobbed instead of weaved). I am aware of this issue and am exploring ways to better detect static areas. However, the whole reason for making DGBob() is to have a faster smart bob. I have to be careful not to lose that advantage.

[neuron2]

DGBob() version 1.1.0 is now available at my website. It greatly improves the motion detection (with no performance loss!) and thus produces much better results. The motion detection threshold is now exposed in the user interface ('thresh' parameter) to allow tweaking the tradeoff between flickering and residual combing/artifacts.

This version greatly reduces the artifacting resulting from single-field pixel changes. I'm just off to my journal to describe how it was done. I hope you all are as pleased with it as I am now. This final little finesse has made smart bobbing really viable, where previously I thought it was barely acceptable (due to the artifacting).

Next is YV12 support and a "show motion map" option, and maybe cubic interpolation and/or edge-directed interpolation for the interpolated pixels.

I don't often engage in hyperbole, but this filter kicks butt. :D

[neuron2]

I cranked out DGBob 1.2.0 over my morning coffee. It adds support for RGB and YV12 color spaces. I also described the algorithmic improvement in my website journal.

Woohoo, the only YV12 smart bob filter! :p

[len0x]

Originally posted by neuron2
Woohoo, the only YV12 smart bob filter! :p

That is soo great! :)
I've already put it in GK instead of simple bob.
(You know how much I love putting new filters in there :cool: )

[FredThompson]

Yeah, the journal entry shows what a HUGE improvement this is.

I've never hyperboled, though I have bowled drunk and in the dark...

[jorel]

:)

thank you neuron2,
after see the journal pictures
with very clear differences,
i was trying to DGBob in my .avs script with 480x480 (29,970 fps)
but give double framesrate and middle time.
with a help of sh0dan(thanks again sh0dan)
is working great in my script using
selecteven() after DGBob(0).

great work, great result!
congrats.

[sh0dan]

Did some real-life encodes. Great quality - possibly the best I've seem.

I do however still get some "marching ants" on high-contrast edges. There also appears some clear (very high contrast) ghosts. I'll PM you a link to some material.

I cannot seem to find any useable threshold as both too low and too high thresholds just make it worse.

[neuron2]

Please get version 1.2.1 from my website. It fixes a terrible bug in RGB support, which affected DV and other files.

@sh0dan

I'm downloading the clip to have a look. Thank you for it.

[neuron2]

OK, I understand the problem and know what to do about it. Standby for an improved release.

[gotaserena]

Would you recommend using this filter (+ some way of decimating) as an alternative to a do-it-all deinterlace filter?

[neuron2]

Originally posted by gotaserena
Would you recommend using this filter (+ some way of decimating) as an alternative to a do-it-all deinterlace filter? I don't know what you mean by a "do-it-all deinterlace filter". I've never seen one and I can't imagine one, so I have no way to respond to your question.

Since you refer to decimation, perhaps you are thinking of using it for inverse telecine. I do not recommend that. Field matching followed by postprocessing of combed frames will always be preferable.

[neuron2]

Version 1.3.0 is now available at my web site. It cleans up sh0dan's clip pretty well. It is not perfect but I don't think it can be. This version considers more pixels in the temporal neighborhood to further improve motion detection.

[neuron2]

I've released what I hope is the final version for a while: DGBob() 1.4.0. This version adds an optional artifact protection feature. It requires more processing and may increase flicker a bit, but it almost guarantees that no visible artifacts will be produced. It should be used only if required; most clips do not require it.

I cannot think of any ways to improve things at this point, unless some bugs are found.

[sh0dan]

Seems like a very good idea! DGBob is way better that anything else by now - so it seems like a good idea to get it into decomb now - I'm looking very much forward to a 5.0 final - even though I guess there is still a long way to go.

Keep up the great work!

Edit:
Could you make a big, bold statement saying: "DGBob DOUBLES the framerate of your video!" - I've already seen several "problems" related to that. Possibly you could also put in there, what selecteven() does. ;)

[neuron2]

Originally posted by sh0dan
Could you make a big, bold statement saying: "DGBob DOUBLES the framerate of your video!" - I've already seen several "problems" related to that. Possibly you could also put in there, what selecteven() does. ;) ROTFL.

Better yet, how about an option to produce non-doubled output? I could do it, but I already have in mind a new straight deinterlacer. But if it would prevent confusion...

[neuron2]

DGBob() 1.5.0 is released at my website. It adds non-doubled frame rate output.

Hey sh0dan, less than half an hour to do that, including updating my web site. :p

[gotaserena]

Thanks sh0dan, and neuron2 for the prompt implementation.

[jorel]

yes,i'm thankfull to neuron2 and sh0dan for this all too.

with the new DGBob1.5.0 don't need to use
selecteven()!

uding
DGBob(x,true)
runs fantastic without give double framesrate and middle time.

[sh0dan]

No need to thank me on this one - the D.G. Master of Digital Downright Deinterlacing Code has shown his mastery face once again! (sorry - the sentence above just flipped into my mind somehow ;) )

Anyway - DGBob is a very good contester for a FieldDeinterlace() replacement. However - even though it gives the best "smart bobbing" available, there is still the flickering issue that should get solved, if it can be considered to be a 100% replacement.

But for a "proof of concept" DGBob rocks!

[neuron2]

Originally posted by sh0dan
there is still the flickering issue that should get solved, if it can be considered to be a 100% replacement. Which issue is this? Are you talking about the marching ants or something else? Can you please provide a test clip? Thank you.

[sh0dan]

If you use the latter part of the testclip I sent you, you should be able to reproduce - notice the outline of the static text. I get flicker - even with the latest version.

It's a great filter - and for what it does I don't expect it to do miracles - I have though about the possibility of doing a "bob-postprocessing" filter, that was able to detect this flicker and elimiate it.

(But please ignore me, and get back on the decomb - it's much more important than this - DGBob is already a big step forward!)

[neuron2]

I noticed that, but the video content is changing underneath the edges of the letters in some places. I'm not sure what I can do about it. Anway, let me finish up Decomb 5 first and see if I have an unconscious brainstorm about this.

[ADLANCAS]

Do you recommend use Dgbob with interlaced sources ?

I have a script that produces much better results with Dgbob than SeparateFields(), SelectOdd()/SelectEven() and a noise filter.
Script is here:

http://forum.doom9.org/showthread.php?s=&threadid=55607&perpage=20&pagenumber=2

Thanks,

Alexandre

[neuron2]

Originally posted by ADLANCAS
Do you recommend use Dgbob with interlaced sources ?
Well, there's not much point to using it with progressive sources. :)

If you meant as a deinterlacer that retains the input frame rate, all I can say is that it was designed and optimized for double rate output. If it works well for you in single-rate mode, I am happy.

[ADLANCAS]

Maybe I was not so clear (or I don't understand what you mean).
I intend only to produce SVCD(NTSC) with VHS sources from my handy camera.
My script is basically (YUY2):
AviSource("D:\Teste\AVS\VHS.avi")
dgbob(1)
Convolution3d(0,12,24,8,8,3,0)
BicubicResize(480,480,0,0.6)
separatefields()
selectevery(4,0,3)
Weave()

I'd be glad if you comment it and propose another way to make it faster(if there is).
As I said, It seems to me a big better difference to use dgbob than I described in the last post.
I know that there are many ways to do the same thing. I know only two of them. As I'm not expert in avisynth and handly video files and you are, maybe you could give some more ideas that I can have opportunity to test them and decide what's better to me.

Thanks

Alexandre

[FredThompson]

What he's saying is the bob routines are not designed to produce progressive images at the same frame rate as the source. They produce twice the frame rate. If you feed it 25 fps of interlaced, it returns 50.

If you use a bob to deinterlace by throwing away half of the generated frames, you'll get the original frame rate but the quality will not be as good as a proper deinterlacing routine which is designed to keep the source frame rate.

[neuron2]

Originally posted by ADLANCAS
Maybe I was not so clear (or I don't understand what you mean).
I intend only to produce SVCD(NTSC) with VHS sources from my handy camera. I'm no expert on SVCD, but doesn't it support interlacing? If so, you're better off keeping things interlaced, as long as your target display device is a TV.

My script is basically (YUY2):
AviSource("D:\Teste\AVS\VHS.avi")
dgbob(1)
Convolution3d(0,12,24,8,8,3,0)
BicubicResize(480,480,0,0.6)
separatefields()
selectevery(4,0,3)
Weave()Why not just:

dgbob(order=1,single=true)
Convolution3d(0,12,24,8,8,3,0)
BicubicResize(480,480,0,0.6)

I'm also no expert on Convolution3d() so I may be missing something.

Note I'm not saying DGBob() is bad for single-rate output; rather I only say that it is designed and optimized for double-rate.

[ADLANCAS]

I'll try it.
Thanks

Alexandre

[FredThompson]

Originally posted by Bach
The problem is: spatial filtering must be done with progressive frames, otherwise you will have screwed up interlaced pictures. Could he use separatefields.filter? Nope, because the temporal filtering would also be screwed.Why? I've done exactly this and don't see any problems. Admittedly, my source is very high quality to begin with. The intent was to stop some of the pixel bouncing inherent in camcorder source. Even if the camcorder is on a tripod, a "static" background tends to have a lot of motion. Filtering out false motion without wiping out details would yield a heck of a gain for some source.

[FredThompson]

Nice explanation.

I should have been more explicit.

Why the statement that SeparateFields() will screw up temporal filtering?

[FredThompson]

Hmmmm....that makes sense.

After bobbing, 50% of the pixels are synthesized as a "best guess." Wouldn't that also tend to distort the temporal analysis?

Guess what's really needed is for the filters to account for interlacing.

[FredThompson]

Correct me if I'm wrong:

Convolution3D and Guave Comb are not compatible with AviSynth 2.5x, right? That leaves FluxSmooth for 3D cleaning with AviSynth 2.5x.

If the source is bobbed, then cleaned, the cut back to normal frame rate, FluxSmooth won't be doing a proper temporal analysis because it looks at the current frame and one frame in either direction.

With bobbing, those "either direction" frames would have only half the influence of the true following frame, right?

Wouldn't that tend to weaken the temporal analysis because the values of those frames are 50% directly attributable to the frame we're trying to clean?

Are we not then making it quite likely the noise will remain becaue FluxSmooth will falsely assign a higher probability the tested pixel is correct? because the error would propogate in both directions?

[gotaserena]

In http://www.avisynth.org/~warpenterprises/ there are two versions of Convolution3D for AVISynth 2.5, one being YV12 -- which I have been using for some months now.

And there's also Deen() but I guess this is straying too much.

[FredThompson]

The change log in those files is old.

This is the most recent I can find: http://hellninjacommando.com/con3d/beta/readme.html and it says no temporal support.

Here is vlad59's thread about Convolution3D and AviSynth 2.5: http://forum.doom9.org/showthread.php?s=&threadid=38281

It wants a progressive source. I think Bach is correct about the use of dgbob. I wonder if a more accurate way is to split the source by field, filter, then reassemble the fields. That would also be more difficult.

[bilu]

@neuron2 or trbarry

TomsMoComp(1,x,0) and DGBob(order=1,single=true) are for the same streams?

Is there a criteria to choose between them?


Bilu

[neuron2]

Originally posted by bilu
TomsMoComp(1,x,0) and DGBob(order=1,single=true) are for the same streams? DGBob() is designed and optimized for double-rate output. The single-rate mode was easy to add and someone wanted it, so I made it.

I don't think TMC does double-rate, yet. As for choosing between them for single-rate output, TMC may get the nod due to its speed and its attempt to reduce jaggies with EDI. I am not entirely happy with the EDI implementation, however, I suspect it can cause as much or more damage than good. I am currently researching this area.

[gotaserena]

trbarry mentions in the TMC's readme file that it works as a smarter bob when the "SearchEffort" parameter is set to "0". But it doesn't give double rate output, as opposed to DGBob().

@neuron2: is "SearchEffort" algorithm in TMC's the "EDI implementation" you refer to? What "EDI" stands for, if I might ask?

[zeus163]

I decided to give this a whirl since I'm still trying to learn the ropes of scripting. I wrote a basic script that seemed to work (gathered from reading this thread), however, I tried this one based on input from this thread. It opens fine in Virtual Dub, but CCE tells me that the framerate isn't supported. I'm not sure why I'm getting this error, but this is my script. Any advice would be appreciated it:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\dgbob.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MPEG2Dec3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\convolution3d.dll")
Avisource("E:\avis to work on\new pornographers\new pornographers letterman.avi")
dgbob(order=1,single=true)
Convolution3d(0,12,24,8,8,3,0)
BicubicResize(704,440)
AddBorders(8,20,8,20)
separatefields()
selectevery(4,0,3)
Weave()
AddAudio()
Of course, I'm probably missing something or just not quite understanding a simple concept (this is entirely plausible!).

thanks for everyone's hard work.

[trbarry]

From the other recent thread, EDI is Edge Directed Interpolation. I briefly tried to go through the math of this but came to the conclusion that I didn't really understand how they were doing it. But it was not the same as my ELA, Edge directed Line Averaging, which I got from a different paper.

What I called a "Smarter Bob" was still just ELA, a fancier way to get better info from a single frame. The other half of the algoritm when SE > 0 is a motion compensated deinterlace. This also looks at data from adjacent frames. The SE parm determines how much work it expends doing a motion search. But we've found that SE > 5 also let's through additional artifacts, so usually just use 5.

So generally there is a bit of confusion about terminology between our various deinterlacers.

- Tom

[ADLANCAS]

@zeus163

you could remove "single=true" in your script,
or if you like to use this option, then don´t use:
#separatefields()
#selectevery(4,0,3)
#Weave()

I think it´ll work.

Alexandre

[zeus163]

Thanks! Actually the one I'm encoding right now omits those lines. So, in actuallity it's doing what I think will work right now.

Cool and thanks!

[neuron2]

You sound pretty confident about it there, Mister. :)

So I had a look and.....you're right!

I broke it when I added single-rate support over my morning coffee. :o

Please get version 1.5.1 at the usual place. Thank you for bringing this to my attention. The changes were so minor that I didn't think any testing was needed. :rolleyes:

[neuron2]

Originally posted by Bach
this is the fastest bugfix ever seen:). It could have been faster except for the time spent developing a script to test your assertion:

LoadPlugin("..\release\dgbob.dll")
blackness(200,fps=29.97)
converttoYUY2()
assumetff.separatefields
showframenumber
weave
dgbob(order=1,thresh=0)

[FredThompson]

The parameter "thresh" is described in the readme as being an integer. What size? I'm guessing 1 byte so the values are 0-255, correct?

[neuron2]

It has signed integer range. Values below 0 and above ~50 are unlikely to be of much use.

[jarthel]

is this filter a better substitute to fielddeinterlace (from decomb)?

Thanks

jayel

[neuron2]

Originally posted by jarthel
is this filter a better substitute to fielddeinterlace (from decomb)? That depends upon your application and aesthetic tastes.

[neuron2]

I've added a new mode to DGBob(). It produces double the number of input frames (frames from fields), but sets the final frame rate to the original frame rate. This produces a 50% slow motion effect.

Note that the syntax has changed, so please refer to the help file.

http://shelob.mordor.net/dgraft/dgbob/dgbob.html

[IanB]

Don,

DGBob() rocks :)

<<wrong thinking deleted>>

IanB

[bachopin]

I've been using fieldeinterlace() from the decomb.dll for
quite a long time. It was a great help
and never let me down while working with pure PAL intarlaced material.
And now I just noticed this new filter and I wonder what's are
the main differences between the two, or simply put,
can I achive maybe even better results with this new filter ?

Thank you ver much in advance

Regards
Peter

[cheap-red-wine]

You may find that DGBob() damages static logos, etc., less than FieldDeinterlace(). But DGBob() lacks some features of FD. So, as mentioned in this thread, it all depends upon your application and aesthetic tastes. Only you can decide which is preferable.

You might also look at KernelDeint(), which is another new deinterlacer from neuron2.

[morsa]

I really like its slow motion mode.But there is an old and awfull problem: Marching ants.

[FredThompson]

You know, I saw that junk on my parents' cable feed last week. Drove me nuts and now I have to figure out how to remove it from the tapes I made on their system. (Why can't old people just get DirecTiVos?)

Richard Berg released AviSynth 2.5 versions of some filters including Guava Comb just recently. Maybe that will help.

Sure would be nice to see a filter called Raid to take care of marching ants. (For those who don't know, Raid is the name of an American bug spray, the byline is kills bugs dead.)

[MacAddict]

Sorry to drag up this old thread but I just had to say thanks again Don for brilliant work. Majority of my bobbing projects still seem to be smoother using DGBob compared to newer smart bobs for whatever reason. Any chance of an optimized SSE2 version in the future? I know your busy with other projects but I couldn't resist the question :-)

[scharfis_brain]

please forget about dgbob().

it is very outdated now. TDeint() or Leakkernelbob() will give you much better results

[MacAddict]

I know it's very dated but on certain field blended movies I find it still gives me the smoother panning motion. I'm currently looking at TFM and TDeint options though and trying to adapt the parameters for this type of material. The number of options are quiet overwhelming...but nice :-)

[CrAcKo]

I was looking for a way to add slow motion effect to my video clips, I found Smart Bob, but I don't really know how to use it in VirtualDub. VD is pretty much the only thing I use, next to nandub.

Can someone explain how this exactly works? The description on Neuron's site said I had to set the fps to the input's fps somewhere in the AVI Header? I really don't understand...

[Richard Berg]

You'll be much better off with motion compensation. Do a search on this forum for MotionProtectedFPS or MvFPS.

[CrAcKo]

Looks like both MotionProtectedFPS and MvFPS involves Avisynth. I'm not familiar with avisynth at all.

[Adub]

I suggest that you become familiar with it. It is the best free editor in the world! Not kidding!
Avisynth really is your number 1 option for what you are trying to do. There are numerous plugins that have to do with slow motion in video. And the great thing is that VDub fully supports it!
If you need help, surf the forum, or go to the main website and check out the tutorials. Plus every plugin comes with it's own explanation of every function.
Sorry I could not be of more help.
Good luck!

[CrAcKo]

Thank you all very much.

I'll explore the forums when I got enough time for it.

- CrAcKo