DGDecomb

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
Post Reply
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

I've decided on a design for this filter.

First, I run an edge detector that produces a map of edges and their directions. Taking 12 o'clock on the clock face as 0 degrees, 3 o'clock as 90 degrees, and 6 o'clock as 180 degrees, then, as we sweep from 0 to 180 degrees, the directional value sweeps from 255 to 0. I have already tested a filter that does this (CPU at this time). Next, when I recreate a pixel to be interpolated during bobbing, if it is an edge pixel, I use the directional value to direct which pixels get used. As the angle gets closer to horizontal we have m increasing in:

dstp[x] = (srcpp[x + m] + srcpn[x - m]) / 2;

For non-edge pixels, m is 0. I have tested this with angled lines and fixed m's. Aliasing is entirely eliminated. Now, we have to combine the two mechanisms, so that each pixel gets interpolated according to its associated edge direction. I have to keep the signs straight for all four quadrants of the circle. We have to limit m to some reasonable maximum to keep the processing local (we don't want to be averaging pixels from the two extreme edges of the image!). A maximum of 8 seems like a good starting point.

This is reminiscent of Faroudja's DCDi algorithm. It's impossible to know how close they really are, because DCDi is proprietary. However, my approach is well-described by the Faroudja marketing hype. ;)

This should be very fast when implemented with CUDA kernels (and even on the CPU), but first, I will get it working on the CPU. Debugging is much easier on the CPU.

I am using QTGMC as a gold standard for quality. One little problem I have run into on TheBeast is that, inexplicably, the RemoveGrainSSE2/3 DLLs will not load on Win10. They load on Win8.1, and all the other QTGMC DLLs load fine on Win10. So I had to use RemoveGrainS.dll, which may slow down QTGMC a little. No big deal as I use it for a quality benchmark only. If anyone can enlighten me about this, I'd be grateful.

On another matter, I discovered serendipitously that with Avisynth+ there is no need for the Avisynth 32/64 switch I have been using. Both are supported at once and you only need to use the correct 32/64 bit DLLs in your script and then load into VirtualDub 32 or 64. That switching stuff was a pain in the butt so I am happy to see it go away.

Finally, I am thinking of upgrading my hosting to a VPS, as I have noticed periods of poor responsiveness on the shared server.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

admin wrote:I am using QTGMC as a gold standard for quality. One little problem I have run into on TheBeast is that, inexplicably, the RemoveGrainSSE2/3 DLLs will not load on Win10. They load on Win8.1, and all the other QTGMC DLLs load fine on Win10. So I had to use RemoveGrainS.dll, which may slow down QTGMC a little. No big deal as I use it for a quality benchmark only. If anyone can enlighten me about this, I'd be grateful.
Strange. I have no problem here with RemoveGrainSSE2 on Avisynth 2.6 and Win10.
However, I've got another oddity since recently (last W10 update?): Whenever I browse a folder with an .m2v file in it, the MS file explorer just closes (exits) silently within a second :shock:
DAE avatar
Guest

Re: DGDecomb

Post by Guest »

Formerly used RemoveGrainSSE2 and AviSynth 2.6 on Win10 as well.
Use DGDenoise now
DAE avatar
Guest

Re: DGDecomb

Post by Guest »

Last night I ran a few tests on the new capabilities of DGDecomb with a variety of samples.
The map and show functions are quite handy, I must say.
The results were real good, actually they were very good :bravo:
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

@Sharc

I wonder if it is specific to Avisynth+. I will try Avisynth 2.6.

@gonca

Well, mode=2 is OK, but as a general-purpose deinterlacer we can do much better to avoid aliasing. You just wait and see. ;)

Initial tests of combining the edge map with directional interpolation are promising. I need to dilate the edge map as sometimes a point to be interpolated doesn't realize it is an edge because the edge map is not exactly aligned. No big deal. To be honest, my edge detector is a bit quick-and-dirty and I'll revisit it at an appropriate time. The key right now is to get the combined mechanism working.

Interestingly, I had the idea to, instead of interpolate at an angle, just slide the previous line value over by the offset. So, instead of:

dstp[x] = (srcpp[x-m] + srcpn[x+m]) / 2;

just do:

dstp[x] = srcpp[x-m];

It works very well and is faster. You can think of it as a poor man's motion compensation. The edge direction implicitly defines a shift. Of course, it is done only on edges.
DAE avatar
Guest

Re: DGDecomb

Post by Guest »

