BMP file format

Windows Bitmap
Filename extension	.bmp, .dib
Internet media type	image/bmp image/x-bmp
Type code	'BMP ' 'BMPf' 'BMPp'
Uniform Type Identifier (UTI)	com.microsoft.bmp
Developed by	Microsoft Corporation
Type of format	Raster graphics
Open format?	OSP for WMF

The BMP file format, also known as bitmap image file, device-independent bitmap (DIB), or simply bitmap, is a raster graphics image file format used to store bitmap digital images, independently of the display device (such as a graphics adapter). It originated with Microsoft Windows and was adopted by OS/2; used by the GDI subsystem of both platforms, it is sometimes called the Windows and OS/2 bitmap file format and is usually named with the file extension .bmp or .dib.

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 format's simplicity, its familiarity on Windows, and its status as a relatively well-documented, open format have made it very widely supported, so that image-processing programs on many operating systems can read and write BMP files. The same bitmap structure is embedded in related Windows formats: ICO and CUR files, for example, contain images that begin with a BITMAPINFOHEADER. Because uncompressed BMP files hold a great deal of redundant data, they can often be reduced substantially by general-purpose lossless compression such as ZIP or RAR.

The bitmap header structures were documented from the outset in Microsoft's general Windows and OS/2 programmer's references rather than in a specification dedicated to BMP alone; a formal specification of the same structures, using normative language, was only later folded into the Windows Metafile (WMF) specification, which Microsoft placed under its Open Specification Promise.

History

The BMP format is among the oldest image formats on the IBM PC, having originated with the first release of Microsoft Windows and evolved alongside it — and, for a time, alongside OS/2 — over the following decade. Because the format carries no field recording its version, the successive variants are distinguished by the size of their header, and an application identifies a variant by reading the header-size field at the start of the bitmap header.

The bitmap format that originated with Windows 1.0 (1985) was a simple device-dependent bitmap (DDB), highly dependent on the output device for which it was created, so a bitmap suited to one display was not necessarily usable on another. A program created such a bitmap through handle-based GDI calls and loaded it from a module's resources; the BITMAP structure recorded only its width, height, plane count and bits-per-pixel, and the raw bits followed in the device's own format, with no color table of its own.

Windows 3.0 (1990) introduced the device-independent bitmap (DIB) — the form still dominant today — as a bitmap that could be displayed correctly on any device of a given resolution regardless of how that device stored color, by carrying its own color table. Written to disk, this became the BMP file, built around the new 40-byte BITMAPINFOHEADER. The same release added run-length encoding for 4- and 8-bit images (BI_RLE4 and BI_RLE8). Windows 3.0 also still accepted the older, smaller header inherited from OS/2 (below), which it documented as a BITMAPCOREHEADER "compatible with … OS/2 Presentation Manager versions 1.1 and 1.2".

While these early versions of Windows were being developed, Microsoft shared responsibility with IBM for the first releases of OS/2, whose Presentation Manager graphical interface used a closely related bitmap format; the Windows 2.x and OS/2 1.x formats were identical. The device-independent bitmap that Windows 3.0 established was itself described at the time as "an extension of the bitmap format supported in the OS/2 1.1 Presentation Manager". That OS/2 format used a 12-byte information header — later named BITMAPCOREHEADER — whose leading size field was required to be 12. IBM's own documentation, and that same Microsoft reference, instead name this header BITMAPINFOHEADER — the same name Microsoft later gave the unrelated 40-byte structure above. To avoid that collision, some secondary sources instead call the OS/2 1.x and 2.x headers OS21XBITMAPHEADER and OS22XBITMAPHEADER; this article uses IBM's own names for them.

OS/2 then extended its version independently. The 64-byte BITMAPINFOHEADER2 widened the dimensions to 32 bits and added 24-bit RLE compression and Huffman 1D compression for bi-level images. OS/2 also defined a bitmap-array container — identified by the BA signature and holding images tagged BM, IC, PT, CI or CP — that could bundle several device-dependent and device-independent renderings of a bitmap, icon or pointer in a single file, the device-independent version first. As the two companies' operating-system efforts diverged, the Windows and OS/2 formats grew steadily further apart. Microsoft's support for OS/2 itself ended after Windows 2000, leaving BITMAPINFOHEADER as the common Windows format.

