Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!cs.utexas.edu!usc!venera.isi.edu!raveling From: raveling@isi.edu (Paul Raveling) Newsgroups: comp.graphics Subject: Re: Compression of multi-bit images Message-ID: <13906@venera.isi.edu> Date: 13 Jun 90 17:31:50 GMT References: <8099@b11.ingr.com> <1990Jun7.114905.1714@athena.mit.edu> <27663@pprg.unm.edu> <2926@demo.COM> Sender: news@venera.isi.edu Reply-To: raveling@isi.edu (Paul Raveling) Organization: USC Information Sciences Institute Lines: 30 In article <2926@demo.COM>, jgk@demo.COM (Joe Keane) writes: > In article <27663@pprg.unm.edu> krukar@pprg.unm.edu (Richard Krukar [CHTM]) > writes: > > I worked with various images compression schemes a few years ago > >and I found a very disgusting method. Two steps: > > 1) Write up your favorite predictor. > > 2) Run compress ( LZW compression ) on the error image. > > I don't think this is disgusting at all. Compress is a useful, general > utility, so there's no point in re-implementing it. I agree, though it seems to me that its implementation should run faster. Someday I'll probably try to reimplement a fast version of the same algorithm. You might want to look at module fileutil.c in the imglib portion of the Img Software Set. Two functions, open_yafile and close_yafile, encapsulate a simple way to do this: If the name of the file to be opened ends in .Z, open_yafile invokes uncompress or compress and returns a pipe from/to that program, using popen(); otherwise it simply opens the file. The application can then read or write files as if they're simple uncompressed data, even if they're actually compressed. ---------------- Paul Raveling Raveling@isi.edu