Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!utarlg.utarl.edu!b645zai From: b645zai@utarlg.utarl.edu (Jay Finger) Newsgroups: comp.graphics Subject: Re: Next machine as animation platform Message-ID: <10074@helios.TAMU.EDU> Date: 14 Nov 90 19:08:07 GMT References: <85866@tut.cis.ohio-state.edu> Sender: usenet@helios.TAMU.EDU Reply-To: b645zai@utarlg.utarl.edu Followup-To: comp.graphics Organization: Computer Science and Engineering, U. of Texas at Arlington Lines: 71 In article , velasco@beowulf.ucsd.edu (Gabriel Velasco) writes... >From: Kim_Orumchian@NeXT.COM > >>I think what the discussion below hinges on what is meant by >>"broadcast quality". Images that are compressed and played back by a >>NeXTdimension are not going to look as good as those produced frame by >>frame on a dedicated video production system. > >Why? This is not a flame. I am really wondering where the deficiency is. Is >it in the hardware? The software? The compression algorithm? The original >poster was talking about producing the sequences frame by frame. > >>Another issue is that even though the NeXTdimension's JPEG compressed >>images may not be as high resolution as what production houses have >>today, > >I am not at all familiar with NeXTdimension's JPEG compressed images. What >type of algorithm do they use? Is it delta modulation? Run length encoding? >Send only changes from one frame to the next? Selective color mapping? First of all, I am not very familiar with video compression, so you may want to take this with a few grains of salt: JPEG is a large consortium (sorry, but I don't know what it stands for). "JPEG Compression" itself denotes an industry wide algorithm(s) that many people are using or are planning to use. What algorithms it is based upon I have no idea. It's relatively new, and requires a *LOT* of processing. C-Cube is the first with a single chip solution that can do the compression in real time. The compression used is not fully recoverable. That is, some information gets lost, you may lose some detail, colors may change a little etc. Ever you've every watched something compressed and the de-compressed with this chip though, you won't be dissapointed. For normal TV you can't tell the difference, at 640x480 only if you're trying to notice. The reason stuff produce on the NeXT dimension (or any other similar system, it's *NOT* a matter of NeXT doing something stupid) will not be as good as dedicated equipment, is as follows: When producing on a NeXTdimension, you produce a frame, compress it (through the C-Cube chip) save it. Do the next frame compress, append to end of first. And so on. When you record to tape, you're just playing the recorded images back in real time, letting them be expanded by the C-Cube chip. The dedicated hardware Kim was talking about (I think) is capable of taking each frame as you produce it, and recording that single frame to tape. Then you produce the next frame, record straight to tape. What's different? You're not compressing and re-expanding each frame. The idea though, is that the compression algorithms are (hopefully) good enough that a viewer who isn't looking for differences will never see them. >If NeXTdimension is using 32 bit color (mentioned later in the article) >then isn't that *better* than what production houses are using? HDTV >is only 24 bit color. How are the 32 bits divided into the three >colors? > 32 bits = 8 Red + 8 Green + 8 Blue + 8 Alpha. The alpha channel is used for transparency information (I think). >The author is treating the "compression" like a dirty word. >Compression need not decrease the quality of the image any. It depends >on the type of compression. He's not treating it like a dirty word. He simply knows that it is not perfect, and is trying to keep people from thinking that. ---- Jay Finger Computer Science and Engineering, University of Texas at Arlington b645zai@utarlg.utarl.edu finger@csun5.utarl.edu