papa@pollux.usc.edu (Marco Papa) (08/15/88)
Peter Selverstone, designer of FlickerFixer and with no access to Usenet, asked me to forward this. Enjoy. ------ Memo #20009 From: pselverstone Date: Sun, 7 Aug 88 00:06:04 EDT To: papa Message-Id: <memo.20009> Subject: Usenet message Marco, I'd appreciate it if you would post the following message to the Amiga group on Usenet if that is possible. haitex@pnet01.cts.com (Wade Bickel) writes: > ... Our 3D glasses will not work with either the FlickerFixer or > Long Perstistance monitors. > As I see it the problem is that the Amiga's refresh rate is too slow. >The reasons for this are obvious; We live in a 60hz country. In Europe >things are even worse with PAL, which runs at only 50hz (or is it 48?). > The FlickerFixer is a half-azzed attempt to double buffer the display, >which I think is junk. But I can understand their reasoning. It does >elimate the flicker on interlaced images, and uses (I assume) only about 1/3rd >the memory it would have taken to do it right. And of course, it works with >a multi-sync monitor at 76hz. But I really don't like the way objects in >motion split, and especially the inablity to by-pass the thing. > What I think C= should do is support a 76hz mode. This would mean >that with a multi-sync monitor you would acchieve a 38hz flicker rate between >the short and long frames of interlaced images, which I doubt would be >perceptable in any but the worst of circumstances. It seems to me that individuals associated with companies doing business in the Amiga market are under a special obligation to provide accurate information to the Amiga community. The propagation of inaccurate information about another company's product is foolish. It causes users to question the technical competence of the originator and his employer. People have a lot of fun with disclaimers. Here is a case where their purpose is clear. I note that there was none on this message. Haitex would be well advised to require them. This is of some consolation to me as I designed flicker fixer and much of the discussion that I have seen on Usenet (I've only caught bits and pieces) seems to be based on a misconception of the manner in which it operates. I am not currently on Usenet. If people are interested in information on flicker fixer I am quite active on most of the commercial services. Peter Selverstone Bix:pselverstone Plink:pselverst CIS:72527,2652 ------ -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
haitex@pnet01.cts.com (Wade Bickel) (08/16/88)
My appologies to Peter Selverstone.
I did not intend to say that the flicker fixer itself is poorly
designed, and clearly miss-worded my sentance. What I meant to say was
that the way (I think) it works is a cludge. The cludge is needed to solve
a problem that is otherwise unreasonably expensive to correct.
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).
As stated before I think that given the cost of RAM the manner in which the
flicker fixer does function is reasonable. Who would buy it if it cost
a $1000 or more?
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?
Again, I am sorry for having implied that the design of the fF was
poor, which it is not.
Sincerly,
Wade W. Bickel
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM
Opionions expressed are mine, and not necessarily those of my employer.u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) (08/17/88)
In article <3318@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >The cludge is needed to solve >a problem that is otherwise unreasonably expensive to correct. >...However I stand by the point that IDEALLY it >should not be mixing mis-matched fields (which I can definitly see it doing). >...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? > Wade W. Bickel > >UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex >ARPA: crash!pnet01!haitex@nosc.mil >INET: haitex@pnet01.CTS.COM >Opionions expressed are mine, and not necessarily those of my employer. This came up before, but I think that much of the discussion was in Email (for a change :^). When the machine is modifying the display at 60 Hz, like redrawing a moving mouse pointer, there are no two correctly matched fields to display that will not cause split images, and hence the Flicker- fixer does the absolute best possible thing until the system forces all software to update at a maximum of 30 Hz, which would be a Bad Thing. Nobody likes having their animation speed cut in half. The designers worked with what they had, and did the best they could. To properly de-interlace an NTSC signal, you need to be able to tell which pair to match, but only if they are meant to be matched, which they currently are not on the Amiga. Under the current system, every pair of adjacent frames is technically mis-matched, but you only notice when things move. It's a common problem for someone familiar with how TV NTSC works to see a computer that sends an NTSC signal, and assume that the formats are similar. You should know better than to trust a standard. :^) /| | /||| /\| | John M. Olsen, 1547 Jamestown Drive \|()|\|\_ |||. \/|/)@|\_ | Salt Lake City, UT 84121-2051 | u-jmolse%ug@cs.utah.edu or ...!utah-cs!utah-ug!u-jmolse "I'd give my right arm to be ambidexterous."
tope@enea.se (Tommy Petersson) (08/17/88)
In article <3318@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >My appologies to Peter Selverstone. . stuff deleted >As stated before I think that given the cost of RAM the manner in which the >flicker fixer does function is reasonable. Who would buy it if it cost >a $1000 or more? . more stuff deleted What DOES the FlickerFixer cost in the US? Here in Sweden it's almost $1000... A question: When (if?) the new graphics chips will come, is there any need for the FlickerFixer (I have a B2000 with 3 meg RAM).
haitex@pnet01.cts.com (Wade Bickel) (08/17/88)
u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) writes: >This came up before, but I think that much of the discussion was in Email >(for a change :^). When the machine is modifying the display at 60 Hz, >like redrawing a moving mouse pointer, there are no two correctly matched >fields to display that will not cause split images, and hence the Flicker- >fixer does the absolute best possible thing until the system forces all >software to update at a maximum of 30 Hz, which would be a Bad Thing. >Nobody likes having their animation speed cut in half. The designers >worked with what they had, and did the best they could. Not so. What you could do is to buffer a full 2 fields and show them on both screen updates. Example: Time (60th/secs) Amiga Displays Buffered video output ------------------- ------------------ --------------------------------- 0 Shortframe[0] undefined 1 Longframe[1] undefined 2 Shortrame[2] Shortframe[0] + LongFrame[1] 3 Longframe[3] Shortframe[0] + Longframe[1] 4 Shortframe[4] Shortframe[2] + Longframe[3] 5 Longframe[5] Shortframe[2] + Longframe[3] 6 Shortframe[6] Shortframe[4] + Longframe[5] as compared to what the fF generates 3 Longframe[3] Shortframe[2] + Longframe[3] 4 Shortframe[4] Longframe[3] + Shorframe[4] 5 Longframe[5] Shortframe[4] + Longframe[5] As you can see, this does not impose any slow down on the actual data rate of the CRT. It does however require aprox. twice the ram, and this is why the fF does things the way it does. With RAM chips as expensive as they are cost is a definite design criterium, and a legitimate one at that. Still, I cannot see the fF being accurately described as a de-interlacer. It is a flickerFixer. I think there is a difference. > >To properly de-interlace an NTSC signal, you need to be able to tell which >pair to match, but only if they are meant to be matched, which they >currently are not on the Amiga. Under the current system, every pair of >adjacent frames is technically mis-matched, but you only notice when things >move. By definition an interlaced screen has a specifically matched Long and Short frame. Admittedly a non-interlaced screen has no such property. It is interlaced screens we are discussing when talking about the fF? No? > >It's a common problem for someone familiar with how TV NTSC works to see >a computer that sends an NTSC signal, and assume that the formats are >similar. You should know better than to trust a standard. :^) > When examining the Amiga display system it is clear that it was designed to emulate NTSC video, which has it's positive and negative points. The formats are almost IDENTICAL. Clearly the intelaced mode coresponds directly to normal NTSC video. My only point in all this is that one possible solution might be to speed up the frame rate of the Amiga. If the A3000 were to have the ability to be put in a special 76hz mode, it could be used with a Multi- Sync monitor and would provide a 38hz interlaced mode, whicl would probably appear flickerless to over 40% of the population in normal viewing conditions (supposedly at 40hz 50% of the pop notices no flicker, the visual LD50 :^)). What would be even better would be adjustability. Of course, I think refreshed displays are a soon-to-be thing of the past (a couple of years), so new display issues will probably hit us before the A3000 does :^). In the meantime, imperfect as it is, the flickerFixer is the only game in town. Thanks Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM Opionions expressed are mine, and not necessarily those of my employer.
u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) (08/18/88)
Note: I un-cross posted this. haitex@pnet01.cts.com (Wade Bickel) writes: >u-jmolse%ug@utah-cs.UUCP (John M. Olsen) writes: >> <FlickerFixer does the best it can> > Not so. ... Example: > Time (60th/secs) Amiga Displays Buffered video output > ------------------- ------------------ --------------------------------- > 0 Shortframe[0] undefined > 1 Longframe[1] undefined > 2 Shortrame[2] Shortframe[0] + LongFrame[1] > 3 Longframe[3] Shortframe[0] + Longframe[1] > 4 Shortframe[4] Shortframe[2] + Longframe[3] > as compared to what the fF generates > 3 Longframe[3] Shortframe[2] + Longframe[3] > 4 Shortframe[4] Longframe[3] + Shorframe[4] > 5 Longframe[5] Shortframe[4] + Longframe[5] This would be fixable *if* the Amiga matched the short and long frames instead of ignoring them for *update* purposes. Things move between each frame, whether long or short. The above example would be great if Ami didn't change things between (for example) short[0] and long[1] as well as between long[1] and short[2]. Several things are updated in screen memory and on the display every 60th of a second. :^( > Still, I cannot see the fF being accurately described as a >de-interlacer. It is a flickerFixer. I think there is a difference. I called it a de-interlacer simply because it takes an interlaced signal as input and sends a non-interlaced output. If this is wrong, and if anyone's shorts got in a bind because of this, I'm sorry. :^) > By definition an interlaced screen has a specifically matched Long >and Short frame. They may be matched, but things still move between each 1/60th sec frame, (or half frame, if you want to look at it that way) so anything that tries to join them in any way will have moving objects go schitzoid. >>It's a common problem for someone familiar with how TV NTSC works to see >>a computer that sends an NTSC signal, and assume that the formats are >>similar. You should know better than to trust a standard. :^) > When examining the Amiga display system it is clear that it was >designed to emulate NTSC video, which has it's positive and negative points. >The formats are almost IDENTICAL. Clearly the intelaced mode coresponds ^^^^^^ >directly to normal NTSC video. TV runs at 30 Hz, displaying who halves of a single picture per 1/30 of a second. The Amiga doesn't redisplay two halves of a single still picture, but draws whatever happens to be the most current stuff to draw. Close, but not exactly the same. > My only point in all this is that one possible solution might be >to speed up the frame rate of the Amiga. Yup. It would be great if we could have multisync way-hi-res output while still being able to go back to (near) NTSC. > Wade. >UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex >ARPA: crash!pnet01!haitex@nosc.mil I guess with stereoscopics, you have to know which frame is which, and only update at 30 Hz max. I still have to give you a phone call about adding stereo and LC shutter stuff to my game, Wade. :^) /| | /||| /\| | John M. Olsen, 1547 Jamestown Drive \|()|\|\_ |||. \/|/)@|\_ | Salt Lake City, UT 84121-2051 | u-jmolse%ug@cs.utah.edu or ...!utah-cs!utah-ug!u-jmolse "...if cows ate plankton whales would die off." Randy Meyers
keithd@cadovax.UUCP (Keith Doyle) (08/19/88)
In article <3328@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > By definition an interlaced screen has a specifically matched Long >and Short frame. Admittedly a non-interlaced screen has no such property. Ah, I have a question about this terminology. From what I remember from my video days, is that a "Frame" is made up of two "Fields", even and odd, and they're both the same size, 262-1/2 lines. One of the fields starts 1/2 line out of phase with the other. How does that translate to your use of "short" and "long" frame terminology? Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
jesup@cbmvax.UUCP (Randell Jesup) (08/19/88)
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
haitex@pnet01.cts.com (Wade Bickel) (08/21/88)
u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) writes: >Note: I un-cross posted this. > >This would be fixable *if* the Amiga matched the short and long frames >instead of ignoring them for *update* purposes. Things move between each >frame, whether long or short. The above example would be great if Ami >didn't change things between (for example) short[0] and long[1] as well as >between long[1] and short[2]. Several things are updated in screen memory This should not happen in a double buffered Interlaced display. I guess if you aren't buffering your output anything could happen. However, when you write into say, a 320x400 bitmap, that is exactly how it appears to the RastPort. No interleaving is recognized at this level. Assumedly, in an interlaced animation the animation program should make sure that both frames are given time to be shown. If not, why waste bandwidth using interlaced mode (ie for drawing), as those long frames will not be seen anyway. (Certainly we don't draw into the bitmap as it's being shown, or we're in rip city :^)). I sincerly doubt that what you describe actually happens. The Ami does change things between short[0] and long[1], but these are probably things in short[2] or long[3]! It's just bad programming if anything else happens (using INTERLACED output). Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM Opionions expressed are mine, and not necessarily those of my employer.
jms@antares.UUCP (joe smith) (08/21/88)
In article <5662@utah-cs.UUCP> u-jmolse%sunset.utah.edu.UUCP@utah-cs.UUCP (John M. Olsen) writes: >TV runs at 30 Hz, displaying who halves of a single picture per 1/30 of a >second. The Amiga doesn't redisplay two halves of a single still picture, >but draws whatever happens to be the most current stuff to draw. Does this mean that when the networks are providing a live feed and the TV camera is panning horizontally across a scene with a lot of vertial lines, we will see pictures updated at only 30 Hz? I was under the impression that the camera does no buffering; if the image changes it will output consecutive frames that do not match, just like the Amiga. Is this correct? -- +-----------------------------------------------------------------------------+ | TYMNET: JMS@F29 UUCP: {ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 | +-----------------------------------------------------------------------------+
jdow@gryphon.CTS.COM (J. Dow) (08/21/88)
In article <3318@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >My appologies to Peter Selverstone. > > > I did not intend to say that the flicker fixer itself is poorly >designed, and clearly miss-worded my sentance. What I meant to say was >that the way (I think) it works is a cludge. The cludge is needed to solve >a problem that is otherwise unreasonably expensive to correct. > > 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). >As stated before I think that given the cost of RAM the manner in which the >flicker fixer does function is reasonable. Who would buy it if it cost >a $1000 or more? > > 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? > > Again, I am sorry for having implied that the design of the fF was >poor, which it is not. > Perhaps you would care to detail a correct design? With moving pictures you have two frames in succession - ANY two frames - that cannot possibly match perfectly unless the animation is done wrong. (Assuming you are talking about an interlaced animation. I have not noticed any particular problem with 200 line animations.) You get this effect on standard TV as well as the Amiga. Correcting it requires a great deal of video processing, I am afraid. For the price I do not think it is possible to do any significant bit better than the FlickerFixer. (I just wish it had three times the memory so that it could display a decently digitized TV picture overlayed genlock style on the Amiga graphics. (Then for REALLY nice TV I might just let screenblanker blank the Amiga screen and ..... Just think - Rambo with no flicker <gag - choke> -make that Worf with no flicker.) > Sincerly, > > > Wade W. Bickel > > >UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex >ARPA: crash!pnet01!haitex@nosc.mil >INET: haitex@pnet01.CTS.COM >Opionions expressed are mine, and not necessarily those of my employer. Equally sincerely, Joanne B. Dow -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) (08/22/88)
In article <3348@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: <u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) writes: <>This would be fixable *if* the Amiga matched the short and long frames <>instead of ignoring them for *update* purposes. Things move between each <>frame, whether long or short. The above example would be great if Ami <>didn't change things between (for example) short[0] and long[1] as well as <>between long[1] and short[2]. Several things are updated in screen memory < < However, when you write into say, a 320x400 bitmap, that is exactly <how it appears to the RastPort. No interleaving is recognized at this level. <Assumedly, in an interlaced animation the animation program should make sure <that both frames are given time to be shown. If not, why waste bandwidth <using interlaced mode (ie for drawing), as those long frames will not be <seen anyway. (Certainly we don't draw into the bitmap as it's being shown, <or we're in rip city :^)). Interlaced mode and updating at 60 Hz is still a winner because it tricks our brains into seeing what was meant instead of what is really drawn. You will see the odd scans of screen n, the even scans of screen n+1, and so on, and your brain is pretty good at interpolating the "missing" half. I guess you must conclude by your argument that the Amiga was built wrong. I personally like the *ability* to redraw at 60 Hz, whether used or not. At least we now know it wasn't the fault of the designer of FlickerFixer. The Amiga doesn't buffer rastport info, so it draws whatever happens to be there when it wants to show a particular pixel, no matter whether it's an interlaced or noninterlaced display. It's up to the software to decide when to draw what. < I sincerly doubt that what you describe actually happens. The Ami <does change things between short[0] and long[1], but these are probably <things in short[2] or long[3]! It's just bad programming if anything else <happens (using INTERLACED output). Move the pointer around quickly on an interlaced screen. Each time it is drawn, you will see either odd or even scans drawn, but *never* both at the same location as long as the mouse is moving. QED. (If you have a hard time seeing this, you could record it on a VCR and single frame it.) < Thanks, < Wade. /| | /||| /\| | John M. Olsen, 1547 Jamestown Drive \|()|\|\_ |||. \/|/)@|\_ | Salt Lake City, UT 84121-2051 | u-jmolse%ug@cs.utah.edu or ...!utah-cs!utah-ug!u-jmolse "...if cows ate plankton whales would die off." Randy Meyers
king@client1.DRETOR.UUCP (Stephen King) (08/23/88)
In article <128@antares.UUCP> jms@antares.UUCP (joe smith) writes: >Does this mean that when the networks are providing a live feed and the >TV camera is panning horizontally across a scene with a lot of vertial >lines, we will see pictures updated at only 30 Hz? I was under the >impression that the camera does no buffering; if the image changes >it will output consecutive frames that do not match, just like the Amiga. > >Is this correct? > If the studio is using a conventional TV camera, then the vertical lines may appear to be jagged, depending on the speed with which the cameraperson pans the camera. Each successive field will show the verticals as being slightly displaced horizontally due to the camera motion. FlickerFixer cannot fix this. Complete frames occur at a 30Hz rate. Fields are 60Hz. Interlace causes the problem. Shuttered cameras have been developed wherein the image sensor is exposed briefly and a frame is stored until both fields have been transmitted. I don't know (exactly) how they work, but they will alleviate this annoying problem. Does this answer any questions? -- ***** DCIEM Simulation & Training Group *********** Stephen J King ********** - is not responsible for this message. {utzoo|mnetor}!dciem!dretor!king
charles@hpcvca.HP.COM (Charles Brown) (08/24/88)
>>u-jmolse%sunset.utah.edu.UUCP@utah-cs.UUCP (John M. Olsen): >>TV runs at 30 Hz, displaying who halves of a single picture per 1/30 of a >>second. The Amiga doesn't redisplay two halves of a single still picture, >>but draws whatever happens to be the most current stuff to draw. >Does this mean that when the networks are providing a live feed and the >TV camera is panning horizontally across a scene with a lot of vertial >lines, we will see pictures updated at only 30 Hz? I was under the >impression that the camera does no buffering; if the image changes >it will output consecutive frames that do not match, just like the Amiga. >Is this correct? >| {ames|pyramid}oliveb!tymix!antares!jms Most video cameras behave just as you say. There are special cameras designed for high speed work which have high speed shutters (just like still cameras) to take stop action pictures. Most network cameras (possibly all, but I don't know) are not those high speed cameras. So in most cases Mr. Olsen is incorrect. What this means of course is that the FlickerFixer is designed the way it should be. The special buffering that some have suggested would be counter productive and expensive. Charles Brown "representing myself only"
haitex@pnet01.cts.com (Wade Bickel) (08/30/88)
I don't know what you guys are talking about. I have a minor in Video and
I've spent a lot of time doing frame editing. On a video display frames are
NEVER mismatched the way the are by the FlickerFixer.
What is particularely disturbing is when the second feild of a frame is
overlayed with the first feild of the next frame to form a non interlaced
screen. This never happens with video tape or transmitted signals. In fact,
if it did, it would be very disturbing.
Perhaps someone can give some example of how they think this happens. Lets
consider a basketball moveing diagnally accross the screen. When are scan
lines drawn with the basketball appearing in two different positions at once?
(ie: in the same pass of the beam).
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM
Opionions expressed are mine, and not necessarily those of my employer.jesup@cbmvax.UUCP (Randell Jesup) (08/31/88)
In article <3379@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >I don't know what you guys are talking about. I have a minor in Video and >I've spent a lot of time doing frame editing. On a video display frames are >NEVER mismatched the way the are by the FlickerFixer. Because you always deal with fields, not frames, I suspect. Also, even if you deal in 2 interlaced fields that make up a frame at a time, camera-shot video is much more blurred than computer generated video, which can hide much of the effect. Try it with a baseball game some time, if it is well focused (AND moving across the screen quickly). Note that to see this, you may need to de-interlace the signal (the first field has faded before the second shows, and your brain interpolates for you). Trying to make non-interlaced versions of interlaced video is why the TV manufacturers are playing with interpolation chips to try to avoid to motion problems of de-interlacing video. >What is particularely disturbing is when the second feild of a frame is >overlayed with the first feild of the next frame to form a non interlaced >screen. This never happens with video tape or transmitted signals. In fact, >if it did, it would be very disturbing. Because "normal" video is interlaced. You get a succession of _fields_, not frames, on the monitor. Each is displayed for ~ 1/60 sec. Each is of a different "time". >Perhaps someone can give some example of how they think this happens. Lets >consider a basketball moveing diagnally accross the screen. When are scan >lines drawn with the basketball appearing in two different positions at once? >(ie: in the same pass of the beam). No. At time T, the camera circuitry reads a field of an image (I know it isn't instantaneous, but lets pretend). It outputs this to somehting (VCR, TV, whathaveyou). At time T+1/60sec, it grabs and outputs the next filed (that makes up a frame (more or less, there are some argue- ments that a frame is really 4 fields, but that doesn't matter here)). Note that the ball has moved some distance in that 1/60th of a second. The distance may well be small, if the ball is at a distance. If you were to deinterlace these two fields, it would be obvious (given fast enough movement) that the ball is being displayed in two different places. In interlaced video, unless it is moving VERY fast, you won't notice this, since it appears the ball is moving smoothly (which is why we display so fast, so that the brain interprets a series of pictures as a continuos stream.) Even if it were moving very fast in interlace, it wouldn't be noticable unless the frame (NOT field) were isolated and repeated, so the brain isn't tricked into thinking it's in motion. Does that (finally) explain it? -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
jms@antares.UUCP (joe smith) (08/31/88)
In article <3379@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >I don't know what you guys are talking about. I have a minor in Video and >I've spent a lot of time doing frame editing. On a video display frames are >NEVER mismatched the way the are by the FlickerFixer. > >What is particularely disturbing is when the second feild of a frame is >overlayed with the first feild of the next frame to form a non interlaced >screen. This never happens with video tape or transmitted signals. In fact, >if it did, it would be very disturbing. The mismatch between frames ALWAYS happens whenever a theatrical film is shown on TV. It's called the "5 to 2 pulldown", I'm suprised you didn't mention that. It is because film runs at 24 frames per second and television runs at 30 frames per second (60 fields per second). One twelfth second lasts 2 film frames or 5 TV fields. By transmitting 1 film frame as 2 TV fields and the next film frame as 3 TV fields, the 5 to 2 ratio is used. The symptom is visible on any VCR with a frame-by-frame advance button. If you single-frame thru a movie that was recorded on film (not a made for TV movie), you will notice a pattern of 3 good frames and 2 mismatched frames. Frame A A B B B C C D D D E E F F F G G H H H Field 00,01 02,03 04,05 06,07 08,09 10,11 12,13 14,15 16,17 18,19 good good blur blur good good good blur blur good The good freeze-frames occur when an even numbered video field matches with the next higher odd numbered video frame. The blurry freeze-frames occur when video frame 2N does not match 2N+1, WHICH OCCURS TWO OUT OF EVERY FIVE FRAMES DURING THE MOVIE! >Perhaps someone can give some example of how they think this happens. Lets >consider a basketball moveing diagnally accross the screen. When are scan >lines drawn with the basketball appearing in two different positions at once? >(ie: in the same pass of the beam). > >ARPA: crash!pnet01!haitex@nosc.mil >INET: haitex@pnet01.CTS.COM >Opionions expressed are mine, and not necessarily those of my employer. In my experience, the answer is yes. If the basketball moves between field 2N and field 2N+1 and you are not using a slo-mo-cam, then you will get a combined frame that has the ball appearing in two different places. -- +-----------------------------------------------------------------------------+ | TYMNET: JMS@F29 UUCP: {ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 | +-----------------------------------------------------------------------------+
king@client2.DRETOR.UUCP (Stephen King) (09/01/88)
> >The mismatch between frames ALWAYS happens whenever a theatrical film is >shown on TV. It's called the "5 to 2 pulldown", Not quite - it's called 2-3 pulldown. (Benson, Television Engineering Handbook, p 17.4) >In my experience, the answer is yes. If the basketball moves between >field 2N and field 2N+1 and you are not using a slo-mo-cam, then you will >get a combined frame that has the ball appearing in two different places. Agreed, although the motion of the ball may result in edge artifacts, rather than appearing in two entirely separate places. Solutions? 1) Shoot the film at 30 fps. 2) Use a shuttered TV camera. -- Stephen J King ...{utzoo|mnetor}!dciem!dretor!king -- Stephen J King ...{utzoo|mnetor}!dciem!dretor!king
haitex@pnet01.cts.com (Wade Bickel) (09/04/88)
Thanks Randall,
My point exactly.
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM
Opionions expressed are mine, and not necessarily those of my employer.