I've been noticing that methods of de-interlacing are being described more consistently these days. I thought it worthwhile to try to classify our algorithm. We're quite proud of it, and it seems to match up to the best techniques available. Let's try to define it.

Well, first it's a Pixel Based Motion Adaptive De-interlacer. That means that areas of the picture that are stable use the pixels from both fields to increase resolution, but areas in motion do not, to reduce 'combing'.

Second is that we have diagonal enhancement, in that when we can't use both fields, we look at the pixels around a target pixel to try to infer what it should be. THis is more of a side-effect of our de-interlacing/scaling combo, that I'll mention in a minute.

Third is that we use 4 field correction. That just means the previous 2 fields are kept around and used to detect whether there has been motion around each pixel. If the content is a different frame rate, especially 24 fps, or is running slowed down, we also use frame blending to interpolate frames if you want. That uses the 2 field buffers to hold previous frames.

What I haven't seen anyone else describe is the way that we're doing our scaling and de-interlacing together, so we can change the way we decide on things based on how we scale pixels up or down. That means interpolated pixels can be treated cautiously when scaling, so they don't introduce artifacts (any more than they have to). It's also fairly efficient - you have to 'sample' all the same pixels around each target pixel to do either job.

Another feature that I suspect gets missed in other systems, is that we scale and interpolate in a 'linear' color space, as opposed to video's gamma corrected luminance space. It makes all the pixel magic work properly. That's all in 16-bit floating point, so we can get to and from 8, 10 and 12-bit formats, YRB and RGB with no losses.

I suppose a side-note is that we're doing this all in the graphics processor (GPU) so that we can do twin HD streams in real-time.

Bruce