BMP file format

This article is about the file format. For the data structure/type of image, seeBitmap graphics.

TheBMP file format,orbitmap,is araster graphicsimage file formatused to storebitmapdigital images,independently of thedisplay device(such as agraphics adapter), especially onMicrosoft WindowsandOS/2operating systems.

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?	OSPforWMF

The BMP file format is capable of storingtwo-dimensionaldigital images in variouscolor depths,and optionally withdata compression,alpha channels,andcolor profiles.TheWindows Metafile(WMF) specification covers the BMP file format.

Device-independent bitmaps and the BMP file format

Diagram 1– The structure of the bitmap image file

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 (DIB) 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 (hence, the device-independent part of the name). A DIB is an external format, in contrast to a device-dependent bitmap, which appears in the system as a bitmap object (created by an application...). A DIB is normally transported in metafiles (usually using the StretchDIBits() function), BMP files, and the Clipboard (CF_DIBdata format).

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

Referring to the diagram 1, the bitmap file is composed of structures in the following order:

Structure name	Optional	Size	Purpose	Comments
Bitmap file header	No	14 bytes	To store general information about the bitmap image file	Not needed after the file is loaded in memory
DIB header	No	Fixed-size (7 different versions exist)	To store detailed information about the bitmap image and define the pixel format	Immediately follows the Bitmap file header
Extra bit masks	Yes	3 or 4DWORDs (12 or 16 bytes)	To define the pixel format	Present only in case the DIB header is theBITMAPINFOHEADERand the Compression Method member is set to either BI_BITFIELDS or BI_ALPHABITFIELDS
Color table	Semi-optional	Variable size	To define colors used by the bitmap image data (Pixel array)	Mandatory forcolor depths≤ 8 bits
Gap1	Yes	Variable size	Structure alignment	An artifact of the File offset to Pixel array in the Bitmap file header
Pixel array	No	Variable size	To define the actual values of the pixels	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	Yes	Variable size	Structure alignment	An artifact of the ICC profile data offset field in the DIB header
ICC color profile	Yes	Variable size	To define the color profile for color management	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(an additional level of indirection), 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(unlike in diag. 1).

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 (with gap1=0 and gap2=0).
"Packed DIBs" are required byWindowsclipboard 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" inASCIIencoding. All of the integer values are stored inlittle-endianformat (i.e. least-significant byte first).

Offset hex	Offset dec	Size	Purpose
00	0	2 bytes	Theheader fieldused to identify the BMP and DIB file is0x42 0x4Dinhexadecimal,same asBMin 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
02	2	4 bytes	The size of the BMP file in bytes
06	6	2 bytes	Reserved; actual value depends on the application that creates the image, if created manually can be 0
08	8	2 bytes	Reserved; actual value depends on the application that creates the image, if created manually can be 0
0A	10	4 bytes	The offset, i.e. starting address, of the byte where the bitmap image data (pixel array) 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 (32-bit) 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.

Windows and OS/2 bitmap headers

Size	Header name	OS support	Features	Written by
12	BITMAPCOREHEADER OS21XBITMAPHEADER	Windows 2.0or later OS/21.x
64	OS22XBITMAPHEADER	OS/2BITMAPCOREHEADER2	Addshalftoning.AddsRLEandHuffman1D compression.
16	OS22XBITMAPHEADER	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 graphicpal8os2v2-16.bmp of the BMP Suite.
40	BITMAPINFOHEADER	Windows NT,3.1xor later	Extends bitmap width and height to 4 bytes. Adds 16 bpp and 32 bpp formats. Adds RLE compression.
52	BITMAPV2INFOHEADER	Undocumented	Adds RGB bit masks.	Adobe Photoshop
56	BITMAPV3INFOHEADER	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	Addsalpha channelbit mask.	Adobe Photoshop
108	BITMAPV4HEADER	Windows NT 4.0,95or later	Adds color space type andgamma correction
124	BITMAPV5HEADER	Windows NT 5.0,98or later	AddsICC color profiles	The GIMP

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

Offset (hex)	Offset (dec)	Size (bytes)	OS/2 1.xBITMAPCOREHEADER
0E	14	4	The size of this header (12 bytes)
12	18	2	The bitmap width in pixels (unsigned 16-bit)
14	20	2	The bitmap height in pixels (unsigned 16-bit)
16	22	2	The number of color planes, must be 1
18	24	2	The number of bits per pixel

