File Formats: BMP


Products

Preview

Windows Bitmap

defined by Microsoft

status of this document: done.


 
Table of Contents 
Last updated: Jan 14. 1998

to topBasic 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.

to topBasic 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
 

to topRaster 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. 

 

to topRaster 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!) 
 

to topRaster 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'.
 

to topRaster 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'.
 

to topRaster 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.
 

to topRaster 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.
 

to topRaster 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
 
 

to topRaster 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
 

to topPortability

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.

to topTrademarks, Patents and Royalties

To my knowledge: None. 
(please read the disclaimer) 

to topCross-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

to topOnline Resources

http://www.dcs.ed.ac.uk/~mxr/gfx/ 
http://www.r2m.com/windev/  Internet Resources for Windows Developers

to topPaper 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


to topDisclaimer

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. 


© Jörn Daub EDV-Beratung - Glashütter Weg 105 - D-22889 Tangstedt