Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ncar!elroy.jpl.nasa.gov!usc!apple!netcom!marcos From: marcos@netcom.UUCP (Marcos H. Woehrmann) Newsgroups: comp.graphics Subject: Re: Request info on DCT based compresseion/decompression Message-ID: <12281@netcom.UUCP> Date: 21 Aug 90 06:19:27 GMT References: <1233@swan.ulowell.edu> <1990Aug17.210410.28762@nimbus3.uucp> Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest} Lines: 58 In some old article, djs@nimbus3.uucp (Doug) writes: > > My understanding is that the JPEG compression algorithm is for still pictures > and that the motion-picture compression algorithm was being developed by > MPEG but would not be available for a year or two. Yet the chip from C-cube > says that they achieve 40 fold compression on frame to frame. If this is > true, what algorithm are they using for the frame to frame compression? > > Second, if much of the compression is from frame to frame redundancy, what > happens in multi-media applications that want to jump around to various > points in time? Does that mean that after it first jumps to a new time > point the display will be blury because it doesn't have the previous > information or do they jump to some time before the desired point to > get the previous information? > JPEG and MPEG are both currently being drafted. JPEG is much further along; draft Release 5 has been out for 3 months and release 8 is due out at the end of Oct. (there was no Release 6 or 7, as far as I can tell). The final draft will be out early in 1991 (I suppose it shouldn't really be called a draft if it final). The first MPEG draft is supposed to be released near that time too. C-Cube's current silicon implementation is JPEG R5 and is indeed a still frame image compression technique. However what the C-Cube chip can do is to decompress an image in less than a 30th of second. So they can simulate video by continously decompressing and displaying frames. But because JPEG does not rely on previous frames they only get 20 to 40 fold compression (I say only because MPEG will do much better than that). What I've heard is that to allow interactivity MPEG will have the ability to have certain frames designated as "entry" frames. The software can then jump to these frames from anywhere and not have to rely on previous frames. Yes, the scene will be "fuzzy" (chunky?) for a few frames if you are using a severly bandwith limited devices (CD-ROMs) (otherwise the system will temporarily require more data). But remember this is the same as having a scene change (well, not quite the same, since the system has pre-knowledge of the scene change and could pre-initialize the new scene (though I don't know if MPEG will allow that]. For those of you who have seen the Philips CD-I demo of Batman I suspect the artifacts will be similar to the chunkiness exhibited during scene changes: not particularly noticable unless your looking for it (remember, in the U.S. most people think VHS looks good). marcos (Oh, yes, I don't speak for JPEG, MPEG, or C-Cube (nor anyone else even mildly important, for that matter]. -- Marcos H. Woehrmann {claris|apple}!netcom!marcos or marcos@netcom "These are but a few examples of what can happen when the human mind is employed to learn, to probe, to question as opposed to merely keeping the ears from touching." -- rec.humor.funny 90.07.16