Article View: comp.sys.amiga.tech
Article #8529Re: Fixing flicker, & future frame rate issues
From: Bryan Bayerdorffer
Date: Wed, 13 Apr 1988 03:53
Date: Wed, 13 Apr 1988 03:53
52 lines
4035 bytes
4035 bytes
In article <8649@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes:
=-time (in 1/120 sec): 0 1 2 3 4 5 6 7 8 9 10 11 12
=-time (in 1/60 sec): 0 1 2 3 4 5 6
=-time (in 1/30 sec): 0 1 2 3
=-half-frame displayed: ... 1 2 1 2 3 4 3 4 etc
=-full-frame displayed: ... 1 1 1 1 2 2 2 2 etc
=-
=-The "..." represents time spent gathering the first two half-frames
=-in the first 30th of a second, so that they can be displayed at a higher
=-rate than they were generated, in the next 30th of a second.
=-
=-This shows a full-frame being generated and displayed each 30th of
=-a second. But each half-frame is displayed twice within that interval
=-(e.g. half-frame number two appears twice in the first 30th sec).
=-It's true that you don't get a new set of two-half frames until a
=-full 30th of a second goes by, and that has second-order effects,
=-but the first order effect is simply a question of stroboscopic flicker,
=-which perceptually disappears around 40 to 45 hertz. Since you're
=-strobing half-frame two at 60 hertz, there's no stroboscopic flicker.
=-
Aha, so you want to INTERLEAVE the two fields (heretofore 'half-
frames'). I suspected that this was what you meant, but I was being
deliberately obtuse so I could act superior. :-) Yes, this will work, but you
STILL have to buffer four fields to prevent breakup. Therefore, all this might
buy you is...
=-The second-order effect is smoothness of motion. Consider times you've
=-seen a film/vcr played in slow motion. If it was filmed at the regular
=-rate, motion looks jerky in slow motion even though there's no stroboscopic
=-flicker. It's not the whole picture that looks jerky/flickery, as it
=-does at slow frame display rates, it's just the motion itself.
=-
Now you're on track. Your method would be smoother. Except that as
the frame rate increases, the effect of double-shuttering decreases. A double-
shuttered, 24 frame/sec film gives the eye 1/48th sec to fix the image. A
properly working flickerFixer gives it slightly longer--1/30th sec. Let's say,
for the sake of argument, that the image-fixing time of the eye is somewhere
around the perceptual stroboscopic threshhold (say that three times fast),
which you give as ~40Hz, i.e. 1/40th sec. (1/40)/(1/30) = 1.33, so the fF video
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
existentialist humor, please). This seems a little excessive, if the cost of
a 120Hz display is going to be about twice that of a 60Hz display, which is a
reasonable assumption.
______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_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
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
Technical Details
Message-ID:
<11227@ut-sally.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!mcdchg!chinet!att-ih!pacbell!ames!ncar!noao!ut-sally!mothra!bryanReferences:
<11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <8649@agate.BERKELEY.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!mcdchg!chinet!att-ih!pacbell!ames!ncar!noao!ut-sally!mothra!bryan From: bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) Newsgroups: comp.sys.amiga.tech Subject: Re: Fixing flicker, & future frame rate issues Message-ID: <11227@ut-sally.UUCP> Date: 13 Apr 88 03:53:11 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> Sender: news@ut-sally.UUCP Reply-To: bryan@mothra.cs.utexas.edu Organization: Spam Detection & Removal Squad, Austin, TX Lines: 52 Spam-Content: Negligible