This file is paraphrased from files obtained from the Microsoft Knowledge Base on Compuserve. A Windows Device Independent Bitmap (DIB) v3.0 is composed of four sections: BITMAPFILEHEADER, BITMAPINFOHEADER, color table, and finally the image data itself. Each of these sections is defined below. ----------------------------------------------------------------------------- BITMAPFILEHEADER [3.0] The BITMAPFILEHEADER data structure contains information about the type, size, and layout of a device-independent bitmap (DIB) file. The BITMAPFILEHEADER data structure contains the following fields: Field Datatype Description ----- -------- ----------- bfType 2 byte character Specifies the type of file. It must be BM. bfSize 4 byte integer Specifies the size of the file in bytes. bfReserved1 2 byte integer Is reserved and must be set to zero. bfReserved2 2 byte integer Is reserved and must be set to zero. bfOffBits 4 byte integer Specifies in bytes the offset from the beginning of the file to the actual bitmap. ----------------------------------------------------------------------------- The next section can be either a BITMAPINFOHEADER or BITMAPCOREHEADER. The BITMAPCOREHEADER is for Presentation Manager v1.1 compatability and is not described in this document. BITMAPINFOHEADER contains the following fields: Field Data type Description ----- --------- ----------- biSize 4 byte integer This field defines the size of the BITMAPINFOHEADER in bytes. biWidth, 4 byte integer Define the width and the height of the bitmap biHeight in pixels. They are DWORD values for future expansion, and the code in Windows versions 3.0 and 3.1 ignores the high word (which should be set to 0). biPlanes 2 byte integer Should always be 1. All DIB definitions rely on biBitCount for color resolution definition. biBitCount 2 byte integer Defines the color resolution (in bits per pixel) of the DIB. Only four values are valid for this field: 1, 4, 8, and 24. biCompression 4 byte integer Specifies the type of compression. Can be one of three values: BI_RGB, BI_RLE4, or BI_RLE8 (0, 1, or 2). The most common and useful choice, BI_RGB, defines a DIB in which all is as it seems. Each block of biBitCount bits defines an index (or RGB value for 24-bit versions) into the color table. The other two options specify that the DIB is stored (or will be stored) using either the 4-bit or the 8-bit run length encoding (RLE) scheme that Windows supports. biSizeImage 4 byte integer Should contain the size of the bitmap proper in bytes (i.e. without headers or color table). biXPelsPerMeter,4 byte integer Define application-specified values for the biYPelsPerMeter desirable dimensions of the bitmap. This information can be used to maintain the physical dimensions of an image across devices of different resolutions. When not filled in, they should both be set to 0. biClrUsed 4 byte integer Provides a way for getting smaller color tables. When this field is set to 0, the number of colors in the color table is based on the biBitCount field (1 indicates 2 colors, 4 indicates 16, 8 indicates 256, and 24 indicates no color table). A nonzero value specifies the exact number of colors in the table. So, for example, if an 8-bit DIB uses only 17 colors, then only those 17 colors need to be defined in the table, and biClrUsed is set to 17. Of course, no pixel can have an index pointing past the end of the table. biClrImportant 4 byte integer Specifies that the first x colors of the color table are important to the DIB. If the rest of the colors are not available, the image still retains its meaning in an acceptable manner. biClrImportant is purely for application use; GDI does not touch this value. When this field is set to 0, all the colors are important, or rather, their relative importance has not been computed. ----------------------------------------------------------------------------- Color Table The color table immediately follows the header information. No color table is defined for 24-bit DIBs. The table consists of an array of RGBQUAD data structures. Red, green, and blue bytes are in reverse order (red swaps position with blue) from the Windows convention. This is another leftover from Presentation Manager compatibility. The RGBQUAD data structure contains the following fields: Field Data type Description ----- --------- ----------- rgbBlue Byte Blue component of the color. rgbGreen Byte Green component of the color. rgbRed Byte Red component of the color. rgbReserved Byte Is not currently used and must be set to zero. This structure is repeated for as many colors as are in the table (except for 24 bit/pixel DIBs which use the data itself to represent the colors and ignore the color table). ----------------------------------------------------------------------------- The final section contains the data itself. The biBitCount parameter specifies the format of the data. The four possible formats are described below. biBitCount Data format ---------- ----------- 1 DIBs are stored using each bit as an index into the color table. The most significant bit is the leftmost pixel. 4 DIBs are stored with each 4 bits representing an index into the color table. The most significant nibble is the leftmost pixel. 8 These DIBs are the easiest to store because each byte is an index. 24 DIBs have every 3 bytes representing a color (r, g, b). The following rules apply to all formats: - Every scanline is DWORD-aligned (DWORD=4 bytes). The scanline is buffered to alignment; the buffering is not necessarily 0. - The scanlines are stored upside down, with the first scan (scan 0) in memory being the bottommost scan in the image. This is another artifact of Presentation Manager compatibility. - 64K segment boundaries are not respected; scanlines can cross such boundaries (unlike the device-dependent bitmap format that is buffered to 64K boundaries).