Xref: utzoo comp.sys.amiga:21930 comp.sys.amiga.tech:1552
Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: Message from designer of FlickerFixer
Message-ID: <4515@cbmvax.UUCP>
Date: 18 Aug 88 21:26:25 GMT
References: <3318@crash.cts.com>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 46

In article <3318@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes:
>        The flicker fixer clearly does what it was designed to do and in that
>respect is a fine product.  However I stand by the point that IDEALLY it
>should not be mixing mis-matched fields (which I can definitly see it doing).
...
>        Am I mistaken it beleiving that what you've done is to buffer each
>video field (using video industry terminology) and then combine it with the
>subsequent field to form a frame (de-interlaced display).  Given this 
>methodology doesn't that mean that every other display update contains a
>Frame composed of mis-matched feilds?  If I am mistaken about this what is
>the reason for the splitting up of images, most clearly seen by moveing the
>mouse angularly across the screen at a rapid rate?

	In reality, there are 4 'fields' per 'frame', but for our purposes
we can act as if there are 2, Long Field and Short Field.  Now, when displaying
interlaced video, we alternate bewteen these, each displaying every other line.
If an object is moving at least 1 pixel/field, it will have moved on every
field relative to the last field.

	This is what is confusing you.  ANY two fields with a moving object
will NOT show a single object, but will show the same object in two positions.
Usually, these are only a few pixels apart, so it looks like "fuzz" on the
left and right edges.  Remember these two images are on every other line.

	The two images are sampled at different times, so the object is in
different positions.  This is the equivalent of beam collision when writing
data to the screen when the beam is reading it (though not exactly the same,
as there's no way to double-buffer).

	So, to reiterate, there is NO way to get rid of the moving-object
effect when de-interlacing interlaced video.  NONE.

	The reason you usually don't notice is that your brain sees them as
two pictures of the same object at different times, and tracks it as a moving
object.  By the time the next field comes around, the image has mostly faded
(the cause of interlace flicker), so the brain doesn't see the two offset images
at the same time.  After being deinterlaced, they appear simultaneously, which
is very obvious to the brain.

>        Again, I am sorry for having implied that the design of the fF was
>poor, which it is not.
>
>                                                        Wade W. Bickel

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup