BMP file format

Windows bitmap format

The bitmap image file consists of fixed-size structures (headers) 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. Some applications create bitmap image files which are not compliant with the Microsoft documentation; not all fields are used, and a value of 0 will be found in these unused fields. All multi-byte integer fields defined by the BMP and Windows/OS/2 bitmap structures — every header field, as well as the color masks — are stored in little-endian byte order, a heritage of the format's origin on Intel-based machines.

A device-independent bitmap (DIB) is a format for defining bitmaps at various color resolutions so that an image can be moved from one device to another independently of the display hardware — hence the "device-independent" in the name. Unlike a device-dependent bitmap, which exists inside the system as a bitmap object, a DIB is an external format, normally transported in metafiles, in BMP files, and on the clipboard (the CF_DIB data format). A BMP file and a bare DIB are not identical, however: the file begins with the 14-byte bitmap file header (BITMAPFILEHEADER), whereas a DIB transported in a metafile or on the clipboard omits that header and begins directly with the DIB header.

Diagram 1 shows the layout of a BMP file using the BITMAPV5HEADER, the most extensive Windows DIB header — it appears in the diagram because it contains every field added by the successive header extensions. Earlier DIB header variants contain fewer fields, but the structures they define form the initial part of the same layout; the variant actually present in a given file is determined by the DIB header's size field.

In its simplest form, a BMP file contains three structures in sequence: the 14-byte bitmap file header (BITMAPFILEHEADER), which identifies the file and records the offset of the pixel array; a DIB header — most commonly BITMAPINFOHEADER — whose size determines the header variant; and the pixel array, which holds the image data, with each row (scan line) padded to a multiple of four bytes.

Beyond this minimal layout, a file may contain further structures, depending on the pixel format and the header variant:

• Color masks — RGB masks may follow a BITMAPINFOHEADER when biCompression is BI_BITFIELDS; in BITMAPV4HEADER and later, the masks are stored as header fields.
• Color table — an array of RGBQUAD entries; required for indexed-color images (8 bpp or less) and normally absent at 16 bpp and above.
• ICC color profile — available only with BITMAPV5HEADER; it may be embedded in the file or referenced by a path to an external profile.

Because the pixel array and the optional profile are located by offset fields rather than fixed positions, the format also permits small alignment gaps before them. In practice such gaps are almost always absent.

File header

This block of bytes (BITMAPFILEHEADER) stands at the start of the file and is used to identify it: an application typically reads it first to confirm that the file is a BMP file and is not damaged.

DIB header

The DIB header records the image's dimensions, color depth, compression method and related properties. It comes in several variants that all begin with a 32-bit size field, which tells an application which variant is present, since Microsoft extended the format several times. The 12-byte BITMAPCOREHEADER is the oldest and simplest variant; the 40-byte BITMAPINFOHEADER introduced with Windows 3.0 is the common format still written today, and BITMAPV4HEADER and later extend it further.

The 12-byte BITMAPCOREHEADER — identical to the OS/2 1.1 header (detailed below) — contains:

For compatibility reasons, most applications write the older BITMAPINFOHEADER, which remains the common Windows format; it is described in the next table. Unless explicitly noted, the members in this table are unsigned integers.

Versions after BITMAPINFOHEADER only add fields to its end. Two further extensions, rarely encountered and never officially documented by Microsoft, are known: the 52-byte BITMAPV2INFOHEADER adds fields to BITMAPINFOHEADER for red, green and blue color masks, and the 56-byte BITMAPV3INFOHEADER in turn adds a field to BITMAPV2INFOHEADER for an alpha channel mask, together forming an RGBA mask set later standardized as header fields in BITMAPV4HEADER (see below). Their existence was confirmed by an Adobe employee, who stated that this documentation had at one point been included in official Microsoft documentation. The same engineer stated that Photoshop writes only two DIB header sizes — the 40-byte BITMAPINFOHEADER and the 56-byte BITMAPV3INFOHEADER — reserving the latter for its advanced formats, among them 16-bpp images that carry an alpha channel, such as A1R5G5B5 and A4R4G4B4. GIMP likewise offers 16-bpp A1R5G5B5 among its documented BMP export formats.