Windows NT added a variant of the 40-byte header for 16- and 32-bit images, in which a BI_BITFIELDS compression value places color masks after the header instead of a palette. Two further, undocumented headers of 52 and 56 bytes, which fold those RGB masks (and an alpha mask) into the header itself, are also encountered (described above).

Windows 95 and Windows NT 4.0 brought the 108-byte BITMAPV4HEADER, which added an explicit alpha-channel mask together with a color-space identifier, CIE color endpoints and per-channel gamma values, allowing Image Color Matching information to travel with the bitmap. Windows 98 and Windows 2000 followed with the 124-byte BITMAPV5HEADER, which can embed or link an ICC color profile.

An alpha channel had already appeared, undocumented, in BITMAPV3INFOHEADER; once BITMAPV4HEADER made it official, adoption followed — it is used within the Windows XP logon and theme system as well as Microsoft Office (since v2000), and is supported by some image editing software, such as Adobe Photoshop since version 7 and Adobe Flash since version MX 2004 (then known as Macromedia Flash), as well as by GIMP, Google Chrome, Microsoft PowerPoint and Microsoft Word. Independently of these header-borne masks, the alpha-blending functions introduced with Windows 2000 could take a per-pixel alpha value directly from a 32-bit BI_RGB image, with no color mask involved.

Rather than a specification dedicated to BMP alone, the format's structures were documented release by release inside the general Windows and OS/2 programmer's references, header files and online help; only the later Windows Metafile specification defined them formally, in normative language.

Windows bitmap format

Diagram 1 – The structure of the bitmap image file

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 values throughout the file — in every header, as well as in 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 — present only when the DIB header specifies a bitfields-based compression method in place of a color table.
• 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.

Offset (bytes)	Size (bytes)	Member	Description
0	2	bfType	The header field used to identify the file; it must be BM (the ASCII characters "B" and "M", 0x4D42).
2	4	bfSize	The size of the BMP file in bytes
6	2	bfReserved1	Reserved; must be zero
8	2	bfReserved2	Reserved; must be zero
10	4	bfOffBits	The offset, i.e. starting address, of the byte where the bitmap image data (pixel array) can be found.

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 BITMAPV5HEADER extend it further.

Windows DIB headers

Size (bytes)	Header name	OS support	Features
12	BITMAPCOREHEADER	Windows 2.0 or later	The original and smallest DIB header; stores width and height as 16-bit values and supports no compression. Detailed below, under IBM's field names.
40	BITMAPINFOHEADER	Windows 3.0 or later	Extends bitmap width and height to 4 bytes. Adds 16 bpp and 32 bpp formats. Adds RLE compression.
108	BITMAPV4HEADER	Windows NT 4.0, 95 or later	Adds color space type and gamma correction
124	BITMAPV5HEADER	Windows 2000, 98 or later	Adds ICC color profiles

Versions after BITMAPINFOHEADER only add fields to the end of the header of the previous version. 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.

For compatibility reasons, most applications write the older BITMAPINFOHEADER, which remains the common Windows format; it is described in the next table. All values are stored as unsigned integers, unless explicitly noted.

Windows BITMAPINFOHEADER

Offset (bytes)	Size (bytes)	Member	Description
14	4	biSize	The size of this header, in bytes (40)
18	4	biWidth	The bitmap width in pixels (signed integer)
22	4	biHeight	The bitmap height in pixels (signed integer)
26	2	biPlanes	The number of color planes (must be 1)
28	2	biBitCount	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	biCompression	The compression method being used. See the next table for a list of possible values
34	4	biSizeImage	The image size. This is the size of the raw bitmap data; a dummy 0 can be given for BI_RGB bitmaps.
38	4	biXPelsPerMeter	The horizontal resolution of the image (pixels per metre, signed integer)
42	4	biYPelsPerMeter	The vertical resolution of the image (pixels per metre, signed integer)
46	4	biClrUsed	The number of colors in the color palette, or 0 to default to 2n
50	4	biClrImportant	The number of important colors used, or 0 when every color is important; generally ignored

The compression method (offset 30) can be:

Value	Identified by	Compression method	Comment
0	BI_RGB	none	Most common
1	BI_RLE8	RLE 8-bit/pixel	Can be used only with 8-bit/pixel bitmaps
2	BI_RLE4	RLE 4-bit/pixel	Can be used only with 4-bit/pixel bitmaps
3	BI_BITFIELDS	RGB color masks	Can be used only with 16- or 32-bit/pixel bitmaps