we can do much better to avoid aliasing.
I have no doubt you can
You just wait and see.
I'll wait with bells on :D
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

New GPU DGTelecide() vs legacy CPU Telecide():

I made some tests with the GPU and CPU versions and -- after trying to align the vthresh and pthresh values respectively for obtaining about "similar sensitivity" -- I found that there seem to exist significant differences regarding field matching and post processing (deinterlacing decision). I concluded that the metrics of the two version are probably quite different. Could this be true?
In a way I found the old telecide() more reliable or more "robust", but this may depend on the particular source. I need to do more testing, I think ....
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Hi Sharc.

Yes, there are some differences that I made for speed (the field match and combing tests are not windowed). My limited testing did not show any problems with it, but it was not as extensive as your testing. I could offer a "quality" option that fully emulates the original Decomb. Can you supply a clip(s) that demonstrate the differences you see? That would help me a lot.

Thank you for your testing.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Here the .zip containing
- the source (.avi)
- the index file (.dgi)
- my script (.avs)

I added my observations at the end of the script.

http://www.mediafire.com/file/c2336ggwe ... arison.zip

Thanks for looking at it.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Thank you, Sharc. I'll get on it today.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

You were able to index an AVI with DGDecNV? AVI is not supported. Maybe it manages to ignore the AVI container data. I will try it and also try with AVISource to see if there are any differences. I assume you are aware that you can use the DG CUDA filters without DGSource().
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Yes, to my surprise I could index the .avi (avc in avi).
I do normally use AVISource for .avi containers. It's just that whenever possible I prefer to create an index file to avoid directshowsource.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Wow, that's amazing that the AVI goes through. I'll play around with that later. Maybe I can say it is supported. ;)

Regarding your findings, here is my analysis.

Issue 1: Obvious bad matches with DGTelecide.

This due to pathological field jumps in the top fields, which do not occur in the bottom fields (at least for this sample stream). A one-field jump is effectively an orphan with no valid match. DGTelecide chooses the top field and then matches bottom fields, while Telecide() chooses bottom fields and matches top fields. That is why Telecide() avoids it. But it is just lucky because the jumps could have been in the bottom fields. To show this, run this script and you will see that Telecide() would have the same problem if it were in the bottom fields.

clip=DGSource("sample3.dgi").assumetff()
clip=clip.separatefields().trim(1,-0).weave.assumebff() #swap fields
e=clip.separatefields.selecteven
o=clip.separatefields.selectodd
split=stackvertical(e,o)
matched=clip.telecide(post=0,vthresh=60,blend=false,show=true)
stackhorizontal(split,matched)

Look at 50-52 (no decimate or postprocessing here) and you will see Telecide have the same problem. Setting post=1 does not catch it, nor does DGTelecide with the pthresh I use below. So it's not clear what can be done about this. BTW, the reason I choose the top field is that it enables me to get the same results by comparing only two field pairs, whereas Telecide compares three. It's technical; I could explain it in detail if you are interested.

Issue 2: Apparent shift at frame 221.

This is not a bug but a consequence of the way DGTelecide does TF matching while Telecide does BF matching.

Issue 3: Differing amounts of deinterlaced frames.

Here, your pthresh is set too low. Setting pthresh=6.7 makes things comparable.

BTW: guide=1 does not appear to contribute anything at all for this clip. DGTelecide does not support pattern guidance.

BTW2: That was very cool the way you set up the side-by-side compare. I hope you like my refinement of your idea where I show the split fields on the left and the matched frame on the right. It helps to see right away the cause of bad frames.

BTW3: Your ConvertToYV12 is not needed.

Please let me know your reaction, and feel free to post any more clips.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Wow! Thanks a bunch for the analysis and the explanations with the educational script! I think I got it.
I should have remembered the problem with field shifts/orphaned fields, but apparently I was mislead by my wrong interpretation that Telecine had "fixed" the issue. Your explanation made it very clear as to where the difference comes from. Thanks again :bow:
DAE avatar
Aleron Ives
Posts: 126
Joined: Fri May 31, 2013 8:36 pm

Re: DGDecomb

Post by Aleron Ives »

admin wrote:DGTelecide does not support pattern guidance.
Is that because it would be too slow? I usually enable pattern guidance on Telecide when I know the material is of a particular type. It seems like a worthy option to keep, IMO.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Aleron Ives wrote:
admin wrote:DGTelecide does not support pattern guidance.
Is that because it would be too slow? I usually enable pattern guidance on Telecide when I know the material is of a particular type. It seems like a worthy option to keep, IMO.
Good afternoon, Aleron.

