Microsoft Windows Bitmap File Format Summary

pamxy發表於2013-05-14
ROSWindowsORM

轉自：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釋出。資訊結構和資料編碼方法中包含了一些程式設計師的參考手冊，線上幫助工具，包括與微軟Wi​​ndows軟體開發工具包（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-b​​it的畫素的位域定義的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站點。


相關文章