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

[Guest]

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?

[Guest]

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!

[Guest]

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?

[Guest]

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 :(

[Guest]

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.

[Guest]

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.

[Guest]

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

[Guest]

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.

[Guest]

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.

[Guest]

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?

[Guest]

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.

[Guest]

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.

[Guest]

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. ;)

[Guest]

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...

[Guest]

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!

[Guest]

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!)

[Guest]

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

[Guest]

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.

[Guest]

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.