Support forum for DG Tools

Please provide a sample video and script and I'll be happy to look into it. Let me know which frame(s) to focus on.

While I wait for your sample I'll do some comparisons on the streams I have.

I cannot detect any difference using this script:

loadplugin("dgdecodenv.dll")
loadplugin("yadifmod2.dll")
v=dgsource("Cityscape.dgi")
y=v.yadifmod2(order=1,mode=1)
d=v.dgbob(order=1,mode=1)
subtract(y,d) # then Levels in VirtualDub to amplify differences

So I really need your sample. Was it yadifmod2 you were comparing to?

My source:
http://www.mediafire.com/file/qex686cvd ... ob_test.ts

The script (both plugins are autoloaded):
clip=DGSource("c:\DGBob_test.dgi")
bob1=clip.yadifmod2(mode=1,order=1).subtitle("yadifmod2")
bob2=clip.DGbob(order=1,mode=1).subtitle("DGBob")
Return interleave(bob1,bob2)

Downloading now...

OK, I know what is going on. I will fix it. After it is fixed, you may see DGBob having less residual combing due to the small bug in yadifmod2 that I mentioned.

OK, all fixed and uploaded. Thanks for pointing it out, Sharc.

Confirmed. The combing artefacts are gone now. Thanks for the new filter.

You're welcome. I'd be lost without you guys.

Just checking -

In order to add to thread https://forum.doom9.org/showthread.php? ... ost1801677 seeking to update the filter list into Vapoursynth so that VS can successfully seek and return the right number of frames forward/back, is this correct (in particular dgbob which I'm not sure is temporal) ?

filter name, frames (forward and back, or current frame) they need as input to produce one frame of output
DGSource(), 1 = current
DGDenoise(), 1 = current
DGSharpen(), 1 = current
DGTelecide(), 1 = current
DGDecimate(), 1 = current
DGBob(), previous, current, next (per http://avisynth.nl/index.php/Yadif ? "It check pixels of previous, current and next frames to re-create the missed field by some local adaptive method ")


edit: ah, the history, https://forum.doom9.org/showthread.php? ... post332363

Great question, hydra3333. You're right that DGBob needs previous, current, and next, so it has temporal processing. Here's the list.

Each GetFrame() call requests these frames:

DGSource(): current only
DGDenoise(): current only
DGSharpen(): current only
DGTelecide(): always previous + current
DGDecimate(): up to (cycle size + 2) number of previous + current
DGBob(): always previous + current + next

Isn't something seriously wrong with Vapoursynth if this has to be hard-coded in the core? DGDecimate() at script run time cannot tell the Vapoursynth core at its compile time what the cycle size is going to be, and if Vapoursynth always assumes some maximum it is going to over-request frames.

admin wrote:Isn't something seriously wrong with Vapoursynth if this has to be hard-coded in the core? DGDecimate() at script run time cannot tell the Vapoursynth core at its compile time what the cycle size is going to be, and if Vapoursynth always assumes some maximum it is going to over-request frames.

Yep, portable Vapoursynth is great, but let's say it's a tad less than ideal in this case

I suppose an arbitrary large default number of frames will have to do for DGDecimate and "it is going to over-request frames".

... wouldn't it be nice if it were configurable at script startup from a .ini text file of defaults in the vapoursynth folder (with a default file provided with vapoursynth) ... and then a new function available to over-ride with say ["function_name", number_before, number after] if such a thing were possible. Of course, I reckon you have suggested this before

edit 1: your suggestion has been made at https://forum.doom9.org/showthread.php? ... ost1806315

edit 2: The answer was no. Oh well.

Here's another stupidity with the VS prefetch nonsense. DGBob (and yadifmod2 and probably others) can specify either single-rate or double-rate deinterlacing by a parameter. The PREFETCH parameters would need to be different for these two and I don't see how to set that at VS compile time.

DGTelecide vs DGBob for single-rate deinterlacing:
DGBob produces significantly less jaggies (e.g. on nearly horizontal lines), but the picture seems to be a bit softer (loss of details) compared to DGTelecide. Is this observation basically correct? Is DGBob(mode=0) equivalent to DGBob(mode=1).selecteven() ?

Sharc wrote: DGBob produces significantly less jaggies (e.g. on nearly horizontal lines), but the picture seems to be a bit softer (loss of details) compared to DGTelecide.

DGBob (and yadif variants) deinterlaces the entirety of all frames without any checks, while DGTelecide uses a threshold to try to spare static areas of the frame. I could add that to DGBob to get the best of both worlds if you think it would be useful. Is it the static areas you are talking about?

Is DGBob(mode=0) equivalent to DGBob(mode=1).selecteven() ?

Yes, with two caveats: 1) for TFF it's selecteven, for BFF it's selectodd(), 2) mode=0 will be faster.

DGBob (and yadif variants) deinterlaces the entirety of all frames without any checks, while DGTelecide uses a threshold to try to spare static areas of the frame.

I compared DGBob(mode=0) with DGTelecide(mode=2,pthresh=0.0,dthresh=0.0). Doesn't DGTelecide in this case deinterlace the entirety of the frames unconditionally?

Is it the static areas you are talking about?

Camera pan of static objects, yes.

I could add that to DGBob to get the best of both worlds if you think it would be useful.

Hmmm, I don't know. Maybe I should do less pixel peeping ...

Sharc wrote: I compared DGBob(mode=0) with DGTelecide(mode=2,pthresh=0.0,dthresh=0.0). Doesn't DGTelecide in this case deinterlace the entirety of the frames unconditionally?

Yes. I'll run some tests to see if I can see it too.

admin wrote:

Sharc wrote: I compared DGBob(mode=0) with DGTelecide(mode=2,pthresh=0.0,dthresh=0.0). Doesn't DGTelecide in this case deinterlace the entirety of the frames unconditionally?

Yes. I'll run some tests to see if I can see it too.

If you don't see the difference I could upload a sample where the difference (jaggies) is obvious.

The reduction of jaggniness is easy to see. I was referring to your claim that DGBob is softer. Do you have a clip showing that?

I have to check again regarding softening/loss of details. It could be that the jaggies/pixels of DGTelecide left me with the impression of more details/sharpness. I need to find a better interlaced source .....
Anyway, DGBob is very good and looks very much the same (almost identical) as yadifmod2.

DGBob() and yadifmod2() both implement Niedermayer's original concept so it is not surprising. There is one small difference in that yadifmod2() has a small bug in the spatial check. It's not clear how often it is triggered in practice.

The Niedermayer algorithm is an instance of width 7 ELA. Better results can be obtained with a wider kernel, so I am thinking of experimenting with a width 9 or 11 ELA. The challenge is to modify the spatial sanity check in an effective way. I suppose it is only performance issues that limited things to width 7 in the past.

Well, its obvious you are at it, 5 filters and counting, but if you think its worth it and you have a couple of minutes to spare , would you consider resizing filter(s)?

Sure, I'll consider anything. Actually, resizing is ideal for CUDA.

Caveat: I have to write a physics paper for a special issue on Bell's inequality, so I will likely not be able to do much coding for a few months. Also, the nVidia Video SDK 8 is out so I have to modify DGDecNV to deliver high bit depth. Oy, then add high-bit-depth to all the CUDA filters!

Good things are worth waiting for

Damned host is screwed up again. Losing packets all over the place. I cannot get files from FTP, etc. This is it. After I finish my paper I'm changing hosts.

Relax and focus on something fun, like your paper on quantum physics about Bell's inequality