Index Journeys
RFC 797 UNKNOWN FILE FORMAT · IMAGE

Format for Bitmap files

A simple file layout for storing one-bit-per-pixel bitmap images.

On rfc-editor.org ↗
PUBLISHED
September 1981
AUTHORS
A.R. Katz
STREAM
Legacy
HEADER SIZE
10 octets
BITS PER PIXEL
1
STORAGE UNIT
8-bit octets
DOI
10.17487/RFC0797

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                            A. Katz
Request for Comments: 797                                            ISI
                                                          September 1981


                        FORMAT FOR BITMAP FILES

   This note describes a proposed format for storing simple bitmaps (one
   bit per pixel)  in a file.   These  files  may be very  large and the
   intent  is to use this format for short term storage and passing data
   between  closely  coupled  programs.   The data in the file should be
   stored in 8-bit bytes (octets).  Bitmaps may be any size.

   The first  4 octets  of the file  gives  the width  of each  line  (x
   direction),  and the next 4 octets should give the number of lines of
   the display  (length, y direction). After this is one octet for the x
   increment  and one octet for the y  increment.   Following  these  10
   octets  is the bitmap  itself.     The length  and width  fields  are
   stored most significant octet first.

   The x and y increment  octets  tell how much space is between pixels.
   For an ordinary display, both these would be one.

   Each line of the display  should  be scanned  from left to right. The
   lines should start at the top and work down.  Each line in the bitmap
   should  end on an octet boundary.  If the width of the display is not
   divisable  by 8,  the rest of the last octet  should  be filled  with
   zeros on the right.

   Below  is a representation  of a bitmap  file  (each  square  is  one
   octet):

      ----------------------------------------------------------
      |    1     |    2     |    3     |     4     |     5     |
      |  width   |  width   |  width   |   width   |  length   |
      ----------------------------------------------------------

      ----------------------------------------------------------
      |     6    |     7    |     8    |     9     |     10    |
      |  length  |  length  |  length  |x-increment|y-increment|
      ----------------------------------------------------------

      ----------------------------------------------------------
      |   11     |   12     |   13     |    14     |   15
      |  data    |  data    |  data    |   data    |  data...
      ----------------------------------------------------------

   For example,  bitmaps  from the RAPICOM  450 can be in  Fine  Detail,
   Quality,  or Express  Mode.   In Fine Detail mode the x-increment and
   y-increment  would be 1, for Quality mode, the x-increment would be 1
   and the y-increment would be 2, and for Express mode, the x-increment
   would  be 1 and the y-increment  would be 3.  For these bitmaps it is
   intended  that each scan line be repeated y-increment times when they
   are displayed.

ISO Plain Language

On this page
PROBLEMPrograms need a simple way to store and pass bitmaps with one bit per pixel.
MECHANISMThe format stores width, height, and x and y increments in a 10-octet header, followed by image bits packed in scan-line order.
THE PROPOSALThe author proposes the format for short-term storage and transfer between closely coupled programs.

§1Purpose and File Layout

The memo proposes a format for storing simple bitmaps in files. It is intended for short-term storage and passing data between closely coupled programs, and the file stores data in 8-bit octets.

The format begins with ten octets of header followed by the bitmap itself.

The format is for programs that need to store and pass a simple bitmap. The header comes first, followed by the image data.

§2Header and Pixel Order

The first four octets give the width of each line, the next four give the number of lines, and the next two give the x and y increments. The width and length fields are stored with the most significant octet first.

Each line is scanned left to right, and lines start at the top and continue down. Each line ends on an octet boundary; unused bits at the end are zero-filled.

The header tells a reader how wide and tall the bitmap is and gives its x and y increments. Pixel data is arranged across each line, then down the image.

§3Increment Values for Facsimile Data

The x and y increments specify how much space lies between pixels. For an ordinary display, both are one.

The RFC gives Rapicom 450 examples: Fine Detail uses increments of one and one, Quality uses one and two, and Express uses one and three. When displayed, each scan line is repeated according to the y increment.

The increment values describe spacing and can also tell a display how often to repeat a scan line. The memo gives settings for three Rapicom 450 modes.