Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!spdcc!dirtydog.ima.isc.com!suitti From: suitti@ima.isc.com (Stephen Uitti) Newsgroups: comp.archives.admin Subject: Re: ftpmail data Message-ID: <1991Jun07.182035.10914@ima.isc.com> Date: 7 Jun 91 18:20:35 GMT References: <4139@motcsd.csd.mot.com> <1991Jun7.144706.11588@cs.utk.edu> Sender: usenet@ima.isc.com (news) Organization: Interactive Systems, Cambridge, MA 02138-5302 Lines: 130 In article <1991Jun7.144706.11588@cs.utk.edu> Dave Sill writes: >In article , garym@cognos.uucp@uunet.uu.net (Gary Murphy) writes: >> >>The only hope I've seen so far is to store on-line images >>as very low-quality JPEG files and make those interested in obtaining >>the real image arrange the transfer themselves. > >That's an interesting idea. I don't know anything about JPEG, but I >think Jef Poskanzer's PBM toolkit could be used to provide scaled-down >or reduced-number-of-colors versions of large GIF's. Most people >gobbling up the girlie pictures would be happy to preview them first, >I think. (I have no first-hand knowledge, of course :-) > >>While JPEG might save upwards of 80% on the image bandwidth (and >>provide images suitable for 90% of the requests), the downside is most >>prohibitive: the only vendor to date only supplies shareware decoders >>($US20 and a whopping $US65 for the deluxe encoder) and it is >>unreasonable to expect EVERYONE to buy one. > >Of course, PBM is free, and the preview versions would still be GIF or >whatever the original was. > >-- >Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find >Martin Marietta Energy Systems it connected to everything else. >Workstation Support --John Muir First, some facts. GIF is an image format that allows storage of images that have at most 8 bits of colors or grays. It has a color lookup table that allows any of the 256 colors to be any 24 bit color. It uses LZW for compression. It is a fairly simple format. GIF reading is quick. JPEG is a format that does frequency analysis on small chunks of an image in an effort to convert the image to a small number of differant numbers. Then compression is applied. The computations can take a long time. There are many compression options. As I understand it, neither reading or writing of JPEG is fast. When GIF was developed, 8 bit (256 color) screens were getting common, 24 bit (16 million color) screens were not. Gif is a real win in speed for an 8 bit screen. It preserves all you can see anyway, and you don't have to perform color quantization. 8 bits per pixel is generally good enough for grayscale work. GIF is a good format for this type of image. GIF also handles 4 bit per pixel and 1 bit per pixel images well. Color images are typicaly scanned with 24 bit per pixel scanners. To convert such and image to GIF means that it must be quantized. Quantization removes information. For this type of image, GIF is not lossless. For each pixel 24 bits is compressed to 8 bits. Thus the image is 1/3rd the original size. Then it is compressed via LZW, yielding a file that is roughly 70% of that. So, GIF files can be expected to be about 20% to 25% of the original size. A 24 bit video card for the 640x480 Mac II color monitor can be had for $450 these days. I might get one for home. We have 24 bit color on Macs here at work. GIF now gets it the way of actually using the new capability. JPEG images retain the number of colors, but loose some part of the spatial resolution. For most pictures (you started the image in a camera), JPEG compression yields a better looking image than GIF on a 24 bit screen. JPEG files are often less than 10% of the original size. Quantizing a 24 bit image to 8 bits introduces high frequency noise into the image. Thus, JPEG may reduce a 24 bit image to something smaller and better looking than it would the same file that had been converted to GIF. I don't know if JPEG handles 8 bit gray, 4 bit and 1 bit per pixel images well. One feature of JPEG is that software for it has not yet settled into an easily available and stable form yet. There is a group on the net colaborating on a public version of source for conversions. Observations: 1) Images are binaries. 2) Binaries are large. 3) To prevent huge bandwidth consumption, binaries should only be posted via moderated groups. This increases quaility, reduces duplication, etc. 4) GIF files are already reduced-number-of-colors. Reducing colors further won't buy much. A 100x100 image is 1/4 the size of a 200x200 image. It often produces an image better than reducing an 8 bit image to 4 bits - which only saves half. 5) One need not resort to lowest quality JPEG to achieve substantially better compression than GIF. 6) JPEG was designed to handle images that are large. 7) Netnews is good for wide distribution. Mail and FTP are not as good. It does not matter how big or small the data is. Conclusions: 1) If you want to reduce network bandwidth, use a moderator. 2) If you want to archive images, it is possible to treat it as a seperate problem. For example: The moderator posts original images in whatever form. The moderator keeps images at an FTP site, or automatic mail access for the month following an image's posting. An archive site retains 128x128 4 bit gray thumbnails (8,192 bytes, uncompressed) in a well known format, available via ftp & automatic mail. Also, a text archive index is avilable. Some or all full images are available. Since one archive site does not have the resources to burn, a distributed archive is set up. The central archive has pointers to other archives. An archive site devotes a fixed maximum amount of online resources to archiving. Rules should allow an archiver to change their mind. The data is transfered to a new archiver, or archivers. The pointers are updated.