Decoding facsimile data from the Rapicom 450
RFC 798
|
Document |
Type |
|
RFC - Unknown
(September 1981; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 798 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group A. Katz
Request for Comments: 798 ISI
September 1981
DECODING FACSIMILE DATA FROM THE RAPICOM 450
I. Introduction
This note describes the implementation of a program to decode
facsimile data from the Rapicom 450 facsimile (fax) machine into an
ordinary bitmap. This bitmap can then be displayed on other devices
or edited and then encoded back into the Rapicom 450 format. In
order to do this, it was necessary to understand the how the
encoding/decoding process works within the fax machine and to
duplicate that process in a program. This algorithm is descibed in
an article by Weber [1] as well as in a memo by Mills [2], however,
more information than is presented in these papers is necessary to
successfully decode the data.
The program was written in L10 as a subsystem of NLS running on
TOPS20. The fax machine is interfaced to TOPS20 as a terminal
through a microprocessor-based interface called FAXIE.
Grateful acknowledgment is made to Steve Treadwell of University
College, London and Jon Postel of Information Sciences Institute for
their assistance.
II. Interface to TOPS20
The fax machine is connected to a microprocessor-based unit called
FAXIE, designed and built by Steve Casner and Bob Parker. More
detailed information can be found in reference [3]. FAXIE is
connected to TOPS20 over a terminal line, and a program was written
to read data over this line and store it in a file. The decoding
program reads the fax data from this file.
The data comes from the fax machine serially. FAXIE reads this data
into an 8-bit shift register and sends the 8-bit byte (octet) over
the terminal line. Since the fax machine assigns MARK to logical 0's
and SPACE to logical 1's (which is backward from RS232), FAXIE
complements each bit in the octet. The data is sent to TOPS20 in
octets, the most significant bit first. If you read each octet from
most significant bit to least significant bit in the order FAXIE
sends the data to TOPS20, you would be reading the data in the same
order in comes into FAXIE from the fax machine.
The standard for storing Rapicom 450 Facsimile Data is described in
RFC 769 [4]. According to this standard, each octet coming from
FAXIE must be complemented and inverted (i.e. invert the order of the
bits in the octet). Thus, the receiving program did this before
Alan R. Katz [page 1]
DECODING FACSIMILE DATA RFC 798
II. Interface to TOPS20
storing the data in a file. When the decoding program reads this
file, it must invert and complement each octet before reading the
data.
Each data block from the fax machine is 585 bits long. The end of
this data is padded with 7 0's to make 592 bits or 74 octets.
According to RFC 769, this data is stored in a file preceded by a
length octet and a command octet. The possible commands are:
56 (70 octal)--This is a Set-Up block (the first block of the
file, contains information about the fax image)
57 (71 octal)--This is a data block (the rest of the blocks in the
file except for the last one)
58 (72 octal)--End command (the last block of the file)
The length field tells how many octets in this block and is always 76
(114 octal) except for the END command which can be 2 (no data). The
length and command octets are NOT inverted and complemented.
Below is a diagram of each block in the file:
+--------+--------+--------+--------+--------+--------+--------
| length | command| data | data | ... | |
+--------+--------+--------+--------+--------+--------+--------
III. The Rapicom 450 Encoding Algorithm
An ordinary 8 1/2" by 11" document is made up of about 2100 scan
lines, each line has 1726 pels (picture elements) in it. Each pel
can be either black (1) or white (0).
The Rapicom 450 has three picture quality modes. In fine detail
mode, all of the document is encoded. In quality mode only every
other scan line is encoded and it is intended that these missing
lines are filled in on playback by replicating the previous line.
There is also express mode, where only every third line is encoded.
[page 2] Alan R. Katz
RFC 798 DECODING FACSIMILE DATA
III. The Rapicom 450 Encoding Algorithm
Show full document text