The compression method (offset 30) is most often BI_RGB (0), meaning no compression. BI_RLE8 (1) and BI_RLE4 (2) apply run-length encoding and are limited to 8- and 4-bpp bitmaps respectively. BI_BITFIELDS (3), restricted to 16- or 32-bpp images, means that three color masks specify the RGB bit layout for each pixel; their placement relative to the header is detailed below.

A handful of further values exist but are rarely encountered in practice: BI_JPEG (4) and BI_PNG (5) embed a JPEG or PNG image in place of raw pixel data (from BITMAPV4HEADER on); these values are documented as valid only for the StretchDIBits and SetDIBitsToDevice functions, and only when their destination is a printer device, letting an application forward already-compressed image data straight to printers with hardware JPEG/PNG support rather than for general bitmap storage or display. BI_ALPHABITFIELDS (6) is a Windows CE extension, valid in Windows CE .NET 4.0 and later, and is described below; Windows CE also departs from the desktop format with a non-standard 2 bpp format (below). BI_CMYK (11), BI_CMYKRLE8 (12) and BI_CMYKRLE4 (13) appear only inside Windows Metafiles, holding uncompressed, RLE-8 and RLE-4 CMYK images respectively.

BITMAPV4HEADER and later reuse BITMAPINFOHEADER's first 40 bytes unchanged, each member merely renamed with a bV4/bV5 prefix, and then append further fields.

BITMAPV5HEADER in turn keeps every BITMAPV4HEADER field unchanged, renamed with a bV5 prefix, and appends four more fields to support linked or embedded ICC color profiles:

Color management

bV4CSType and bV5CSType (offset 70) identify the color space of the DIB. LCS_CALIBRATED_RGB (0) means the endpoints and gamma values are given in the endpoint and gamma fields of the BITMAPV4HEADER extension table above; LCS_sRGB (0x73524742) selects sRGB, and LCS_WINDOWS_COLOR_SPACE (0x57696E20) the Windows default color space, which on modern Windows is sRGB. These three logical color-space values are available in BITMAPV4HEADER and are also valid in BITMAPV5HEADER.

BITMAPV5HEADER accepts two further values for bV5CSType: PROFILE_LINKED (0x4C494E4B) and PROFILE_EMBEDDED (0x4D424544), specific to it since BITMAPV4HEADER lacks the profile-data fields they require. For all values other than LCS_CALIBRATED_RGB, the endpoint and gamma fields above are ignored.

When bV5CSType is PROFILE_LINKED or PROFILE_EMBEDDED, bV5ProfileData gives the offset, in bytes from the beginning of the BITMAPV5HEADER structure, to the profile data; for a packed DIB, and similarly in the BMP file format, this data follows the pixel array. For PROFILE_EMBEDDED, the data found there is the ICC profile itself; for PROFILE_LINKED, it is instead the null-terminated path of an external profile file — which may be a fully qualified local or network path — composed of characters from the Windows-1252 code page, not Unicode. For an embedded profile, bV5ProfileSize gives the size of the profile data in bytes.

bV5Intent (offset 122, BITMAPV5HEADER only) sets the rendering intent. It can be LCS_GM_BUSINESS (1), the ICC Saturation intent, which maintains saturation and is used for business charts and other situations requiring undithered colors; LCS_GM_GRAPHICS (2), Relative Colorimetric, which maintains a colorimetric match and is used for graphic designs and named colors; LCS_GM_IMAGES (4), Perceptual, which maintains contrast and is used for photographs and natural images; or LCS_GM_ABS_COLORIMETRIC (8), Absolute Colorimetric, which maintains the white point and matches colors to their nearest color in the destination gamut.