BI_BITFIELDS (3) means the masks accompany the pixel data instead of a palette, 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, usable only for printing (from BITMAPV4HEADER on). BI_ALPHABITFIELDS (6), available only on Windows CE 5.0 with .NET 4.0 or later, is described below; Windows CE also departs from the desktop format with a non-standard 2-bit-per-pixel 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 BITMAPV5HEADER reuse BITMAPINFOHEADER's first 40 bytes unchanged, each member merely renamed with a bV4/bV5 prefix, and then append further fields.

Windows BITMAPV4HEADER extension fields

Offset (bytes)	Size (bytes)	Member	Description
54	4	bV4RedMask	Mask selecting the red bits of each pixel; used only when biCompression is BI_BITFIELDS (see Color masks below)
58	4	bV4GreenMask	Mask selecting the green bits of each pixel
62	4	bV4BlueMask	Mask selecting the blue bits of each pixel
66	4	bV4AlphaMask	Mask selecting the alpha bits of each pixel
70	4	bV4CSType	The color space of the DIB. See the table below for a list of possible values
74	36	bV4Endpoints	The CIE XYZ coordinates of the color space's red, green and blue endpoints, used only when bV4CSType is LCS_CALIBRATED_RGB
110	4	bV4GammaRed	Gamma response curve for red, in unsigned 16.16 fixed-point format; used only when bV4CSType is LCS_CALIBRATED_RGB
114	4	bV4GammaGreen	Gamma response curve for green
118	4	bV4GammaBlue	Gamma response curve for blue

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:

Windows BITMAPV5HEADER extension fields

Offset (bytes)	Size (bytes)	Member	Description
122	4	bV5Intent	The rendering intent to use for the bitmap. See the table below for a list of possible values
126	4	bV5ProfileData	Offset, in bytes from the start of this header, to an embedded or linked ICC profile
130	4	bV5ProfileSize	Size, in bytes, of the embedded profile data
134	4	bV5Reserved	Reserved; must be zero

bV4CSType and bV5CSType (offset 70) can be:

Value	Identified by	Meaning	Supported by
0	LCS_CALIBRATED_RGB	Endpoints and gamma values are given in the fields above	BITMAPV4HEADER and BITMAPV5HEADER
0x73524742	LCS_sRGB	The sRGB color space	BITMAPV4HEADER and BITMAPV5HEADER
0x57696E20	LCS_WINDOWS_COLOR_SPACE	The system default color space, sRGB	BITMAPV4HEADER and BITMAPV5HEADER
0x4C494E4B	PROFILE_LINKED	bV5ProfileData points to a linked profile's file name (see below)	BITMAPV5HEADER only — BITMAPV4HEADER lacks the profile-data fields these need
0x4D424544	PROFILE_EMBEDDED	bV5ProfileData points to embedded profile data (see below)	BITMAPV5HEADER only — BITMAPV4HEADER lacks the profile-data fields these need

bV5Intent (offset 122, BITMAPV5HEADER only) can be:

Value	Identified by	ICC name	Meaning
1	LCS_GM_BUSINESS	Saturation	Maintains saturation; used for business charts and other situations requiring undithered colors
2	LCS_GM_GRAPHICS	Relative Colorimetric	Maintains colorimetric match; used for graphic designs and named colors
4	LCS_GM_IMAGES	Perceptual	Maintains contrast; used for photographs and natural images
8	LCS_GM_ABS_COLORIMETRIC	Absolute Colorimetric	Maintains the white point; matches colors to their nearest color in the destination gamut

Several classic GDI bitmap functions key real color management to this distinction: CreateDIBitmap, CreateDIBSection, SetDIBits, SetDIBitsToDevice and StretchDIBits perform color matching using the color space recorded in the header 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

For 16- and 32-bit pixels, the header alone does not indicate which bits belong to which color channel. When the compression method is BI_BITFIELDS, three color masks — for red, green and blue — follow the header, spelling out exactly which bits make up each channel. The masks can also be built directly into an extended header instead of following it: the officially documented BITMAPV4HEADER (and later) carries all four color masks — red, green, blue and alpha — as header fields. When no masks are supplied at all, a fixed default layout is assumed for the bit depth, shown for every depth in Diag. 4 below. The following diagram illustrates the mechanism:

Diag. 2 – The BITFIELDS mechanism for a 32-bit pixel depicted in RGBAX sample length notation