The Windows 2.x BITMAPCOREHEADER differs from the OS/2 1.x BITMAPCOREHEADER (shown in the table above) in the one detail that the image width and height fields are signed integers, not unsigned.

Versions afterBITMAPINFOHEADERonly add fields to the end of the header of the previous version. For example:BITMAPV2INFOHEADERadds fields toBITMAPINFOHEADER,andBITMAPV3INFOHEADERadds fields toBITMAPV2INFOHEADER.

An integrated alpha channel has been introduced with the undocumentedBITMAPV3INFOHEADERand with the documentedBITMAPV4HEADER(sinceWindows 95) and is used withinWindows XPlogon and theme system as well as Microsoft Office (since v2000); it is supported by someimage editingsoftware, such asAdobe Photoshopsince version 7 andAdobe Flashsince version MX 2004 (then known as Macromedia Flash). It is also supported byGIMP,Google Chrome,Microsoft PowerPointandMicrosoft 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 theBITMAPINFOHEADERheader.See next table for its description. All values are stored as unsigned integers, unless explicitly noted.

Offset (hex)	Offset (dec)	Size (bytes)	WindowsBITMAPINFOHEADER
0E	14	4	the size of this header, in bytes (40)
12	18	4	the bitmap width in pixels (signed integer)
16	22	4	the bitmap height in pixels (signed integer)
1A	26	2	the number of color planes (must be 1)
1C	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.
1E	30	4	the compression method being used. See the next table for a list of possible values
22	34	4	the image size. This is the size of the raw bitmap data; a dummy 0 can be given for BI_RGB bitmaps.
26	38	4	the horizontal resolution of the image. (pixel per metre, signed integer)
2A	42	4	the vertical resolution of the image. (pixel per metre, signed integer)
2E	46	4	the number of colors in the color palette, or 0 to default to 2n
32	50	4	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	Comments
0	BI_RGB	none	Most common
1	BI_RLE8	RLE8-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	OS22XBITMAPHEADER:Huffman 1D	BITMAPV2INFOHEADER:RGB bit field masks, BITMAPV3INFOHEADER+:RGBA
4	BI_JPEG	OS22XBITMAPHEADER:RLE-24	BITMAPV4INFOHEADER+:JPEGimage for printing
5	BI_PNG		BITMAPV4INFOHEADER+:PNGimage for printing
6	BI_ALPHABITFIELDS	RGBA bit field masks	onlyWindows CE5.0 with.NET 4.0 or later
11	BI_CMYK	none	onlyWindows MetafileCMYK
12	BI_CMYKRLE8	RLE-8	onlyWindows MetafileCMYK
13	BI_CMYKRLE4	RLE-4	onlyWindows MetafileCMYK

