Path: utzoo!mnetor!uunet!husc6!im4u!ut-sally!gamera!bryan
From: bryan@gamera.cs.utexas.edu (Bryan Bayerdorffer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <11255@ut-sally.UUCP>
Date: 14 Apr 88 21:37:43 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <8649@agate.BERKELEY.EDU> <11227@ut-sally.UUCP> <8693@agate.BERKELEY.EDU>
Sender: news@ut-sally.UUCP
Reply-To: bryan@gamera.cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 66
Spam-Content: Negligible


In article <8693@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes:
=->STILL have to buffer four fields to prevent breakup.  Therefore, all this might
=-
=-Huh? You lost me...in the above diagram, first fields #1 and #2 are buffered,
=-and then fields #3 and #4...that's only *two* at a time. Where did "four"
=-come from? Hmmm...do you mean in terms of memory requirements? It's
=-true that you have to capture 3 & 4 while displaying 1 & 2, that's four
=-frames, for sure. But it sounded like you were talking about something else.
=-
	Yes, exactly, I mean in terms of memory requirements.  I wouldn't
say that fields being displayed are not being buffered, but if you like...
In this case fF buffers NOTHING.  That sounds really bad.  After having
spent the $448, I like my terminology better. :-)

=-BTW I eventually come to realize that this 120 hz scheme is overkill,
=-based on your comments, but first a few other issues:
=- 
=->=-The second-order effect is smoothness of motion. [ ... ]
=->	Now you're on track.  Your method would be smoother.  [ ... ]
=->is only 33% more jumpy than 'real motion,' assuming a linear relationship,
=->whereas un-double-shuttered film is 67% more jumpy.  Your method shows each
=->field for 1/120th second, which is 200% LESS jumpy than reality (no
=-
=-That would be nice, wouldn't it? Unfortunately, it requires intermediate
=-*generated* frames as well as *displayed* frames, to show the intermediate
=-positions of moving objects, to smooth *motion*. The Amiga can't really
=-generate them, because it can only send out fields at 60hz (and frames
=-at 30hz of course). On the other hand, it's feasible (though difficult)
=-to *interpolate* those frames. See work done by the "Advanced Television"
=-research group at the MIT Media Lab; the perceptual smoothing of jerky
=-motion is quite noticeable.
=-
=-So again, all this fancy 120hz scheme (without motion interpoloation)
=-does is eliminate *stroboscopic* flicker, not *motion* jerkiness. It'll
=-look *exactly* like the Amiga's current interlaced display, but with no
=-flicker whatsoever.
=-
	It becomes clear to me now that flicker is really being used in two
related but different ways.  Therefore I propose the following, more precise
definitions:

	Flicker:  A perceived INTERMITTENCE in an ENTIRE image, as in successive
	frames interleaved with intervals of 'darkness' (= absence of image).

	Jitter:  A perceived MOTION of an image COMPONENT due to PARTIAL
	images being interleaved, as in interlaced displays.

	Jerkiness:  A perceived DISCONTINUITY of motion, due to a slow frame
	rate.

	Now I claim the following:

	-Double-shuttering addresses FLICKER, by equalizing the on and off
	 intervals for a frame.

	-flickerFixer should really be called jitterFixer.

	-Nothing but a higher frame rate or interpolation helps jerkiness.
	 (i.e., Doug is right, above.)
 ______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___
|____Teachers leave the kids alone__|_____|_____|bryan@mothra.cs.utexas.edu___|
___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|