Decoding facsimile data from the Rapicom 450
RFC 798

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• rfc798

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