An OS/2 2.xOS22XBITMAPHEADER(BITMAPINFOHEADER2in IBM's documentation) contains 24 additional bytes:

Offset (hex)	Offset (dec)	Size (bytes)	OS/2OS22XBITMAPHEADER(BITMAPINFOHEADER2)
36	54	2	An enumerated value specifying the units for the horizontal and vertical resolutions (offsets 38 and 42). The only defined value is 0, meaning pixels per metre
38	56	2	Padding. Ignored and should be zero
3A	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 (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
3C	60	2	An enumerated value indicating a halftoning algorithm that should be used when rendering the image.
3E	62	4	Halftoning parameter 1 (see below)
42	66	4	Halftoning parameter 2 (see below)
46	70	4	An enumerated value indicating the color encoding for each entry in the color table. The only defined value is 0, indicating RGB.
4A	74	4	An application-defined identifier. Not used for image rendering

The halftoning algorithm (offset 60) can be:

Value	Halftoning algorithm	Comments
0	none	Most common
1	Error diffusion	Halftoning parameter 1 (offset 64) 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 (offsets 64 and 68, respectively) represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used
3	Super-circle	Halftoning parameters 1 and 2 (offsets 64 and 68, respectively) represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used

Color table

The color table (palette) occurs in the BMP image file directly after the BMP file header, the DIB header, and after the optional three or four bitmasks if theBITMAPINFOHEADERheader with BI_BITFIELDS (12 bytes) or BI_ALPHABITFIELDS (16 bytes) option is used. Therefore, its offset is the size of theBITMAPFILEHEADERplus the size of the DIB header (plus optional 12-16 bytes for the three or four bit masks).
Note: OnWindows CEtheBITMAPINFOHEADERheader can be used with the BI_ALPHABITFIELDSoption in the biCompression member.

The number of entries in the palette is either 2ⁿ(where n is the number of bits per pixel) or a smaller number specified in the header (in the OS/2BITMAPCOREHEADERheader format, only the full-size palette is supported).In most cases, each entry in the color table occupies 4 bytes, in the order blue, green, red, 0x00 (see below for exceptions). This is indexed in theBITMAPINFOHEADERin the structure member biBitCount.

The color table is a block of bytes (a table) listing the colors used by the image. Each pixel in an indexed color image is described by a number of bits (1, 4, or 8) which is an index of a single color described by this table. The purpose of the color palette in indexed color bitmaps is to inform the application about the actual color that each of these index values corresponds to. The purpose of the color table in non-indexed (non-palettized) bitmaps is to list the colors used by the bitmap for the purposes of optimization on devices with limited color display capability and to facilitate future conversion to different pixel formats and palettization.

The colors in the color table are usually specified in the 4-byte per entryARGB32format. The color table used with the OS/2BITMAPCOREHEADERuses the 3-byte per entryRGB24format.For DIBs loaded in memory, the color table can optionally consist of 2-byte entries – these entries constitute indexes to the currently realized paletteinstead of explicit RGB color definitions.

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

As mentioned above, the color table is normally not used when the pixels are in the 16-bit per pixel (16bpp) format (and higher); there are normally no color table entries in those bitmap image files. However, the Microsoft documentation (on the MSDN web site as of Nov. 16, 2010) specifies that for 16bpp (and higher), the color table can be present to store a list of colors intended for optimization on devices with limited color display capability, while it also specifies, that in such cases, no indexed palette entries are present in this Color Table. This may seem like a contradiction if no distinction is made between the mandatory palette entries and the optional color list.

Pixel storage

The bits representing the bitmap pixels arepackedin rows (also known as strides or scan lines). The size of each row is rounded up to a multiple of 4 bytes (a 32-bitDWORD) by padding.

For images with height above 1, multiple padded rows are stored consecutively, forming a Pixel Array.

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,$$

ImageWidthis expressed in pixels. The equation above uses thefloor and ceiling functions.

The total number of bytes necessary to store an array of pixels in annbits per pixel (bpp) image, with2ⁿcolors, 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}}|$$

ImageHeightis expressed in pixels. The absolute value is necessary becauseImageHeightis expressed as a negative number for top-down images.

Pixel array (bitmap data)

The pixel array is a block of 32-bit DWORDs, that describes the image pixel by pixel. Usually pixels are stored "bottom-up", 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.UnlessBITMAPCOREHEADERis used, uncompressed Windows bitmaps also can be stored from the top to bottom, when the Image Height value is negative.

In the original OS/2 DIB, the only four legal values of color depth were 1, 4, 8, and 24 bits per pixel (bpp). Contemporary DIB Headers allow pixel formats with 1, 2, 4, 8, 16, 24 and 32 bits per pixel (bpp).GDI+also permits 64 bits per pixel.

Padding bytes (not necessarily 0) must be appended to the end of the rows in order to bring up the length of the rows to a multiple of four bytes. When the pixel array is loaded into memory, each row must begin at a memory address that is a multiple of 4. This address/offset restriction is mandatory only for Pixel Arrays loaded in memory. For file storage purposes, only the size of each row must be a multiple of 4 bytes while the file offset 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.

Compression

• Indexedcolor images may be compressed with 4-bit or 8-bitRLEorHuffman1D algorithm.
• OS/2BITMAPCOREHEADER224bppimages may be compressed with the 24-bit RLE algorithm.
• The16bppand32bppimages arealways stored uncompressed.
• Note that images in all color depths can be stored without compression if so desired.

Pixel format

