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:
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
Bitmap file header This block of bytes is at the start of the file and is used to identify the file. A typical application reads this block first to ensure that the file is actually a BMP file and that it is not damaged. The first 2 bytes of the BMP file format are the character "B" then the character "M" in
ASCII encoding. All of the integer values are stored in
little-endian format (i.e. least-significant byte first).
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. 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 after only add fields to the end of the header of the previous version. For example: adds fields to , and adds fields to . An integrated alpha channel has been introduced with the undocumented and with the documented (since
Windows 95) and is used within
Windows XP logon and theme system as well as Microsoft Office (since v2000); it 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). It is also supported by
GIMP,
Google Chrome,
Microsoft PowerPoint and
Microsoft Word. For compatibility reasons, most applications use the older DIB headers for saving files.
With OS/2 no longer supported after Windows 2000, for now the common Windows format is the header. See next table for its description. All values are stored as unsigned integers, unless explicitly noted. The compression method (offset 30) can be: An OS/2 2.x ( in IBM's documentation) contains 24 additional bytes: option in the biCompression member.'' The number of entries in the palette is either 2
n (where n is the number of bits per pixel) or a smaller number specified in the header (in the OS/2 header format, only the full-size palette is supported). in and for 1bpp, 4bpp and 8bpp indexed color images, which indicates that the color table entries can also specify an alpha component using the RGBAX|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". 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 are
packed in rows (also known as strides or scan lines). The size of each row is rounded up to a multiple of 4 bytes (a 32-bit
DWORD) 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, The total number of bytes necessary to store an array of pixels in an n bits per pixel (bpp) image, with
2n 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}|
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.
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.). 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 significant
nibble. of 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 header ) with pixel format RGB24. File:Bmp_format2.svg|frame|right|
Example 2 of a 4×2 pixel bitmap, with 32 bits/pixel encoding rect 50 50 100 100
0,0: blue 0000FF FF rect 100 50 150 100
0,1: green 00FF00 FF rect 150 50 200 100
0,2: red FF00000 FF rect 200 50 250 100
0,3: white FFFFFF FF rect 50 100 100 150
1,0: blue 0000FF 7F, half transparent rect 100 100 150 150
1,1: green 00FF00 7F, half transparent rect 150 100 200 150
1,2: red FF0000 7F, half transparent rect 200 100 250 150
1,3: white FFFFFF 7F, half transparent default Netpbm#Transparency desc top-left
Example 2 Following is an example of a 4×2 pixel, 32-bit bitmap with opacity values in the alpha channel (Windows DIB Header ) with pixel format ARGB32. Note that the bitmap data starts with the lower left hand corner of the image. == Usage of BMP format ==