Inline comments ...
| -----Original Message-----
| From: deinterlace-discuss-admin@...
| [mailto:deinterlace-discuss-admin@... Behalf Of
| Steven Grimm
| Sent: Thursday, June 14, 2001 12:42 PM
| To: deinterlace-discuss@...
| Subject: Re: [Deinterlace-discuss] Changes to LinearCorrection filter
| I think we don't want to just throw away scanlines. Consider the case of
| a stock ticker; if you happen to throw away the dividing line between the
| ticker at the bottom of the screen and the main image, it'll look pretty
| It shouldn't be too horribly CPU-intensive to average adjacent scanlines
| rather than throwing them away, especially on SSE and 3DNow! CPUs. It's
| basically just the cost of two scanlines' worth of memcpyMMX with an
| extra pavgb instruction thrown in for each qword. That won't be quite
| right if the squeeze factor increases toward the edge of the screen,
| but it'll look better than throwing scanlines away. You don't even
| need to worry about smart deinterlacing on those scanlines since you're
| essentially bobbing all the pixels.
I think the bottom line of the ticker may be toast anyway unless we are
willing to warp the middle too much. :(
But yes, we will probably want to do a (weighted) Interpolated Bob
eventually. I just thought it would be good to see what it looked like first
with the simpler approach.
| As for the bigger picture, so to speak, I think the best compromise will
| probably end up being a combination of vertical squeeze and nonlinear
| horizontal stretch. Doing both means you don't have to be as extreme
| about either one, so the non-distorted center area of the picture can
| be that much larger. I think doing vertical squeeze could also make
| horizontal stretching less CPU-intensive, again since there'll be more
| area in the middle of each scanline that you can just memcpy without
| stretching. (Don't know if that's how the current algorithm works,
| but it seems like a reasonable optimization.)
Again, that's much more complicated, and possibly still too CPU intensive.
The vertical squeeze can be just by accomplished giving ownership of the top
and bottom of the screen to the squeeze and allowing the old routines to
work in the middle as before. And vertical scaling in MMX/SSE is much more
efficient, even if it's not just pavgb instructions.
But possibly something similar could be worked out later for the horizontal
edges. And that 2-dimensional stretch/squish would look kinda cool. ;-)
Possible 3-Tap Vertical scaling in MMX: (separately on luma and chroma)
Pout[i] = (a * P[i-1] + b * P[i] + c * P[i+1] ) >> 8
where a,b,c are any 3 positive integers that add to 256. They can be calc'd
and tabled once at squeeze initialization time for each output line so C
floating point can be used to calc them.
| Deinterlace-discuss mailing list