Several classic GDI bitmap functions use the color-space information in the header when performing color matching: CreateDIBitmap, CreateDIBSection, SetDIBits, SetDIBitsToDevice and StretchDIBits do so only when it is BITMAPV4HEADER or BITMAPV5HEADER; for any other header, the current device context's own color profile (or, failing that, sRGB) is used instead.

Color masks

Color masks specify exactly which bits, within a 16- or 32-bit pixel, belong to each color channel. These masks can be supplied in two ways: when the compression method is BI_BITFIELDS, three DWORD color masks — for red, green and blue — follow the header; alternatively, versions after BITMAPINFOHEADER include the masks as part of the header itself (see above for how this developed across versions), with all four — red, green, blue and alpha — officially documented as header fields from BITMAPV4HEADER onward. Of these, only the red, green and blue masks are tied to BI_BITFIELDS — valid only under that compression method, whichever way they are supplied — while the alpha mask, available only as a header field, carries no such restriction and is described as always valid, regardless of compression method. The following example illustrates the mechanism:

The bit fields defined by the color masks must be contiguous and non-overlapping, but their order is arbitrary; a common bit-significance ordering is A-R-G-B, from the most significant bit to the least significant.

When no masks are supplied at all, a fixed default layout is assumed for the bit depth, shown below for every depth.

^a Color table entries are 3-byte RGBTRIPLE values, and the table is always full-size, with no biClrUsed-style override.

^b Color table entries are 4-byte RGBQUAD values; a smaller count may be given instead. ^c Any contiguous, non-overlapping red, green and blue bit masks — for example R5G6B5 at 16 bpp.

^d Versions after BITMAPINFOHEADER can also declare a separate alpha mask as a header field (see above), valid independently of whether the compression method is BI_RGB or BI_BITFIELDS.

A less common extension, found on Windows CE, adds a fourth compression value, BI_ALPHABITFIELDS, which appends a fourth mask, for alpha, directly after the three color masks — the trailing-mask counterpart, for the plain BITMAPINFOHEADER, of the alpha mask that versions after it instead carry as a header field, officially documented as such from BITMAPV4HEADER onward.

Color table

The color table, or palette, lists the colors used by the image. In an indexed-color bitmap each pixel is stored as a number of bits (1, 4 or 8) that form an index into this table; the entry it selects gives the color the pixel is displayed in. The table thus tells the application which actual color each index value represents. When present, it follows the header and any trailing color masks (see above).

For indexed-color images, the default number of entries is 2ⁿ, where n is the bit depth (the biBitCount member); a smaller count may be given instead in the biClrUsed member, and a value of zero means the table uses the full, default size for that bit depth. The biClrImportant member can likewise record how many of those color indexes are actually required to display the bitmap; a value of zero means all of them are. Unlike biClrUsed, biClrImportant is purely advisory for applications — GDI itself never reads it.

In Windows bitmaps each entry occupies 4 bytes in the order blue, green, red, 0x00 — the X8R8G8B8 layout (a RGBQUAD), whose fourth byte is reserved rather than a true alpha channel.

The BITMAPCOREHEADER format handles the color table differently: it supports only the full-size table, with no biClrUsed-style override, and each entry is 3 bytes, in blue, green, red order (a RGBTRIPLE), rather than the 4-byte RGBQUAD used elsewhere.

Because the palette is always stored explicitly in the file, the choice of colors is left to the encoder. A monochrome (1 bpp) image carries a two-entry table that is most often black and white, although the two entries are ordinary palette colors and may be any pair. By convention, 16-color (4 bpp) images tend to use a fixed, standard palette — typically the 16-color VGA/EGA palette, whose entries also correspond closely to the reserved static colors that Windows keeps in its system palette and does not allow to be changed. 256-color (8 bpp) images, by contrast, are more often given a palette tailored to the individual image through color quantization.

One edge case falls outside this description: for DIBs held in memory rather than in a file, the color table may instead consist of 2-byte entries that are indexes into the currently realized palette, rather than explicit color values.

