From netaxs.com!netnews.upenn.edu!dsinc!newsfeed.pitt.edu!hudson.lm.com!netline-fddi.jpl.nasa.gov!nntp.et.byu.edu!cwis.isu.edu!isuux.isu.edu!not-for-mail Sun Feb 12 00:59:32 1995 Path: netaxs.com!netnews.upenn.edu!dsinc!newsfeed.pitt.edu!hudson.lm.com!netline-fddi.jpl.nasa.gov!nntp.et.byu.edu!cwis.isu.edu!isuux.isu.edu!not-for-mail From: selljame@isuux.isu.edu (SELLMAN_JAMES_K) Newsgroups: alt.binaries.pictures.misc,alt.binaries.pictures.cartoons,alt.pictures.fuzzy.animals,alt.binaries.pictures.animals,alt.binaries.pictures.furry,alt.binaries.pictures.d,alt.binaries.pictures.tasteless,alt.binaries.pictures.supermodels Subject: My Final Answer To GIF vs. JPEG vs. WHATEVER Date: 8 Feb 1995 15:01:36 -0700 Organization: Idaho State University, Pocatello Lines: 125 Message-ID: <3hbf00$j0s@isuux.isu.edu> Reply-To: selljame@isuux.isu.edu NNTP-Posting-Host: isuux.isu.edu Xref: netaxs.com alt.binaries.pictures.misc:75896 alt.binaries.pictures.cartoons:6695 alt.pictures.fuzzy.animals:268 alt.binaries.pictures.furry:1563 alt.binaries.pictures.d:17705 alt.binaries.pictures.tasteless:14084 alt.binaries.pictures.supermodels:41491 JPEG is a format designed for entirely different applications than GIF. It has its place, but so does GIF. GIF's Lempel-Ziv approach to compression means that repeated patterns and long stretches of solid color will compress extremely well. Color gradients will not. Since GIF is a lossless compression scheme, solid lines will retain their integrity, and minute details will be preserved. GIF is probably the best standard for the compression of hand-drawn art outside of gradient-heavy drawing apparatus such as watercolor and airbrush. GIF is also the best format for the compression of graphic text, diagrams, and blueprints. All of which compress extremely well under the LZ scheme. Furthermore, GIFs are the only intelligent compression scheme if your data is already 256 colors or less. JPEGs set to a high enough quality level to appear even remotely unchanged invariably wind up larger. This difference varies inversely with the number of bits per pixel. Since grayscale images are almost always 8 bpp or less, it makes sense to try GIF on the image as well as the B+W JFIF JPEG standard, which only works well on gradient-heavy grayscale pictures. GIF also has the advantage of the GIFBlast compressor, which takes an average of 20-30% off of the already highly-compressed GIF format. The performance of GIF + GIFBlast is simply amazing. The JPEG standard describes a compression scheme, rather than a file format. That is why you will occasionally see a format other than the familiar JFIF format, which has becom a standard. JPEG compresses by dividing up an image into blocks, then breaking the light levels into component frequencies (via a DCT). Different levels of block/frequency quantization are used to alter the quality/compression ratio. The JFIF format also supports Huffman aftercoding to further compress the file. Because of the way JPEG works, sudden changes in color and intensity do not survive well within a given block. The fewer shared component frequencies the less accurate the display will be within a given block. This creates a "fringing" effect which is the trademark of the JPEG system. Loss occurs even at a 1 to 1 block quantization level (100% quality) because of the frequency breakdown. This results in a "noise" error, rather than a fringing effect, because each error is affecting a very small area. As I said, JFIF is not the only image format which uses the JPEG compression scheme. Stanford University has released code for a lossless JPEG format, which compressed far better than any other lossless 24-bit format on most files. Unfortunately, this system never caught on and I have never seen any code supporting it aside from the Stanford code. 24-bit lossless compression is therefore limited to more conventional LZW and RLE schemes. I have found that images will compress better under one of two formats - TIFF-LZW, and IFF24. The TIFF format offers three means of encoding image data. Raw, RLE, and LZW. The run-length mode doesn't work very well, and using the Raw mode is pretty pointless, so I'll just talk about the LZW. LZW is of course one of the Lempel-Ziv family of compression schemes. That is it copies data verbatim until it hits a repeated pattern, which is replaced with a pointer to the original data. This scheme works very well on compression of regular or self-similar objects with solid areas of color. Most images will turn out better in LZW format. The only exception is images with certain kinds of color gradients. IFF24 will compress approximately 10-20% of the 24-bit images I have come across better than TIFF-LZW. IFF24 uses a run-length compression scheme, which is algorithmically inferior to the LZW scheme which TIFF employs. How then could it ever compress better? The answer lies in the way it stores the raw image data. IFF24 is a 'planar' system, meaning data is stored in a series of layers, or planes. When the data in the corresponding sections of a given plane are combined, the final image results. IFF24 is this way mainly because it is an extension of the IFF-ILBM image format, which was designed around the Amiga computer's quirky-yet-effecient planar display system. Because of this seperation of data, images which modify only some of the planes will still realize compression, because there will be strings of identical bytes in some of the unmodified areas, whereas if it were all together it would form a hopless jumble of varying bytes. This type of image will only show up around 1/5 - 1/10th of the time, but it is a useful thing to note. Futhermore, IFF24 can compress even further through the use of an external program which employs a LZ, Huffman, or arithmetic compression scheme. Each of these formats has its own merits.... Which ones you use largely depends on the data you wish to store. Generally the following works well: GIF + GIFBlast - Any image <= 256 colors. Line art and B+W drawings. Diagrams and blueprints. Bitmapped text. JFIF-JPEG - 24-bit digitized images where viewability, not precision is required. 8-bit grayscale photographs (same criteria). Low-quality, storage-sensitive uses (e.g. catalogs, indexes) TIFF-LZW - Most precision 24-bit uses. DTP images. Regular or repeating images. Large areas of solid color. IFF24 - 24-bit images with lots of color gradients, without lots of sharp contrasting lines. These uses have come from years of pesonal experimentation, driven by an eternal lack of disk space. :-) For long-term archival purposes one should try using a low or no compression image format to store the image then compress it with a high quality general-purpose compressor (such as Matthias Meixner's excellent Shrink). GIFBlast will generally do better on low-color images but 24-bit images will benefit greatly. On an interesting note, all of the compression schemes used here (except JPEG) employ a horizontal line-by-line method of compression. You might do well to use an image-processing program to rotate you image 90 degrees. :-) You never know. :-) I *HAVE* seen one vertically-oriented compression scheme, employed by the Amiga program IFFConvert. It's a modification of the IFF-ILBM standard which uses multiple-column vertical run-length encoding. :-) It's really fast and generally does close to GIF compression levels. (And has the bonus of being further compressable by LZ schemes). It's a shame no other software supports it. :-( I hope this clears up some of the image-format confusions. :-) - Jim "The cost of living has in no way reduced its popularity." From netaxs.com!netnews.upenn.edu!dsinc!newsfeed.pitt.edu!godot.cc.duq.edu!news.duke.edu!agate!howland.reston.ans.net!ix.netcom.com!netcom.com!skant Sun Feb 12 00:59:33 1995 Newsgroups: alt.binaries.pictures.misc,alt.binaries.pictures.cartoons,alt.pictures.fuzzy.animals,alt.binaries.pictures.animals,alt.binaries.pictures.furry,alt.binaries.pictures.d,alt.binaries.pictures.tasteless,alt.binaries.pictures.supermodels Path: netaxs.com!netnews.upenn.edu!dsinc!newsfeed.pitt.edu!godot.cc.duq.edu!news.duke.edu!agate!howland.reston.ans.net!ix.netcom.com!netcom.com!skant From: skant@netcom.com (Skant) Subject: Re: My Final Answer To GIF vs. JPEG vs. WHATEVER Message-ID: Followup-To: alt.binaries.pictures.misc,alt.binaries.pictures.cartoons,alt.pictures.fuzzy.animals,alt.binaries.pictures.animals,alt.binaries.pictures.furry,alt.binaries.pictures.d,alt.binaries.pictures.tasteless,alt.binaries.pictures.supermodels Organization: Dracovarian Heavy Explorer Vessel _-UFSDEF FarSeer-_ X-Newsreader: TIN [version 1.2 PL1] References: <3hbf00$j0s@isuux.isu.edu> Date: Thu, 9 Feb 1995 21:32:32 GMT Lines: 44 Sender: skant@netcom18.netcom.com Xref: netaxs.com alt.binaries.pictures.misc:76000 alt.binaries.pictures.cartoons:6726 alt.pictures.fuzzy.animals:269 alt.binaries.pictures.furry:1574 alt.binaries.pictures.d:17730 alt.binaries.pictures.tasteless:14111 alt.binaries.pictures.supermodels:41724 I mostly agree. }:> However, I don't agree with the 256 colors or less always compresses better with GIF. Once again it depends on the software you are using. My software rather consistently compresses 256 color pictures into JPEGs of visually identical quality (and I've got a nice sharp 17 inch monitor };> ) which are about three times smaller than the GIFs. That's not true for graphs and such of course. }:> But your stipulation said _any_ 256 color or less image. 256 color photographic(ish) images at least can compress better if your software is up to the task. JPEG is a rather unique format in that it's about the only format where your mileage may vary depending on your hardware and software. Varying from aweful to perfect. You seemed to indicate that JPEGs display with fairly poor quality on your system as well as being larger than the GIFs much of the time. As I don't experience the same difficulties, I think you should be checking the quality of your software. }:> GIFBlast, I assume, is a program that implements lossy GIF compression? I've seen such schemes. They seem to work fairly well in a number of cases... adjusting the data slightly so the compression scheme gets more and larger dictionary hits. But off hand, they seemed to change the image more than JPEGs would even at fairly low qualities. However, that may well be a failing of _my_ software. And prolly is. }:> Oh, and by the way... the TIFF format offers several more compression schemes than that. }:> It also has some CCITT compressions, fax compressions, and some other _really_ exotic ones. And then you get into all the ways the data could be stored... etc etc etc... }:> The only standard things about TIFFs is how the data blocks are identified. TIFF is kinda like MIDI... with a lot of System Exclusive blocks... fortunately, most TIFF viewers understand most of the less exotic forms TIFFs can use. I agree or at least have no comment on the rest of you post. }:> Good job! Now stop posting on a binary group, dammit. }:> Skant slaps herself as well. -- _________________________________________________________________________ | ////////////// The evil nasty wicked bad Skant Dragon! \\\\\\\\\\\\\\\\ | | "I am going to blow up the Earth!! It obstructs my view of Venus!!" | | "Holy chameleon attack dwagins, Batman!" }:> skant@netcom.com | |_________________________________________________________________________| From netaxs.com!netnews.upenn.edu!msunews!caen!zip.eecs.umich.edu!panix!cmcl2!is.NYU.EDU!bjz9099 Sun Feb 12 00:59:33 1995 Path: netaxs.com!netnews.upenn.edu!msunews!caen!zip.eecs.umich.edu!panix!cmcl2!is.NYU.EDU!bjz9099 From: bjz9099@is.nyu.edu (Benjamin J. Zelevansky) Newsgroups: alt.binaries.pictures.misc,alt.binaries.pictures.cartoons,alt.pictures.fuzzy.animals,alt.binaries.pictures.animals,alt.binaries.pictures.furry,alt.binaries.pictures.d,alt.binaries.pictures.tasteless,alt.binaries.pictures.supermodels Subject: Re: My Final Answer To GIF vs. JPEG vs. WHATEVER Date: 10 Feb 1995 00:12:32 GMT Organization: New York University Lines: 65 Message-ID: <3heb1g$dfg@cmcl2.NYU.EDU> References: <3hbf00$j0s@isuux.isu.edu> NNTP-Posting-Host: is.nyu.edu X-Newsreader: TIN [version 1.2 PL2] Xref: netaxs.com alt.binaries.pictures.misc:76086 alt.binaries.pictures.cartoons:6748 alt.pictures.fuzzy.animals:270 alt.binaries.pictures.furry:1580 alt.binaries.pictures.d:17750 alt.binaries.pictures.tasteless:14142 alt.binaries.pictures.supermodels:41921 OH YEAH?!?!? I'd like to see you back that up with a little factual information next time, rather than on personal opinion and hearsay. And next timne, try to be more thourough! (ha ha) Skant (skant@netcom.com) wrote: : I mostly agree. }:> : However, I don't agree with the 256 colors or less always compresses better : with GIF. Once again it depends on the software you are using. My software : rather consistently compresses 256 color pictures into JPEGs of visually : identical quality (and I've got a nice sharp 17 inch monitor };> ) which : are about three times smaller than the GIFs. That's not true for graphs and : such of course. }:> But your stipulation said _any_ 256 color or less : image. 256 color photographic(ish) images at least can compress better if : your software is up to the task. JPEG is a rather unique format in that : it's about the only format where your mileage may vary depending on your : hardware and software. Varying from aweful to perfect. You seemed to : indicate that JPEGs display with fairly poor quality on your system as well : as being larger than the GIFs much of the time. As I don't experience the : same difficulties, I think you should be checking the quality of your : software. }:> : GIFBlast, I assume, is a program that implements lossy GIF compression? I've : seen such schemes. They seem to work fairly well in a number of cases... : adjusting the data slightly so the compression scheme gets more and larger : dictionary hits. But off hand, they seemed to change the image more than : JPEGs would even at fairly low qualities. However, that may well be a : failing of _my_ software. And prolly is. }:> : Oh, and by the way... the TIFF format offers several more compression : schemes than that. }:> It also has some CCITT compressions, fax : compressions, and some other _really_ exotic ones. And then you get into : all the ways the data could be stored... etc etc etc... }:> The only : standard things about TIFFs is how the data blocks are identified. TIFF is : kinda like MIDI... with a lot of System Exclusive blocks... fortunately, : most TIFF viewers understand most of the less exotic forms TIFFs can use. : I agree or at least have no comment on the rest of you post. }:> Good job! : Now stop posting on a binary group, dammit. }:> : Skant slaps herself as well. : -- : _________________________________________________________________________ : | ////////////// The evil nasty wicked bad Skant Dragon! \\\\\\\\\\\\\\\\ | : | "I am going to blow up the Earth!! It obstructs my view of Venus!!" | : | "Holy chameleon attack dwagins, Batman!" }:> skant@netcom.com | : |_________________________________________________________________________| -- Ben Zelevansky/Goddard 503A/79 Washington Sq. E./New York, NY/10003 (212) 443-6085/bjz9099@is.nyu.edu "Don't get your panties in an uproar." - Chris Peterson, "Get A Life" From netaxs.com!netnews.upenn.edu!msunews!caen!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!uunet!world!news.mtholyoke.edu!nntp.et.byu.edu!cwis.isu.edu!isuux.isu.edu!not-for-mail Sun Feb 12 00:59:33 1995 Path: netaxs.com!netnews.upenn.edu!msunews!caen!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!uunet!world!news.mtholyoke.edu!nntp.et.byu.edu!cwis.isu.edu!isuux.isu.edu!not-for-mail From: selljame@isuux.isu.edu (SELLMAN_JAMES_K) Newsgroups: alt.binaries.pictures.misc,alt.binaries.pictures.cartoons,alt.pictures.fuzzy.animals,alt.binaries.pictures.animals,alt.binaries.pictures.furry,alt.binaries.pictures.d,alt.binaries.pictures.tasteless,alt.binaries.pictures.supermodels Subject: Re: My Final Answer To GIF vs. JPEG vs. WHATEVER Date: 10 Feb 1995 14:45:42 -0700 Organization: Idaho State University, Pocatello Lines: 103 Message-ID: <3hgmq6$bcp@isuux.isu.edu> References: <3hbf00$j0s@isuux.isu.edu> NNTP-Posting-Host: isuux.isu.edu Xref: netaxs.com alt.binaries.pictures.misc:76145 alt.binaries.pictures.cartoons:6782 alt.pictures.fuzzy.animals:271 alt.binaries.pictures.furry:1583 alt.binaries.pictures.d:17761 alt.binaries.pictures.tasteless:14152 alt.binaries.pictures.supermodels:42033 Cc: > I mostly agree. }:> Geee..... :-) >However, I don't agree with the 256 colors or less always compresses better >with GIF. Once again it depends on the software you are using. My software >rather consistently compresses 256 color pictures into JPEGs of visually >identical quality (and I've got a nice sharp 17 inch monitor };> ) which >are about three times smaller than the GIFs. That's not true for graphs and >such of course. }:> But your stipulation said _any_ 256 color or less >image. 256 color photographic(ish) images at least can compress better if >your software is up to the task. I should have made myself more clear on this.... It *IS* true that they will compress better and be, at least at first glance, visually identical. This depends on the resolution of the image and the resolution of the display. My buddy regularly uses JPEG to compress his GIFs, but I don't. I guess that's because I'm a stickler for detail. If you examine a picture at 640x4xx or less resolution, chromatic bleeding becomes more apparent. While the casual viewer would do well to compress his GIFs to JPEG, I don't because I don't *WANT* even that minor distortion. When using good JPEG software you should usually smooth out the dithering to make the gradients etc. more fluid, and the resulting JPEG will be a much better match than if you had just JPEGed the dithered image. Unfortunately you lose clarity from the dithering. :-) JPEG is obviously the better format for even 256 color photographic images provided you don't care about the minute details. I guess I should have included that in my explanation... :-) > JPEG is a rather unique format in that >it's about the only format where your mileage may vary depending on your >hardware and software. Varying from aweful to perfect. You seemed to >indicate that JPEGs display with fairly poor quality on your system as well >as being larger than the GIFs much of the time. As I don't experience the >same difficulties, I think you should be checking the quality of your >software. }:> No I meant that the high-quality JPEGs usually wound up larger. :-) The low-quality ones of course turned out smaller. I just didn't want them. (see above) My definition of high quality is (using the traditional 1-100 scale) 90-100. :-) Like I said I *HATE* those little changes. They don't seem to show up as much if my original data was 24 bpp rather than 8. >GIFBlast, I assume, is a program that implements lossy GIF compression? I've >seen such schemes. They seem to work fairly well in a number of cases... >adjusting the data slightly so the compression scheme gets more and larger >dictionary hits. But off hand, they seemed to change the image more than >JPEGs would even at fairly low qualities. However, that may well be a >failing of _my_ software. And prolly is. }:> MY version of GIFBlast is lossless. It saves its own custom format (suffix .gfb). There may be a newer version that implements lossy but I'm not aware of one. The amazing thing about GIFBlast is that it gets 20-30% LOSSLESS. I have absolutely no idea how the algorithm works but I've never seen anything else that could take lossless data down further than it. (The Stanford lossless JPEG may well do so for 24-bit, but I haven't experimented...) >Oh, and by the way... the TIFF format offers several more compression >schemes than that. }:> It also has some CCITT compressions, fax >compressions, and some other _really_ exotic ones. And then you get into >all the ways the data could be stored... etc etc etc... }:> The only >standard things about TIFFs is how the data blocks are identified. TIFF is >kinda like MIDI... with a lot of System Exclusive blocks... fortunately, >most TIFF viewers understand most of the less exotic forms TIFFs can use. Yeah yeah I know I know. :-) The TIFF format is a mutant IFF format (which for some reason has been also mutated into AIFF and RIFF... :-( Why can't anyone stick with a standard that works just fine?) I was, of course, referring to the typical TIFF which contains typical image data blocks. I've never actually seen another application of this format (or for that matter of AIFF or RIFF... ) in actual use. Whereas I've seen dozens of different formats following the IFF block protocol. :-) >I agree or at least have no comment on the rest of you post. }:> Good job! Awwwww.... ::blush:: :-) >Now stop posting on a binary group, dammit. }:> THppptpppptpppptpppppppthhhhh!!!!!! All of this data is stored in binary. :-) It's just ASCII binary. :-) > Skant slaps herself as well. ::ahem:: >-- > _________________________________________________________________________ >| ////////////// The evil nasty wicked bad Skant Dragon! \\\\\\\\\\\\\\\\ | >| "I am going to blow up the Earth!! It obstructs my view of Venus!!" | >| "Holy chameleon attack dwagins, Batman!" }:> skant@netcom.com | >|_________________________________________________________________________| - Jim -- - Jim