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

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

[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

[Guest]

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!

[Guest]

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.

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.

[Guest]

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)