Format for Bitmap files
A simple format for storing black-and-white pictures as files of bits.
Katz, A.R., "Format for Bitmap files", RFC 797, DOI 10.17487/RFC0797, September 1981, <https://www.rfc-editor.org/info/rfc797>.
@misc{rfc797,
series = {Request for Comments},
number = 797,
howpublished = {RFC 797},
publisher = {RFC Editor},
doi = {10.17487/RFC0797},
url = {https://www.rfc-editor.org/info/rfc797},
author = {A.R. Katz},
title = {{Format for Bitmap files}},
pagetotal = 2,
year = 1981,
month = sep,
} RFC text
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.
AI ELI5
On this page
§1File Structure Overview
RFC 797 proposes a simple format for storing one-bit-per-pixel (monochrome) bitmaps in files. The RFC emphasizes that this format is intended for short-term storage and interchange between closely coupled programs, not as a universal image format. Each file begins with a 10-octet header followed by the bitmap data.
This is a quick and simple way to save a black-and-white picture when programs on the same computer need to share it.
§2Header and Bitmap Layout
The header consists of: Width (octets 1–4, most significant octet first), Height (octets 5–8), X increment (octet 9), and Y increment (octet 10). The X and Y increment fields specify how much space is between pixels (normally both are 1, but different values allow for different scan modes, such as from facsimile machines). The bitmap data follows immediately, with each scan line stored from left to right and all lines from top to bottom. Each line must end on an octet boundary; if the width is not divisible by 8, the remainder of the last octet is filled with zero bits.
The first 10 bytes say 'width is X, height is Y, skip X pixels at a time, skip Y lines at a time.' Then come the picture bytes.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
WIDTH-1 | Width byte 1 | 1 byte | Most significant byte of image width. | |
WIDTH-2 | Width byte 2 | 1 byte | Second byte of width. | |
WIDTH-3 | Width byte 3 | 1 byte | Third byte of width. | |
WIDTH-4 | Width byte 4 | 1 byte | Least significant byte of width. | |
HEIGHT-1 | Height byte 1 | 1 byte | Most significant byte of height. | |
HEIGHT-2 | Height byte 2 | 1 byte | Second byte of height. | |
HEIGHT-3 | Height byte 3 | 1 byte | Third byte of height. | |
HEIGHT-4 | Height byte 4 | 1 byte | Least significant byte of height. | |
X-INC | X increment | 1 byte | Pixel spacing in X direction. | |
Y-INC | Y increment | 1 byte | Pixel spacing in Y direction. |
§3Facsimile Machine Support
The RFC notes that bitmaps from the Rapicom 450 facsimile machine (subject of RFC 798) can be in different modes. In fine-detail mode, the x-increment and y-increment are both 1. In quality mode, x-increment is 1 and y-increment is 2 (meaning each scan line should be displayed twice on playback). In express mode, x-increment is 1 and y-increment is 3 (each line displayed three times). This flexibility allows fax data to be stored in a uniform bitmap format while preserving the original scan resolution information.
A fax machine might send every line of a picture, or every other line, or every third line. The header numbers tell the display whether to repeat lines when showing the picture.