PDA

View Full Version : Detecting Deinterlacing?


LB
28th September 2006, 06:55
Is there a filter out there which can detect deinterlacing? I have a nasty DVD that for the most part IVTC's very well, but there is a particular scene in it that has (good frames) + (deinterlaced frames). So I am trying to find a filter which can detect the frames which are deinterlaced, so I can flag them and not have they included as "potential good frames" during the IVTC since all the IVTC programs I have tried do not detect these deinterlaced frames as combed.

Weird situation eh?

neuron2
28th September 2006, 14:21
You can try a MEGUI interlace analysis. Those funny sections should show as progressive at full frame rate.

Mug Funky
28th September 2006, 15:22
possibly you could compare the source frame with a (crappily) deinterlaced version of it and check it against a threshold.

if something's been "annoyingly" deinterlaced (for lack of a better word), it'll be somewhat like ibob or bob(0,.5).selecteven() (or selectodd of course). either that or it'll be separatefields().selectxxx().pointresize(width,last.height).

either way, running it again should produce the same frame, or near enough to it to be useful.

another possibility is detecting stairstepping somehow. maybe diagonal edgemask?

LB
29th September 2006, 02:51
Neuron2:
Mmm, I've fooled around with MEGUI but I don't know where the interlace analysis in it is... but irregardless, since you say that the source frames (which have bad deinterlacing in them) will detect as progressive, then I don't see how MEGUI will help? I want to detect on this dvd what frames are not deinterlaced/interlaced, and use them, and not frames that are interlaced/deinterlaced.

Mug Funky:
Hmm, I've been trying to build a threshold but it just doesn't work because the result image is merely stairstepping which is hard as hell to detect. I've been pondering something like the diagonal edgemask but have no clue how to construct something like that... Any hints ya can give me?

Jeremy Duncan
29th September 2006, 03:05
Try fielddeinterlace.
You need the decomb.dll

fieldDeinterlace(full=true, blend=true, dthreshold=10)

neuron2
29th September 2006, 03:54
Give us a sample unprocessed source clip.

LB
29th September 2006, 04:47
@Jeremy Duncan
I'm not trying to deinterlace my clip. Here is the situation again. I have a DVD which for the most part IVTC's fine, however there is an area on the DVD that contains fields which are deinterlaced and contain stairstepping residue. Along with these "crap" fields, are "good" fields which I want my IVTC to use instead of the crap deinterlaced fields. However, all the IVTC programs I have tried cannot detect the stairstepping residue and thus avoid using the deinterlaced fields, instead of the good fields.

@neuron2
I uploaded my clip here (http://www.savefile.com/files/116184). I used ChopperXP to slice the clip down to the problem area so ignore the first 5 fields or so because chopperxp threw it off. Anyway, the "problem" area begins when the screen switches to the character with the yellow backpack running away. For this "backpack" scene, each static image has three types of fields: (1) interlaced; (2) deinterlaced; (3) good. I'm trying to figure out a way to get an IVTC method to use the good fields, flagging both the interlaced and deinterlaced fields as "combed". Most IVTC programs have no problem detecting interlaced fields, but I have yet to run across one which can detect this deinterlaced stairstepping residue and ignore it.

Also, I can just do a manual IVTC in tmpgenc and select the "good" fields, but that's no fun obviously. There has got to be a way to detect the good fields using avisynth...

neuron2
29th September 2006, 14:10
You cannot have "interlaced fields", so your faulty conceptualization is blocking you from seeing what is really happening.

Consider Telecide's field matching for frame 90. It tries to match the lower field of frame 90 to the upper field of frame 90 (current or c match) and to the upper field of frame 91 (next or n match). The n match is correct but Telecide chooses the c match. When you inspect these two top fields you see that they are from the same anime picture, and so they should be identical. But they are not identical. They are subtly different. The problem is that the differences makes the wrong field a closer match to the bottom field, but they cause stairstepping in the resulting matched frame. I don't know why these fields are showing these pathological differences.

This is a very hard thing for Telecide to deal with. Have you tried TFM()? I don't know what field matching algorithm it uses, but it is likely similar.

You will probably have to resort to manual IVTC, either using Telecide overrides or TMPGE manual mode.

E.g., a Telecide override to correct frame 90 would be:

90 n