Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!dino!news.iastate.edu!du248-09.cc.iastate.edu!skank From: skank@du248-09.cc.iastate.edu (Skank George L) Newsgroups: comp.sys.amiga Subject: Re: Compression Message-ID: <1990Oct6.060719.28484@news.iastate.edu> Date: 6 Oct 90 06:07:19 GMT References: <3266@orbit.cts.com> <1990Oct3.215038.8863@zorch.SF-Bay.ORG> Sender: usenet@news.iastate.edu (USENET News Poster) Reply-To: skank@iastate.edu (Skank George L) Organization: Iowa State University Lines: 28 In article <1990Oct3.215038.8863@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >koleman@pnet51.orb.mn.org (Kurt Koller) writes: >>Why don't the people that write the LHArc, Zip, etc stuff for the Amiga >>compile a Floating-Point version and include that as well? If this has been >>done, where can I find it? >> >>Kurt "Koleman" Koller - amdahl!bungia!orbit!pnet51!koleman > >Maybe I'm being a bit dense, but since I make data compression one of my >specialties, I don't think so: what in the world has "floating point" >to do with data compression? Moreover, if there were some way to convert >the present, in their essence integer based, algorithms to floating point, >why would anyone want to slow them down that much? > >Kent, the man from xanth. > I think the origional author is probably a little confused. In numerical analysis theory, there is a form of image compression where an image is represented by a matrix (the matrix has a bunch of special properties), the matrix is operated on (using floating point) to produce a second matrix. This new matrix is much smaller and has had image 'noise' reduced. This process results in an overall loss in image resolution, however it is often possible to obtain LARGE (100x) reductions in the size of the image data with only minimal (read: impreceptible) loss of resolution, additionally, since this is a noise compression process the final picture will often look much better than the origional. --George