Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!shelby!morrow.stanford.edu!fizzle.stanford.edu!eillihca From: eillihca@fizzle.stanford.edu (Achille Hui) Newsgroups: alt.sources.d Subject: Re: Compressing alt.sex.pictures files Message-ID: Date: 29 Aug 90 16:26:29 GMT References: <1990Aug27.154419.25882@mcs.anl.gov> <1990Aug28.192024.22435@zorch.SF-Bay.ORG> <6467@sugar.hackercorp.com> Sender: news@morrow.stanford.edu (USENET News System) Organization: Data Center, Stanford University, California, USA Lines: 32 peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Aug28.192024.22435@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> Hmmm. Good idea. Here's one suggestion for an experiment. Somewhere on >> the net, a month or two back, there was a suggestion that a good way to >> compress realistic images was to XOR scan lines after the first with their >> predecessor line, then LZW compress the output. >I believe that XORing alternate scan-lines and run-length-encoding the result >would do a better job. I've heard of this algorithm being pretty effective >in past discussions. Should one do this with the image bitplane-mapped or >pixel-mapped? >-- >Peter da Silva. `-_-' >. I have tried several things on several images: lighthouse, oldmill, lush (1024x768x ~ 256 ) each ~ 600k babe24 ( ~ 512 x ~ 800 x ~ 256 ) ~ 400k avaliable from ticsys.tamu.edu 1) just compress the raw image extracted from the gif files 2) XOR neighbouring scan lines in raw image and then compress it. 3) subtract neighbouring ...... 4) build a color index table for each scan line and it turns out the size of the resulting files .. 1) ~ 90% of original gif 2,3) ~ 110% 4) ~ 100% if we exclude the color index table for the lines! -eillihca@fizzle.stanford.edu