分类: 嵌入式
2011-08-08 19:50:51
BMP文件格式,也称为位图图像文件或设备无关位图(DIB),文件格式,或只是一个位图, 光栅图形 图像文件格式独立于用来存储位图 的数字图像,显示设备(如图形适配器),特别是在微软Windows和OS / 2操作系统。
BMP文件格式存储的二维数字图像能够任意宽度,高度和分辨率, 单色和彩色,各种颜色深度,以及可选的数据压缩,alpha通道和颜色配置文件 。
目录 [ 隐藏 ] |
微软已经定义了一个特别是不同颜色的深度彩色位图表示,作为交换设备和多种内部表示应用之间的位图的援助。他们呼吁这些设备无关位图的DIB,并为他们的文件格式被称为DIB文件格式或BMP图像文件格式 。根据微软的支持:[ 1 ]
设备无关位图(DIB)是用于定义各种颜色的决议设备无关位图的格式。DIB的主要目的是为了让(因此,独立于设备的名称的一部分)的位图从一个设备移动到另一个。DIB是外部格式,设备相关的位图,在系统出现位图对象(应用程序创建的...). DIB是正常运在图元文件(通常使用StretchDIBits()函数),BMP文件和剪贴板(CF_DIB数据格式)。
以下各节讨论在BMP文件或DIB详细存储数据。这是标准的BMP文件格式。 [ 1 ]有些应用程序创建的位图图像文件,这是不符合当前的Microsoft文档。此外,不是所有的字段为0的值将被发现在这些未使用的的字段。
[ 编辑 ]文件结构位图图像文件由固定大小的结构(头)以及可变大小的结构,出现在预定的顺序。许多不同的版本,其中一些结构可以出现在文件中,由于这个文件的格式长期演变 。
图1,位图图像文件的结构组成,按下列顺序 :
结构名称 | 可选 | 尺寸 | 目的 | 评论 |
---|---|---|---|---|
位图文件头 | 无 | 14个字节 | 要存储有关的位图图像文件的一般信息 | 后不需要的文件加载到内存中 |
DIB的头 | 无 | 固定大小的 (但有7种不同的版本) | 要存储有关的位图图像的详细信息,并定义像素格式 | 紧随位图文件头 |
额外的位掩码 | 是 | 3或4个DWORDs[ 2 ] (12或16字节) | 要定义的像素格式 | 目前唯一的DIB头是BITMAPINFOHEADER |
颜色表 | 半可选 | 可变大小 | 要定义位图图像数据(像素阵列)所使用的颜色 | 强制性色彩深度 <= 8 |
GAP1 | 是 | 可变大小 | 结构对齐 | 文件的一个工件位图文件头偏移到PixelArray |
像素阵列 | 无 | 可变大小 | 要定义的像素的实际值 | 像素格式定义的DIB页眉或额外的位掩码。像素阵列的每一行填充到4个字节大小的的倍数 |
Gap2 | 是 | 可变大小 | 结构对齐 | ICC配置文件数据神器抵消在DIB头字段 |
ICC颜色配置文件 | 是 | 可变大小 | 要定义颜色配置文件的颜色管理 | 还可以包含一个到外部文件中包含的颜色配置文件的路径 。[ 3 ]当加载在内存中为“非包装的DIB”,它是位于之间的颜色表和 GAP1。 |
位图图像文件加载到内存中成为一个DIB数据结构-在Windows GDI API的一个重要组成部分 。在内存中的DIB数据结构是为BMP文件格式几乎相同,但它不包含14字节的位图文件头和与DIB头开始。对于加载到内存中的DIB,颜色表,也可以由16位项目,目前实现的 调色板 [ 4](更高一级的间接),而不是明确的RGB 颜色定义,构成索引。在所有情况下,像素阵列必须开始一个内存地址是一个4字节的倍数。在加载到内存中的非盒装的DIB,可选的颜色配置文件数据应位于后立即颜色表前GAP1和像素阵列 [ 3 ](不像Diag.1) 。
GAP1和Gap2大小为零时,习惯上被称为内存中的DIB数据结构作为“ 打包DIB “,可称为一个单一的指针指向的DIB头开始。在所有情况下,像素阵列必须开始一个内存地址是一个4字节的倍数。在某些情况下可能需要调整颜色表中的条目数,以迫使4个字节的倍数的像素阵列的内存地址。[ 4]的“包装的DIB”加载到内存中,可选的颜色个人资料数据,应立即按照Diag.1描绘的像素阵列,(与GAP1 = 0和Gap2 = 0)。[ 3 ]
“盒装的DIB”需要通过Windows剪贴板API函数,以及一些Windows图案刷和资源功能。[ 5 ] 。
此字节块是在文件的开始,是用来识别该文件。一个典型的应用程序首先读取这个块,以确保该文件实际上是一个BMP文件,并没有损坏 。BMP文件格式的头两个字节的字符'b'字符“M”在1个字节的ASCII编码。整数的值都存储在little - endian的格式(即最低有效字节在前) 。
偏移量# | 尺寸 | 目的 |
---|---|---|
0000 h | 2个字节 | 头字段用于识别BMP DIB文件的0x42 0x4D 十六进制,相同的骨髓在ASCII 。下面的条目是可能的:
|
0002 h | 4个字节 | BMP文件的字节大小 |
0006 h | 2个字节 | 保留;实际值取决于图像的应用程序,创建 |
0008 h | 2个字节 | 保留;实际值取决于图像的应用程序,创建 |
000A h | 4个字节 | 的偏移,即起始地址,位图图像数据(像素阵列)可以找到的字节 。 |
在C语言中的等效头
此字节块告诉有关的形象,这将是用来显示在屏幕上的图像应用程序的详细信息。本区块还匹配Windows和OS / 2内部使用的头,有几个不同的变种。他们都包含一个DWORD(32位)字段,指定它们的大小,从而使应用程序可以很容易地确定它的头是在图像中使用。之所以有不同的头是微软扩大DIB格式几次。新的扩展头,可以使用一些GDI函数,而不是旧的,提供更多的功能。由于GDI支持加载的位图文件的功能,典型的Windows应用程序中使用该功能。这方面的一个后果是,对于这样的应用,与正在运行的Windows版本支持,他们支持的BMP格式的格式。更多信息,请参阅下表。
尺寸 | 标题名称 | 操作系统支持 | 增加的功能(增量) | 在写位图文件 |
---|---|---|---|---|
12 | BITMAPCOREHEADER OS21XBITMAPHEADER | OS / 2,也都因为Windows 版本的Windows 3.0 | ||
64 | BITMAPCOREHEADER2 OS22XBITMAPHEADER | OS / 2 | 添加半色调。添加RLE和哈夫曼1D压缩。 | |
40 | BITMAPINFOHEADER | 因为所有的Windows 版本的Windows 3.0 | 删除RLE - 24和Huffman 1D压缩。添加16bpp的32bpp像素格式。添加可选的RGB位掩码。 | Adobe Photoshop中 |
52 | BITMAPV2INFOHEADER | 无证。 | 删除可选的RGB位掩码。添加强制性RGB位掩码。 | |
56 | BITMAPV3INFOHEADER | 无证。 | 添加强制性Alpha通道的位掩码。 | Adobe Photoshop中 |
108 | BITMAPV4HEADER | 所有版本的Windows,因为Windows 95 / NT 4 | 增添了色彩空间类型和伽玛校正 | |
124 | BITMAPV5HEADER | Windows 98 / 2000和较新的中 | 添加ICC色彩配置文件 |
BITMAPCOREHEADER后的版本只将字段添加到以前的版本头结束。例如:BITMAPV2INFOHEADER增加字段的BITMAPINFOHEADER和BITMAPV3INFOHEADER添加字段BITMAPV2INFOHEADER(或BITMAPINFOHEADER的是BITMAPV2INFOHEADER剥离版本)
由于兼容性的原因,大多数应用程序使用保存文件的旧的DIB头。与OS / 2正在过时,现在常见的格式是BITMAPINFOHEADER的头。它的描述,请参阅下表。所有的值都存储为无符号整数,除非明确指出。
偏移量# | 尺寸 | 目的 |
---|---|---|
0EH | 4 | 这个头的大小(40字节) |
12H | 4 | 在像素位图的宽度(有符号整数)。 |
16H | 4 | 在像素位图的高度(有符号整数)。 |
1AH | 2 | 正在使用的彩色平面。必须设置为1。 |
1CH | 2 | 每个像素的位数,这是图像的色彩深度。典型值是1,4,8,16,24和32。 |
1EH | 4 | 正在使用的压缩方法。一个可能值的列表,请参阅下表。 |
22H | 4 | 图像的大小。这是原始位图的数据(见下文)的大小,文件大小不应该混淆。 |
26H | 4 | 图像的水平分辨率。(每米的像素,有符号整数) |
2AH | 4 | 图像的垂直分辨率。(每米的像素,有符号整数) |
2EH | 4 | 在颜色调色板,或0默认为2 ñ。 |
32H | 4 | 重要的颜色数,或0时,每一种颜色是很重要的,普遍忽视。 |
注:“图像大小”字段可以BI_RGB位图0。
在C语言中的等效头
The compression method field (bytes #30-33) can have the following values:
Value | Identified by | Compression method | Comments |
---|---|---|---|
0 | BI_RGB | none | Most common |
1 | BI_RLE8 | RLE 8-bit/pixel | Can be used only with 8-bit/pixel bitmaps |
2 | BI_RLE4 | RLE 4-bit/pixel | Can be used only with 4-bit/pixel bitmaps |
3 | BI_BITFIELDS | Bit field or Huffman 1D compression for BITMAPCOREHEADER2 | Pixel format defined by bit masks or Huffman 1D compressed bitmap for BITMAPCOREHEADER2 |
4 | BI_JPEG | JPEG or RLE-24 compression for BITMAPCOREHEADER2 | The bitmap contains a JPEG image or RLE-24 compressed bitmap for BITMAPCOREHEADER2 |
5 | BI_PNG | PNG | The bitmap contains a PNG image |
6 | BI_ALPHABITFIELDS | Bit field | This value is valid in Windows CE .NET 4.0 and later. |
Note: BI_JPEG and BI_PNG are for printer drivers and are not supported when rendering to the screen.[6]
Equivalent header in C language (compression methods)
The OS/2 BITMAPCOREHEADER header is also popular:
Offset | Size | Purpose |
---|---|---|
Eh | 4 | the size of this header (12 bytes) |
12h | 2 | the bitmap width in pixels. |
14h | 2 | the bitmap height in pixels. |
16h | 2 | the number of color planes; 1 is the only legal value |
18h | 2 | the number of bits per pixel. Typical values are 1, 4, 8 and 24. |
Note: OS/2 BITMAPCOREHEADER bitmaps cannot be compressed and cannot be 16 or 32 bits/pixel. All values in the OS/2 BITMAPCOREHEADER header are unsigned integers.
A 16-bit and 32-bit version of DIB with an integrated alpha channel has been introduced with the undocumented BITMAPV3INFOHEADER and with the documented BITMAPV4HEADER (sinceWindows 95) and is used within Windows XP logon and theme system as well as Microsoft Office (since v2000); it is supported by some image editing software, such as Adobe Photoshop since version 7 and Adobe Flash since version MX 2004 (then known as Macromedia Flash). It is also supported by GIMP, Google Chrome, MS-PowerPoint and MS-Word.
[edit]Color TableThe Color Table (a.k.a. Palette) occurs in the BMP image file directly after the BMP file header, the DIB header (and after optional three Red, Green and Blue bitmasks if the BITMAPINFOHEADER Header with BI_BITFIELDS option is used). Therefore, its offset is the size of the BITMAPFILEHEADER plus the size of the DIB header (plus optional 12 bytes for the three bit masks).
Note: On Windows CE the BITMAPINFOHEADER Header can be used with the BI_ALPHABITFIELDS[2] option in the biCompression member. In such case, four optional bitmasks follow the BITMAPINFOHEADER Header instead of the three bitmask mentioned above, thus the Color Table's offset is the size of the BITMAPFILEHEADER plus the size of the BITMAPINFOHEADER Header plus the 16 bytes of the four bitmasks (Red, Green, Blue and Alpha).
The number of entries in the palette is either 2n or a smaller number specified in the header (in the OS/2 BITMAPCOREHEADER header format, only the full-size palette is supported).[1][7] In most cases, each entry in the color table occupies 4 bytes, in the order Blue, Green, Red, 0x00 (see below for exceptions).
The Color Table is a block of bytes (a table) listing the colors used by the image. Each pixel in an indexed color image is described by a number of bits (1, 4, or 8) which is an index of a single color described by this table. The purpose of the color palette in indexed color bitmaps is to inform the application about the actual color that each of these index values corresponds to. The purpose of the Color Table in non-indexed (non-palettized) bitmaps is to list the colors used by the bitmap for the purposes of optimization on devices with limited color display capability and to facilitate future conversion to different pixel formats and paletization.
The colors in the Color Table are usually specified in the 4-byte per entry 8.8.8.0.8 format (in RGBAX notation). The Color Table used with the OS/2 BITMAPCOREHEADER uses the 3-byte per entry 8.8.8.0.0 format.[1][7] For DIBs loaded in memory, the Color Table can optionally consist of 2-byte entries - these entries constitute indexes to the currently realized palette[4] instead of explicit RGB color definitions.
Microsoft does not disallow the presence of a valid Alpha channel bit mask[8] in BITMAPV4HEADER and BITMAPV5HEADER for 1bpp, 4bpp and 8bpp indexed color images, which indicates that the Color Table entries can also specify an Alpha component using the 8.8.8.[0-8].[0-8] format via the RGBQUAD.rgbReserved[9] member. However, some versions of Microsoft's documentation disallow this feature by stating that the RGBQUAD.rgbReserved member "must be zero".
As mentioned above, the Color Table is normally not used when the pixels are in the 16-bit per pixel (16bpp) format (and higher); there are normally no Color Table entries in those bitmap image files. However, the Microsoft documentation (on the MSDN web site as of Nov. 16, 2010) specifies that for 16bpp (and higher), the Color Table can be present to store a list of colors intended for optimization on devices with limited color display capability, while it also specifies, that in such cases, no indexed palette entries are present in this Color Table. This may seem like a contradiction if no distinction is made between the mandatory palette entries and the optional color list.
[edit]Pixel storageThe bits representing the bitmap pixels are packed in rows. The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding.
For images with Height > 1, multiple padded rows are stored consecutively, forming a Pixel Array.
The total number of bytes necessary to store one row of pixels can be calculated as:
ImageWidth is expressed in pixels.The total amount of bytes necessary to store an array of pixels in an n Bits per Pixel (bpp) image, with 2n colors, can be calculated by accounting for the effect of rounding up the size of each row to a multiple of a 4 bytes, as follows:
ImageHeight is expressed in pixels. The absolute value is necessary because ImageHeight can be negativeThe total Bitmap Image File size can be approximated as:
,for BPP ≤ 8 ( because for pixels larger than 8 bits, the palette is not mandatory )Only images with 8 or fewer Bits per Pixel must account for the palette. 16bpp images (or higher), may omit the palette part from the size calculation, as follows:
,for Bits per Pixel > 8.In the formulas above, the number 54 is the combined size of the 14 byte Bitmap File Header and the 40 byte popular Windows DIB Header - the BITMAPINFOHEADER (some other DIB Header versions will be larger or smaller than that as described by the table above) and the expression is the size of the color palette in bytes.
This total file size formula is only an approximation, since the size of the color palette will be bytes for the OS/2 DIB Header version BITMAPCOREHEADER, and some files may define only the number of colors needed by the image, potentially fewer than 2n.[1]
An additional size uncertainty is introduced by the optional presence of the 12 or 16 bytes needed for the extra bit masks stored immediately after the BITMAPINFOHEADER DIB Header and the variable-size GAP depiced in Diag.1
The Pixel Array is a block of 32-bit DWORDs, that describes the image pixel by pixel. Normally pixels are stored "upside-down" with respect to normal image raster scan order, starting in the lower left corner, going from left to right, and then row by row from the bottom to the top of the image.[1]
Uncompressed Windows bitmaps also can be stored from the top to bottom, when the Image Height value is negative.
In the original OS/2 DIB, the only four legal values of color depth were 1, 4, 8, and 24 bits per pixel (bpp).[1] Contemporary DIB Headers allow pixel formats with 1, 2, 4, 8, 16, 24 and 32 bits per pixel (bpp).[10]
Padding bytes (not necessarily 0) must be appended to the end of the rows in order to bring up the length of the rows to a multiple of four bytes. When the Pixel Array is loaded into memory, each row must begin at a memory address that is a multiple of 4. This address/offset restriction is mandatory only for Pixel Array's loaded in memory. For file storage purposes, only the size of each row must be a multiple of 4 bytes while the file offset can be arbitrary.[1]
A 24-bit bitmap with Width=1, would have 3 bytes of data per row (blue, green, red) and 1 byte of padding, while Width=2 would have 2 bytes of padding, Width=3 would have 3 bytes of padding, and Width=4 would not have any padding at all.
Bitmap Image Files are typically much larger than image file formats compressed with other algorithms, for the same image. For example, the 1058×1058 Wikipedia logo, which occupies about 271 KB in the lossless PNG format, takes about 3358 KB as a 24bpp BMP Image File. Uncompressed formats are generally unsuitable for transferring images on theInternet or other slow or capacity-limited media.
[edit]CompressionIndexed color images may be compressed with 4-bit or 8-bit RLE or Huffman 1D algorithm.
OS/2 BITMAPCOREHEADER2 24bpp images may be compressed with the 24-bit RLE algorithm.
The 16bpp and 32bpp images are always stored uncompressed.
Note that images in all color depths can be stored without compression if so desired.
In bitmap image file on a disk or bitmap image in memory, the pixels can be defined by varying number of bits.
In order to resolve the ambiguity of which bits define which samples, the DIB Headers provide certain defaults as well as specific BITFIELDS which are bit masks that define the membership of particular group of bits in a pixel to a particular channel.
The following diagram defines this mechanism:
Diag.2 - The BITFIELDS mechanism for a 32 bit pixel depicted in RGBAX Sample Length notation
The sample fields defined by the BITFIELDS bit masks have to be contiguous and non-overlapping.
The Red, Green and Blue bit masks are valid only when the Compression member of the DIB Header is set to BI_BITFIELDS.
The Alpha bit mask is valid whenever it is present in the DIB Header or when the Compression member of the DIB Header is set to BI_ALPHABITFIELDS[2] (Windows CE only).
Diag.3 - The pixel format with an Alpha channel in a 16 bit pixel (in RGBAX Sample Length notation) actually generated by Adobe Photohop[11]
The table below lists all of the possible pixel formats of a DIB (in RGBAX notation).The BITFIELD mechanism described above allows for the definition of tens of thousands different pixel formats, however only several of them are used in practice,[11] such as:
[The list above is in the RGBAX notation]
[edit]Example 1Following is an example of a 2×2 pixel, 24-bit bitmap (Windows DIB Header BITMAPINFOHEADER) with pixel format 8.8.8.0.0 (in RGBAX notation).
Offset | Size | Hex Value | Value | Description |
---|---|---|---|---|
BMP Header | ||||
0h | 2 | 42 4D | "BM" | Magic number (unsigned integer 66, 77) |
2h | 4 | 46 00 00 00 | 70 Bytes | Size of the BMP file |
6h | 2 | 00 00 | Unused | Application specific |
8h | 2 | 00 00 | Unused | Application specific |
Ah | 4 | 36 00 00 00 | 54 bytes | Offset where the Pixel Array (bitmap data) can be found |
DIB Header | ||||
Eh | 4 | 28 00 00 00 | 40 bytes | Number of bytes in the DIB header (from this point) |
12h | 4 | 02 00 00 00 | 2 pixels | Width of the bitmap in pixels |
16h | 4 | 02 00 00 00 | 2 pixels | Height of the bitmap in pixels |
1Ah | 2 | 01 00 | 1 plane | Number of color planes being used |
1Ch | 2 | 18 00 | 24 bits | Number of bits per pixel |
1Eh | 4 | 00 00 00 00 | 0 | BI_RGB, no Pixel Array compression used |
22h | 4 | 10 00 00 00 | 16 bytes | Size of the raw data in the Pixel Array (including padding) |
26h | 4 | 13 0B 00 00 | 2,835 pixels/meter | Horizontal resolution of the image |
2Ah | 4 | 13 0B 00 00 | 2,835 pixels/meter | Vertical resolution of the image |
2Eh | 4 | 00 00 00 00 | 0 colors | Number of colors in the palette |
32h | 4 | 00 00 00 00 | 0 important colors | 0 means all colors are important |
Start of Pixel Array (bitmap data) | ||||
36h | 3 | 00 00 FF | 0 0 255 | Red, Pixel (0,1) |
39h | 3 | FF FF FF | 255 255 255 | White, Pixel (1,1) |
3Ch | 2 | 00 00 | 0 0 | Padding for 4 byte alignment (could be a value other than zero) |
3Eh | 3 | FF 00 00 | 255 0 0 | Blue, Pixel (0,0) |
41h | 3 | 00 FF 00 | 0 255 0 | Green, Pixel (1,0) |
44h | 2 | 00 00 | 0 0 | Padding for 4 byte alignment (could be a value other than zero) |
Following is an example of a 4×2 pixel, 32-bit bitmap with opacity values in the alpha channel (Windows DIB Header BITMAPV4HEADER) with pixel format 8.8.8.8.0 (in RGBAXnotation).
Offset | Size | Hex Value | Value | Description |
---|---|---|---|---|
BMP Header | ||||
0h | 2 | 42 4D | "BM" | Magic number (unsigned integer 66, 77) |
2h | 4 | 9A 00 00 00 | 154 Bytes | Size of the BMP file |
6h | 2 | 00 00 | Unused | Application specific |
8h | 2 | 00 00 | Unused | Application specific |
Ah | 4 | 7A 00 00 00 | 122 bytes from the start of the file | Offset where the Pixel Array (bitmap data) can be found |
DIB Header | ||||
Eh | 4 | 6C 00 00 00 | 108 bytes | Number of bytes in the DIB header (from this point) |
12h | 4 | 04 00 00 00 | 4 pixels | Width of the bitmap in pixels |
16h | 4 | 02 00 00 00 | 2 pixels | Height of the bitmap in pixels |
1Ah | 2 | 01 00 | 1 plane | Number of color planes being used |
1Ch | 2 | 20 00 | 32 bits | Number of bits per pixel |
1Eh | 4 | 03 00 00 00 | 3 | BI_BITFIELDS, no Pixel Array compression used |
22h | 4 | 20 00 00 00 | 32 bytes | Size of the raw data in the Pixel Array (including padding) |
26h | 4 | 13 0B 00 00 | 2,835 pixels/meter | Horizontal physical resolution of the image |
2Ah | 4 | 13 0B 00 00 | 2,835 pixels/meter | Vertical physical resolution of the image |
2Eh | 4 | 00 00 00 00 | 0 colors | Number of colors in the palette |
32h | 4 | 00 00 00 00 | 0 important colors | 0 means all colors are important |
36h | 4 | 00 00 FF 00 | 00FF0000 in big-endian | Red channel bit mask (valid because BI_BITFIELDS is specified) |
3Ah | 4 | 00 FF 00 00 | 0000FF00 in big-endian | Green channel bit mask (valid because BI_BITFIELDS is specified) |
3Eh | 4 | FF 00 00 00 | 000000FF in big-endian | Blue channel bit mask (valid because BI_BITFIELDS is specified) |
42h | 4 | 00 00 00 FF | FF000000 in big-endian | Alpha channel bit mask |
46h | 4 | 20 6E 69 57 | LCS_WINDOWS_COLOR_SPACE | Type of Color Space |
4Ah | 24h | 24* 00...00 | CIEXYZTRIPLE Color Space endpoints | Unused when LCS_WINDOWS_COLOR_SPACE is specified |
6Eh | 4 | 00 00 00 00 | 0 Red Gamma | Unused when LCS_WINDOWS_COLOR_SPACE is specified |
72h | 4 | 00 00 00 00 | 0 Green Gamma | Unused when LCS_WINDOWS_COLOR_SPACE is specified |
76h | 4 | 00 00 00 00 | 0 Blue Gamma | Unused when LCS_WINDOWS_COLOR_SPACE is specified |
Start of the Pixel Array (the bitmap Data) | ||||
7Ah | 4 | FF 00 00 7F | 255 0 0 127 | Blue (Alpha: 127), Pixel (0,1) |
7Eh | 4 | 00 FF 00 7F | 0 255 0 127 | Green (Alpha: 127), Pixel (1,1) |
82h | 4 | 00 00 FF 7F | 0 0 255 127 | Red (Alpha: 127), Pixel (2,1) |
86h | 4 | FF FF FF 7F | 255 255 255 127 | White (Alpha: 127), Pixel (3,1) |
8Ah | 4 | FF 00 00 FF | 255 0 0 255 | Blue (Alpha: 255), Pixel (0,0) |
8Eh | 4 | 00 FF 00 FF | 0 255 0 255 | Green (Alpha: 255), Pixel (1,0) |
92h | 4 | 00 00 FF FF | 0 0 255 255 | Red (Alpha: 255), Pixel (2,0) |
96h | 4 | FF FF FF FF | 255 255 255 255 | White (Alpha: 255), Pixel (3,0) |
Note that the bitmap data starts with the lower left hand corner of the image.
[edit]Usage of BMP formatThe simplicity of the BMP file format, and its widespread familiarity in Windows and elsewhere, as well as the fact that this format is relatively well documented and free ofpatents, makes it a very common format that image processing programs from many operating systems can read and write.
Many older graphical user interfaces used bitmaps in their built-in graphics subsystems;[12] for example, the Microsoft Windows and OS/2 platforms' GDI subsystem, where the specific format used is the Windows and OS/2 bitmap file format, usually named with the file extension of .BMP or .DIB.
While most BMP files have a relatively large file size due to lack of any compression (or generally low-ratio RLE on palletized images), many BMP files can be considerably compressed with lossless data compression algorithms such as ZIP (in extreme cases of non-photographic data, up to 0.1% of original size) because they contain redundant data. Some formats, such as RAR, even include routines specifically targeted at efficient compression of such data.
[edit]Related formats