Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!djohnson
From: djohnson@jarthur.Claremont.EDU (Arctic Sirocco)
Newsgroups: comp.graphics
Subject: Re: Alchemy on PC (JPEG compression): some findings
Message-ID: <10478@jarthur.Claremont.EDU>
Date: 25 Jan 91 19:47:41 GMT
References: <1115@accucx.cc.ruu.nl>
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 26

In article <1115@accucx.cc.ruu.nl> jaapv@accucx.cc.ruu.nl (Jaap Verhage) writes:
>
>7. Anyone care to share some light on these observations? E.g., why does
>   WINDOWJV.GIF, when compressed-and-then-decompressed, come out much bigger
>   than the original file? Any reason why Alchemy should do better on a scan
>   of a photograph (KATYA3.GIF) than on a raytraced image (WINDOWJV.GIF)? I
>   can imagine something to do with sharply defined borders between two
>   adjacent areas of uniform color; these will allways be *somewhat* blurred
>   in a scan of a photograph, but not necessarily so in a raytraced image, and
>   certainly not in the one I used.

Actually, the most probable reason for the increase in GIF image size after
processing with ALCHEMY is the DCT that operates on it. Since the DCT
effectively decimates some of the phase information (the sine terms of the
FFT) in the image (hence its "lossy" description), large pools of uniform
color will probably end up as large pools of many colors. These areas may
*look* the same to the eye, but when the GIF encoding (lempel-ziv) takes
place, the minute differences in colors in these areas which used to be
uniform will cause the compression ratio to drop enormously. Think of trying
to compress a string of 255 pixels, all with a value "15233" - and then
compressing a string of 255 pixels, all random.

This is probably less noticable with scanned images as they are usually
fairly randomly distributed to begin with. Raytraced images, however, do
tend to have large areas of uniform color, as do "painted" or hand-drawn
files.