Image (Bitmap) File Description

A typical BMP file usually contains the following blocks of data:

BMP File Header	Stores general information about the BMP file
Bitmap Information (DIB header)	Stores detailed information about the bitmap image.
Color Palette	Stores the definition of the colros being used for indexed color bitmaps.
Bitmap Data	Stores the actual image, pixel by pixel

 

The following sections discuss the data stored in the BMP file or DIB in details. This is the standard BMP file format.[2] Some bitmap images may be stored using a slightly different format, depending on the application that creates it. Also, not all fields are used; a value of 0 will be found in these unused fields.

 

DIBs in memory

A BMP file is loaded into memory as a DIB data structure, an important component of the Windows GDI API. The DIB data structure is the same as the BMP file format, but without the 14-byte BMP header.

 

BMP file header

This block of bytes is at the start of the file and is used to identify the file. A typical application reads this block first to ensure that the file is actually a BMP file and that it is not damaged. Note that the first two bytes of the BMP file format (thus the BMP header) are stored in big-endian order. This is the magic number 'BM'. All of the other integer values are stored in little-endian format (i.e. least-significant byte first).

Offset#	Size	Purpose
0	2	the magic number used to identify the BMP file: 0x42 0x4D (Hex code points for B and M)
2	4	the size of the BMP file in bytes
6	2	reserved; actual value depends on the application that creates the image
8	2	reserved; actual value depends on the application that creates the image
10	4	the offset, i.e. starting address, of the byte where the bitmap data can be found.

 

Bitmap information (DIB header)

This block of bytes tells the application detailed information about the image, which will be used to display the image on the screen. The block also matches the header used internally by Windows and OS/2 and has several different variants. All of them contain a dword field, specifying their size, so that an application can easily determine which header is used in the image. The reason that there are different headers is that Microsoft extended the DIB format several times. The new extended headers can be used with some GDI functions instead of the older ones, providing more functionality. Since the GDI supports a function for loading bitmap files, typical Windows applications use that functionality. One consequence of this is that for such applications, the BMP formats that they support match the formats supported by the Windows version being run. See the table below for more information.

 

Size	Header	Identified by	Supported by the GDI of
40	Windows V3	BITMAPINFOHEADER	all Windows versions since Windows 3.0
12	OS/2 V1	BITMAPCOREHEADER	OS/2 and also all Windows versions since Windows 3.0
64	OS/2 V2
108	Windows V4	BITMAPV4HEADER	all Windows versions since WIndows 95/NT4
124	Windows V5	BITMAPV5HEADER	WIndows 98/2000 and newer

 

For compatibility reasons, most applications use the older DIB headers for saving files. With OS/2 being obsolete, for now the only common format is the V3 header.

The palette occurs in the BMP file directly after the BMP header and the DIB header. Therefore, its offset is the size of the BMP header plus the size of the DIB header.

 

The palette is a block of bytes (a table) listing the colors available for use in a particular indexed-color image. Each pixel in the image is described by a number of bits (1, 4, or 8) which index a single color in this table. The purpose of the color palette in indexed-color bitmaps is to tell the application the actual color that each of these index values corresponds to.

 

A DIB always uses the RGB color model. In this model, a color is terms of different intensities (from 0 to 255) of the additive primary colors red (R), green (G), and blue (B). A color is thus defined using the 3 values for R, G and B (though stored in backwards order in each palette entry).

 

The number of entries in the palette is either 2n or a smaller number specified in the header (in the OS/2 V1 format, only the full-size palette is supported).[2][4] Each entry contains four bytes, except in the case of the OS/2 V1 versions, in which case there are only three bytes per entry.[4] The first (and only for OS/2 V1) three bytes store the values for blue, green, and red, respectively,[2] while the last one is unused and is filled with 0 by most applications.

 

As mentioned above, the color palette is not used when the bitmap is 16-bit or higher; there are no palette bytes in those BMP files.

 

This block of bytes describes the image, pixel by pixel. Pixels are stored "upside-down" with respect to normal image raster scan order, starting in the lower left corner, going from left to right, and then row by row from the bottom to the top of the image.[2] Uncompressed Windows bitmaps can also be stored from the top row to the bottom, if the image height value is negative.

 

RGB color (24-bit) pixel values are stored with bytes in the same order (blue, green, red) as in the color table.[2]

 

If the number of bytes matching a row (scanline) in the image is not divisible by 4, the line is padded with one to three additional bytes of unspecified value (not necessarily 0) so that the next row will start on a multiple of 4 byte location in memory or in the file. (the total number of bytes in a row can be calculated as the image size/bitmap height in pixels) Following these rules there are several ways to store the pixel data depending on the color depth and the compression type of the bitmap.