At 16 bpp and higher the pixels carry their color directly, so a color table is normally absent, but it may be present as a palette for optimizing colors on palette-based devices — in which case biClrUsed specifies its size. Even then, it is not an indexed palette, and none of its entries are read back as pixel indices.

Pixel array

The pixel array (also called the bitmap data) holds the actual image, one row (also called a scan line) at a time; its offset from the start of the file is given by the file header, after the DIB header and any color table or color masks. The size of a stored row, including padding, is commonly called its stride. For uncompressed bitmaps, the pixel array consists of such DWORD-aligned scan lines; RLE-compressed bitmaps instead hold a variable-length encoded stream (see below).

Row order

Rows are usually stored "bottom-up": the first row of the pixel data is the bottom of the image, and each row runs left to right. When the Image Height value is negative, an uncompressed bitmap is instead stored "top-down", with the first row at the top of the image; top-down DIBs cannot be compressed, so their compression value must be BI_RGB or BI_BITFIELDS. BITMAPCOREHEADER can never select top-down order this way, since its height field is unsigned (see above).

Row padding

The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding; the padding bytes are not necessarily zero. The total number of bytes necessary to store one row of pixels can be calculated as: $${\displaystyle \text{RowSize}=\lceil \frac{\text{BitsPerPixel}\cdot \text{ImageWidth}}{32}\rceil \cdot 4=\lfloor \frac{\text{BitsPerPixel}\cdot \text{ImageWidth}+31}{32}\rfloor \cdot 4,}$$

ImageWidth is expressed in pixels. The equation above uses the floor and ceiling functions.

For images with height above 1, multiple padded rows are stored consecutively, forming the pixel array, whose total size can be calculated by accounting for the effect of rounding up the size of each row to a multiple of 4 bytes, as follows:

$${\displaystyle \text{PixelArraySize}=\text{RowSize}\cdot |\text{ImageHeight}|}$$

ImageHeight is expressed in pixels. The absolute value is necessary because ImageHeight is expressed as a negative number for top-down images. This formula applies to uncompressed pixel arrays only; RLE-compressed bitmaps hold a variable-length encoded data stream instead (see below).

When the pixel array is loaded into memory, each row must begin at a memory address that is a multiple of 4; this restriction applies only in memory — for file storage, only the size of each row must be a multiple of 4 bytes, while the offset of the pixel array itself can be arbitrary. A 24 bpp bitmap with Width=1 would have 3 bytes of data per row (blue, green, red) and 1 byte of padding, while Width=2 would have 6 bytes of data and 2 bytes of padding, Width=3 would have 9 bytes of data and 3 bytes of padding, and Width=4 would have 12 bytes of data and no padding.

Pixel formats

The BITMAPINFOHEADER (and later) supports 1, 4, 8, 16, 24 and 32 bpp; the older BITMAPCOREHEADER is limited to 1, 4, 8 or 24 bpp, its bcBitCount field excluding 16 and 32. Within a row, pixels are packed as follows:

• At 1 bpp, each bit is one pixel, the left-most pixel in the most significant bit of the first byte; each bit indexes a two-entry color table.
• At 4 bpp, each byte holds two pixels, the left-most in the more significant nibble; each nibble indexes a color table of up to 16 colors.
• At 8 bpp, each byte is one pixel, indexing a color table of up to 256 colors.
• At 16 bpp, each pixel is a 2-byte WORD; by default its bits form the X1R5G5B5 layout (the top bit unused), or one given by color masks (commonly R5G6B5).
• At 24 bpp, each pixel is 3 bytes in blue, green, red order (R8G8B8).
• At 32 bpp, each pixel is a 4-byte DWORD; by default its bits form the X8R8G8B8 layout (the high byte unused), or one given by color masks (commonly A8R8G8B8).

