crowl@cs.rochester.edu (Lawrence Crowl) (03/17/90)
In article <132563@sun.Eng.Sun.COM> poynton@vector.Sun.COM (Charles A. Poynton) writes: >... the case for 1920x1080 as leading to economical framebuffer >implementations (due to its total of two megapixels) and offering an >excellent compromise among the choices proposed for picture line count >(966, 1035, 1080 and 1152). Why not 2048x1024? This is easy to address, easy to store, exactly and two mega-pixels. Why is it that the proposed standards have picked such bizzare numbers? If people are serious about making images easy to manipulate on computers (and only the terminally unimaginative would not be), then we should choose a frame size that is very easy to manipulate on computers. >Experts agree that a single international standard [for frame rate] cannot be >achieved at any one of 25, 29.97 or 30 Hz. A very large fraction of >broadcast programming is currently originated at 24 Hz so that rate is >amenable to broadcast. If a frame rate other than 24 Hz is adopted for HDTV, >then movies will continue to be produced on film to assure continued access >to the international markets that 24 Hz film currently enjoys in cinema, >television, videotape and videodisc distribution. I have two concerns. First, the frame rate should be high enough so that there is no observable flicker. Second, the frame rate should not be close enough to existing power line frequences to cause the screen to beat with flourescent lighting. Which rates have which problems? -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{ames,rutgers}!rochester!crowl Rochester, New York, 14627
myers@hpfcdj.HP.COM (Bob Myers) (03/20/90)
>I have two concerns. First, the frame rate should be high enough so that >there is no observable flicker. Second, the frame rate should not be close >enough to existing power line frequences to cause the screen to beat with >flourescent lighting. Which rates have which problems? Two problems here; first, increasing the frame rate of the transmitted image will eat up bandwidth like nobody's business, and for no particularly good reason. If you're really worried about getting a flicker-free image, then the best way to go about it while still having reasonable TV channels (the RF spectrum is *not* in infinite resource), then I'd suggest broadcasting at 24 or 30 frames/second (there are some good reasons for picking 24), and putting the received image into a frame store. You can then *display* the image at your choice of rates - 72 Hz sounds like a good number. The second problem has to do with a common misunderstanding - "beating" with fluorescent lighting is *not* a primary cause of CRT flicker (for that matter, how many home viewers use fluorescent lighting in the TV viewing area?). CRT flicker is basically a function only of refresh rate, brightness, and the ambient lighting *level*. "Beating" with the lights is a secondary problem, occuring due to a perceived change in the contrast ratio of the screen as the reflected light changes. It's usually not a big deal, and in most situations displays will appear to flicker worse with the local lights OFF - due to the fact that the apparent brightness of the displayed image increases. (Also, consider the fact that many workstations in the U.S. are now using refresh rates in excess of 60 Hz - the nominal line frequency - and have *better* flicker performance than their 60 Hz cousins. The best compromise, IMHO, between bandwidth and flicker would require either a sufficiently cheap full-color frame store or some other technique which would allow broadcast at 24 frames/sec. and display at 72. Bob Myers KC0EW HP Graphics Tech. Div.| Opinions expressed here are not Ft. Collins, Colorado | those of my employer or any other myers%hpfcla@hplabs.hp.com | sentient life-form on this planet.
sehat@iit (Sehat Sutardja) (03/20/90)
In article <1990Mar16.205807.5971@cs.rochester.edu>, crowl@cs.rochester.edu (Lawrence Crowl) writes: > Why not 2048x1024? This is easy to address, easy to store, exactly and two > mega-pixels. Why is it that the proposed standards have picked such bizzare > numbers? If people are serious about making images easy to manipulate on > computers (and only the terminally unimaginative would not be), then we should > choose a frame size that is very easy to manipulate on computers. > The main reason to this is because in many digital motion video compression algorithm such as the motion compensated DCT, some extra video memory area may be needed to store some temporary image data. If you use all of the frame buffer, then you need additional storage chips to do this function. Since the reduction in resolution is insignificant compared to the reduction in cost, the trade off is justifiable. -- Sehat Sutarja, {decwrl!sun}!imagen!iit!sehat | Integrated Information Tech. sutarja@janus.Berkeley.EDU | Santa Clara, CA. (408)-727-1885