• The 1-bit per pixel (1bpp) format supports 2 distinct colors, (for example: black and white). The pixel values are stored in each bit, with the first (left-most) pixel in the most-significant bit of the first byte.Each bit is an index into a table of 2 colors. An unset bit will refer to the first color table entry, and a set bit will refer to the last (second) color table entry.
• The 2-bit per pixel (2bpp) format supports 4 distinct colors and stores 4 pixels per 1 byte, the left-most pixel being in the two most significant bits (Windows CEonly:). Each pixel value is a 2-bit index into a table of up to 4 colors.
• The 4-bit per pixel (4bpp) format supports 16 distinct colors and stores 2 pixels per 1 byte, the left-most pixel being in the more significantnibble.Each pixel value is a 4-bit index into a table of up to 16 colors.
• The 8-bit per pixel (8bpp) format supports 256 distinct colors and stores 1 pixel per 1 byte. Each byte is an index into a table of up to 256 colors.
• The 16-bit per pixel (16bpp) format supports 65536 distinct colors and stores 1 pixel per 2-byte WORD. Each WORD can define the alpha, red, green and bluesamplesof the pixel.
• The 24-bit per pixel (24bpp) format supports 16,777,216 distinct colors and stores 1 pixel value per 3 bytes. Each pixel value defines the red, green and blue samples of the pixel (8.8.8.0.0 in RGBAX notation). Specifically, in the order: blue, green and red (8 bits per each sample).
• The 32-bit per pixel (32bpp) format supports 4,294,967,296 distinct colors and stores 1 pixel per 4-byte DWORD. Each DWORD can define the alpha, red, green and blue samples of the pixel.

In order to resolve the ambiguity of which bits define which samples, the DIB headers provide certain defaults as well as specific BITFIELDS, which are bit masks that define the membership of particular group of bits in a pixel to a particularchannel.The following diagram defines this mechanism:

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

The sample fields defined by the BITFIELDS bit masks have to be contiguous and non-overlapping, but the order of the sample fields is arbitrary. The most ubiquitous field order is: Alpha, Blue, Green, Red (MSB to LSB). The red, green and blue bit masks are valid only when the Compression member of the DIB header is set to BI_BITFIELDS. The alpha bit mask is valid whenever it is present in the DIB header or when the Compression member of the DIB header is set to BI_ALPHABITFIELDS(Windows CEonly).

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

All of the possible pixel formats in a DIB

RGB video subtypes

The BITFIELD mechanism described above allows for the definition of tens of thousands of different pixel formats, however only several of them are used in practice,all palettized formats RGB8, RGB4, and RGB1 (marked in yellow in the table above, defined indshow.h.MEDIASUBTYPE names):

Uncompressed RGB Video Subtypes

R.G.B.A.X	RGB subtype	R.G.B.A.X	ARGB subtype
8.8.8.0.8	RGB32	8.8.8.8.0	ARGB32
		10.10.10.2.0	A2R10G10B10
8.8.8.0.0	RGB24	10.10.10.2.0	A2B10G10R10
5.6.5.0.0	RGB565	4.4.4.4.0	ARGB4444
5.5.5.0.1	RGB555	5.5.5.1.0	ARGB1555

Bit fields for ten RGB bits

Bit field	Offset	BitsA2R10G10B10			BitsA2B10G10R10
Red	36h	00 00 F0 3F	LE:3FF00000	20...29	FF 03 00 00	LE:000003FF	0...9
Green	3Ah	00 FC 0F 00	LE:000FFC00	10...19	00 FC 0F 00	LE:000FFC00	10...19
Blue	3Eh	FF 03 00 00	LE:000003FF	0...9	00 00 F0 3F	LE:3FF00000	20...29
Alpha	42h	00 00 00 C0	LE:C0000000	30...31	00 00 00 C0	LE:C0000000	30...31

In version 2.1.4FFmpegsupported (in its own terminology) the BMP pixel formatsbgra, bgr24, rgb565le, rgb555le, rgb444le, rgb8, bgr8, rgb4_byte, bgr4_byte, gray, pal8,andmonob;i.e.,bgrawas the only supported pixel format with transparency.

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

Example 1

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

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

Example 2

Following is an example of a 4×2 pixel, 32-bit bitmap with opacity values in the alpha channel (Windows DIB HeaderBITMAPV4HEADER) with pixel format ARGB32.

