DGDecomb
Re: DGDecomb
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.
While I wait for your sample I'll do some comparisons on the streams I have.
Re: DGDecomb
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?
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?
Re: DGDecomb
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)
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)
Re: DGDecomb
Downloading now...
Re: DGDecomb
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.
Re: DGDecomb
OK, all fixed and uploaded. Thanks for pointing it out, Sharc.
Re: DGDecomb
Confirmed. The combing artefacts are gone now. Thanks for the new filter.
Re: DGDecomb
You're welcome. I'd be lost without you guys.
![Bow down :bow:](./images/smilies/icon_bow_down.gif)
![Bow down :bow:](./images/smilies/icon_bow_down.gif)
Re: DGDecomb
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
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
I really do like it here.
Re: DGDecomb
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.
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.
Re: DGDecomb
Yep, portable Vapoursynth is great, but let's say it's a tad less than ideal in this caseadmin 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.
![Smile :)](./images/smilies/icon_e_smile.gif)
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
![Smile :)](./images/smilies/icon_e_smile.gif)
edit 1: your suggestion has been made at https://forum.doom9.org/showthread.php? ... ost1806315
edit 2: The answer was no. Oh well.
I really do like it here.
Re: DGDecomb
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.
Re: DGDecomb
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() ?
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() ?
Re: DGDecomb
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?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.
Yes, with two caveats: 1) for TFF it's selecteven, for BFF it's selectodd(), 2) mode=0 will be faster.Is DGBob(mode=0) equivalent to DGBob(mode=1).selecteven() ?
Re: DGDecomb
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?
Camera pan of static objects, yes.Is it the static areas you are talking about?
Hmmm, I don't know. Maybe I should do less pixel peeping ...I could add that to DGBob to get the best of both worlds if you think it would be useful.
![Geek :geek:](./images/smilies/icon_e_geek.gif)
Re: DGDecomb
Yes. I'll run some tests to see if I can see it too.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?
Re: DGDecomb
If you don't see the difference I could upload a sample where the difference (jaggies) is obvious.admin wrote:Yes. I'll run some tests to see if I can see it too.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?
Re: DGDecomb
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?
Re: DGDecomb
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.
Anyway, DGBob is very good and looks very much the same (almost identical) as yadifmod2.
Re: DGDecomb
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.
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.
Re: DGDecomb
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)? ![Question :?:](./images/smilies/icon_question.gif)
![Wink ;)](./images/smilies/icon_e_wink.gif)
![Question :?:](./images/smilies/icon_question.gif)
Re: DGDecomb
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!![Crying or Very Sad :cry:](./images/smilies/icon_cry.gif)
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!
![Crying or Very Sad :cry:](./images/smilies/icon_cry.gif)
Re: DGDecomb
Good things are worth waiting for ![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Re: DGDecomb
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.
Re: DGDecomb
Relax and focus on something fun, like your paper on quantum physics about Bell's inequality ![Wink ;)](./images/smilies/icon_e_wink.gif)
![Wink ;)](./images/smilies/icon_e_wink.gif)