| |
| |  |  |  | |  |
status of this document: work in progress
|
Table of Contents
Last updated: Jan 14. 1998
|
Basic
Description
This file format is the MS-Windows standard
format. It holds black&white-, 16-color, 256-color and Truecolor images.
The palletized 16-color and 256-color images may be compressed via run
length encoding. Notice there is also a OS/2-BMP format. |
Basic
File Format
| Name |
Size |
Description |
| Header |
14 bytes |
Windows Structure: BITMAPFILEHEADER |
| |
Signature |
2 bytes |
'BM' |
| FileSize |
4 bytes |
File size in bytes |
| reserved |
4 bytes |
unused (=0) |
| DataOffset |
4 bytes |
File offset to Raster Data |
| InfoHeader |
40 bytes |
Windows Structure: BITMAPINFOHEADER |
| |
Size |
4 bytes |
Size of InfoHeader =40 |
| Width |
4 bytes |
Bitmap Width |
| Height |
4 bytes |
Bitmap Height |
| Planes |
2 bytes |
Number of Planes (=1) |
| BitCount |
2 bytes |
Bits per Pixel
1 = monochrome palette. NumColors = 1
4 = 4bit palletized. NumColors = 16
8 = 8bit palletized. NumColors = 256
16 = 16bit RGB. NumColors = 65536
(?)
24 = 24bit RGB. NumColors = 16M |
| Compression |
4 bytes |
Type of Compression
0 = BI_RGB no
compression
1 = BI_RLE8 8bit
RLE encoding
2 = BI_RLE4 4bit
RLE encoding |
| ImageSize |
4 bytes |
(compressed) Size of Image
It is valid to set this =0 if Compression
= 0 |
| XpixelsPerM |
4 bytes |
horizontal resolution: Pixels/meter |
| YpixelsPerM |
4 bytes |
vertical resolution: Pixels/meter |
| ColorsUsed |
4 bytes |
Number of actually used colors |
| ColorsImportant |
4 bytes |
Number of important colors
0 = all |
| ColorTable |
4 * NumColors bytes |
present only if Info.BitsPerPixel <=
8
colors should be ordered by importance |
| |
|
Red |
1 byte |
Red intensity |
| Green |
1 byte |
Green intensity |
| Blue |
1 byte |
Blue intensity |
| reserved |
1 byte |
unused (=0) |
| repeated NumColors times |
| Raster Data |
Info.ImageSize bytes |
The pixel data |
|
Raster
Data encoding
Depending on the image's BitCount and on the
Compression flag there are 6 different encoding schemes. All of them share
the following:
Pixels are stored bottom-up, left-to-right.
Pixel lines are padded with zeros to end on a 32bit (4byte) boundary. For
uncompressed formats every line will have the same number of bytes. Color
indices are zero based, meaning a pixel color of 0 represents the first
color table entry, a pixel color of 255 (if there are that many) represents
the 256th entry. For images with more than 256 colors there is no
color table. |
Raster
Data encoding for 1bit / black & white images
BitCount = 1 Compression = 0
Every byte holds 8 pixels, its highest
order bit representing the leftmost pixel of those. There are 2 color table
entries. Some readers will ignore them though, and assume that 0 is black
and 1 is white. If you are storing black and white pictures you should
stick to this, with any other 2 colors this is not an issue. Remember padding
with zeros up to a 32bit boundary (This can be up to 31 zeros/pixels!) |
Raster
Data encoding for 4bit / 16 color images
BitCount = 4 Compression = 0
Every byte holds 2 pixels, its high order
4 bits representing the left of those. There are 16 color table entries.
These colors do not have to be the 16 MS-Windows standard colors. Padding
each line with zeros up to a 32bit boundary will result in up to 28 zeros
= 7 'wasted pixels'. |
Raster
Data encoding for 8bit / 256 color images
BitCount = 8 Compression = 0
Every byte holds 1 pixel. There are 256
color table entries. Padding each line with zeros up to a 32bit boundary
will result in up to 3 bytes of zeros = 3 'wasted pixels'. |
Raster
Data encoding for 16bit / hicolor images
BitCount = 16 Compression = 0
Every 2bytes / 16bit holds 1 pixel.
<information missing: the 16
bit was introduced together with Video For Windows? Is it a memory-only-format?>
The pixels are no color table pointers.
There are no color table entries. Padding each line with zeros up to a
16bit boundary will result in up to 2 zero bytes. |
Raster
Data encoding for 24bit / truecolor images
BitCount = 24 Compression = 0
Every 4bytes / 32bit holds 1 pixel. The
first holds its red, the second its green, and the third its blue intensity.
The fourth byte is reserved and should be zero. There are no color table
entries. The pixels are no color table pointers. No zero padding necessary. |
Raster
Data compression for 4bit / 16 color images
BitCount = 4 Compression = 2
The pixel data is stored in 2bytes / 16bit
chunks. The first of these specifies the number of consecutive pixels
with the same pair of color. The second byte defines two color indices.
The resulting pixel pattern will be interleaved high-order 4bits and low
order 4 bits (ABABA...). If the first byte is zero, the second defines
an escape code. The End-of-Bitmap is zero padded to end on a 32bit boundary.
Due to the 16bit-ness of this structure this will always be either two
zero bytes or none.
| n (byte 1) |
c (Byte 2) |
Description |
| >0 |
any |
n pixels are to be drawn. The 1st,
3rd, 5th, ... pixels' color is in c's high-order 4 bits, the even
pixels' color is in c's low-order 4 bits. If both color indices
are the same, it results in just n pixels of color c |
| 0 |
0 |
End-of-line |
| 0 |
1 |
End-of-Bitmap |
| 0 |
2 |
Delta. The following 2 bytes define an
unsigned offset in x and y direction (y being up) The skipped pixels should
get a color zero. |
| 0 |
>=3 |
The following c bytes will be read
as single pixel colors just as in uncompressed files. up to 12 bits of
zeros follow, to put the file/memory pointer on a 16bit boundary again. |
Example for 4bit RLE
| Compressed Data |
Expanded data |
| 03 04 |
0 4 0 |
| 05 06 |
0 6 0 6 0 |
| 00 06 45 56 67 00 |
4 5 5 6 6 7 |
| 04 78 |
7 8 7 8 |
| 00 02 05 01 |
Move 5 right and 1 up. (Windows docs say
down, which is wrong) |
| 00 00 |
End-of-line |
| 09 1E |
1 E 1 E 1 E 1 E 1 |
| 00 01 |
EndofBitmap |
| 00 00 |
Zero padding for 32bit boundary |
|
Raster
Data compression for 8bit / 256 color images
BitCount = 8 Compression = 1
The pixel data is stored in 2bytes / 16bit
chunks. The first of these specifies the number of consecutive pixels
with the same color. The second byte defines their color index. If the
first byte is zero, the second defines an escape code. The End-of-Bitmap
is zero padded to end on a 32bit boundary. Due to the 16bit-ness of this
structure this will always be either two zero bytes or none.
| n (byte 1) |
c (Byte 2) |
Description |
| >0 |
any |
n pixels of color number c |
| 0 |
0 |
End-of-line |
| 0 |
1 |
EndOfBitmap |
| 0 |
2 |
Delta. The following 2 bytes define an
unsigned offset in x and y direction (y being up) The skipped pixels should
get a color zero. |
| 0 |
>=3 |
The following c bytes will be read
as single pixel colors just as in uncompressed files. A zero follows, if
c is odd, putting the file/memory pointer on a 16bit boundary again. |
Example for 8bit RLE
| Compressed Data |
Expanded data |
| 03 04 |
04 04 04 |
| 05 06 |
06 06 06 06 06 |
| 00 03 45 56 67 00 |
45 56 67 |
| 02 78 |
78 78 |
| 00 02 05 01 |
Move 5 right and 1 up. (Windows docs say
down, which is wrong) |
| 00 00 |
End-of-line |
| 09 1E |
1E 1E 1E 1E 1E 1E 1E 1E 1E |
| 00 01 |
End-of-bitmap |
| 00 00 |
Zero padding for 32bit boundary |
|
Portability
Although BMPs were invented by Microsoft for
its Windows platform, a lot of programs on other platforms are capable
of reading and writing them. Notice the Intel order in 2byte and 4-byte
integer values (Least significant byte first). The 16bit BMPs have been
introduced to Windows after the others, still puzzling many applications. |
Trademarks,
Patents and Royalties
To my knowledge: None.
(please read the disclaimer) |
Cross-Checking
Software
This section is for programmers, who wish
to cross-check their implementation with others. This is an incomplete
list of programs, which are available as freeware / shareware / try-before-buy
etc.
The following software is able to decode
BMPs:
-
easiest: Make the file the MS-Windows' background.
-
MS-Paint / Paintbrush
-
JASC Paint Shop Pro
The following software is able to encode BMPs
-
JASC Paint Shop Pro
-
MS-Paint / Paintbrush
|
Paper
Resources
MS-Windows SDK
[German:] Referenzhandbuch Dateiformate
by Günter Born.
the following suggestions are from the
Graphics Fileformats FAQ:
-
Inside Windows File Formats, Tom Swan, Sams
Publishing 1993.
ISBN 0-672-30338-8 $24.95 softcover, 337 pages and 1 disk (3.5 in.).
Order: Sams Publishing, 2201 West 103rd Street, Indianapolis, IN
46290
-
Luse, Marv. "The BMP File Format," Dr. Dobb's
Journal, #219 September
1994 (Vol 9, Issue 10), pp. 18-22.
code available at: ftp://ftp.mv.com/pub/ddj/1994/1994.09/bmp.zip
-
The BMP File Format: Part I+II, Dr. Dobb's
Journal, David Charlap, #228+#229
March+April 1995 (Vol. 20, Issue 3+4).
code available at: ftp://ftp.mv.com/pub/ddj/1995/1995.03/bmp.zip
|
|  | |  |  | |
|
| |
Disclaimer
| |  |  |  | |  |
This is not the official format documentation.
Although we're doing our best to keep this information as accurate as possible,
there is no way of checking all of it under all possible circumstances.
We're not taking any responsibility for the results of this information
or lack thereof. The 'trademarks, patents and royalties' section is here
just for your convenience, and is in no way complete. Please send us a
note, if you find any incorrect of missing information to fileformats@daubnet.com.
|  | |  |  | |
|