BMP file format
The BMP file format, or bitmap, is a raster graphics image file format used to store bitmap digital images, independently of the display device, especially on Microsoft Windows and OS/2 operating systems.
The BMP file format is capable of storing two-dimensional digital images in various color depths, and optionally with data compression, alpha channels, and color profiles. The Windows Metafile specification covers the BMP file format.
Device-independent bitmaps and the BMP file format
Microsoft has defined a particular representation of color bitmaps of different color depths, as an aid to exchanging bitmaps between devices and applications with a variety of internal representations. They called these device-independent bitmaps or DIBs, and the file format for them is called DIB file format or BMP image file format.According to Microsoft support:
A device-independent bitmap is a format used to define device-independent bitmaps in various color resolutions. The main purpose of DIBs is to allow bitmaps to be moved from one device to another. A DIB is an external format, in contrast to a device-dependent bitmap, which appears in the system as a bitmap object. A DIB is normally transported in metafiles, BMP files, and the Clipboard.
The following sections discuss the data stored in the BMP file or DIB in detail. This is the standard BMP file format. Some applications create bitmap image files which are not compliant with the Microsoft documentation. Also, not all fields are used; a value of 0 will be found in these unused fields.
File structure
The bitmap image file consists of fixed-size structures as well as variable-sized structures appearing in a predetermined sequence. Many different versions of some of these structures can appear in the file, due to the long evolution of this file format.Referring to the diagram 1, the bitmap file is composed of structures in the following order:
| Structure name | Optional | Size | Purpose | Comment |
| Bitmap file header | 14 | General information | Not needed after the file is loaded in memory | |
| DIB header | Fixed-size | Detailed information and pixel format | Immediately follows the Bitmap file header | |
| Extra bit masks | 12 or 16 | Pixel format | Present only in case the DIB header is the and the Compression Method member is set to either BI_BITFIELDS or BI_ALPHABITFIELDS | |
| Color table | Colors | Mandatory for color depths ≤ 8 bits | ||
| Gap1 | Structure alignment | An artifact of the File offset to Pixel array in the Bitmap file header | ||
| Pixel array | Pixel values | The pixel format is defined by the DIB header or Extra bit masks. Each row in the Pixel array is padded to a multiple of 4 bytes in size | ||
| Gap2 | Structure alignment | An artifact of the ICC profile data offset field in the DIB header | ||
| ICC color profile | Color profile | Can also contain a path to an external file containing the color profile. When loaded in memory as "non-packed DIB", it is located between the color table and Gap1. |
DIBs in memory
A bitmap image file loaded into memory becomes a DIB data structure – an important component of the Windows GDI API. The in-memory DIB data structure is almost the same as the BMP file format, but it does not contain the 14-byte bitmap file header and begins with the DIB header. For DIBs loaded in memory, the color table can also consist of 16-bit entries that constitute indexes to the currently realized palette, instead of explicit RGB color definitions. In all cases, the pixel array must begin at a memory address that is a multiple of 4 bytes. In non-packed DIBs loaded in memory, the optional color profile data should be located immediately after the color table and before the gap1 and pixel array.When the size of gap1 and gap2 is zero, the in-memory DIB data structure is customarily referred to as "packed DIB" and can be referred to by a single pointer pointing to the beginning of the DIB header. In all cases, the pixel array must begin at a memory address that is a multiple of 4 bytes. In some cases it may be necessary to adjust the number of entries in the color table in order to force the memory address of the pixel array to a multiple of 4 bytes. For "packed DIBs" loaded in memory, the optional color profile data should immediately follow the pixel array, as depicted in diag. 1.
"Packed DIBs" are required by Windows clipboard API functions as well as by some Windows patterned brush and resource functions.
Bitmap 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. The first 2 bytes of the BMP file format are the character "B" then the character "M" in ASCII encoding. All of the integer values are stored in little-endian format.| Offset | Size | Description |
| 0 | 2 | The header field used to identify the BMP and DIB file is 0x42 0x4D in hexadecimal, same as BM in ASCII. The following entries are possible:;BM: Windows 3.1x, 95, NT,... etc. ;BA: OS/2 struct bitmap array ;CI: OS/2 struct color icon ;CP: OS/2 const color pointer ;IC: OS/2 struct icon ;PT: OS/2 pointer |
| 2 | 4 | The size of the BMP file in bytes |
| 6 | 2 | Reserved; actual value depends on the application that creates the image, if created manually can be 0 |
| 8 | 2 | Reserved; actual value depends on the application that creates the image, if created manually can be 0 |
| 10 | 4 | The offset, i.e. starting address, of the byte where the bitmap image data can be found. |
DIB header (bitmap information 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 name | OS support | Features | Written by |
| 12 | Windows 2.0 or later OS/2 1.x | |||
| 64 | OS/2 2 | Adds halftoning. Adds RLE and Huffman 1D compression. | ||
| 16 | This variant of the previous header contains only the first 16 bytes and the remaining bytes are assumed to be zero values. An example of such a case is the graphic of the BMP Suite. | |||
| 40 | Windows NT, 3.1x or later | Extends bitmap width and height to 4 bytes. Adds 16 bpp and 32 bpp formats. Adds RLE compression. | ||
| 52 | Undocumented | Adds RGB bit masks. | Microsoft | |
| 56 | Not officially documented, but this documentation was posted on Adobe's forums, by an employee of Adobe with a statement that the standard was at one point in the past included in official MS documentation | Adds alpha channel bit mask. | Microsoft | |
| 108 | Windows NT 4.0, 95 or later | Adds color space type and gamma correction | ||
| 124 | Windows NT 5.0, 98 or later | Adds ICC color profiles | The GIMP |
| Offset | Size | OS/2 1.x |
| 14 | 4 | The size of this header |
| 18 | 2 | The bitmap width in pixels |
| 20 | 2 | The bitmap height in pixels |
| 22 | 2 | The number of color planes, must be 1 |
| 24 | 2 | The number of bits per pixel |
The Windows 2.x BITMAPCOREHEADER differs from the OS/2 1.x BITMAPCOREHEADER in the one detail that the image width and height fields are signed integers, not unsigned.
Versions after only add fields to the end of the header of the previous version.
For example: adds fields to, and adds fields to.
An integrated alpha channel has been introduced with the undocumented and with the documented and is used within Windows XP logon and theme system as well as Microsoft Office ; it is supported by some image editing software, such as Adobe Photoshop since version 7 and Adobe Flash since version MX 2004. It is also supported by GIMP, Google Chrome, Microsoft PowerPoint and Microsoft Word.
For compatibility reasons, most applications use the older DIB headers for saving files. With OS/2 no longer supported after Windows 2000, for now the common Windows format is the header. See next table for its description. All values are stored as unsigned integers, unless explicitly noted.
| Offset | Size | Windows |
| 14 | 4 | the size of this header, in bytes |
| 18 | 4 | the bitmap width in pixels |
| 22 | 4 | the bitmap height in pixels |
| 26 | 2 | the number of color planes |
| 28 | 2 | the number of bits per pixel, which is the color depth of the image. Typical values are 1, 4, 8, 16, 24 and 32. |
| 30 | 4 | the compression method being used. See the next table for a list of possible values |
| 34 | 4 | the image size. This is the size of the raw bitmap data; a dummy 0 can be given for BI_RGB bitmaps. |
| 38 | 4 | the horizontal resolution of the image. |
| 42 | 4 | the vertical resolution of the image. |
| 46 | 4 | the number of colors in the color palette, or 0 to default to 2n |
| 50 | 4 | the number of important colors used, or 0 when every color is important; generally ignored |
The compression method can be:
| Value | Identified by | Compression method | Comment |
| 0 | Most common | ||
| 1 | RLE 8-bit/pixel | Can be used only with 8-bit/pixel bitmaps | |
| 2 | RLE 4-bit/pixel | Can be used only with 4-bit/pixel bitmaps | |
| 3 | : Huffman 1D | : RGB bit field masks, +: RGBA | |
| 4 | : RLE-24 | +: JPEG image for printing | |
| 5 | +: PNG image for printing | ||
| 6 | RGBA bit field masks | only Windows CE 5.0 with.NET 4.0 or later | |
| 11 | only Windows Metafile CMYK | ||
| 12 | RLE-8 | only Windows Metafile CMYK | |
| 13 | RLE-4 | only Windows Metafile CMYK |
An OS/2 2.x contains 24 additional bytes:
| Offset | Size | OS/2 |
| 54 | 2 | An enumerated value specifying the units for the horizontal and vertical resolutions. The only defined value is 0, meaning pixels per metre |
| 56 | 2 | Padding. Ignored and should be zero |
| 58 | 2 | An enumerated value indicating the direction in which the bits fill the bitmap. The only defined value is 0, meaning the origin is the lower-left corner. Bits fill from left-to-right, then bottom-to-top. Note that Windows bitmaps can also specify an upper-left origin by using a negative value for the image height |
| 60 | 2 | An enumerated value indicating a halftoning algorithm that should be used when rendering the image. |
| 62 | 4 | Halftoning parameter 1 |
| 66 | 4 | Halftoning parameter 2 |
| 70 | 4 | An enumerated value indicating the color encoding for each entry in the color table. The only defined value is 0, indicating RGB. |
| 74 | 4 | An application-defined identifier. Not used for image rendering |
The halftoning algorithm can be:
| Value | Halftoning algorithm | Comment |
| 0 | Most common | |
| 1 | Error diffusion | Halftoning parameter 1 is the percentage of error damping. 100 indicates no damping. 0 indicates that errors are not diffused |
| 2 | PANDA: Processing Algorithm for Noncoded Document Acquisition | Halftoning parameters 1 and 2 represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used |
| 3 | Super-circle | Halftoning parameters 1 and 2 represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used |