jaapv@accucx.cc.ruu.nl (Jaap Verhage) (01/24/91)
Recently, the program Alchemy was posted to alt.sex.pictures. As I was rather impressed by the included file SAMPLE.JPG, I decided to try out the program on some GIF files. I chose two: one from alt.sex.pictures, KATYA3.GIF, showing a naked masturbating girl with lots of nicely tanned skin-tones (among other things). I guess this is a scan of a color photograph. The second file is a raytraced picture made by Dkbtrace from a modified version of its sample input file, WINDOW.DAT. The output was a Targa file, which was converted to GIF by Piclab version 1.82 with dithering off and called WINDOWJV.GIF. The picture contains a uniformly blue globe on a brown wooden floor; in the globe, a white windowpane is reflected, as well as some of the floor. Both GIF files are 640x480 pixels, 256 colors. What I did comes down to this: I compressed the pictures with Alchemy on my PC, using various quality settings, resulting in compressed files with the extension .JPG. I then decompressed them back into GIFs and viewed them with Cshow version 8.21b. I marked compression and decompression times and ratios and formed an opinion about the quality of the resulting GIFs, compared to the originals. Quality settings used were 1, 16, 32, 48, 64, 80, and 96. I tried compressing with dithering on (the default) and with dithering off. For the other options, I used the defaults; naturally, I indicated I wanted a GIF file when decompressing. Results of all this, on a 12 MHz Laser AT clone with a 40 MB hard disk, 28 msec access time were as follows. 1. The compression ratio of Alchemy is impressive, no doubt about that - if you choose the right file to compress. Sizes of the .JPG files generated from KATYA3.GIF by Alchemy were from 6 to 48% (dithering on) and 5 to 45% (dithering off) of the original GIF file size: 145244 bytes. However, trying the same thing on WINDOWJV.GIF turned out different results: sizes of the .JPG files were from 16 to 123% (dithering on or off made essential- ly no difference) of the original size, 44916 bytes. Generally, the .JPG files get bigger if you set a higher quality setting while compressing, which I would expect: the more information you try to retain, the more has to be stored, right? But making a compressed file bigger than its original goes a bit too far, in my opinion. 2. Compression times: for KATYA3.GIF, these ranged from 110 to 127 seconds with dithering on, and from 115 to 126 seconds with dithering off. For WINDOWJV.GIF, the timings were from 108 to 117 seconds (dithering on) and from 109 to 118 seconds with dithering off. Compression times grow with increasing quality settings. 3. Now, if you decompress the .JPG files back into GIFs, interesting things happen. For KATYA3.GIF, resulting file sizes were from 48 to 103% (dithering on in the .JPG file) and from 46 to 97% (dithering off) of the original GIF file size. For WINDOWJV.GIF, these figures ranged from 109 to 286% (dithering on or off in the .JPG files made essentially no differen- ce). Yes, 286%! That's almost *three* times as big as the original. 4. Decompression times: from 289 to 334 seconds for KATYA3.GIF with dithering on in the .JPG files, from 303 to 338 seconds with dithering on. Decompres- sing WINDOWJV.JPG back to WINDOWJV.GIF lasted from 297 to 325 seconds with dithering on in the .JPG files, and from 297 to 326 seconds if the .JPG files had been made with dithering off. Again, decompression takes longer for a higher quality (and thus, genarally, larger) .JPG file. This means that I could drum my fingers on the table for around 5 minutes waiting for each file to be decompressed. 5. As for quality of the resulting decompressed pictures, the results are rather conflicting. KATYA3.GIF was fairly like its original if I used quality 48 or higher; 32, the default setting, was more than reasonable. However, I did notice differences between the original and *all* of the compressed-and-then-decompressed files. These were more noticeable with dithering on than with dithering off. In both cases, however, small patches of color, different from their surroundings, appeared where these were absent or blended much more smoothly with their surroundings in the original. Furthermore, a higher quality setting when compressing didn't always produce better results in the decompressed files. Let me say, however, that I studied the pictures fairly extensively (it's remarkable how the erotic effect wanes when you do this :-)); a casual observer might not notice all the differences I did. WINDOWJV.GIF produced bad results, period. Worse with dithering on than with dithering off, but still bad with dithering off. Particularly borders between two regions of uniform color came out blurred and distorted, `noisy' I'd say. 6. Coming to conclusions: I won't be using Alchemy in the future to store GIF files in compressed format. For me, the differences between the original files and their compressed-and-then-decompressed counterparts are too noticeable. However, there is an option in Alchemy to produce a so-called `uniform pallette'; I haven't used this, as I don't know what it's for (the documentation doesn't make this clear to me) and it may change my ideas. If I try it, I'll post the results to this newsgroup. 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. 8. Today, I found three images in alt.sex.pictures intended to demonstrate the effects of JPEG compression on a GIF file: the original file, and two GIF files decompressed from a `medium quality' and a `high quality' compressed version of the original. In my opinion, the quality of the original was so bad (200x200 pixels, 256 colors, containing a girl's face) that I can't take it seriously as a yardstick to measure the effects of JPEG compression by. -- Regards, Jaap. Jaap Verhage, Academic Computer Centre, State University at Utrecht, Holland. jaapv@cc.ruu.nl +<-*|*->+ I claim *every*thing and speak for myself
jaapv@accucx.cc.ruu.nl (Jaap Verhage) (01/24/91)
In article <1115@accucx.cc.ruu.nl> jaapv@accucx.cc.ruu.nl (Jaap Verhage, that's me) writes: > >Recently, the program Alchemy was posted to alt.sex.pictures. As I was rather >impressed by the included file SAMPLE.JPG, I decided to try out the program >on some GIF files. [...] >6. Coming to conclusions: I won't be using Alchemy in the future to store GIF > files in compressed format. For me, the differences between the original > files and their compressed-and-then-decompressed counterparts are too > noticeable. However, there is an option in Alchemy to produce a so-called > `uniform pallette'; I haven't used this, as I don't know what it's for (the > documentation doesn't make this clear to me) and it may change my ideas. > If I try it, I'll post the results to this newsgroup. I've done that - it isn't any help. The pictures come out in a kaleidoscope of colors, not at all like the original ones. Just due to my ignorance, I guess. -- Regards, Jaap. Jaap Verhage, Academic Computer Centre, State University at Utrecht, Holland. jaapv@cc.ruu.nl +<-*|*->+ I claim *every*thing and speak for myself
lance@motcsd.csd.mot.com (lance.norskog) (01/25/91)
For my ray-trace experiments, I found that the system V 'pack' program (which uses Huffman compression, not LZW, thus evading patent restrictions :-) does quite a good job on GIFs. It's possible that the GIFizer programs, pgmtogif and a couple libraries, were lazy. But, you can give it a shot. The freed Berkeley program suite might include the 'compact' and 'uncompact' programs, which are also Huffman-based. Huffman compression, as you all know, was the first commonly used data compression algorithm and doesn't drop any bits. Enjoy.
djohnson@jarthur.Claremont.EDU (Arctic Sirocco) (01/26/91)
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.
jaapv@accucx.cc.ruu.nl (Jaap Verhage) (01/28/91)
A while ago, I posted some of my findings with Alchemy, notably compressing existing GIF files with various quality settings, then decompressing them and comparing the results with the originals. Results were mediocre to bad. Several people reacted to this, writing that starting out with GIFs was not the way to do this. I agree. So, I then took a 24-bit Targa file and 1) converted it directly into GIF with Piclab, in order to be able to view it; 2) converted it directly into GIF with Alchemy; 3) compressed it, using various quality settings, then decompressed the resulting images back into GIFs. Findings were as follows: 1) the best direct conversion Targa->GIF was done by Piclab with dithering off. Alchemy was not bad, but just not as good with dithering off. With dithering on, Alchemy delivered a bit better than Piclab. However, I *hate* this dithering: spurious dots all over the place. 2) GIFs resulting from compressed Targa-images were bad, period. No amount of dithering on/off or quality setting would help. I've heard that version 1.1 of Alchemy contains a bug when decompressing a .JPG file; it should be fixed in 1.3. Well, I believe it's time the original authors posted this version as an evaluation copy. You don't think I'll even *think* of registering on the basis of a 1) crippled, 2) buggy version, do you? 3) As things now stand, Alchemy performs badly for me. I'll feed it down the drain and wait with JPEG compression until Tom Lane's group comes out with something. In the meantime, I strongly suggest that, if images are being posted to whatever newsgroup, they be GIF files and not JPEG compressed ones. I'm *not* impressed with what I've seen up till now. -- Regards, Jaap. Jaap Verhage, Academic Computer Centre, State University at Utrecht, Holland. jaapv@cc.ruu.nl +<-*|*->+ I claim *every*thing and speak for myself
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/29/91)
In article <1115@accucx.cc.ruu.nl> jaapv@accucx.cc.ruu.nl (Jaap Verhage) writes: | | Recently, the program Alchemy was posted to alt.sex.pictures. As I was rather | impressed by the included file SAMPLE.JPG, I decided to try out the program | on some GIF files. | I chose two: one from alt.sex.pictures, KATYA3.GIF, showing a naked | masturbating girl with lots of nicely tanned skin-tones (among other things). | I guess this is a scan of a color photograph. The second file is a raytraced | picture made by Dkbtrace from a modified version of its sample input file, | WINDOW.DAT. The output was a Targa file, which was converted to GIF by Piclab | version 1.82 with dithering off and called WINDOWJV.GIF. The picture contains | a uniformly blue globe on a brown wooden floor; in the globe, a white | windowpane is reflected, as well as some of the floor. Both GIF files are | 640x480 pixels, 256 colors. Although I am neither an author or fan of that program, if you have the original 24 bit Traga file, you might try converting the Targe to JPEG, then the JPEG to GIF for vieweing. It's my impression that Alchemy reacts very badly to data in some GIF files, possibly caused by the dithering, if any. I have seen many cases where it combines a visible loss of quality with actually making the file (after conversion back to GIF) larger than the original, as well as fuzzy. The worst of both worlds... -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me