🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.archives.admin
Article #84

Re: ftpmail data

#84
From: Stephen Uitti
Date: Fri, 07 Jun 1991 18:20
130 lines
6252 bytes
In article <1991Jun7.144706.11588@cs.utk.edu> Dave Sill <de5@ornl.gov> writes:
>In article <GARYM.91Jun6093906@cognos.uucp@uunet.uu.net>, 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.
Technical Details
Message-ID: <1991Jun07.182035.10914@ima.isc.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!spdcc!dirtydog.ima.isc.com!suitti
References: <4139@motcsd.csd.mot.com> <GARYM.91Jun6093906@cognos.uucp@uunet.uu.net> <1991Jun7.144706.11588@cs.utk.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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> <GARYM.91Jun6093906@cognos.uucp@uunet.uu.net> <1991Jun7.144706.11588@cs.utk.edu>
Sender: usenet@ima.isc.com (news)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 130