OK, Sharc, please re-download and re-test. Getting close to goodness now. I was thinking of providing a way to dynamically change pthresh for different scenes. Something like a config file: 0: 1.5 100: 3.2 1050: 0.5 The pthresh value would change at the given frame number and remain until changed a...

Yep, the deinterlacer works now! I noticed however some chroma artefacts, see for example the red stripes near the guy's hand in bottom left corner of frames 248,260,261 of my testclip. Visible for blend=false and blend=true. I don't get these chroma artefacts - well, some others instead - with the ...

Here a testclip. It starts with a telecined segment and changes to interlaced video. http://www.mediafire.com/file/clztmro8la2wc4d/hybrid.m2ts Script: clip=DGSource("....hybrid.dgi") ivtc=clip.DGTelecide(pthresh=1.0,show=true)#.DGDecimate(cycle=5) #for testing IVTC of the telecined segment return ivtc

First quick tests with DGTelecide():
I am getting strong residual combing even though the show=true reports that the frame has been deinterlaced.
I don't get such combes with the classic telecide().

What is the valid range of pthresh? 0.0 to 1.0? (The documentation calls it "strength" btw.)

DGSource has the boolean parameter "use-pf". Is the decision about the frame type (progressive/interlaced) based on flags of the source, or does the algorithm analyse the frames and decide for combed or non-combed frames for deinterlacing (similar to DGDecomb)? How will this be with the new DGDecom...

DGSource has the boolean parameter "use-pf". Is the decision about the frame type (progressive/interlaced) based on flags of the source, or does the algorithm analyse the frames and decide for combed or non-combed frames for deinterlacing (similar to DGDecomb)? How will this be with the new DGDecomb...

Looking forward .....

This might be a dumb question, but since you're working on adding new filters, are there any prospects for replicating the functionality of Decomb this way? That's my most-used filter, and getting a CUDA speedup for it would be welcome. I'm not sure how closely related this would be to your recent ...

I thought leaving the YUY2 4:2:2 colorspace untouched would a priori eliminate certain chroma problems. For example YV12 interlaced needs to be cropped mod4 vertically, whereas YUY2 would accept mod2 cropping without chroma damage, if I am not mistaken. Maybe it's just a fart as I have to deinterlac...

My tape captures are normally YUV or YUY2, 4:2:0 or 4:2:2. Hmm, now I think to remember that lossless 4:2:2 is not supported by Nvidia ..... Script like: AviSource(xxxx.avi) #typically interlaced YUY2 4:2:2 bob() #optional Crop(....) Resize(....) #optional addborders(...) #optional ConverttoYV12() #...

Is the YV12 a CUDA/Nvidia restriction? I am asking because I try to avoid colorspace conversion to YV12 because of the Chroma upsampling and Chroma Interlace Problem.

Colorspace must be YV12 for DGDenoise() and DGSharpen(), right?

Greetings, Don DGSharpen() works fine here. Very effective in conjunction with DGDenoise(). And no, I am missing neither a bell nor a whistle for the time being ...... Just a note on the documentation: DGSource() still has the denoising parameters (strength,blend,chroma,searchw), but the explanation...

Eager to try it ......

The speed of DGDenoise makes it possible to use the NLM algo even on my relatively slow system. That's quite something! Some observations based on VHS tape sources:: For strength >0.05 the denoiser tends to smoothen low contrast areas, e.g. slightly darker grey areas on a brighter gray background ge...

The choice will be yours, of course.

The beer is on the way. QTGMC parameters: - QTGMC() #default, or QTGMC(InputType=1) for cleaning up progressive sources - QTGMC(preset="medium") #typical - QTGMC(preset ="Slow",TR2=2,Sharpness=0.8,EZDenoise=1.0,NoisePreset="Slow",ShowNoise=false,ShowSettings=false,InputType=0) #in few cases, mainly ...

The unexpected speed is making me think about porting other filters to CUDA. MV tools? QTGMC on CUDA would be phantastic 8-) That's why I mentioned mvtools. :wow: I am just about to re-encode all my tapes thanks to the speed improvement with DGDenoise. Rest assured I will test and probably redo eve...

admin wrote:The unexpected speed is making me think about porting other filters to CUDA. MV tools?

QTGMC on CUDA would be phantastic

Nice speed improvement also for Kepler with latest slipstream: from 26.91 fps to 44.43 fps
Edit: or 72fps on bobbed source.

I did some more tests with a noisy interlaced 720x576i videofile source, encoded with x264 CRF=17. The results may be specific for this type of source and my system, but here my findings: Case / filter / speed (fps) / file size (MB) 1 / none / 16.40 / 36.7 2 / --nr 1000 / 16.74 / 25.0 3 / KNLMeansCL...

Is the speed noise agnostic, or does it somehow depend on the kind and strength of the actual noise?
Anon17: Your source (colorbar) is noise free as I understand.

I set h and strength for about same quality (visual) DGDenoise has the edge :bravo: -----------------KNLMeansCL(0,2,4,4.0)-------------------------- Number of frames: 1019 Length (hh:mm:ss.ms): 00:00:40.760 Frame width: 720 Frame height: 576 Framerate: 25.000 (25/1) Colorspace: YV12 Active MT Mode: ...

Good news! I'll be happy to repeat my tests (avisynth 32bit, GT730) with the new version.

admin wrote:Thanks, gonca, default settings would provide the best comparison, so if you could do that it would be helpful.

Keep in mind that for KNLMeansCL the default for d is 1 which penalizes its speed in comparison.