The standard BI_RGB layout does not assign a color channel to the fourth byte of a 32-bit pixel. Windows' GDI can nonetheless treat it as a per-pixel alpha value: its AlphaBlend function supports per-pixel alpha only for 32-bit BI_RGB data, always taking the alpha from a fixed high byte (the bytes being blue, green, red, alpha in memory) — no color mask is involved, and this holds regardless of which DIB header describes the bitmap, so even a BITMAPV4HEADER's or BITMAPV5HEADER's own bV4AlphaMask field is not consulted. AlphaBlend expects the alpha to be premultiplied and has been available since Windows 2000. Applications that parse the header themselves, by contrast, such as GIMP and Google Chrome, do honor a declared bV4AlphaMask when reading a file.

A few pixel formats fall outside this standard set. At 2 bpp, found only on Windows CE, each byte holds four pixels, the left-most in the two most significant bits, each indexing a color table of up to 4 colors. At 64 bpp, a GDI+-specific extension to the header's bit-depth field (undocumented in the core BITMAPINFOHEADER spec), each of the alpha, red, green and blue channels occupies 16 bits.

Compression

Indexed images at 4 or 8 bpp may be compressed with a run-length encoding (RLE) scheme, BI_RLE4 or BI_RLE8 respectively (see the compression values above); ordinary pixel arrays at 1, 16, 24 or 32 bpp are otherwise always stored uncompressed, and any depth may be stored uncompressed if desired. BI_JPEG and BI_PNG are a separate case, reserved for specific GDI printer operations rather than ordinary pixel storage (see the compression values above). A run is normally encoded, in encoded mode, as a count byte followed by a single byte that either gives the color index to repeat (BI_RLE8) or packs two alternating color indices into its high and low nibbles (BI_RLE4); a count of zero instead introduces one of three escapes: end of line, end of bitmap, or a delta that skips to a new position without drawing. In absolute mode (also flagged by a zero count byte), the following byte instead gives the number, 3–255, of literal pixels that follow — one color-index byte per pixel for BI_RLE8, or two nibble-packed pixels per byte for BI_RLE4 — with the run zero-padded to end on a 16-bit word boundary.

Example

The following is an example of a 2×2-pixel, 24 bpp (R8G8B8) bitmap using the Windows BITMAPINFOHEADER DIB header.

This example illustrates several properties of the BMP format at once. The pixel array begins at offset 54, immediately after the 14-byte file header and 40-byte DIB header. Because the image is 24 bpp and two pixels wide, each row contains 6 bytes of pixel data and 2 bytes of padding. The positive height means that the first stored row is the bottom row of the image.

OS/2 bitmap format

The headers and behavior described in this section are OS/2-specific — rarely produced by current software, but still occasionally encountered when reading older bitmap files.

IBM's documentation, and the Microsoft-published OS/2 Programmer's Reference, name the OS/2 1.x and 2.x DIB headers BITMAPINFOHEADER and BITMAPINFOHEADER2 respectively — the names this section uses below.

Structurally, an OS/2 bitmap file is a chain of structures, each nested as a literal member of the structure enclosing it, down to the pixel array at the bottom. When the file uses the bitmap-array container format (see below), a bitmap-array header sits at the very top of this chain — itself never nested inside anything else — wrapping an ordinary file header, which in turn wraps a DIB header, itself immediately followed by a color table when one is present. Because of this nesting, each structure's own recorded size is cumulative: a BITMAPFILEHEADER is 26 bytes (14 plus its nested 12-byte BITMAPINFOHEADER), a BITMAPFILEHEADER2 up to 78 (14 plus a BITMAPINFOHEADER2 of up to 64 bytes, less if truncated; see below), a BITMAPARRAYFILEHEADER 40 (14 plus the 26-byte BITMAPFILEHEADER), and a BITMAPARRAYFILEHEADER2 up to 92 (14 plus a BITMAPFILEHEADER2 of up to 78 bytes). In practice, though, this recorded size (cbSize) is often simply written as 0; parsers should instead rely on the nested header's own size field to determine its variant — just as usType (below) determines the resource type — and on offNext rather than cbSize to walk a bitmap array.

File headers

