转自：http://www.fileformat.info/format/bmp/egff.htm
Also Known As:
BMP, DIB, Windows BMP, Windows DIB, Compatible Bitmap
| Type | Bitmap |
| Colors | 1-, 4-, 8-, 16-, 24-, and 32-bits |
| Compression | RLE, uncompressed |
| Maximum Image Size | 32Kx32K and 2Gx2G pixels |
| Multiple Images Per File | No |
| Numerical Format | Little-endian |
| Originator | Microsoft Corporation |
| Platform | Intel machines running Microsoft Windows, Windows NT, Windows 95, OS/2, and MS-DOS |
| Supporting Applications | Too numerous to list |
| See Also | OS/2 Bitmap |
Usage
Used as the standard bitmap storage format in the Microsoft Windows environment. Although it is based on Windows internal bitmap data structures, it is supported by many non-Windows and non-PC applications.
Comments
A well-defined format for programmers having access to the Microsoft Developer's Network Knowledge Base and Software Development Kits (SDKs). Its simple RLE compression scheme is rather inefficient for complex images. Its many variations and differences from the OS/2 BMP format can be confusing.
Vendor specifications are available for this format.
Code fragments are available for this format.
Sample images are available for this format.
The Microsoft Windows Bitmap (BMP) file format is one of several graphics file formats supported by the Microsoft Windows operating environment. BMP is the native bitmap format of Windows and is used to store virtually any type of bitmap data. Most graphics and imaging applications running under Microsoft Windows support the creation and display of BMP format files. BMP is also very popular in the MS-DOS operating system. It is also the native bitmap file format of OS/2.
Contents:
File Organization
File Details
For Further Information
The original bitmap format created for Windows 1.0 was very simple. It had a fixed color palette, did not support bitmap data compression, and was designed to support the most popular IBM PC graphics cards in use at the time (CGA, EGA, Hercules, and others). This defunct format is now often referred to as the original Windows device-dependent bitmap (DDB).
As Windows 2.0 was being developed, support for a programmable color palette was added to both Windows and BMP, allowing user-definable color data to be stored along with the bitmap data that used it. When stored in memory, this collection of information is known as a Microsoft Device Independent Bitmap, or DIB. When this information is written out to a file, it is known as the Microsoft Bitmap Format, or BMP. When you hear references to the DIB file format, it is BMP that is actually being referred to.
During the development of BMP, Microsoft shared responsibility with IBM for the development of early versions of IBM's OS/2 operating system. When Presentation Manager, the OS/2 graphical user interface, required a bitmap format, the Windows BMP format was used. Thus, the Windows 2.x and OS/2 1.x BMP formats are identical.
The BMP format modified for Windows 3.0 differs only slightly from the OS/2 Presentation Manager bitmap format that preceded it. Note that later revisions designed to support IBM OS/2 Presentation Manager 2.x have resulted in further divergence between the Microsoft Windows and IBM OS/2 BMP file formats. The current version of BMP for Windows 4.0 (Windows 95) contains all of the features and history of the Windows 2.x, 3.x, and Windows NT BMP formats.
The structure of BMP format files is closely tied to the API of both Windows and OS/2. In this regard, BMP was never meant to be a portable format or used for bitmap data interchange between different operating systems. As each of these operating system APIs has changed, the BMP format has changed along with it.
There are currently three versions of BMP under Windows (2.x, 3.x, and 4.x [Windows 95]), two versions under OS/2 (1.x and 2.x, with six possible variations), and a single version for Windows NT. This article details the three versions used under Microsoft Windows, as well as the Windows NT version. The original Microsoft device-dependent bitmap format is also discussed. For a discussion of the OS/2 BMP format versions and variants, see the article about the OS/2 BMP format.
All of the BMP versions originated on Intel-based machines and thus share a common little-endian heritage. The current BMP format is otherwise hardware-independent and can accommodate images with up to 32-bit color. Its basic design makes it a good general purpose format that can be used for color or black-and-white image storage if file size is not a factor. Its main virtues are its simplicity and widespread support in the PC marketplace.
The compression method used is a type of run-length encoding (RLE), although most BMP files to date have been stored uncompressed. A notable exception is the Microsoft Windows 3.1 sign-on screen shipped with all copies of the product. Although the BMP RLE scheme is lossless and easily and quickly decompressed, it is not considered a superior compression method.
Although the BMP format is well-defined, there is no actual format specification document published by Microsoft. Information about structure and data encoding methods is contained in a number of programmer's references, manuals, online help facilities, and include files associated with the Microsoft Windows Software Development Kits (SDKs) and Microsoft Developers Network Knowledge Base.
File Organization
Windows 1.x DDB files contain two sections: a file header and the bitmap data. There is no provision for a color palette or any other features that would make this format device-independent. Support for compression of the bitmap data is also lacking.
| File Header |
| Bitmap Data |
Windows 2.x, 3.x, and 4.x BMP files contain four sections: a file header, a bitmap information header, a color palette, and the bitmap data. Of these four sections, only the palette information may be optional, depending on the bit depth of the bitmap data. The BMP file header is 14 bytes in length and is nearly identical to the 1.x DDB header. The file header is followed by a second header (called the bitmap header), a variable-sized palette, and the bitmap data.
| File Header |
| Bitmap Header |
| Color Palette |
| Bitmap Data |
File Details
This section describes the original Windows DDB format and BMP format versions 2x, 3x, and 4x in greater detail.
Version 1 Device-Dependent Bitmap (Microsoft Windows 1.x)
DDB files contain only a file header followed by uncompressed bitmap data. The following shows the structure of the 10-byte DDB file header:
typedef struct _Win1xHeader
{
WORD Type; /* File type identifier (always 0) */
WORD Width; /* Width of the bitmap in pixels */
WORD Height; /* Height of the bitmap in scan lines */
WORD ByteWidth; /* Width of bitmap in bytes */
BYTE Planes; /* Number of color planes */
BYTE BitsPerPixel; /* Number of bits per pixel */
} WIN1XHEADER;
Type indicates the file type; for v1.x headers, it is always 0.
Width and Height represent the size of the bitmap in pixels and in scan lines, respectively.
ByteWidth shows the width of the bitmap in bytes. It is assumed that this value will include the size of any scan line padding that is present.
Planes is the number of color planes used to store the bitmap. This value is always 1.
BitsPerPixel is the size of each pixel in bits. This value is typically 1, 4, or 8.
The image data immediately follows the header and is stored in an uncompressed format. Each pixel stores an index value into the fixed system colormap used by Windows 1.0. The presence of scan line padding may be determined by comparing the calculated width of a line in bytes with the actual width of the line in bytes stored as the value of the ByteWidth field.
BMP Version 2 (Microsoft Windows 2.x)
All versions of BMP format files begin with the following 14-byte header:
typedef struct _WinBMPFileHeader
{
WORD FileType; /* File type, always 4D42h ("BM") */
DWORD FileSize; /* Size of the file in bytes */
WORD Reserved1; /* Always 0 */
WORD Reserved2; /* Always 0 */
DWORD BitmapOffset; /* Starting position of image data in bytes */
} WINBMPFILEHEADER;
FileType holds a 2-byte magic value used to identify the file type; it is always 4D42h or "BM" in ASCII. If your application reads Windows bitmap files, make sure to always check this field before attempting to use any of the data read from the file.
FileSize is the total size of the BMP file in bytes and should agree with the file size reported by the filesystem. This field only stores a useful value when the bitmap data is compressed, and this value is usually zero in uncompressed BMP files.
Reserved1 and Reserved2 do not contain useful data and are usually set to zero in a BMP header written to disk. These fields are instead used by an application when the header is read into memory.
BitmapOffset is the starting offset of the bitmap data from the beginning of the file in bytes.
Following the file header in v2.x BMP files is a second header called the bitmap header. This header contains information specific to the bitmap data. This header is 12 bytes in length and has the following format:
typedef struct _Win2xBitmapHeader
{
DWORD Size; /* Size of this header in bytes */
SHORT Width; /* Image width in pixels */
SHORT Height; /* Image height in pixels */
WORD Planes; /* Number of color planes */
WORD BitsPerPixel; /* Number of bits per pixel */
} WIN2XBITMAPHEADER;
Size is the size of the header in bytes. For Windows 2.x BMP files, this value is always 12.
Width and Height are the width and height of the image in pixels, respectively. If Height is a positive number, then the image is a "bottom-up" bitmap with the origin in the lower-left corner. If Height is a negative number, then the image is a "top-down" bitmap with the origin in the upper-left corner. Width does not include any scan-line boundary padding.
Planes is the number of color planes used to represent the bitmap data. BMP files contain only one color plane, so this value is always 1.
BitsPerPixel is the number of bits per pixel in each plane. This value will be in the range 1 to 24; the values 1, 4, 8, and 24 are the only values considered legal by the Windows 2.x API.
The Windows 2.x bitmap header is identical to the OS/2 1.x bitmap header except that the Width and Height fields are signed values in Windows BMP files.
Following the header is the color palette data. A color palette is always present in a BMP file if the bitmap data contains 1-, 4-, or 8-bit data. Twenty-four-bit bitmap data never uses a color palette (nor does it ever need to). Each element of the palette is three bytes in length and has the following structure:
typedef struct _Win2xPaletteElement
{
BYTE Blue; /* Blue component */
BYTE Green; /* Green component */
BYTE Red; /* Red component */
} WIN2XPALETTEELEMENT;
Blue, Green, and Red hold the color component values for a pixel; each is in the range 0 to 255.
The size of the color palette is calculated from the BitsPerPixel value. The color palette has 2, 16, 256, or 0 entries for a BitsPerPixel of 1, 4, 8, and 24, respectively. The number of color palette entries is calculated as follows:
NumberOfEntries = 1 << BitsPerPixel;
To detect the presence of a color palette in a BMP file (rather than just assuming that a color palette does exist), you can calculate the number of bytes between the bitmap header and the bitmap data and divide this number by the size of a single palette element. Assuming that your code is compiled using 1-byte structure element alignment, the calculation is:
NumberOfEntries = (BitmapOffset - sizeof(WINBMPFILEHEADER) - sizeof(WIN2XBITMAPHEADER)) / sizeof(WIN2XPALETTEELEMENT);
If NumberOfEntries is zero, there is no palette data; otherwise, you have the number of elements in the color palette.
BMP Version 3 (Microsoft Windows 3.x)
Version 3.x BMP files begin with the same 14-byte header as v2.x BMP files. The file header is also followed by a bitmap header, which is an expanded version of the v2.x bitmap header. It is 40 bytes in size and contains six additional fields:
typedef struct _Win3xBitmapHeader
{
DWORD Size; /* Size of this header in bytes */
LONG Width; /* Image width in pixels */
LONG Height; /* Image height in pixels */
WORD Planes; /* Number of color planes */
WORD BitsPerPixel; /* Number of bits per pixel */
/* Fields added for Windows 3.x follow this line */
DWORD Compression; /* Compression methods used */
DWORD SizeOfBitmap; /* Size of bitmap in bytes */
LONG HorzResolution; /* Horizontal resolution in pixels per meter */
LONG VertResolution; /* Vertical resolution in pixels per meter */
DWORD ColorsUsed; /* Number of colors in the image */
DWORD ColorsImportant; /* Minimum number of important colors */
} WIN3XBITMAPHEADER;
Size is the size of the header in bytes. For Windows 3.x BMP files, this value is always 40.
Width and Height are the width and height of the image in pixels, respectively. If Height is a positive number, then the image is a "bottom-up" bitmap with the origin in the lower-left corner. If Height is a negative number, then the image is a "top-down" bitmap with the origin in the upper-left corner. Width does not include any scan-line boundary padding.
Planes is the number of color planes used to represent the bitmap data. BMP files contain only one color plane, so this value is always 1.
BitsPerPixel is the number of bits in each pixel. This value is in the range 1 to 24; the values 1, 4, 8, and 24 are the only values considered legal by the Windows 3.x API.
Compression indicates the type of encoding method used to compress the bitmap data. 0 indicates that the data is uncompressed; 1 indicates that the 8-bit RLE algorithm was used; 2 indicates that the 4-bit RLE algorithm was used. (See the section called "Image Data and Compression" below for more information on BMP RLE encoding.)
SizeOfBitmap is the size of the stored bitmap in bytes. This value is typically zero when the bitmap data is uncompressed; in this case, the decoder computes the size from the image dimensions.
HorzResolution and VertResolution are the horizontal and vertical resolutions of the bitmap in pixels per meter. These values are used to help a BMP reader choose a proper resolution when printing or displaying a BMP file.
ColorsUsed is the number of colors present in the palette. If this value is zero, and the value of BitsPerPixel is less than 16, then the number of entries is equal to the maximum size possible for the colormap. BMP files with a BitsPerPixel value of 16 or greater will not have a color palette. This value is calculated by using the value of the BitsPerPixel field:
ColorsUsed = 1 << BitsPerPixel;
ColorsImportant is the number of significant colors in the palette, determined by their frequency of appearance in the bitmap data; the more frequent the occurrence of a color, the more important it is. This field is used to provide as accurate a display as possible when using graphics hardware supporting fewer colors than are defined in the image. For example, an 8-bit image with 142 colors might only have a dozen or so colors making up the bulk of the image. If these colors could be identified, a display adapter with only 16-color capability would be able to display the image more accurately using the 16 most frequently occurring colors in the image. The most important colors are always stored first in the palette; ColorsImportant is 0 if all of the colors in the palette are to be considered important.
The color palette that may follow the bitmap header is basically the same as the v2.x palette but adds an extra byte of padding to increase its size to four bytes. This allows palette entries to be read as 4-byte values, making these values more efficient to read in memory and easier to see in a hex dump or debugger.
typedef struct _Win3xPaletteElement
{
BYTE Blue; /* Blue component */
BYTE Green; /* Green component */
BYTE Red; /* Red component */
BYTE Reserved; /* Padding (always 0) */
} WIN3XPALETTEELEMENT;
Blue, Green, and Red hold the color component values for a pixel; each is in the range 0 to 255.
Reserved pads the structure to end on an even-byte boundary and is always zero.
BMP Version 3 (Microsoft Windows NT)
Windows NT uses a variation of the Windows 3.x BMP format to store 16- and 32-bit data in a BMP file. This variation adds three additional fields that follow the bitmap header in place of a color palette. The bitmap header is 40 bytes in length and has the following format:
typedef struct _WinNtBitmapHeader
{
DWORD Size; /* Size of this header in bytes */
LONG Width; /* Image width in pixels */
LONG Height; /* Image height in pixels */
WORD Planes; /* Number of color planes */
WORD BitsPerPixel; /* Number of bits per pixel */
DWORD Compression; /* Compression methods used */
DWORD SizeOfBitmap; /* Size of bitmap in bytes */
LONG HorzResolution; /* Horizontal resolution in pixels per meter */
LONG VertResolution; /* Vertical resolution in pixels per meter */
DWORD ColorsUsed; /* Number of colors in the image */
DWORD ColorsImportant; /* Minimum number of important colors */
} WINNTBITMAPHEADER;
All fields are the same as in the v3.x BMP format, except for the Compression field.
Compression indicates the type of encoding method used to compress the bitmap data. 0 indicates that the data is uncompressed; 1 indicates that the 8-bit RLE algorithm was used; 2 indicates that the 4-bit RLE algorithm was used; and 3 indicates that bitfields encoding was used. If the bitmap contains 16 or 32 bits per pixel, then only a Compression value of 3 is supported and the RedMask, GreenMask, and BlueMask fields will be present following the header in place of a color palette. If Compression is a value other than 3, then the file is identical to a Windows 3.x BMP file.
typedef _WinNtBitfieldsMasks
{
DWORD RedMask; /* Mask identifying bits of red component */
DWORD GreenMask; /* Mask identifying bits of green component */
DWORD BlueMask; /* Mask identifying bits of blue component */
} WINNTBITFIELDSMASKS;
RedMask, GreenMask, and BlueMask specify which bits in a pixel value correspond to a specific color in 16- and 32-bit bitmaps. The bits in these mask values must be contiguous and must not contain overlapping fields. The bits in the pixel are ordered from most significant to least significant bits. For 16-bit bitmaps, the RGB565 format is often used to specify five bits each of red and blue values, and six bits of green:
RedMask = 0xF8000000; /* 1111 1000 0000 0000 0000 0000 0000 0000 */ GreenMask = 0x07E00000; /* 0000 0111 1110 0000 0000 0000 0000 0000 */ BlueMask = 0x001F0000; /* 0000 0000 0001 1111 0000 0000 0000 0000 */
For 32-bit bitmaps, the RGB101010 format can be used to specify 10 bits each of red, green, and blue:
RedMask = 0xFFC00000; /* 1111 1111 1100 0000 0000 0000 0000 0000 */ GreenMask = 0x003FF000; /* 0000 0000 0011 1111 1111 0000 0000 0000 */ BlueMask = 0x00000FFC; /* 0000 0000 0000 0000 0000 1111 1111 1100 */
BMP Version 4 (Microsoft Windows 95)
Version 4.x BMP files begin with the same 14-byte header as v2.x and v3.x BMP files. The file header is also followed by a bitmap header, which is an expanded version of the v3.xbitmap header, incorporating the mask fields of the NT BMP format. This v4.x bitmap header is 108-bytes in size and contains 17 additional fields:
typedef struct _Win4xBitmapHeader
{
DWORD Size; /* Size of this header in bytes */
LONG Width; /* Image width in pixels */
LONG Height; /* Image height in pixels */
WORD Planes; /* Number of color planes */
WORD BitsPerPixel; /* Number of bits per pixel */
DWORD Compression; /* Compression methods used */
DWORD SizeOfBitmap; /* Size of bitmap in bytes */
LONG HorzResolution; /* Horizontal resolution in pixels per meter */
LONG VertResolution; /* Vertical resolution in pixels per meter */
DWORD ColorsUsed; /* Number of colors in the image */
DWORD ColorsImportant; /* Minimum number of important colors */
/* Fields added for Windows 4.x follow this line */
DWORD RedMask; /* Mask identifying bits of red component */
DWORD GreenMask; /* Mask identifying bits of green component */
DWORD BlueMask; /* Mask identifying bits of blue component */
DWORD AlphaMask; /* Mask identifying bits of alpha component */
DWORD CSType; /* Color space type */
LONG RedX; /* X coordinate of red endpoint */
LONG RedY; /* Y coordinate of red endpoint */
LONG RedZ; /* Z coordinate of red endpoint */
LONG GreenX; /* X coordinate of green endpoint */
LONG GreenY; /* Y coordinate of green endpoint */
LONG GreenZ; /* Z coordinate of green endpoint */
LONG BlueX; /* X coordinate of blue endpoint */
LONG BlueY; /* Y coordinate of blue endpoint */
LONG BlueZ; /* Z coordinate of blue endpoint */
DWORD GammaRed; /* Gamma red coordinate scale value */
DWORD GammaGreen; /* Gamma green coordinate scale value */
DWORD GammaBlue; /* Gamma blue coordinate scale value */
} WIN4XBITMAPHEADER;
Size is the size of the header in bytes. For Windows 4.x BMP files, this value is always 108.
Width and Height are the width and height of the image in pixels, respectively. If Height is a positive number, then the image is a "bottom-up" bitmap with the origin in the lower-left corner. If Height is a negative number, then the image is a "top-down" bitmap with the origin in the upper-left corner. Width does not include any scan-line boundary padding.
Planes is the number of color planes used to represent the bitmap data. BMP files contain only one color plane, so this value is always 1.
BitsPerPixel is the number of bits in each pixel. This value is in the range 1 to 24; the values 1, 4, 8, 16, 24, and 32 are the only values considered legal by the Windows 4.x API.
Compression indicates the type of encoding method used to compress the bitmap data. 0 indicates that the data is uncompressed; 1 indicates that the 8-bit RLE algorithm was used; 2 indicates that the 4-bit RLE algorithm was used; and 3 indicates that bitfields encoding was used. If the bitmap contains a 16- or 32-bit bitmap, then only a compression value of 3 is supported.
SizeOfBitmap is the size of the stored bitmap in bytes. This value is typically zero when the bitmap data is uncompressed (including bitfields-encoded bitmaps); in this case, the decoder computes the size from the image dimensions.
HorzResolution and VertResolution are the horizontal and vertical resolutions of the bitmap in pixels per meter. These values are used to help a BMP reader choose a proper resolution when printing or displaying a BMP file.
ColorsUsed is the number of colors present in the palette. If this value is zero and the BMP file contains a color palette, then the number of entries is equal to the maximum size possible for the color palette. If the bitmap has a pixel depth of 16 or greater, there is never a color palette, and this value will be zero.
ColorsImportant is the number of significant colors in the palette, determined by their frequency of appearance in the bitmap data; the more frequent the occurrence of a color, the more important it is. See the explanation of this field for the Windows 3.x bitmap header for more information.
RedMask, GreenMask, BlueMask, and AlphaMask specify which bits in a pixel value correspond to a specific color or alpha channel in 16- and 32-bit bitmaps. The bits in these mask values must be contiguous and must not contain overlapping fields. The bits in the pixel are ordered from most significant to least significant bits. For example, a 16-bit bitmap using the RGB555 format would specify five bits each of red, green, blue, and alpha as follows:
AlphaMask = 0xF8000000; /* 1111 1000 0000 0000 0000 0000 0000 0000 */ RedMask = 0x07C00000; /* 0000 0111 1100 0000 0000 0000 0000 0000 */ GreenMask = 0x003E0000; /* 0000 0000 0011 1110 0000 0000 0000 0000 */ BlueMask = 0x0001F000; /* 0000 0000 0000 0001 1111 0000 0000 0000 */
A 32-bit bitmap using the RGB888 format would specify eight bits each of red, green, and blue using the mask values as follows:
AlphaMask = 0xFF000000; /* 1111 1111 0000 0000 0000 0000 0000 0000 */ RedMask = 0x00FF0000; /* 0000 0000 1111 1111 0000 0000 0000 0000 */ GreenMask = 0x0000FF00; /* 0000 0000 0000 0000 1111 1111 0000 0000 */ BlueMask = 0x000000FF; /* 0000 0000 0000 0000 0000 0000 1111 1111 */
Note that Windows 95 only supports the RGB555 and RGB565 masks for 16-bit BMP bitmaps and RGB888 for 32-bit BMP bitmaps.
CSType is the color space type used by the bitmap data. Values for this field include 00h (calibrated RGB), 01h (device-dependent RGB), and 02h (device-dependent CMYK). Device-dependent RGB is the default color space. Calibrated RGB is defined by the 1931 CIE XYZ standard.
RedX, RedY, and RedZ specify the CIE X, Y, and Z coordinates, respectively, for the endpoint of the red component of a specified logical color space. These fields are used only when CSType is 00h (calibrated RGB).
GreenX, GreenY, and GreenZ specify the CIE X, Y, and Z coordinates, respectively, for the endpoint of the green component of a specified logical color space. These fields are used only when CSType is 00h (calibrated RGB).
BlueX, BlueY, and BlueZ specify the CIE X, Y, and Z coordinates, respectively, for the endpoint of the blue component of a specified logical color space. These fields are used only when CSType is 00h (calibrated RGB).
GammaRed, GammaGreen, and GammaBlue are the red, green, and blue gamma coordinate scale values, respectively, for this bitmap.
All of the additional fields added to the Windows 4.x bitmap header are used to support 16- and 32-bit bitmaps and color matching and color characterization of the bitmap data. Color processing may be performed on an image and the ICM (Image Color Matching) information stored in the BMP file. This data is used to provide color matching processing when the bitmap is printed or displayed.
Color Palette
As we have seen, a BMP color palette is an array of structures that specify the red, green, and blue intensity values of each color in a display device's color palette. Each pixel in the bitmap data stores a single value used as an index into the color palette. The color information stored in the element at that index specifies the color of that pixel.
One-, 4-, and 8-bit BMP files are expected to always contain a color palette. Sixteen-, 24-, and 32-bit BMP files never contain color palettes. Sixteen- and 32-bit BMP files contain bitfields mask values in place of the color palette.
You must be sure to check the Size field of the bitmap header to know if you are reading 3-byte or 4-byte color palette elements. A Size value of 12 indicates a Windows 2.x (or possibly an OS/2 1.x) BMP file with 3-byte elements. Larger numbers (such as 40 and 108) indicate later versions of BMP, which all use 4-byte color palette elements.
Windows BMP File Types
Each new version of BMP has added new information to the bitmap header. In some cases, the newer versions have changed the size of the color palette and added features to the format itself. Unfortunately, a field wasn't included in the header to easily indicate the version of the file's format or the type of operating system that created the BMP file. If we add Windows' four versions of BMP to OS/2's two versions--each with four possible variations--we find that as many as twelve different related file formats all have the file extension ".BMP".
It is clear that you cannot know the internal format of a BMP file based on the file extension alone. But, fortunately, you can use a short algorithm to determine the internal format of BMP files.
The FileType field of the file header is where we start. If these two byte values are 424Dh ("BM"), then you have a single-image BMP file that may have been created under Windows or OS/2. If FileType is the value 4142h ("BA"), then you have an OS/2 bitmap array file. Other OS/2 BMP variations have the file extensions .ICO and .PTR.
If your file type is "BM", then you must now read the Size field of the bitmap header to determine the version of the file. Size will be 12 for Windows 2.x BMP and OS/2 1.x BMP, 40 for Windows 3.x and Windows NT BMP, 12 to 64 for OS/2 2.x BMP, and 108 for Windows 4.x BMP. A Windows NT BMP file will always have a Compression value of 3; otherwise, it is read as a Windows 3.x BMP file.
Note that the only difference between Windows 2.x BMP and OS/2 1.x BMP is the data type of the Width and Height fields. For Windows 2.x, they are signed shorts and for OS/2 1.x, they are unsigned shorts. Windows 3.x, Windows NT, and OS/2 2.x BMP files only vary in the number of fields in the bitmap header and in the interpretation of the Compression field.
Image Data and Compression
Uncompressed data is a series of values representing either color palette indices or actual RGB color values. Pixels are packed into bytes and arranged as scan lines. Each scan line must end on a 4-byte boundary, so one, two, or three bytes of padding may follow each scan line.
Scan lines are stored from the bottom up if the value of the Height field in the bitmap header is a positive value; they are stored from the top down if the Height field value is negative. The bottom-up configuration is the most common, because scan lines stored from the top down cannot be compressed.
Monochrome bitmaps contain one bit per pixel, eight pixels per byte (with the most significant bit being the leftmost pixel), and have a 2-element color palette. If a BMP reader chooses to ignore the color palette, all "one" bits are set to the display's foreground color and all "zero" bits are set to the background color.
Four-bit pixels are packed two per byte with the most significant nibble being the leftmost pixel. Eight-bit pixels are stored one per byte. Both 4- and 8-bit pixel values are indices into color palettes 16 and 256 elements in size respectively.
Sixteen-bit pixels in the Windows NT format are two bytes in size and are stored in big-endian order. In other words, on little-endian machines these bytes must be read and flipped into little-endian order before they are used. The organization of the bit fields in the 16-bit pixels is defined by the values of the RedMask, GreenMask, and BlueMask fields in the header. The most common masks are RGB555 and RGB565. The Compression field must always be a value of 3 (bitfields encoding) when a file stores 16-bit data.
In the v4.x BMP format, 16- and 32-bit pixels are stored as little-endian 4-byte RGB values. Common masks for 32-bit data include RGB888 and RGB101010. These bit depths also require bitfields encoding and the mask fields in the bitmap header to define their pixel format. 24-bit bitmap data is always stored as 3-byte RGB values.
The Windows BMP format supports a simple run-length encoded (RLE) compression scheme for compressing 4-bit and 8-bit bitmap data. Since this is a byte-wise RLE scheme, 1-, 16-, 24-, and 32-bit bitmaps cannot be compressed using it, due to the typical lack of long runs of bytes with identical values in these types of data.
BMP uses a two-value RLE scheme. The first value contains a count of the number of pixels in the run, and the second value contains the value of the pixel. Runs of up to 255 identical pixel values may be encoded as only two bytes of data. Actually, it's a bit more complex than this. In addition to encoded runs, there are unencoded runs, delta markers, end-of-scan-line markers, and an end-of-RLE-data marker.
The 8-bit RLE algorithm (RLE8) stores repeating pixel values as encoded runs. The first byte of an encoded run will be in the range of 1 to 255. The second byte is the value of the 8-bit pixels in the run. For example, an encoded run of 05 18 would decode into five pixels each with the value 18, or 18 18 18 18 18.
When a scan line does not contain enough pixel runs to achieve a significant amount of compression, contiguous pixel values may be stored as literal or unencoded runs. An unencoded run may contain from 3 to 255 pixel values. The first byte of an unencoded run is always zero. This makes it possible to tell the difference between the start of an encoded and the start of an unencoded run. The second byte value is the number of unencoded pixel values that follow. If the number of pixels is odd, then a 00 padding value also follows. This padding value is not part of the original pixel data and should not be written to the decoded data stream. Here are some examples of encoded and unencoded data streams:
| Encoded Bytes | Decoded Bytes |
|---|---|
| 05 10 | 10 10 10 10 10 |
| 00 05 23 65 34 56 45 00 | 23 65 34 56 45 |
| 0A 0A | 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A |
| 00 04 46 57 68 79 | 46 57 68 79 |
Three marker values may also be found in the RLE data. Each of these markers also begins with a zero-byte value. The second byte value indicates the type of marker. These markers specify positional information relating to the decoded bitmap data and do not generate any data themselves.
The first marker is the end-of-scan-line marker and is identified by two byte values 00 and 00. This marker is an indication that the end of data for the current scan line has been reached. Encoded data occurring after this marker is decoded starting at the beginning of the next scan line. If an end-of-scan-line marker is not present in the encoded data, then the pixels will automatically wrap from the end of one scan line to the start of the next.
This marker is only used when you want to force the decoding of a scan line to end at a particular place. If the end-of-scan-line marker occurs in the middle of a scan line, all remaining pixels in the decoded bitmap for the line are ignored. This "short scan line" technique is used to omit unneeded portions of scan lines. Most often, it is found in icon and pointer BMP files.
The next marker is the end of RLE data marker. It is identified by the two byte values 00 and 01. This marker occurs only as the last two bytes of the RLE data. This marker is an indication that the reader should stop decoding data.
The last marker is the run offset marker, also called a delta or vector code. This marker is four bytes in size, with the first two bytes being the values 00 and 02, and the last two values specifying a pixel address using unsigned X and Y values as an offset from the current bitmap cursor position. The X value is the number of pixels across the scan line, and the Y value is the number of rows forward in the bitmap.
This run offset marker indicates the location in the bitmap where the next decoded run of pixels should be written. For example, a run offset marker value of 00 02 05 03 would indicate that the offset of the bitmap cursor should move five pixels down the scan line, three rows forward, and write out the next run. The cursor then continues writing decoded data from its new position moving forward.
Run offset markers are used when a bitmap may contain a large amount of "don't care" pixels. For example, if the BMP file holds a bitmap used as a mask (such as those used with icons and pointers), many of the pixels in the rectangular bitmap may not be used. Rather than store these unused pixels in the BMP file, only the significant pixels are stored, and the delta markers are used as "jumps" to skip over the parts of the bitmap not actually used in the mask.
The following are the BMP RLE markers:
00 00 End of scan line 00 01 End of bitmap data 00 02 XX YY Run offset marker
Here is an example of decoding an 8-bit data stream. Each of the values is an 8-bit index value into the color palette and not an actual color value.
| Encoded Bytes | Decoding Description | Decoded Bytes |
|---|---|---|
| 04 16 | Four bytes of value 16 | 16 16 16 16 |
| 08 45 | Eight bytes of value 45 | 45 45 45 45 45 45 45 45 |
| 00 00 | End of scan line | None |
| 00 02 04 02 | Move to offset four pixels forward and two rows up | None |
| 03 E4 | Three bytes of value E4 | E4 E4 E4 |
| 00 03 12 A4 46 00 | Three bytes of unencoded data | 12 A4 46 |
| 00 00 | End of scan line | None |
| 00 01 | End of RLE data | None |
The 4-bit RLE algorithm (RLE4) stores repeating pixel values in a very similar manner to RLE8. All of the markers are the same. The only real difference is that two pixel values are packed per byte, and these pixel values alternate when decoded. For example, an RLE4-encoded data stream of 07 48 would decode to seven pixels, alternating in value as 04 08 04 08 04 08 04.
If this looks bizarre, it's because you rarely see alternating runs of pixel values in bitmaps eight bits or greater in depth. Four-bit (16-color) bitmaps, however, usually contains a lot of dithering. Most dithering algorithms will yield relatively large runs of alternating pixels. Runs of repeating sequences of three and four pixels are also fairly common output from many dithering algorithms. But the ability to efficiently encode these types of pixel runs is not currently supported in the BMP RLE scheme.
In case you are thinking that runs of identical pixel values cannot be encoded by RLE4, you are incorrect. For example, a run of twelve pixels all of the value 9 would be RLE4-encoded as 0C 99 and would decode to the run 09 09 09 09 09 09 09 09 09 09 09 09.
Padding is added to unencoded pixel runs that are an odd number of bytes, rather than pixels, in length. And an unused final nibble in odd-length runs is set to zero. For example, the six pixel values 1 3 5 7 9 0 would be stored as the unencoded run 00 06 13 57 90 00, while the five pixel values 1 3 5 7 9 would be stored as the unencoded run 00 05 13 57 90 00.
Following is an example of decoding a 4-bit data stream. Each of the values is a 4-bit index value into the color palette and not an actual color value.
| Encoded Bytes | Decoding Description | Decoded Bytes |
|---|---|---|
| 04 16 | Four values alternating 1 and 6 | 1 6 1 6 |
| 08 44 | Eight values alternating 4 and 4 | 4 4 4 4 4 4 4 4 |
| 00 00 | End of scan line | None |
| 00 02 04 02 | Move to offset four pixels forward and two rows up | None |
| 03 E4 | Three values alternating E and 4 | E 4 E |
| 00 06 12 A4 46 00 | Six values of unencoded data | 1 2 A 4 4 6 |
| 00 00 | End of scan line | None |
| 00 01 | End of RLE data | None |
Here is a summary of Windows BMP data characteristics:
| Pixel Depth | Pixel Size | Compression | Color Palette | Color Masks |
|---|---|---|---|---|
| 1 bit | 1 bit | 0 | Yes | No |
| 4 bits | 4 bits | 0,2 | Yes | No |
| 8 bits | 1 byte | 0,1 | Yes | No |
| 16 bits | 4 bytes | 3 | No | Yes |
| 24 bits | 3 bytes | 0 | No | No |
| 32 bits | 4 bytes | 3 | No | Yes |
For Further Information
For further information about the Microsoft Windows Bitmap format, see the documentation included on the CD-ROM. Although you probably will not be able to get any information directly from them, here is Microsoft's address:
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Voice: 206-882-8080
FAX: 206-936-7329
BBS: 206-637-9009
FTP: ftp://ftp.microsoft.com
WWW: http://www.microsoft.com
The closest thing there is to an archive of Microsoft file format specifications is the Microsoft Developers Network Knowledge Base available on the MSDN CD-ROM and at Microsoft's Web site. The Win16 and Win32 Software Development Kits (SDKs) also have information on BMP.
Information about the Windows BMP format can also be found in the following references:
Charlap, David, "The BMP File Format: Part I," Dr. Dobb's Journal, vol. 20, no. 228, March 1995.
Charlap, David, "The BMP File Format: Part II," Dr. Dobb's Journal, vol. 20, no. 229, April 1995.
Luse, Marv, "The BMP File Format," Dr. Dobb's Journal, vol. 9, no. 219, September 1994, pp. 18-22.
Microsoft Corporation, Microsoft Win32 Programmer's Reference, vol. 5, Microsoft Press, Redmond, WA, 1993.
Microsoft Corporation, Microsoft Windows Programmer's Reference, vol. 2, v3, Microsoft Press, Redmond, WA, 1990.
Petzold, Charles, "Preserving a Device-Independent Bitmap: The Packed-DIB Format," PC Magazine, July 1991, pp. 433-439.
Petzold, Charles, "What's New in Bitmap Formats: A Look at Windows and OS/2," PC Magazine, 11 September 1990, pp. 403-410.
Swan, Tom, Inside Windows File Formats, Sams Publishing, 1993.
The code for the above issues of Dr. Dobb's Journal are available at:
ftp://ftp.mv.com/pub/ddj/1994/1194.09/bmp.zip
ftp://ftp.mv.com/pub/ddj/1995/1195.03/bmp.zip
The two Dr. Dobb's Journal articles by David Charlap contain a complete collection of source code for working with Windows 2.x, 3.x, NT, and OS/2 BMP file formats. It is available at the above FTP site.
//-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
也被称为：
BMP，DIB的Windows时，Windows BMP，DIB，兼容位图
| 类型 | 位图 |
| 颜色 | 1 - ，4 - ，8 - ，16 - ，24 - ，和32位 |
| 压缩 | RLE，未压缩 |
| 最大图像大小 | 32Kx32K和2Gx2G像素 |
| 每个文件的多张图片 | 没有 |
| 数值格式 | 小端 |
| 鼻祖 | 微软公司 |
| 平台 | 英特尔机器上运行的Microsoft Windows时，Windows NT，Windows 95中，OS / 2，和MS-DOS |
| 支持应用程序 | 不胜枚举 |
| 参见 | OS / 2位图 |
用途
用于在Microsoft Windows环境中的位图存储格式为标准。虽然它是基于Windows内部的位图数据结构，它支持许多非Windows和非PC应用。
评论
一个良好定义的格式程序员访问微软开发的网络知识库和软件开发工具包（SDK）。其简单的RLE压缩方案是相当低效的复杂图像。它的许多变化，从OS / 2的BMP格式的差异可能会造成混淆。
供应商规范 这种格式。
这种格式的代码片段。
这种格式样本图像。
微软Windows位图（BMP）文件格式是几个图形文件格式，支持Microsoft Windows操作系统环境之一。BMP是原生的位图格式的Windows是用来存储任何类型的位图数据。大多数图形和图像Microsoft Windows下运行的应用程序支持创建和显示BMP格式的文件。BMP是在MS-DOS操作系统也很受欢迎。这也是本机的OS / 2的位图文件格式。
原来创建的位图格式为Windows 1.0是很简单的。它有一个固定的调色板，不支持位图数据压缩，并且被设计为支持最流行的IBM PC图形卡在使用时间（CGA，EGA，大力士，和其他人）。现在这种被禁的格式通常被称为为原始Windows依赖于设备的位图（DDB）。
由于Windows 2.0正在开发一个可编程的调色板，支持被添加到Windows和BMP，允许用户自定义的颜色数据使用位图数据一起存储。此类信息收集，存储在内存中，被称为微软的设备无关位图，或DIB。当这个信息被写入到一个文件中，它被称为微软的位图格式，或BMP。当你听到引用DIB文件格式，它是BMP，实际上是被提及。
在BMP的发展过程中，微软与IBM共同承担责任，为IBM的OS / 2操作系统的早期版本的发展。当演示管理器，OS / 2的图形用户界面，需要一个位图格式，使用的Windows BMP格式。因此，视窗2 x 和OS / 2的1 列 BMP格式是相同的。
BMP格式修改为Windows 3.0，OS / 2 Presentation Manager的位图格式之前略有不同。注意，以后的版本支持IBM OS / 2 Presentation Manager的2 x进一步分歧导致微软Windows和IBM OS / 2 BMP文件格式。当前版本的BMP为Windows 4.0（Windows 95）中包含了所有的功能和历史的Windows 2 X，3 x和Windows NT BMP格式。
BMP格式文件的结构是紧密相关的API，Windows和OS / 2。在这方面，BMP从来不意味着是一个便携式的格式，或使用不同的操作系统之间的位图数据交换。由于这些操作系统API发生了变化，BMP格式的改变与它一起。
目前有三个版本的BMP Windows下（2，x 3，x，和4 × [ 视窗95]），OS / 2下的两个版本（1，x和2 x，有六个可能的变化），并单一版本，用于Windows NT。本文详细介绍了三个版本的Microsoft Windows下使用，以及Windows NT版本。原始的Microsoft设备相关的位图格式进行了讨论。OS / 2的BMP格式的版本和变体的讨论，请参阅有关OS / 2的BMP格式的文章。
所有的BMP版本起源在基于Intel的机器，都有一个共同的little-endian的遗产。目前BMP格式，否则独立于硬件，可容纳多达32位色的图像。它的基本设计使得它一个很好的通用格式，可用于彩色或黑色和白色图像的存储，如果文件大小是不是一个因素。它的主要优点是其简单性和PC市场的广泛支持。
使用的压缩方法是一种不同的运行长度编码（RLE），虽然大多数的BMP文件迄今已存储的未压缩的。一个值得注意的例外是在Microsoft Windows 3.1标志屏幕上附带产品的所有副本。虽然BMP RLE计划的是无损，轻松，快速地解压缩，它不被认为是卓越的压缩方法。
虽然BMP格式的定义，不存在实际的格式规范文件由Microsoft发布。信息结构和数据编码方法中包含了一些程序员的参考手册，在线帮助工具，包括与微软Windows软件开发工具包（SDK）和Microsoft开发人员网络知识库文件相关。
文件组织
视窗1 x DDB文件包含两个部分：一个文件头和位图数据。调色板或任何其他格式独立于设备的功能，将没有任何规定。支持压缩的位图数据也缺乏。
| 文件头 |
| 位图数据 |
窗口2 x 3 x 4 x BMP文件包含四个部分：一个文件头，位图信息头，一个调色板，位图数据。这四个部分中，只有调色板信息可以是可选的，根据位图数据的位深度。BMP文件头是14个字节的长度的1几乎是相同的。：x， DDB标头。文件的标题，其次是第二报头（称为位图信息头），一个可变大小的调色板，和位图数据。
| 文件头 |
| 位图信息头 |
| 调色板 |
| 位图数据 |
文件详细信息
本节介绍了原始的Windows DDB格式和BMP格式版本2 x 3 x 4 x更详细。
版本1设备相关位图（微软Windows 1.x中）
DDB文件只包含一个文件头，其次是未压缩的位图数据。显示DDB文件头10字节的结构如下：
typedef结构_Win1xHeader的
{
WORD类型; / *文件类型标识符（总是0）* /
字宽; / *位图的宽度（以像素为单位）* /
字高; / *扫描线中的位图的高度* /
WORD ByteWidth; / *位图的宽度（以字节为单位）* /
字节飞机; / *彩色飞机的数量* /
BYTE bitsperpixel计算; / *每像素比特数* /
} WIN1XHEADER;
类型表示的文件类型;卷x头，它始终为0。
“宽度”和“高度”表示以像素为单位的位图的大小和扫描线。
ByteWidth显示的位图的宽度（以字节为单位）。据推测，此值将包括本任何扫描线填充的大小。
平面是用于存储位图的颜色平面的数量。此值始终为1。
bitsperpixel计算每个像素的位数的大小。此值通常为1，4，或8。
的图象数据紧跟的标头和被存储在一个未压缩的格式。每个像素存储所使用的Windows 1.0的固定系统的颜色表的索引值。作为的ByteWidth字段的值存储以字节为单位的行的实际宽度（以字节为单位），通过比较计算出的宽度的线，扫描线填充的存在下可被确定。
BMP第2版（微软Windows 2.x的）
BMP格式文件的所有版本以下14个字节的头开始：
typedef结构_WinBMPFileHeader的
{
WORD文件格式; / *文件类型，总是4D42h（“BM”）* /
DWORD文件大小; / *文件的大小（以字节为单位）* /
WORD保留; / * 0 * /
WORD保留; / * 0 * /
DWORD BitmapOffset / *起始位置的图像数据（以字节为单位）* /
} WINBMPFILEHEADER;
文件格式拥有一个2字节的魔法值，用于识别文件类型，它始终是从4D42h或“BM”的ASCII。如果您的应用程序读取Windows位图文件，请尝试使用从文件中读取的任何数据之前，请务必确认这一领域。
文件大小的BMP文件的字节数和总规模应同意报告的文件大小，文件系统。该字段仅存储被压缩的位图数据时的一个有用的值，并且该值通常是零，在未压缩的BMP文件。
保留和预留不包含有用的数据，通常设置为零在一个BMP头写入到磁盘中。这些字段，而不是由应用程序使用时，头被读入内存。
BitmapOffset是起始偏移量从一开始的位图数据文件的字节数。
继V2 x BMP文件的文件头是第二头叫点阵图头。这个头文件包含位图数据的特定信息。的长度为12字节的长度，并具有以下格式：
typedef结构_Win2xBitmapHeader的
{
DWORD大小; / *此头的大小（以字节为单位）* /
短宽; / *图像宽度的像素* /
身材矮小; / *图像的像素高度* /
WORD飞机; / *彩色飞机数量* /
WORD bitsperpixel计算; / *每像素比特数* /
} WIN2XBITMAPHEADER;
大小的标头的大小（以字节为单位）。对于Windows 2 x BMP文件，此值始终是12。
“宽度”和“高度”中的图像像素的宽度和高度分别。如果身高是一个正数，那么图像是一个“自下而上”的起源，在左下角的位图。如果高度是负数，那么图像是一种“自上而下”的位图在左上角的起源。宽度不包括任何扫描线边界填充。
平面是用于表示位图数据的颜色平面的数量。BMP文件只包含一个色彩平面，所以这个值总是1。
bitsperpixel计算是在每个平面上的每个像素的比特数。此值范围为1〜24，值1，4，8和24是唯一的值视为合法的Windows X 的API。
窗口2。所述位图信息头是相同的OS / 2的1 所述位图信息头，但宽度和高度方面签署值在Windows BMP文件。
继头调色板数据。调色板是始终存在的一个BMP文件中，如果包含1 - ，4 - ，8位数据位图数据。二十四位位图数据从来没有使用一个调色板（也不需要）。调色板中的每个元素是3个字节的长度，并具有以下结构：
typedef结构_Win2xPaletteElement的
{
BYTE蓝/ *蓝色分量* /
BYTE绿色; / *绿色分量* /
BYTE红; / *红色分量* /
} WIN2XPALETTEELEMENT;
蓝，绿，和红保持一个像素的颜色分量的值分别是范围为0〜255。
bitsperpixel计算值计算出调色板的大小。调色板有2个，16，256，或0的条目bitsperpixel计算1，4，8和24，分别。调色板条目的数目的计算方法如下：
NumberOfEntries = 1 << bitsperpixel计算;
来检测是否存在一个BMP文件的彩色调色板中（而不是仅仅假定存在一个调色板），则可以计算之间的位图信息头和位图数据的字节数和一个单一的大小除以这个数字调色板的元素。假设您的代码被编译使用1个字节的结构元素对齐，计算是：
BitmapOffset NumberOfEntries =（ - sizeof（WINBMPFILEHEADER）的 - 大小（WIN2XBITMAPHEADER））/ sizeof（WIN2XPALETTEELEMENT）的;
如果NumberOfEntries为零，也没有调色板数据，否则，就必须在调色板中的元素的数量。
BMP第3版（微软Windows 3.x中）
第3版x BMP文件V2 x BMP文件具有相同的14字节的头开始。文件的标题，还跟着一个位图信息头，这是一个扩大版V2 x位图信息头。它的大小为40个字节，包含6个额外的字段：
typedef结构_Win3xBitmapHeader的
{
DWORD大小; / *此头的大小（以字节为单位）* /
长宽; / *图像宽度的像素* /
长个儿; / *图像的像素高度* /
WORD飞机; / *彩色飞机数量* /
WORD bitsperpixel计算; / *每像素比特数* /
/ *添加的字段的Windows 3.x遵循这一行* /
DWORD压缩/压缩方法* /
DWORD SizeOfBitmap / *位图的大小（以字节为单位）* /
长HorzResolution; / *水平分辨率，每米像素数* /
长VertResolution; / *垂直分辨率，每米像素数* /
DWORD ColorsUsed / *图像中的颜色数* /
DWORD ColorsImportant的; / *最低数量的重要颜色* /
} WIN3XBITMAPHEADER;
大小的标头的大小（以字节为单位）。的Windows 3 x BMP文件，这个值是40。
“宽度”和“高度”中的图像像素的宽度和高度分别。如果身高是一个正数，那么图像是一个“自下而上”的起源，在左下角的位图。如果高度是负数，那么图像是一种“自上而下”的位图在左上角的起源。宽度不包括任何扫描线边界填充。
平面是用于表示位图数据的颜色平面的数量。BMP文件只包含一个色彩平面，所以这个值总是1。
bitsperpixel计算是在每个像素中的比特的数量。这个值是1〜24;值1，4，8和24是唯一的值认为是合法的Windows 3 X API。
压缩表示不同的编码方法，用于压缩的位图数据。0表示该数据是未压缩的; 1表明，在8位的RLE算法使用，2表示使用的4位的RLE算法。（请参阅节“称为”图像数据和压缩 BMP RLE编码的更多信息。）
SizeOfBitmap所存储的位图的大小（以字节为单位）。此值通常为零时，位图数据是未压缩的，在这种情况下，解码器计算从图像尺寸的大小。
HorzResolution和VertResolution的水平和垂直分辨率，每米像素的位图。这些值被用来帮助一个BMP读者时，选择适当的分辨率打印或显示一个BMP文件。
ColorsUsed是本调色板中的颜色的数量。如果这个值是零，bitsperpixel计算的值小于16，则该条目数等于未能颜色表的最大大小。BMP文件与BitsPerPixel的16或更大的价值不会有调色板。这个值是计算使用bitsperpixel计算领域的价值：
ColorsUsed = 1 << bitsperpixel计算;
ColorsImportant显着调色板中的颜色，是由位图中的数据出现的频率越频繁发生的颜色，更重要的它是。这个字段是用来提供尽可能准确的显示时，使用图形硬件的支持较少的图像中定义的颜色比。例如，一个8位的142色图像可能只会有一打左右的颜色了大量的图像。如果这些颜色可以被识别，只有16色的能力，将能够更准确地使用的16个最频繁出现的图像中的颜色来显示图像的显示适配器。最重要的颜色总是先在调色板中存储; ColorsImportant的是0，如果所有的调色板中的颜色都被认为是重要的。
该调色板可能遵循的位图信息头基本上是相同的卷x调色板，但增加了一个额外的填充字节，以增加其大小4个字节。这允许调色板项被理解为4个字节的值，这些值更有效地读到内存中，并在十六进制转储或调试更容易看到。
typedef结构_Win3xPaletteElement的
{
BYTE蓝/ *蓝色分量* /
BYTE绿色; / *绿色分量* /
BYTE红; / *红色分量* /
字节保留; / *填充（总是0）* /
} WIN3XPALETTEELEMENT;
蓝，绿，和红保持一个像素的颜色分量的值分别是范围为0〜255。
保留填充结构甚至字节边界结束，始终为零。
BMP第3版（微软的Windows NT）
Windows NT使用的视窗3的变化x BMP格式来存储一个BMP文件中的16 -和32-bit数据。这种变化增加了三个额外字段遵循的调色板的位图信息头。位图信息头的长度为40个字节，并具有以下格式：
typedef结构_WinNtBitmapHeader的
{
DWORD大小; / *此头的大小（以字节为单位）* /
长宽; / *图像宽度的像素* /
长个儿; / *图像的像素高度* /
WORD飞机; / *彩色飞机数量* /
WORD bitsperpixel计算; / *每像素比特数* /
DWORD压缩/压缩方法* /
DWORD SizeOfBitmap / *位图的大小（以字节为单位）* /
长HorzResolution; / *水平分辨率，每米像素数* /
长VertResolution; / *垂直分辨率，每米像素数* /
DWORD ColorsUsed / *图像中的颜色数* /
DWORD ColorsImportant的; / *最低数量的重要颜色* /
} WINNTBITMAPHEADER;
所有的信息在卷3的相同。x BMP格式，除了压缩字段。
压缩表示不同的编码方法，用于压缩的位图数据。0表示该数据是未压缩的; 1表明，在8位的RLE算法使用，2表示使用的4位的RLE算法，图3表示使用了位域编码。如果位图的每个像素包含16或32位，则只有一个压缩值为3的支持和RedMask GreenMask和BlueMask字段代替一个调色板中的标头后，将本。如果压缩是3以外的值，则该文件到Windows 3相同。：x， BMP文件。
的typedef _WinNtBitfieldsMasks的
{
DWORD RedMask; / *红色成分的面膜识别位* /
DWORD GreenMask; / *绿色成分的面膜识别位* /
DWORD BlueMask; / *蓝色成分的面膜识别位* /
} WINNTBITFIELDSMASKS;
RedMask，GreenMask，BlueMask指定位的像素值对应到一个特定的颜色：16 - 和32位位图。这些掩码值位必须是连续的，不能包含重叠的领域。位在像素下令从最显著的最低有效位。对于16位的位图，RGB565格式通常被用来指定的红色和蓝色的值的5位，6位绿色：
RedMask = 0xF8000000 / * 1111 1000 0000 0000 0000 0000 0000 0000 * / GreenMask = 0x07E00000 / * 0000 0111 1110 0000 0000 0000 0000 0000 * / BlueMask = 0x001F0000; / * 0000 0000 0001 1111 0000 0000 0000 0000 * /
对于32位的位图，的RGB101010格式可用于指定红色，绿色和蓝色各10位：
RedMask = 0xFFC00000; / * 1111 1111 1100 0000 0000 0000 0000 0000 * / GreenMask = 0x003FF000 / * 0000 0000 0011 1111 1111 0000 0000 0000 * / （BlueMask = 0x00000FFC）; / * 0000 0000 0000 0000 0000 1111 1111 1100 * /
BMP第4版（微软Windows 95）
第4版x BMP文件V2 x 和x v3的BMP文件具有相同的14字节的头开始。文件的标题，也跟着由一个位图信息头，这是一个扩大版的V3，x位图信息头，将NT BMP格式的掩码字段。此卷所述位图信息头的大小是108字节，包含17个额外的字段：
typedef结构_Win4xBitmapHeader的
{
DWORD大小; / *此头的大小（以字节为单位）* /
长宽; / *图像宽度的像素* /
长个儿; / *图像的像素高度* /
WORD飞机; / *彩色飞机数量* /
WORD bitsperpixel计算; / *每像素比特数* /
DWORD压缩/压缩方法* /
DWORD SizeOfBitmap / *位图的大小（以字节为单位）* /
长HorzResolution; / *水平分辨率，每米像素数* /
长VertResolution; / *垂直分辨率，每米像素数* /
DWORD ColorsUsed / *图像中的颜色数* /
DWORD ColorsImportant的; / *最低数量的重要颜色* /
/ *添加的字段为Windows 4.x中遵循这一行* /
DWORD RedMask; / *红色成分的面膜识别位* /
DWORD GreenMask; / *绿色成分的面膜识别位* /
DWORD BlueMask; / *蓝色成分的面膜识别位* /
DWORD AlphaMask; / *掩膜识别位alpha分量* /
DWORD CSType; / *颜色空间类型* /
龙RedX / * X坐标红端点* /
LONG REDY / *红端点的Y坐标* /
龙RedZ / * Z坐标红端点* /
龙GreenX / *绿色终点的X坐标* /
LONG GREENY; / *绿色终点Y坐标* /
龙GreenZ / * Z坐标的绿色端点* /
龙蓝色快车/ * X坐标的蓝色端点* /
龙发蓝; / *蓝色端点Y坐标* /
龙BlueZ的; / * Z坐标的蓝色端点* /
DWORD GammaRed / *伽玛红色坐标刻度值* /
DWORD GammaGreen / *伽玛绿色坐标刻度值* /
DWORD GammaBlue / *伽玛蓝色坐标刻度值* /
} WIN4XBITMAPHEADER;
大小的标头的大小（以字节为单位）。对于Windows 4 x BMP文件，这个值是108。
“宽度”和“高度”中的图像像素的宽度和高度分别。如果身高是一个正数，那么图像是一个“自下而上”的起源，在左下角的位图。如果高度是负数，那么图像是一种“自上而下”的位图在左上角的起源。宽度不包括任何扫描线边界填充。
平面是用于表示位图数据的颜色平面的数量。BMP文件只包含一个色彩平面，所以这个值总是1。
bitsperpixel计算是在每个像素中的比特的数量。此值范围为1〜24;值1，4，8，16，24和32是唯一的值认为是合法的Windows 4 X API。
压缩表示不同的编码方法，用于压缩的位图数据。0表示该数据是未压缩的; 1表明，在8位的RLE算法使用，2表示使用的4位的RLE算法，图3表示使用了位域编码。如果位图包含一个16 - 位或32位位图，那么只有3支持的压缩值。
SizeOfBitmap所存储的位图的大小（以字节为单位）。此值通常为零时，位图数据是未压缩的（包括位字段编码的位图），在这种情况下，解码器计算从图像尺寸的大小。
HorzResolution和VertResolution的水平和垂直分辨率，每米像素的位图。这些值被用来帮助一个BMP读者时，选择适当的分辨率打印或显示一个BMP文件。
ColorsUsed是本调色板中的颜色的数量。如果这个值是零，BMP文件包含一个调色板，则条目的数量是等于调色板尽可能的最大大小。如果位图有16或更大的像素的深度，是从来没有一个调色板，并且这个值将是零。
ColorsImportant显着调色板中的颜色，是由位图中的数据出现的频率越频繁发生的颜色，更重要的它是。为Windows 3。所述位图信息头的更多信息，请参阅此字段的解释。
RedMask GreenMask，BlueMask，AlphaMask指定位的像素值对应一种特定的颜色或alpha通道的16 - 和32位位图。这些掩码值位必须是连续的，不能包含重叠的领域。位在像素下令从最显著的最低有效位。例如，一个16位的位图，使用RGB555格式指定5位红色，绿色，蓝色，和α，如下所示：
AlphaMask = 0xF8000000 / * 1111 1000 0000 0000 0000 0000 0000 0000 * / 0x07C00000 RedMask = / * 0000 0111 1100 0000 0000 0000 0000 0000 * / GreenMask = 0x003E0000 / * 0000 0000 0011 1110 0000 0000 0000 0000 * / BlueMask = 0x0001F000; / * 0000 0000 0000 0001 1111 0000 0000 0000 * /
一个32位位图，使用RGB888格式将指定的红，绿，蓝各8位掩码值如下：
AlphaMask为0xff000000 =; / * 1111 1111 0000 0000 0000 0000 0000 0000 * / RedMask = 0x00FF0000; / * 0000 0000 1111 1111 0000 0000 0000 0000 * / GreenMask = 0x0000FF00 / * 0000 0000 0000 0000 1111 1111 0000 0000 * /; BlueMask = 0x000000ff的; / * 0000 0000 0000 0000 0000 0000 1111 1111 * /
请注意，仅Windows 95支持的RGB555和RGB565口罩，为16位BMP位图和RGB888 32位BMP位图。
CSType的色彩空间的类型，所使用的位图数据。此字段的值（校准RGB）00H，01H（设备相关的RGB），02H（设备相关的CMYK）。与设备相关的RGB是默认的颜色空间。校准的RGB被定义在1931 CIE XYZ标准。
REDY RedX，RedZ指定与CIE X，Y，和Z坐标，分别用于指定逻辑颜色空间中的红色成分的端点。只有当这些字段用于CSType是00H（校准RGB），。
GreenX，GREENY，GreenZ指定与CIE X，Y，和Z坐标，分别为端点的绿色分量的指定逻辑颜色空间的。只有当这些字段用于CSType是00H（校准RGB），。
蓝色快车，发蓝，BlueZ的指定的CIE X，Y，和Z坐标，分别用于蓝色分量的指定逻辑颜色空间的端点。只有当这些字段用于CSType是00H（校准RGB），。
GammaRed，GammaGreen，GammaBlue的红色，绿色，和蓝色伽玛坐标刻度值，分别为，该位图。
所有的附加 字段添加到Windows 4。所述 位图信息头，支持16 -位和32位位图和颜色匹配和颜色特征的位图数据。可以进行色彩处理，图像和ICM（图像颜色匹配）信息存储在BMP文件。该数据被用来提供颜色匹配处理时，位图打印或显示。
调色板
正如我们已经看到，BMP调色板是一个数组结构，指定显示设备调色板中的红，绿，蓝每种颜色的亮度值。每个像素的位图数据中存储一个单一的价值作为一个索引调色板。存储在该索引处的元素的颜色信息，指定该像素的颜色。
一，4 - ，和8-bit BMP文件总是包含一个调色板。十六，24 - ，和32位BMP文件从来不包含调色板。十六位和32位的BMP文件包含位域掩码值的调色板。
您必须确保检查的位图信息头的大小字段知道如果你正在阅读的3字节或4字节的调色板元素。Size值12表示一个Windows 2 x（或可能是OS / 2的1 倍），3个字节的元素与BMP文件。较大的数字（如40和108）显示BMP，更高版本的所有这些都使用4个字节的调色板元素。
Windows BMP文件的类型
每个新版本的BMP位图信息头增添了新的信息。在某些情况下，较新的版本已更改的彩色调色板的大小和格式本身增加的功能。不幸的是，一个字段不包含在标头中容易地指示该文件的格式或不同的操作系统创建的BMP文件的版本。如果我们添加了四个版本的Windows的BMP OS / 2的两个版本 - 每个有四个可能的变化 - 我们发现，多达12个不同的文件格式的文件扩展名“BMP”。
很清楚，你可以不知道基于单独的文件扩展名BMP文件的内部格式。但是，幸运的是，你可以用很短的算法来确定内部格式BMP文件。
文件头的文件类型字段是我们开始的地方。如果这两个字节的值是424Dh（“BM”），那么你有可能已创建Windows或OS / 2下单图像BMP文件。如果文件类型是值4142H（“广管局”），那么你有一个OS / 2位图数组文件。其他OS / 2 BMP变化具有文件扩展名。ICO和PTR。
如果您的文件类型为“BM”，那么你现在必须读的位图信息头的大小字段来确定版本的文件。大小12为视窗2 x BMP和OS / 2 1 40 x BMP的Windows 3 x 和Windows NT的BMP，12到64的OS / 2 2 x BMP和108的Windows 4 x BMP 。总是有一个Windows NT将BMP文件压缩值3;否则，它被读为Windows 3 x BMP文件。
请注意，唯一的区别视窗2 x BMP和OS / 2 1 x BMP“宽度”和“高度”字段的数据类型。对于Windows 2 x，他们都签署了短裤和OS / 2 1 x，他们是无符号的短裤。的Windows 3 x时，Windows NT，OS / 2 2 x BMP文件唯一不同的位图信息头中的字段数和压缩字段的解释。
图像数据和压缩
未压缩的数据是代表任一彩色调色板的索引或实际的RGB颜色值的一系列值。像素打包成字节，并配置为扫描线。每个扫描行的4个字节的边界上必须结束，所以，一个，两个或三个字节的填充，可以按照每个扫描线。
扫描线被存储从底部向上，如果位图中的标头的高度“字段的值是一个正的值，它们被存储从上而下，如果高度”字段的值是负的。自底向上的结构是最常见的，因为不能被压缩存储的扫描线从上而下。
单色位图的每个像素包含一个位，每个字节的8个像素（最重要的位，即最左边的像素），并有一个2元素的颜色调色板。如果一个BMP阅读器选择忽略调色板，所有的“1”位被设置为显示的前景颜色和所有“零”位被设置为背景色。
四比特像素包装每字节的两个最重要的半字节，即最左边的像素。八位的像素被存储每一个字节。两个4 - 和8-bit的像素值是调色板16和256个元素的大小分别索引。
在Windows NT格式的十六位的像素大小是两个字节，存储在大端秩序。换句话说，在little-endian的机器上，这些字节必须阅读并翻转成little-endian顺序使用它们之前。的组织的16-bit的像素的位域定义的RedMask GreenMask，BlueMask在标头中的字段的值。最常见的口罩是RGB555，RGB565。当一个文件存储16位数据压缩字段必须始终是一个价值3位域编码。
在存储卷x BMP格式，16 -位和32位像素little-endian的4个字节的RGB值。普通口罩32位数据包括RGB888 RGB101010的的。这些位深度还需要来定义它们的像素格式的位图头位域编码和掩码字段。24位位图数据始终存储为3字节的RGB值。
Windows BMP格式的支持一个简单的运行长度编码（RLE）压缩4位和8位的位图数据压缩方案。由于这是一个字节明智的RLE计划，1 - ，16 - ，24 - ，和32位位图不能使用压缩，由于缺乏典型的长期运行的字节，在这些类型的数据具有相同的值。
BMP使用两个值的RLE计划。的第一个值包含在运行的像素的数目的计数，第二个值中包含的像素的值。运行高达255相同的像素值可被编码为两个字节的数据。其实，这是一个有点比这更复杂。在除了编码运行中，有未编码的运行，delta标记，结束时的扫描线的标记，和一个end-of-RLE数据标记。
8位RLE算法（RLE8）的存储重复的像素值作为编码运行。编码运行的第一个字节的取值范围为1〜255。第二个字节是8位的像素的值在运行。例如，一个编码解码成5个像素，每个像素的值18，或18 18 18 18 18 05 18运行。
当扫描线不包含足够的像素运行，实现了显着的压缩量，连续的像素值可被存储为文字或非编码运行。未编码的运行可能包含3至255的像素值。一个非编码的第一个字节始终为零。这使得它可以告诉编码的开始和一个非编码的开始之间的差异。第二个字节的值是多少未编码的像素值。如果像素数是奇数，则一个00填充值如下。这种填充值的原始像素数据的一部分，不应该被写入到解码数据流中。下面是一些例子的编码和未编码的数据流：
| 编码字节 | 解码字节 |
|---|---|
| 05 10 | 10 10 10 10 10 |
| 00 05 23 65 34 56 45 00 | 23 65 34 56 45 |
| 0A 0A | 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A |
| 00 04 46 57 68 79 | 46 57 68 79 |
三个标记值可能也被发现在RLE数据。这些标记中的每一个都与一个零字节的值也开始。第二个字节的值表示的标记类型。这些标记指定有关解码的位图数据的位置信息，并不会产生任何数据本身。
第一个标记是结束时的扫描线的标记，并确定了两个字节的值00和00。这种标记是指示已经达到了为当前扫描线的端部的数据。该标记物后发生的编码的数据进行解码的下一个扫描线的开头开始。如果一个end-of-扫描线标记在编码数据中不存在，则像素将自动换行从一个扫描行的末尾，以开始下一个。
此标记仅用于当你想强制解码扫描线在一个特定的地方结束。如果发生在一个扫描行的中间结束的扫描行标记，所有剩余的像素线在解码后的位图将被忽略。这种“短的扫描线”技术用于扫描线，省略不需要的部分。大多数情况下，它被发现在图标和指针BMP文件。
下一个标记是RLE数据标记结束。它确定了两个字节的值00和01。此标记发生的RLE数据仅作为最后的两个字节。这种标记是一个迹象表明，读者应该停止解码数据。
的最后一个标记是运行偏置标记，也称为 增量或矢量代码。这种标记是4个字节的大小，与前两个字节的值00和02，最后两个值指定的像素地址，使用无符号X和Y值作为偏移从当前位图的光标位置。的X值是在整个扫描线的像素数，Y值是位图中的行的数目。
此运行偏置标记指示位图中的下一个像素的解码后的运行应写入的位置。例如，在运行偏置标记值00 02 05 03将指示光标的位图的偏移量应该移动5个像素的扫描线，三排向前向下，写出来的下一次运行。然后继续解码后的数据写入新的位置向前移动光标。
运行偏移的标记使用位图时，可以含有大量的“不关心”的像素。例如，如果持有BMP文件作为掩模使用的位图（如图标和指针所使用的），矩形的位图中的像素可能不被使用。而不是存储这些未使用的像素的BMP文件，只有显着的像素被存储，并使用增量标记为“跳跃”跳过实际上并不使用掩码中的位图部分。
以下是BMP RLE标记：
00 00结束扫描线 00 01结束的位图数据 00 02 XX YY运行失调标记，
下面是一个例子，一个8位数据流进行解码。每个值是一个8位的索引值写入调色板而不是实际的颜色值。
| 编码字节 | 解码说明 | 解码字节 |
|---|---|---|
| 04 16 | 四字节的值16 | 16 16 16 16 |
| 08 45 | 8个字节的值45 | 45 45 45 45 45 45 45 45 |
| 00 00 | 扫描线结束 | 无 |
| 00 02 04 02 | 移动到偏移四个像素向前和两排 | 无 |
| 03 E4 | 3个字节的值E4 | E4 E4 E4 |
| 00 03 12 A4 46 00 | 未编码数据的三个字节 | 12 A4 46 |
| 00 00 | 扫描线结束 | 无 |
| 00 01 | RLE数据结束 | 无 |
4位RLE算法（RLE4）的存储重复的像素值，在一个非常类似的方式RLE8。所有的标记是相同的。唯一真正的区别是两个像素值都挤满每字节，解码时这些像素值交替。例如，将解码一个RLE4的编码的数据流07 48 7个像素，交替值04 08 04 08 04 08 04。
如果这看起来很奇怪的，那是因为你很少看到交替运行的像素值，位图中的8位或更大深入。四比特（16色）的位图，但是，通常包含的特定的抖动。大多数抖动算法会产生比较大的运行交替像素。3个和4个像素重复序列的运行也相当常见的输出抖动算法。但目前尚未在BMP RLE计划的支持有效像素运行这些类型的编码能力。
如果你是想运行相同的像素值不能被编码由RLE4，你是不正确的。例如，将运行12个像素值9 RLE4 0C 99编码和解码运行09 09 09 09 09 09 09 09 09 09 09 09。
填充被加到未编码象素的运行长度的字节数为奇数，而不是像素，。和一个未使用的最后四位奇数长度的运行被设置为零。例如，将六个像素值1 3 5 7 9 0 00 06 13 57 90 00未编码的运行存储为5个像素值，而将被存储为1 3 5 7 9 00 05 13 57 90 00未编码的运行。
下面是一个例子，一个4位的数据流进行解码。每个值是一个4位的调色板，而不是一个实际的颜色值的索引值。
| 编码字节 | 解码说明 | 解码字节 |
|---|---|---|
| 04 16 | 交替的1和6的四个值 | 1 6 1 6 |
| 08 44 | 八个值交替4和4 | 4 4 4 4 4 4 4 4 |
| 00 00 | 扫描线结束 | 无 |
| 00 02 04 02 | 移动到偏移四个像素向前和两排 | 无 |
| 03 E4 | 三值交替E和4 | Ë4 E |
| 00 06 12 A4 46 00 | 六未编码的数据值 | 1 2 4 6 |
| 00 00 | 扫描线结束 | 无 |
| 00 01 | RLE数据结束 | 无 |
下面是总结的Windows BMP数据特征：
| 像素深度 | 像素大小 | 压缩 | 调色板 | 彩色面具 |
|---|---|---|---|---|
| 1位 | 1位 | 0 | 是 | 没有 |
| 4位 | 4位 | 0,2 | 是 | 没有 |
| 8位 | 1个字节 | 0,1 | 是 | 没有 |
| 16位 | 4个字节 | 3 | 没有 | 是 |
| 24位 | 3个字节 | 0 | 没有 | 没有 |
| 32位 | 4个字节 | 3 | 没有 | 是 |
如需进一步信息
有关Microsoft Windows位图格式欲了解更多信息，请参阅在CD-ROM中包含的文档。虽然你可能不会是能够直接从他们那里得到任何信息，这里是微软的地址：
微软公司
Microsoft方式
雷德蒙，WA 98052-6399
语音：206-882-8080
传真：206-936-7329
BBS：206-637-9009
FTP： WWW ftp://ftp.microsoft.com
：http://www microsoft.com。
最接近的是微软的文件格式规范的归档是微软开发者网络知识库可以在MSDN上的CD-ROM，在微软的网站上。Win16和Win32软件开发工具包（SDK）也有对BMP的信息。
有关Windows BMP格式的信息也可以发现以下引用：
Charlap，大卫，“bmp格式的文件：第一部分，” 博士 道博的杂志，第一卷。20，没有。228，1995年3月。
Charlap，大卫，“BMP文件格式：第二部分，” 博士 道博的杂志，第一卷。20，没有。229，1995年4月。
卢斯，马福，“BMP文件格式，” 博士 道博的杂志，第一卷。9，没有。219，1994年9月，第18-22页。
微软公司的Microsoft Win32程序员参考，第一卷。5，华盛顿州Redmond的微软出版社，1993年。
微软公司，微软Windows程序员参考，第一卷。2，V3，华盛顿州Redmond的微软出版社，1990年。
Petzold的查尔斯，“保持一个设备无关位图：盒装DIB格式，” 个人电脑“杂志 1991年7月，第433-439页。
Petzold的查尔斯，“什么是新的位图格式：在Windows和OS / 2，” 个人电脑杂志看，1990年9月11日，第403-410页。
天鹅，汤姆，深入了解Windows文件格式，萨姆斯出版社，1993。
上述问题的代码博士 道博的杂志 ，请访问：
ftp://ftp.mv.com/pub/ddj/1994/1194.09/bmp.zip
ftp://ftp.mv.com/pub/ddj/1995/1195.03/bmp.zip
两个博士 道博的杂志的文章由大卫Charlap的包含源代码的完整集合，与Windows 2 X，3 x，NT和OS / 2的BMP文件格式。它可在上述FTP站点。
1578
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
