Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!disunix.UUCP!jhs
From: jhs@disunix.UUCP
Newsgroups: net.micro.atari16
Subject: Re: image compression
Message-ID: <8605221510.AA17733@mitre-bedford.ARPA>
Date: Thu, 22-May-86 11:10:21 EDT
Article-I.D.: mitre-be.8605221510.AA17733
Posted: Thu May 22 11:10:21 1986
Date-Received: Sat, 24-May-86 21:30:54 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The MITRE Corp., Bedford, MA
Lines: 22

A lot of study has gone into image compression, so I am sure you can find some
very effective algorithms.  One of the simplest to understand is "run-length
coding", in which repeated data (pixel) values are sent as a special "repeat
code" followed by the repeat count and the value, or some such thing (invent
your own protocol if you like).  For certain kinds of images, this results is
a substantial compression.  E.g. line drawings where most space is white
anyway, or highly structured scenes where large regions have the same color
and little or no texture.

If you are constructing the image (i.e. have your mits on the semantics of the
scene) then you can do MUCH better with "Videotex" encoding.  The North
American Presentation-Level Protocol (NAPLPS) does a surprisingly good job of
representing simple pictures etc.  There is an ANSII standards group (X3H33?)
working on such things.  With Videotex encoding (NAPLPS, Teletel, Prestel,
several other standards), pictures can be coded in a few thousand bytes and
therefore sent over even 1200-baud lines in a few seconds!

That's about all I know except I could probably get some specific references
to articles, standards documents, etc. if you can't scrounge them up locally.

-John Sangster
jhs@mitre-bedford.arpa