This file header is analogous to the Windows BITMAPFILEHEADER (above), but with two differences: Windows' two reserved 16-bit fields instead hold the X and Y coordinates of a hotspot, used only when the file is an icon or pointer; and the size field records the size of the header structure itself, rather than the size of the whole file.

Its type field (usType in IBM's BITMAPFILEHEADER/BITMAPFILEHEADER2, bfType in Windows) also records which kind of resource the file holds:

Bitmap arrays

A separate container format, with no Windows counterpart, bundles several device-dependent or device-independent renderings of the same bitmap, icon or pointer — for different display resolutions or color depths — together in one file as a bitmap array. Each rendering gets its own complete chain, headed by a BITMAPARRAYFILEHEADER (OS/2 1.x) or BITMAPARRAYFILEHEADER2 (OS/2 2.x), signature BA, wrapping an ordinary file header for that rendering. These per-rendering chains sit side by side in the file rather than nested inside one another: their array headers form a singly linked list, each one pointing, via an absolute file offset rather than one relative to itself, to the next (zero ending the chain); each also carries the pixel dimensions of the display device it targets (for example, 640×480 for VGA), and the device-independent rendering is required to come first.

IBM shipped its own system icons this way: a single array could bundle a 32×32 4 bpp rendering for VGA together with a 40×40 4 bpp rendering for 8514/A and XGA displays, alongside smaller 1 bpp 32×32, 20×20 and 16×16 mini-icon renderings.

Icons and pointers

Icons and pointers (mouse cursors) are stored as bitmaps using the same family of file headers, with the hotspot recorded in the file header. The AND and XOR masks always occupy a single 1-bit-per-pixel bitmap twice the declared height (BFT_ICON/BFT_POINTER), XOR first and AND second — the same arrangement used by monochrome Windows icons and cursors. A color icon or pointer (BFT_COLORICON/BFT_COLORPOINTER) adds a separate color layer after this one, giving two consecutive file headers: the AND/XOR bitmap first, the color layer second. For the mechanics of combining these masks, see ICO/CUR.

DIB headers

The OS/2 1.1 header (BITMAPINFOHEADER) is byte-for-byte identical to the Windows BITMAPCOREHEADER (detailed above), merely using IBM's own field names — cbFix, cx, cy, cPlanes and cBitCount, corresponding to Windows' bcSize, bcWidth, bcHeight, bcPlanes and bcBitCount respectively.

The OS/2 2.x BITMAPINFOHEADER2 corresponds field-for-field to the Windows 3.0 BITMAPINFOHEADER (above), then adds 24 further bytes:

The structure can be truncated after cBitCount or any subsequent field, with the omitted fields taking their default (generally zero) values — a truncated 16-byte form of the BITMAPINFOHEADER2 is encountered in, for example, the file pal8os2v2-16.bmp of the BMP Suite.

OS/2 bitmaps support only 1, 4, 8, or 24 bpp.

Compression

OS/2 2.x stores the compression scheme in the same field as Windows (ulCompression), but assigns some of the same values to different, OS/2-specific schemes: besides RLE for 4- and 8-bpp images (shared with Windows), it defines BCA_HUFFMAN1D (3), a modified Huffman encoding for bi-level (1 bpp) images, and BCA_RLE24 (4), a run-length encoding for 24 bpp images.

Halftoning

Rather than affecting how the pixel data itself is stored, usRendering (offset 60) records which halftoning algorithm should be used when rendering the image. Its default and most common value, BRH_NOTHALFTONED (0), disables halftoning. BRH_ERRORDIFFUSION (1) selects error diffusion, whose damping is set by halftoning parameter 1 (cSize1, offset 62) as a percentage — 100 indicating no damping, 0 indicating that errors are not diffused. BRH_PANDA (2) selects PANDA, the Processing Algorithm for Non-coded Document Acquisition, and BRH_SUPERCIRCLE (3) selects the Super Circle algorithm; for both, halftoning parameters 1 and 2 (cSize1/cSize2, offsets 62 and 66, respectively) give the X and Y dimensions, in pixels, of the halftoning pattern used.