[MPlayer-dev-eng] [PATCH] -vf combdetect: crude detection of interlaced sources

[Christopher Key]

  On 02/08/2010 17:39, Reimar Döffinger wrote:
> On Mon, Aug 02, 2010 at 03:50:30PM +0100, Christopher Key wrote:
>> As mentioned, this is very crude.  It works well for my library of PAL
>> dvds, which will either be 24fps film sped to to 25fps, or natively
>> 50f(ields)ps interlaced TV, but isn't designed to analyse NTSC material
>> that may use 3:2 pulldown etc.  This is why I've named it combdetect,
>> that's all it does, and it leaves room for a more advanced filter than
>> can detect a rather broader range of field/frame fiddling techniques.
>> Nevertheless, I find this very useful, and suspect that it may be useful
>> to others with similar aims.
> But even for detecting combing it should be quite simple to do a lot
> better, e.g. by comparing C(line i, line i+1) to C(line i, line i+2) where
> C is the covariance.
> But even without going that far, the property of combing is not that
> line i differs a lot from line i+1 but that line i+1 differs _more_ from
> line i than line i+2.
> Thus your filter only detects a high variance vertically but has not
> much to do with combing IMO.
Thanks for the prompt feedback.

I perhaps didn't explain my current algorithm very well.  I'm not 
looking for just a large change from line i to line i+1, but also for 
another large change in the opposite direction from line i+1 to line 
i+2.  In effect, I'm looking for Low, High, Low or High, Low, High.  I 
think this is doing the same as you suggest:

a = luma for pixel from line i
b = luma for pixel from line i + 1
c = luma for pixel from line i + 2
T = threshold value

consider the "Low High Low" case:

(b - a > T) && (b - c > T)

this implies:

((b - a) - abs(c - a) > T) || ((b - c) - abs(c - a) > T)

or in words, that the absolute change from line i to line i+2 is smaller 
than the difference either from line i to line i+1 or from line i+2 to 
line i+1 by some threshold amount.

A similar argument applies for the "High Low High" case.


There are certainly cleaner ways of detecting combing though.

By C(line i, line j), I take it you mean:

Sum_x ( P(x,i) * P(x,j) ) - Sum_x ( P(x,i) ) Sum_x ( P(x,j) )

where P(x,y) is pixel luminance for pixel x,y, and Sum_x denotes sum over x.

Most visible combing occurs in a band around any vertical features that 
are moving horizontally.  For slow movement, this can often only be a 
few pixels wide, quite visible, but perhaps not affecting the covariance 
between adjacent lines as much as the natural increase in covariance 
between lines that are two apart.  It should be simple enough to code 
this technique and try it though.


Kind regards,

Christopher Key