Offset	Size	Hex value	Value	Description
BMP Header
0h	2	42 4D	"BM"	ID field (42h, 4Dh)
2h	4	9A 00 00 00	154 bytes (122+32)	Size of the BMP file
6h	2	00 00	Unused	Application specific
8h	2	00 00	Unused	Application specific
Ah	4	7A 00 00 00	122 bytes (14+108)	Offset where the pixel array (bitmap data) can be found
DIB Header
Eh	4	6C 00 00 00	108 bytes	Number of bytes in the DIB header (from this point)
12h	4	04 00 00 00	4 pixels (left to right order)	Width of the bitmap in pixels
16h	4	02 00 00 00	2 pixels (bottom to top order)	Height of the bitmap in pixels
1Ah	2	01 00	1 plane	Number of color planes being used
1Ch	2	20 00	32 bits	Number of bits per pixel
1Eh	4	03 00 00 00	3	BI_BITFIELDS, no pixel array compression used
22h	4	20 00 00 00	32 bytes	Size of the raw bitmap data (including padding)
26h	4	13 0B 00 00	2835 pixels/metre horizontal	Print resolution of the image, 72 DPI× 39.3701 inches per metre yields 2834.6472
2Ah	4	13 0B 00 00	2835 pixels/metre vertical
2Eh	4	00 00 00 00	0 colors	Number of colors in the palette
32h	4	00 00 00 00	0 important colors	0 means all colors are important
36h	4	00 00 FF 00	00FF0000 in big-endian	Red channel bit mask (valid because BI_BITFIELDS is specified)
3Ah	4	00 FF 00 00	0000FF00 in big-endian	Green channel bit mask (valid because BI_BITFIELDS is specified)
3Eh	4	FF 00 00 00	000000FF in big-endian	Blue channel bit mask (valid because BI_BITFIELDS is specified)
42h	4	00 00 00 FF	FF000000 in big-endian	Alpha channel bit mask
46h	4	20 6E 69 57	little-endian "Win"	LCS_WINDOWS_COLOR_SPACE
4Ah	24h	24h* 00...00	CIEXYZTRIPLE Color Space endpoints	Unused for LCS "Win"or"sRGB"
6Eh	4	00 00 00 00	0 Red Gamma	Unused for LCS "Win"or"sRGB"
72h	4	00 00 00 00	0 Green Gamma	Unused for LCS "Win"or"sRGB"
76h	4	00 00 00 00	0 Blue Gamma	Unused for LCS "Win"or"sRGB"
Start of the Pixel Array (the bitmap Data)
7Ah	4	FF 00 00 7F	255 0 0 127	Blue (Alpha: 127), Pixel (x=0, y=1)
7Eh	4	00 FF 00 7F	0 255 0 127	Green (Alpha: 127), Pixel (x=1, y=1)
82h	4	00 00 FF 7F	0 0 255 127	Red (Alpha: 127), Pixel (x=2, y=1)
86h	4	FF FF FF 7F	255 255 255 127	White (Alpha: 127), Pixel (x=3, y=1)
8Ah	4	FF 00 00 FF	255 0 0 255	Blue (Alpha: 255), Pixel (x=0, y=0)
8Eh	4	00 FF 00 FF	0 255 0 255	Green (Alpha: 255), Pixel (x=1, y=0)
92h	4	00 00 FF FF	0 0 255 255	Red (Alpha: 255), Pixel (x=2, y=0)
96h	4	FF FF FF FF	255 255 255 255	White (Alpha: 255), Pixel (x=3, y=0)

Note that the bitmap data starts with the lower left hand corner of the image.

Usage of BMP format

The simplicity of the BMP file format, and its widespread familiarity in Windows and elsewhere, as well as the fact that this format is relatively well documented and has anopen format,makes BMP a very common format that image processing programs from many operating systems can read and write.ICOand CUR files contain bitmaps starting with a BITMAPINFOHEADER.

Many oldergraphical user interfacesused bitmaps in their built-in graphics subsystems;for example, the Microsoft Windows and OS/2 platforms'GDIsubsystem, where the specific format used is theWindows and OS/2 bitmap file format,usually named with thefile extensionof.BMP.

While most BMP files have a relatively large file size due to lack of any compression (or generally low-ratiorun-length encodingon palletized images), many BMP files can be considerably compressed withlossless data compressionalgorithms such asZIPbecause they contain redundant data. Some formats, such asRAR,even include routines specifically targeted at efficient compression of such data.

Related formats

Main article:Image file formats

TheX Window Systemuses a similarXBMformat for black-and-white images, andXPM(pixelmap) for color images. There are also a variety of "raw" formats, which save raw data with no other information. ThePortable Pixmap(PPM) andTruevision TGAformats also exist, but are less often used – or only for special purposes; for example, TGA can contain transparency information.

External links

• Bitmap File Structure,at digicamsoft.com
• An introduction to DIBs (Device Independent Bitmaps),at herdsoft.com
• A simple bitmap loader C++ class,at kalytta.com (A2R10G10B10 not yetsupported)
• The BMP File Format, Part 1 By David Charlapat Dr. Dobb's journal of software tools (drdobbs.com), March 1995