It wouldn't be too slow. I just haven't implemented it. Do you have a clip that clearly shows its advantage?
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Hi Donald
I made another strange observation, this time with DGDecimate() for the decimation of hard telecined 2:3 sources.
The picture sequence one would expect after IVTC is A B C D E F G H I J K .... progressive pictures, and this is what I usually get, but sometimes I am getting A B C D E E F H I J K ... means a duplication of 1 frame and a skipped frame later. It seems to happen only at the beginning of an IVTC sequence during the first 1...3 cycles and stabilizes correctly afterwards. It may or may not happen when I repeat the test, so it looks like a random initialization problem (?) which happens in say 1 out of 30 repeated tests, not easy to reproduce. It seems to happen with DGDecimate only, I have not observed it with Decimate() or TDecimate(). Weird. Do you have an idea what this could be? I notice that in DGTelecide the first frame (0) is always deinterlaced, could this be related to the issue?
Maybe it's self inflicted or I am just becoming paranoid....
Anyway, it's time for a rest here now. Let's see whether I can still reproduce it tomorrow.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

DGDecimate has to do some trickiness for random access. I'll look again at the code. Meanwhile if you can give me a stream and script and steps to reproduce it that would make it much easier to pin down. It's probably going to involve jumping around on the timeline. Thanks.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

I have decided to ditch my edge-based approach to deinterlacing. The problem is that it is not possible to produce a reliable enough edge map from a single field. And even if it were reliable enough, it's just not right to restrict proper handling to edges.

So now my idea is to start with an existing fast CUDA motion flow code from nVidia and add half-pixel motion compensation (either via constant phase FIR filtering or superresolution). The flow map will be per-pixel, not block-based. The goal is to give decent quality and be much faster than QTGMC. Fun, fun, fun.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

admin wrote:DGDecimate has to do some trickiness for random access. I'll look again at the code. Meanwhile if you can give me a stream and script and steps to reproduce it that would make it much easier to pin down. It's probably going to involve jumping around on the timeline. Thanks.
Here a .zip with
- Synthetic mpeg2 test file
- Index file
- Script

http://www.mediafire.com/file/dp9o68ku2 ... cimate.zip

I discovered the issue first with a natural source. Unfortunately I ditched it as I focused on other things so I just took note and put it aside. I could however reproduce the issue with the uploaded synthetic file. Watch the moving text "PicX". I hope it is ok.
The right hand picture using DGDecimate will show the frame repeat/drop issue when it happens at all, while the left picture using TDecimate (or Decimate) steps always regularly through the frames.
You may have to try/restart many times until you catch the glitch. It may have to do with searching/random access.
I am also not sure whether the glitch happens only with mode=1 enabled for DGTelecide.
The glitch seems to pop up only at the beginning (during the first few cycles) of a telecined sequence. Perhaps you find something in the code. To catch the glitch can be grueling, and as it happens rarely it's probably not worth to waste much time with investigating.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Thanks, Sharc. I'll get on it this morning.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

:bug:
It's very easy to duplicate. Just open the file in VirtualDub and step linearly until frame 125. It shows Frame #35 on both. Now re-open and goto frame 125. DGDecimate shows Frame #34. It should be easy to fix. As I thought it is random access related.

I really appreciate your thorough testing, Sharc!
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Oh that was quick. I was just about to write "Good morning. No rush, you have more important projects in the pipeline". But I am glad you could duplicate it :D
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

It's fixed, I'm just heading over to the Binaries thread.
DAE avatar
Aleron Ives
Posts: 126
Joined: Fri May 31, 2013 8:36 pm

Re: DGDecomb

Post by Aleron Ives »

admin wrote:It wouldn't be too slow. I just haven't implemented it. Do you have a clip that clearly shows its advantage?
I'm afraid not. I've just read the Decomb manual, which says things like:
If your telecined source material is NTSC 3:2 pulldown, you can enable pattern guidance, which can make the field matching more accurate for some clips.
and thought, "OK, that sounds good, so I'll use that." ;) I don't think I'm enough of an expert to advise on whether it's actually necessary, which is why I haven't been participating in the tests. I just tend to use pattern guidance when I'm working with NTSC or PAL DVDs, which are likely to follow standard pulldown patterns, at least if they were authored by a reputable source. I generally run a few tests with post=3 to check what Telecide() is going to be doing to the clip before I actually encode, but that's about it.
Post Reply