The sample fields defined by the color masks must be contiguous and non-overlapping, but their order is arbitrary; the most common order is alpha, red, green, blue (from the most significant bit to the least significant).

The diagrams above and below use RGBAX notation: five numbers giving, in order, the bit width of the red, green, blue and alpha samples and of any unused padding.

Diag. 3 – The pixel format with an alpha channel for a 16-bit pixel (in RGBAX sample Length notation) actually generated by Adobe Photoshop

Diag. 4 – All of the possible pixel formats in a DIB, including the default layout used for each bit depth when no color masks are given

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 BITMAPV4HEADER and later instead carry as a header field.

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.

The table appears immediately after the file header, the DIB header and, when BI_BITFIELDS is used, after the three color masks. Its offset is therefore the size of the BITMAPFILEHEADER plus the size of the DIB header (plus 12 bytes when the color masks are present).

The 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.

In Windows bitmaps each entry occupies 4 bytes in the order blue, green, red, 0x00 — the ARGB32 (RGBQUAD) layout.

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 (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 (1bpp) 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 (4bpp) 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 (8bpp) images, by contrast, are more often given a palette tailored to the individual image through color quantization.

A few edge cases fall outside this description. On Windows CE, the color masks occupy 16 bytes instead of 12 (see above), shifting the table's offset accordingly. And 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.

Microsoft does not disallow the presence of a valid alpha channel mask in BITMAPV4HEADER and BITMAPV5HEADER for 1bpp, 4bpp and 8bpp indexed color images, which indicates that the color table entries can also specify an alpha component using the 8.8.8.[0-8].[0-8] format via the RGBQUAD.rgbReserved member. However, some versions of Microsoft's documentation disallow this feature by stating that the RGBQUAD.rgbReserved member "must be zero".

At 16 bits per pixel and higher the pixels carry their color directly, so a color table is normally absent. When one is nevertheless present it serves only to list colors for optimization on limited-color devices — it is not an indexed palette, and none of its entries are read back as pixel indices.

Pixel storage

The pixel array (also called the bitmap data) holds the actual image, one row — also called a scan line or stride — 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.

Row order

Rows are usually stored "bottom-up": the first row in the file is the bottom of the image, and each row runs left to right. When the Image Height value is negative, an uncompressed bitmap other than one using BITMAPCOREHEADER 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.

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: $${\text{RowSize}}=\left\lceil {\frac {{\text{BitsPerPixel}}\cdot {\text{ImageWidth}}}{32}}\right\rceil \cdot 4=\left\lfloor {\frac {{\text{BitsPerPixel}}\cdot {\text{ImageWidth}}+31}{32}}\right\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:

$${\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.

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-bit 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 standard DIB headers support 1, 4, 8, 16, 24 and 32 bits per pixel (bpp). 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 are split 1.5.5.5 (X1R5G5B5, the top bit unused), or as given by color masks (commonly 5.6.5, RGB565).
• At 24 bpp, each pixel is 3 bytes, in blue, green, red order.
• At 32 bpp, each pixel is a 4-byte DWORD; by default its bits are split 8.8.8 (the high byte unused), or as given by color masks.

The format does not itself define the fourth (unused) byte of a plain 32-bit BI_RGB pixel, yet Windows' GDI treats it as a per-pixel alpha value with no color mask involved: alpha-blended drawing supports per-pixel alpha only for 32-bit BI_RGB data, taking the alpha from the high byte (the bytes being blue, green, red, alpha in memory). The AlphaBlend function that performs this blending expects the alpha to be premultiplied and has been available since Windows 2000.

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); images at 1, 16, 24 or 32 bpp are always stored uncompressed, and any depth may be stored uncompressed if desired. A run is normally encoded, in encoded mode, as a count byte followed by one or two color-index bytes; 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 a literal run of 3–255 uncompressed pixels, padded to end on a 16-bit word boundary.

Example of a 2×2 pixel bitmap, with 24 bits/pixel encoding

ICC color profile

When bV5CSType is PROFILE_LINKED or PROFILE_EMBEDDED, bV5ProfileData gives the offset, in bytes from the start of the BITMAPV5HEADER structure itself (not from the start of the file), to further profile data; for a packed DIB such as a BMP file, that data follows the pixel array, and bV5ProfileSize gives its size in bytes. 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.

Example

Following is an example of a 2×2 pixel, 24-bit bitmap (Windows DIB header BITMAPINFOHEADER) with pixel format RGB24.

Offset (hex)	Size (bytes)	Hex value	Value	Description
BMP Header
00	2	42 4D	"BM"	ID field (42 4D)
02	4	46 00 00 00	70 bytes (54+16)	Size of the BMP file (54 bytes header + 16 bytes data)
06	2	00 00	Unused	Application specific
08	2	00 00	Unused	Application specific
0A	4	36 00 00 00	54 bytes (14+40)	Offset where the pixel array (bitmap data) can be found
DIB Header
0E	4	28 00 00 00	40 bytes	Number of bytes in the DIB header (from this point)
12	4	02 00 00 00	2 pixels (left to right order)	Width of the bitmap in pixels
16	4	02 00 00 00	2 pixels (bottom to top order)	Height of the bitmap in pixels. Positive for bottom to top pixel order.
1A	2	01 00	1 plane	Number of color planes being used
1C	2	18 00	24 bits	Number of bits per pixel
1E	4	00 00 00 00	0	BI_RGB, no pixel array compression used
22	4	10 00 00 00	16 bytes	Size of the raw bitmap data (including padding)
26	4	13 0B 00 00	2835 pixels/metre horizontal	Print resolution of the image, 72 DPI × 39.3701 inches per metre yields 2834.6472
2A	4	13 0B 00 00	2835 pixels/metre vertical
2E	4	00 00 00 00	0 colors	Number of colors in the palette
32	4	00 00 00 00	0 important colors	0 means all colors are important
Start of pixel array (bitmap data)
36	3	00 00 FF	0 0 255	Red, Pixel (x=0, y=1)
39	3	FF FF FF	255 255 255	White, Pixel (x=1, y=1)
3C	2	00 00	0 0	Padding for 4 byte alignment (could be a value other than zero)
3E	3	FF 00 00	255 0 0	Blue, Pixel (x=0, y=0)
41	3	00 FF 00	0 255 0	Green, Pixel (x=1, y=0)
44	2	00 00	0 0	Padding for 4 byte alignment (could be a value other than zero)

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.

File headers

An OS/2 bitmap file begins with a file header 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. OS/2 1.x uses BITMAPFILEHEADER, which nests the 12-byte BITMAPINFOHEADER; OS/2 2.x uses BITMAPFILEHEADER2, which nests the variable-length BITMAPINFOHEADER2 (see below).

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

OS/2 usType signatures

Signature	Value (hex)	Constant	Resource type
BM	0x4D42	BFT_BMAP	Bitmap
BA	0x4142	BFT_BITMAPARRAY	Bitmap array
IC	0x4349	BFT_ICON	Icon
CI	0x4943	BFT_COLORICON	Color icon
PT	0x5450	BFT_POINTER	Pointer (mouse cursor)
CP	0x5043	BFT_COLORPOINTER	Color pointer

OS/2 file header fields

Offset (bytes)	Size (bytes)	Member	Description
0	2	usType	The resource-type signature (see the table above)
2	4	cbSize	The size of this file header structure in bytes (Windows' bfSize instead gives the size of the entire file)
6	2	xHotspot	For an icon or pointer, the X coordinate of its hotspot; ignored for plain bitmaps (occupies the position of Windows' unused bfReserved1)
8	2	yHotspot	The corresponding Y coordinate of the hotspot (Windows' bfReserved2)
10	4	offBits	The offset, in bytes, from the start of this structure to the pixel data (Windows' bfOffBits)
14	variable	bmp / bmp2	The nested information header: BITMAPINFOHEADER inside a BITMAPFILEHEADER, BITMAPINFOHEADER2 inside a BITMAPFILEHEADER2 (see below)

Bitmap arrays

OS/2 also defines a container format with no Windows counterpart: several device-dependent or device-independent renderings of the same bitmap, icon or pointer — for different display resolutions or color depths — can be bundled together in one file as a bitmap array. Each rendering is preceded by a BITMAPARRAYFILEHEADER (OS/2 1.x) or BITMAPARRAYFILEHEADER2 (OS/2 2.x), signature BA, which is in turn followed by an ordinary file header for that rendering. The array headers form a singly linked list, chained by a file offset to the next header (zero ending the chain); each 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.

OS/2 bitmap-array header fields

Offset (bytes)	Size (bytes)	Member	Description
0	2	usType	BFT_BITMAPARRAY (BA)
2	4	cbSize	The size of this array-header structure in bytes
6	4	offNext	The file offset of the next array header, or zero if this is the last one
10	2	cxDisplay	The width, in pixels, of the display device this rendering targets (for example, 640 for VGA)
12	2	cyDisplay	The corresponding height of the target display device (for example, 480 for VGA)
14	variable	bfh / bfh2	The file header for this rendering (BITMAPFILEHEADER or BITMAPFILEHEADER2)

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

Icons and pointers

OS/2 stores icons and pointers (mouse cursors) as bitmaps using the same family of file headers, distinguished by the signatures IC/PT for monochrome images or CI/CP for color, with the hotspot recorded in the file header. As with Windows icons and cursors, the image data combines an AND mask with an XOR mask, applied to the screen in that order — first AND, then XOR; a color icon or pointer stores this as two consecutive file headers, a black-and-white mask bitmap followed by a color bitmap. For the mechanics of combining these masks, see ICO/CUR.

DIB headers

OS/2 DIB headers

Size (bytes)	Header name	OS support	Features
12	BITMAPINFOHEADER	OS/2 1.x	Identical to the Windows 2.0 BITMAPCOREHEADER (above).
64	BITMAPINFOHEADER2	OS/2 2.x	Extends the Windows 3.0 BITMAPINFOHEADER (above) with 24 more bytes. Adds halftoning. Adds RLE and Huffman 1D compression.

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

OS/2 1.x bitmaps are uncompressed and cannot be 16 or 32 bpp.

Offset (bytes)	Size (bytes)	Member	Description
14	4	cbFix	The size of this header (12 bytes)
18	2	cx	The bitmap width in pixels (unsigned 16-bit)
20	2	cy	The bitmap height in pixels (unsigned 16-bit)
22	2	cPlanes	The number of color planes, must be 1
24	2	cBitCount	The number of bits per pixel

The OS/2 2.x BITMAPINFOHEADER2 begins with the same five fields as the 12-byte header above (cbFix through cBitCount, with cx and cy now 32 bits wide), followed by six more matching the Windows 3.0 BITMAPINFOHEADER: ulCompression, cbImage, cxResolution, cyResolution, cclrUsed and cclrImportant. It then adds 24 further bytes:

Offset (bytes)	Size (bytes)	Member	Description
54	2	usUnits	An enumerated value specifying the units for the horizontal and vertical resolutions (offsets 38 and 42). The default value, BRU_METRIC (0), means pixels per metre
56	2	usReserved	Padding. Ignored and should be zero
58	2	usRecording	An enumerated value indicating the direction in which the bits fill the bitmap. The default value, BRA_BOTTOMUP (0), means the origin is the lower-left corner. Bits fill from left-to-right, then bottom-to-top. Note that Windows bitmaps (which don't include this field) can also specify an upper-left origin (bits fill from left-to-right, then top-to-bottom) by using a negative value for the image height
60	2	usRendering	An enumerated value indicating a halftoning algorithm that should be used when rendering the image.
62	4	cSize1	Halftoning parameter 1 (see below)
66	4	cSize2	Halftoning parameter 2 (see below)
70	4	ulColorEncoding	An enumerated value indicating the color encoding for each entry in the color table. The default value, BCE_RGB (0), specifies RGB triples
74	4	ulIdentifier	An application-defined identifier. Not used for image rendering

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 bits per pixel.

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-bit images (shared with Windows), it defines BCA_HUFFMAN1D (3), a modified Huffman encoding for bi-level (1-bit) images, and BCA_RLE24 (4), a run-length encoding for 24-bit 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, and can be:

Value	Constant	Halftoning algorithm	Comment
0	BRH_NOTHALFTONED	none	Most common (default)
1	BRH_ERRORDIFFUSION	Error diffusion	Halftoning parameter 1 (cSize1, offset 62) is the percentage of error damping. 100 indicates no damping. 0 indicates that errors are not diffused
2	BRH_PANDA	PANDA: Processing Algorithm for Non-coded Document Acquisition	Halftoning parameters 1 and 2 (cSize1/cSize2, offsets 62 and 66, respectively) represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used
3	BRH_SUPERCIRCLE	Super Circle	Halftoning parameters 1 and 2 (cSize1/cSize2, offsets 62 and 66, respectively) represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used

External links

• BMP Suite – a collection of test BMP files covering edge cases and non-standard variants, useful for exercising decoders