Path: utzoo!utgpu!watmath!iuvax!ndcheg!uceng!mfinegan From: mfinegan@uceng.UC.EDU (michael k finegan) Newsgroups: comp.graphics Subject: Re: SigGraph Fractal Compression Message-ID: <1934@uceng.UC.EDU> Date: 17 Aug 89 15:55:24 GMT References: <444@mit-amt.MEDIA.MIT.EDU> <20400001@inmet> Organization: Univ. of Cincinnati, College of Engg. Lines: 36 rich@inmet writes: >I suppose people are referring to the Michael Barnsley's demo at the AT&T Pixel >Machine booth. ~ ~ ~ >Remember decompressing really means applying fractal equations over and over >again (like in painting a Mandelbrot). The amazing thing is that he was >"decompressing" the pictures at video rate: 22 pics per second. I have seen the Pixel Machine ads: "up to 820 MFLOPS ...". Is the fact that he could decompress quickly on a Pixel Machine meaningful? Wouldn't you have to know how many DSP32's (~10 MFLOP) were being used (i.e. how many MFLOPS) and then talk about how many MFLOPS/(row X col picture) to decompress? At 820 MFLOPS/sec the demo you saw could have been 37 MFLOP/picture to decompress (size of images?), which might be a higher degree of complexity than for discrete cosine transform, etc. For comparison, the AT&T DSP Review (Winter '89) shows an example of the use of a DSP16A (integer based ~ 30 MIPs) to perform DCT of full-color (24 bits/pixel) images, with compression of 32:1. That would transform a 3/4 Meg input file (512 X 512 X 24bpp) into ~24K output file. The transformations (compress or decompress) each take 1/2 second (at ~30 MIPS). While MIPS and MFLOPS are different animals, the DSP16's could also be used in parallel, and at 820 MIPs the DCT methodology would yield ~54 pics per second (compress or uncompress). This makes the fractal decompression look pretty good (1/2 performance of current methods); what about fractal compression? I was under the impression that encoding the image using 'fractal analysis' took many orders of magnitude longer than the decoding ... - Mike Finegan finegan@aicv01.ece.UC.EDU mfinegan@uceng.UC.EDU