FAXCOM uses arithmetic coding to compress fascimilie files as described
FAXCOM is shareware. If you use this program and find it useful then please
send ($25 is suggested) or whatever you think it is worth to :
Raymond P. Wilson
38 Paremata St.
If you wish to use this, or parts of this program, in a commercial product
then permissiom is required from the author (me).
FAXCOM is split over five different source files. It uses redirection of input
and output reading input from stdin and writing output to stdout. The files
are as follows :
faxcoder.c - source for the fax compressor
Usage : faxcoder
faxdecod.c - source for fax decompressor
Usage : faxdecod
coderdef.i - contains definition etc for fax compressor and decompressor
arithcod.i - contains source for arithmetic coding routines
arithdec.i - contains source for arithmetic decoding routines
To compile the fax compressor just have all of the files present in the same
directory and compile faxcode.c to get the fax compressor and faxdecod.c to
get the fax decompressor. No library files need to be included in compiling
the programs. Don't try this on an MS-DOS machine unless you have a VERY good
C compiler. The macro expansions killed Microsoft C ver5.1 and the memory
requirements mean that it will not run on unexpanded MS-DOS machines without
modification of the program (see below).
The current version of the program compresses fax documents that have been
scanned and stored in files that are 2376 pixel lines long and 1728 pixels wide
(i.e. a straight bit map). This is a restraint that is present to make things
a little easier at the moment - I would be happy to change this and make it
more flexible if there was interest in it.
FAXCOM started off as a university assignment at the University of
Canterbury, Christchurch, New Zealand and as such had a number of constraints
etc. For instance it only compresses files in the above mentioned format.
FAXCOM was written under UNIX (SunOS 4.0) on a Sun 3/60 with 4Mb of memory
with a remote file server connected via Ethernet. The compression that
FAXCOM acheives is very dependant on the fax that it is compressing. A blank
or totally black fax will be compressed down to just 88 bytes while for the
four test fax documents that we had to work with compression ranged from 20:1
to 157:1. One fax that was a full page of text, some mathematical formulae
and a couple of small diagrams was compressed to 26k (the source faxes are
513216 bytes long) - this fax is one of the standard CCITT test fax documents.
The arithmetic coding routines used by FAXCOM come from the book Text
Compression by Bell, Cleary & Witten published by Prentice-Hall. These have
been subsequently modified to increase speed but the basic way that the
algorithm works has not been changed.
FAXCOM runs inside 700k. This can be reduced to around 300k by making some
small changes to the file coderdef.i : Change the type of the zero_count and
sum fields in the contexts array from int to short int, change MODEL_ORDER
from 16 to 15, and change CONTEXT_MASK from 0x3ff to 0x1ff. These changes
result in a loss of speed (about 10 seconds) and a loss in compression
FAXCOM has been very highly optimised for speed. This is why integers are used
instead of unsigned shorts as described above. Suns works faster with integers
thus resulting in the 10 second saving in time to compress a fax. Many other
optimisations have been performed. The existence of so many macros is another
result of the optimisation process. You are free to modify FAXCOM and I would
be interested to know if anyone manages to improve on its current performance.
If you do decide to modify it be very careful - compression/decompression
programs are notoriously sensitive to change.
At present FAXCOM is limited to compressing fax files of a single size (513216)
bytes, that have 2376 lines and are 1726 pixels wide. This may be changed
by altering the values of BITS_PER_LINE and NUM_LINES in the file coderdef.i.
The compressed files are NOT suitable for transmission as there are no error
detecting/correcting provisions in the compressor. A one bit error in
transmission renders the uncompressed fax total garbled from that point on.
At present this could be achieved by running the compressed file through a
program to insert such error detecting/correcting information eg: inserting
parity bits would increase the size of the file by 12.5% but would make it
much more suitable for transmission.
If there is interest in modifying this fax compressor to make it more flexible
and powerful then I would be happy to consider improvement suggestions (there
are a number that could be made).