Extensión de nombre de archivo | .bmp , .dib |
---|---|
Tipo de medio de Internet | image/bmp [1]image/x-bmp |
Código de tipo | 'BMP ' 'BMPf' 'BMPp' |
Identificador de tipo uniforme (UTI) | com.microsoft.bmp |
Desarrollado por | Corporación Microsoft |
Tipo de formato | Gráficos de trama |
¿ Formato abierto ? | OSP para WMF |
El formato de archivo BMP , también conocido como archivo de imagen de mapa de bits , mapa de bits independiente (DIB) Formato de archivo de dispositivo y de mapa de bits , es un gráfico de mapa de bits formato de archivo de imagen utilizado para almacenar mapas de bits imágenes digitales , independientemente del dispositivo de visualización (como un adaptador de gráficos ), especialmente en los sistemas operativos Microsoft Windows [2] y OS / 2 [3] .
El formato de archivo BMP es capaz de almacenar imágenes digitales bidimensionales tanto monocromáticas como en color, en varias profundidades de color y, opcionalmente, con compresión de datos , canales alfa y perfiles de color . La especificación de metarchivo de Windows (WMF) cubre el formato de archivo BMP. [4]
Mapas de bits independientes del dispositivo y formato de archivo BMP [ editar ]
Microsoft ha definido una representación particular de mapas de bits de color de diferentes profundidades de color, como una ayuda para intercambiar mapas de bits entre dispositivos y aplicaciones con una variedad de representaciones internas. Llamaron a estos mapas de bits independientes del dispositivo o DIB, y el formato de archivo para ellos se llama formato de archivo DIB o formato de archivo de imagen BMP.
Según el soporte de Microsoft: [5]
Un mapa de bits independiente del dispositivo (DIB) es un formato que se utiliza para definir mapas de bits independientes del dispositivo en varias resoluciones de color. El objetivo principal de los DIB es permitir que los mapas de bits se muevan de un dispositivo a otro (de ahí la parte del nombre independiente del dispositivo). Un DIB es un formato externo, en contraste con un mapa de bits dependiente del dispositivo, que aparece en el sistema como un objeto de mapa de bits (creado por una aplicación ...). Un DIB normalmente se transporta en metarchivos (normalmente usando la función StretchDIBits ()), archivos BMP y el Portapapeles ( formato de datos CF_DIB ).
Las siguientes secciones tratan en detalle los datos almacenados en el archivo BMP o DIB. Este es el formato de archivo BMP estándar. [5] Algunas aplicaciones crean archivos de imagen de mapa de bits que no cumplen con la documentación de Microsoft. Además, no se utilizan todos los campos; se encontrará un valor de 0 en estos campos no utilizados.
Estructura de archivo [ editar ]
El archivo de imagen de mapa de bits consta de estructuras de tamaño fijo (encabezados), así como estructuras de tamaño variable que aparecen en una secuencia predeterminada. En el archivo pueden aparecer muchas versiones diferentes de algunas de estas estructuras, debido a la larga evolución de este formato de archivo.
Con referencia al diagrama 1, el archivo de mapa de bits se compone de estructuras en el siguiente orden:
Nombre de la estructura | Opcional | Tamaño | Propósito | Comentarios |
---|---|---|---|---|
Encabezado del archivo de mapa de bits | No | 14 bytes | Para almacenar información general sobre el archivo de imagen de mapa de bits | No es necesario después de que el archivo se carga en la memoria |
Encabezado DIB | No | Tamaño fijo (existen 7 versiones diferentes) | Para almacenar información detallada sobre la imagen de mapa de bits y definir el formato de píxeles | Sigue inmediatamente el encabezado del archivo de mapa de bits |
Máscaras de bits adicionales | sí | 3 o 4 DWORD [6] (12 o 16 bytes) | Para definir el formato de píxel | Presente solo en caso de que el encabezado DIB sea el BITMAPINFOHEADER y el miembro del Método de compresión esté establecido en BI_BITFIELDS o BI_ALPHABITFIELDS |
Tabla de colores | Semi-opcional | Tamaño variable | Para definir los colores utilizados por los datos de la imagen de mapa de bits (matriz de píxeles) | Obligatorio para profundidades de color ≤ 8 bits |
Gap1 | sí | Tamaño variable | Alineación de estructura | Un artefacto de la matriz de desplazamiento de archivo a píxel en el encabezado del archivo de mapa de bits |
Matriz de píxeles | No | Tamaño variable | Para definir los valores reales de los píxeles | El formato de píxel se define mediante el encabezado DIB o máscaras de bits adicionales. Cada fila de la matriz de píxeles se rellena con un tamaño múltiple de 4 bytes |
Gap2 | sí | Tamaño variable | Alineación de estructura | Un artefacto del campo de desplazamiento de datos del perfil ICC en el encabezado DIB |
Perfil de color ICC | sí | Tamaño variable | Para definir el perfil de color para la gestión del color | También puede contener una ruta a un archivo externo que contenga el perfil de color. Cuando se carga en la memoria como "DIB no empaquetado", se ubica entre la tabla de colores y Gap1. [7] |
DIB en la memoria [ editar ]
Un archivo de imagen de mapa de bits cargado en la memoria se convierte en una estructura de datos DIB, un componente importante de la API de GDI de Windows. La estructura de datos DIB en memoria es casi la misma que la del formato de archivo BMP, pero no contiene el encabezado del archivo de mapa de bits de 14 bytes y comienza con el encabezado DIB. Para los DIB cargados en la memoria, la tabla de colores también puede constar de entradas de 16 bits que constituyen índices de la paleta realizada actualmente [8] (un nivel adicional de direccionamiento indirecto), en lugar de definiciones explícitas de colores RGB. En todos los casos, la matriz de píxeles debe comenzar en una dirección de memoria que sea múltiplo de 4 bytes. En los DIB no empaquetados cargados en la memoria, los datos de perfil de color opcionales deben ubicarse inmediatamente después de la tabla de colores y antes del gap1 y la matriz de píxeles [7] (a diferencia del diagrama 1).
Cuando el tamaño de gap1 y gap2 es cero, la estructura de datos DIB en memoria se denomina habitualmente "DIB empaquetada" y se puede hacer referencia a ella mediante un único puntero que apunta al comienzo del encabezado DIB. En todos los casos, la matriz de píxeles debe comenzar en una dirección de memoria que sea múltiplo de 4 bytes. En algunos casos, puede ser necesario ajustar el número de entradas en la tabla de colores para forzar la dirección de memoria de la matriz de píxeles a un múltiplo de 4 bytes. [8] Para los "DIB empaquetados" cargados en la memoria, los datos de perfil de color opcionales deben seguir inmediatamente a la matriz de píxeles, como se muestra en la diag. 1 (con gap1 = 0 y gap2 = 0). [7]
"DIB empaquetados"son necesarios para las funciones de la API del portapapeles de Windows , así como para algunas funciones de recursos y pincel con patrón de Windows.[9]
Encabezado del archivo de mapa de bits [ editar ]
Este bloque de bytes está al comienzo del archivo y se usa para identificar el archivo. Una aplicación típica lee este bloque primero para asegurarse de que el archivo sea realmente un archivo BMP y que no esté dañado. Los primeros 2 bytes del formato de archivo BMP son el carácter "B" y luego el carácter "M" en codificación ASCII . Todos los valores enteros se almacenan en formato little-endian (es decir, primero el byte menos significativo).
Desplazamiento hexagonal | Compensación dec | Tamaño | Propósito |
---|---|---|---|
00 | 0 | 2 bytes | El campo de encabezado utilizado para identificar el archivo BMP y DIB está 0x42 0x4D en hexadecimal , al igual que BM en ASCII. Son posibles las siguientes entradas:
|
02 | 2 | 4 bytes | El tamaño del archivo BMP en bytes |
06 | 6 | 2 bytes | Reservado; el valor real depende de la aplicación que crea la imagen, si se crea manualmente puede ser 0 |
08 | 8 | 2 bytes | Reservado; el valor real depende de la aplicación que crea la imagen, si se crea manualmente puede ser 0 |
0A | 10 | 4 bytes | El desplazamiento, es decir, la dirección de inicio, del byte donde se pueden encontrar los datos de la imagen de mapa de bits (matriz de píxeles). |
Encabezado DIB (encabezado de información de mapa de bits) [ editar ]
Este bloque de bytes le dice a la aplicación información detallada sobre la imagen, que se utilizará para mostrar la imagen en la pantalla. El bloque también coincide con el encabezado utilizado internamente por Windows y OS / 2 y tiene varias variantes diferentes. Todos ellos contienen un campo dword (32 bits), especificando su tamaño, para que una aplicación pueda determinar fácilmente qué encabezado se usa en la imagen. La razón por la que hay diferentes encabezados es que Microsoft extendió el formato DIB varias veces. Los nuevos encabezados extendidos se pueden usar con algunas funciones de GDI en lugar de los más antiguos, proporcionando más funcionalidad. Dado que GDI admite una función para cargar archivos de mapa de bits, las aplicaciones típicas de Windows utilizan esa funcionalidad. Una consecuencia de esto es que para tales aplicaciones,los formatos BMP que admiten coinciden con los formatos admitidos por la versión de Windows que se está ejecutando. Consulte la tabla siguiente para obtener más información.
Tamaño | Nombre del encabezado | Soporte del sistema operativo | Características | Escrito por |
---|---|---|---|---|
12 | BITMAPCOREHEADER OS21XBITMAPHEADER | Windows 2.0 o posterior OS / 2 1.x [3] | ||
64 | OS22XBITMAPHEADER | OS / 2 BITMAPCOREHEADER 2 | Agrega medios tonos . Agrega compresión RLE y Huffman 1D. | |
dieciséis | OS22XBITMAPHEADER | Esta variante del encabezado anterior contiene solo los primeros 16 bytes y se supone que los bytes restantes son valores cero. [3] Un ejemplo de tal caso es el gráfico pal8os2v2-16.bmp [10] de BMP Suite. [11] | ||
40 | BITMAPINFOHEADER | Windows NT , 3.1xo posterior [2] | Agrega formatos de 16 bpp y 32 bpp. Agrega compresión RLE. | |
52 | BITMAPV2INFOHEADER | Indocumentado | Agrega máscaras de bits RGB. | Adobe Photoshop |
56 | BITMAPV3INFOHEADER | No documentado oficialmente, pero esta documentación fue publicada en los foros de Adobe, por un empleado de Adobe con una declaración de que el estándar se incluyó en un momento en el pasado en la documentación oficial de MS [12] | Agrega una máscara de bits de canal alfa . | Adobe Photoshop |
108 | BITMAPV4HEADER | Windows NT 4.0 , 95 o posterior | Agrega tipo de espacio de color y corrección de gamma | |
124 | BITMAPV5HEADER | Windows NT 5.0 , 98 o posterior | Agrega perfiles de color ICC | El GIMP |
Desplazamiento (hex) | Desplazamiento (dec) | Tamaño (bytes) | OS / 2 1.x BITMAPCOREHEADER [3] |
---|---|---|---|
0E | 14 | 4 | El tamaño de este encabezado (12 bytes) |
12 | 18 | 2 | El ancho del mapa de bits en píxeles (16 bits sin firmar) |
14 | 20 | 2 | La altura del mapa de bits en píxeles (16 bits sin firmar) |
dieciséis | 22 | 2 | El número de planos de color, debe ser 1 |
18 | 24 | 2 | El número de bits por píxel |
El BITMAPCOREHEADER de Windows 2.x se diferencia del BITMAPCOREHEADER de OS / 2 1.x (que se muestra en la tabla anterior) en el único detalle de que los campos de ancho y alto de la imagen son enteros con signo, no sin firmar. [13]
Las versiones posteriores a BITMAPCOREHEADER solo agregan campos al final del encabezado de la versión anterior. Por ejemplo: BITMAPV2INFOHEADER agrega campos a BITMAPINFOHEADER y BITMAPV3INFOHEADER agrega campos a BITMAPV2INFOHEADER .
Se ha introducido un canal alfa integrado con el BITMAPV3INFOHEADER no documentado y con el BITMAPV4HEADER documentado (desde Windows 95 ) y se utiliza en el sistema de inicio de sesión y temas de Windows XP , así como en Microsoft Office (desde v2000); es compatible con algún software de edición de imágenes , como Adobe Photoshop desde la versión 7 y Adobe Flash desde la versión MX 2004 (entonces conocido como Macromedia Flash). También es compatible con GIMP , Google Chrome , Microsoft PowerPoint y Microsoft Word .
Por razones de compatibilidad, la mayoría de las aplicaciones utilizan los encabezados DIB más antiguos para guardar archivos. Dado que OS / 2 ya no es compatible después de Windows 2000, por ahora el formato común de Windows es el encabezado BITMAPINFOHEADER . Consulte la siguiente tabla para obtener su descripción. Todos los valores se almacenan como enteros sin signo, a menos que se indique explícitamente.
Desplazamiento (hex) | Desplazamiento (dec) | Tamaño (bytes) | Windows BITMAPINFOHEADER [2] |
---|---|---|---|
0E | 14 | 4 | el tamaño de este encabezado, en bytes (40) |
12 | 18 | 4 | el ancho del mapa de bits en píxeles (entero con signo) |
dieciséis | 22 | 4 | la altura del mapa de bits en píxeles (entero con signo) |
1A | 26 | 2 | el número de planos de color (debe ser 1) |
1C | 28 | 2 | el número de bits por píxel, que es la profundidad de color de la imagen. Los valores típicos son 1, 4, 8, 16, 24 y 32. |
1E | 30 | 4 | el método de compresión que se está utilizando. Consulte la siguiente tabla para obtener una lista de posibles valores. |
22 | 34 | 4 | the image size. This is the size of the raw bitmap data; a dummy 0 can be given for BI_RGB bitmaps. |
26 | 38 | 4 | the horizontal resolution of the image. (pixel per metre, signed integer) |
2A | 42 | 4 | the vertical resolution of the image. (pixel per metre, signed integer) |
2E | 46 | 4 | the number of colors in the color palette, or 0 to default to 2n |
32 | 50 | 4 | the number of important colors used, or 0 when every color is important; generally ignored |
The compression method (offset 30) can be:
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 | OS22XBITMAPHEADER: Huffman 1D | BITMAPV2INFOHEADER: RGB bit field masks, BITMAPV3INFOHEADER+: RGBA |
4 | BI_JPEG | OS22XBITMAPHEADER: RLE-24 | BITMAPV4INFOHEADER+: JPEG image for printing[14] |
5 | BI_PNG | BITMAPV4INFOHEADER+: PNG image for printing[14] | |
6 | BI_ALPHABITFIELDS | RGBA bit field masks | only Windows CE 5.0 with .NET 4.0 or later |
11 | BI_CMYK | none | only Windows Metafile CMYK[4] |
12 | BI_CMYKRLE8 | RLE-8 | only Windows Metafile CMYK |
13 | BI_CMYKRLE4 | RLE-4 | only Windows Metafile CMYK |
An OS/2 2.x OS22XBITMAPHEADER (BITMAPINFOHEADER2 in IBM's documentation) contains 24 additional bytes:[3]
Offset (hex) | Offset (dec) | Size (bytes) | OS/2 OS22XBITMAPHEADER (BITMAPINFOHEADER2)[3] |
---|---|---|---|
36 | 54 | 2 | An enumerated value specifying the units for the horizontal and vertical resolutions (offsets 38 and 42). The only defined value is 0, meaning pixels per metre |
38 | 56 | 2 | Padding. Ignored and should be zero |
3A | 58 | 2 | An enumerated value indicating the direction in which the bits fill the bitmap. The only defined value is 0, meaning the origin is the lower-left corner. Bits fill from left-to-right, then bottom-to-top. Note that Windows bitmaps (which don't include this field) can also specify an upper-left origin (bits fill from left-to-right, then top-to-bottom) by using a negative value for the image height |
3C | 60 | 2 | An enumerated value indicating a halftoning algorithm that should be used when rendering the image. |
40 | 64 | 4 | Halftoning parameter 1 (see below) |
44 | 68 | 4 | Halftoning parameter 2 (see below) |
48 | 72 | 4 | An enumerated value indicating the color encoding for each entry in the color table. The only defined value is 0, indicating RGB. |
4C | 76 | 4 | An application-defined identifier. Not used for image rendering |
The halftoning algorithm (offset 60) can be:
Value | Halftoning algorithm | Comments |
---|---|---|
0 | none | Most common |
1 | Error diffusion | Halftoning parameter 1 (offset 64) is the percentage of error damping. 100 indicates no damping. 0 indicates that errors are not diffused |
2 | PANDA: Processing Algorithm for Noncoded Document Acquisition | Halftoning parameters 1 and 2 (offsets 64 and 68, respectively) represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used |
3 | Super-circle | Halftoning parameters 1 and 2 (offsets 64 and 68, respectively) represent the X and Y dimensions, in pixels, respectively, of the halftoning pattern used |
Color table[edit]
The color table (palette) occurs in the BMP image file directly after the BMP file header, the DIB header, and after the optional three or four bitmasks if the BITMAPINFOHEADER header with BI_BITFIELDS (12 bytes) or BI_ALPHABITFIELDS (16 bytes) option is used. Therefore, its offset is the size of the BITMAPFILEHEADER plus the size of the DIB header (plus optional 12-16 bytes for the three or four bit masks).
Note: On Windows CE the BITMAPINFOHEADER header can be used with the BI_ALPHABITFIELDS[6] option in the biCompression member.
The number of entries in the palette is either 2n (where n is the number of bits per pixel) or a smaller number specified in the header (in the OS/2 BITMAPCOREHEADER header format, only the full-size palette is supported).[3][5] In most cases, each entry in the color table occupies 4 bytes, in the order blue, green, red, 0x00 (see below for exceptions). This is indexed in the BITMAPINFOHEADER under the function biBitCount.
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 RGBA32 format. The color table used with the OS/2 BITMAPCOREHEADER uses the 3-byte per entry RGB24 format.[3][5] For DIBs loaded in memory, the color table can optionally consist of 2-byte entries – these entries constitute indexes to the currently realized palette[8] instead of explicit RGB color definitions.
Microsoft does not disallow the presence of a valid alpha channel bit mask[15] 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[16] 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[17]) specifies that for 16bpp (and higher), the color table can be present to store a list of colors intended for optimization on devices with limited color display capability, while it also specifies, that in such cases, no indexed palette entries are present in this Color Table. This may seem like a contradiction if no distinction is made between the mandatory palette entries and the optional color list.
Pixel storage[edit]
The 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 above 1, multiple padded rows are stored consecutively, forming a Pixel Array.
The total number of bytes necessary to store one row of pixels can be calculated as:
- ImageWidth is expressed in pixels. The equation above uses the floor and ceiling functions.
The total number of bytes necessary to store an array of pixels in an n bits per pixel (bpp) image, with 2n colors, can be calculated by accounting for the effect of rounding up the size of each row to a multiple of 4 bytes, as follows:
- PixelArraySize = RowSize · |ImageHeight|
- ImageHeight is expressed in pixels. The absolute value is necessary because ImageHeight is expressed as a negative number for top-down images.
Pixel array (bitmap data)[edit]
The pixel array is a block of 32-bit DWORDs, that describes the image pixel by pixel. Usually pixels are stored "bottom-up", starting in the lower left corner, going from left to right, and then row by row from the bottom to the top of the image.[5] Unless BITMAPCOREHEADER is used, 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).[5] Contemporary DIB Headers allow pixel formats with 1, 2, 4, 8, 16, 24 and 32 bits per pixel (bpp).[18] GDI+ also permits 64 bits per pixel.[19]
Padding bytes (not necessarily 0) must be appended to the end of the rows in order to bring up the length of the rows to a multiple of four bytes. When the pixel array is loaded into memory, each row must begin at a memory address that is a multiple of 4. This address/offset restriction is mandatory only for Pixel Arrays loaded in memory. For file storage purposes, only the size of each row must be a multiple of 4 bytes while the file offset can be arbitrary.[5] 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 6 bytes of data and 2 bytes of padding, Width=3 would have 9 bytes of data and 3 bytes of padding, and Width=4 would have 12 bytes of data and no padding.
Compression[edit]
- Indexed 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.
Pixel format[edit]
- The 1-bit per pixel (1bpp) format supports 2 distinct colors, (for example: black and white). The pixel values are stored in each bit, with the first (left-most) pixel in the most-significant bit of the first byte.[5] Each bit is an index into a table of 2 colors. An unset bit will refer to the first color table entry, and a set bit will refer to the last (second) color table entry.
- The 2-bit per pixel (2bpp) format supports 4 distinct colors and stores 4 pixels per 1 byte, the left-most pixel being in the two most significant bits (Windows CE only:[20]). Each pixel value is a 2-bit index into a table of up to 4 colors.
- The 4-bit per pixel (4bpp) format supports 16 distinct colors and stores 2 pixels per 1 byte, the left-most pixel being in the more significant nibble.[5] Each pixel value is a 4-bit index into a table of up to 16 colors.
- The 8-bit per pixel (8bpp) format supports 256 distinct colors and stores 1 pixel per 1 byte. Each byte is an index into a table of up to 256 colors.
- The 16-bit per pixel (16bpp) format supports 65536 distinct colors and stores 1 pixel per 2-byte WORD. Each WORD can define the alpha, red, green and blue samples of the pixel.
- The 24-bit pixel (24bpp) format supports 16,777,216 distinct colors and stores 1 pixel value per 3 bytes. Each pixel value defines the red, green and blue samples of the pixel (8.8.8.0.0 in RGBAX notation). Specifically, in the order: blue, green and red (8 bits per each sample).[5]
- The 32-bit per pixel (32bpp) format supports 4,294,967,296 distinct colors and stores 1 pixel per 4-byte DWORD. Each DWORD can define the alpha, red, green and blue samples of the pixel.
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:
The sample fields defined by the BITFIELDS bit masks have to be contiguous and non-overlapping, but the order of the sample fields is arbitrary. The most ubiquitous field order is: Alpha, Blue, Green, Red (MSB to LSB). 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[6] (Windows CE only).
RGB video subtypes[edit]
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,[21] all palettized formats RGB8, RGB4, and RGB1 (marked in yellow in the table above, dshow.h
MEDIASUBTYPE names) and:
R.G.B.A.X | RGB subtype | R.G.B.A.X | ARGB subtype |
---|---|---|---|
8.8.8.0.8 | RGB32 | 8.8.8.8.0 | ARGB32 |
10.10.10.2.0 | A2R10G10B10 | ||
8.8.8.0.0 | RGB24 | 10.10.10.2.0 | A2B10G10R10 |
5.6.5.0.0 | RGB565 | 4.4.4.4.0 | ARGB4444 |
5.5.5.0.1 | RGB555 | 5.5.5.1.0 | ARGB1555 |
Bit field | Offset | Bits A2R10G10B10 | Bits A2B10G10R10 | ||||
---|---|---|---|---|---|---|---|
Red | 36h | 00 00 F0 3F | LE: 3FF00000 | 20 …29 | FF 03 00 00 | LE: 000003FF | 0 … 9 |
Green | 3Ah | 00 FC 0F 00 | LE: 000FFC00 | 10 …19 | 00 FC 0F 00 | LE: 000FFC00 | 10 …19 |
Blue | 3Eh | FF 03 00 00 | LE: 000003FF | 0 … 9 | 00 00 F0 3F | LE: 3FF00000 | 20 …29 |
Alpha | 42h | 00 00 00 C0 | LE: C0000000 | 30 …31 | 00 00 00 C0 | LE: C0000000 | 30 …31 |
In version 2.1.4 FFmpeg supported (in its own terminology) the BMP pixel formats bgra, bgr24, rgb565le, rgb555le, rgb444le, rgb8, bgr8, rgb4_byte, bgr4_byte, gray, pal8, and monob; i.e., bgra was the only supported pixel format with transparency.[23]
Example 1[edit]
Following is an example of a 2×2 pixel, 24-bit bitmap (Windows DIB header BITMAPINFOHEADER) with pixel format RGB24.
Offset | Size | Hex value | Value | Description |
---|---|---|---|---|
BMP Header | ||||
0h | 2 | 42 4D | "BM" | ID field (42h, 4Dh) |
2h | 4 | 46 00 00 00 | 70 bytes (54+16) | Size of the BMP file (54 bytes header + 16 bytes data) |
6h | 2 | 00 00 | Unused | Application specific |
8h | 2 | 00 00 | Unused | Application specific |
Ah | 4 | 36 00 00 00 | 54 bytes (14+40) | 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 (left to right order) | Width of the bitmap in pixels |
16h | 4 | 02 00 00 00 | 2 pixels (bottom to top order) | Height of the bitmap in pixels. Positive for bottom to top pixel order. |
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 bitmap data (including padding) |
26h | 4 | 13 0B 00 00 | 2835 pixels/metre horizontal | Print resolution of the image, 72 DPI × 39.3701 inches per metre yields 2834.6472 |
2Ah | 4 | 13 0B 00 00 | 2835 pixels/metre vertical | |
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) |
Example 2[edit]
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 ARGB32.
Offset | Size | Hex value | Value | Description |
---|---|---|---|---|
BMP Header | ||||
0h | 2 | 42 4D | "BM" | ID field (42h, 4Dh) |
2h | 4 | 9A 00 00 00 | 154 bytes (122+32) | 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 (14+108) | 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 (left to right order) | Width of the bitmap in pixels |
16h | 4 | 02 00 00 00 | 2 pixels (bottom to top order) | 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 bitmap data (including padding) |
26h | 4 | 13 0B 00 00 | 2835 pixels/metre horizontal | Print resolution of the image, 72 DPI × 39.3701 inches per metre yields 2834.6472 |
2Ah | 4 | 13 0B 00 00 | 2835 pixels/metre vertical | |
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 | little-endian "Win " | LCS_WINDOWS_COLOR_SPACE |
4Ah | 24h | 24h* 00...00 | CIEXYZTRIPLE Color Space endpoints | Unused for LCS "Win " or "sRGB " |
6Eh | 4 | 00 00 00 00 | 0 Red Gamma | Unused for LCS "Win " or "sRGB " |
72h | 4 | 00 00 00 00 | 0 Green Gamma | Unused for LCS "Win " or "sRGB " |
76h | 4 | 00 00 00 00 | 0 Blue Gamma | Unused for LCS "Win " or "sRGB " |
Start of the Pixel Array (the bitmap Data) | ||||
7Ah | 4 | FF 00 00 7F | 255 0 0 127 | Blue (Alpha: 127), Pixel (1,0) |
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 (1,2) |
86h | 4 | FF FF FF 7F | 255 255 255 127 | White (Alpha: 127), Pixel (1,3) |
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 (0,1) |
92h | 4 | 00 00 FF FF | 0 0 255 255 | Red (Alpha: 255), Pixel (0,2) |
96h | 4 | FF FF FF FF | 255 255 255 255 | White (Alpha: 255), Pixel (0,3) |
Note that the bitmap data starts with the lower left hand corner of the image.
Usage of BMP format[edit]
The 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 of patents, makes it a very common format that image processing programs from many operating systems can read and write[citation needed]. ICO and CUR files contain bitmaps starting with a BITMAPINFOHEADER.
Many older graphical user interfaces used bitmaps in their built-in graphics subsystems;[24] 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
.[25]
While most BMP files have a relatively large file size due to lack of any compression (or generally low-ratio run-length encoding on palletized images), many BMP files can be considerably compressed with lossless data compression algorithms such as ZIP because they contain redundant data. Some formats, such as RAR, even include routines specifically targeted at efficient compression of such data.
Related formats[edit]
The X Window System uses a similar XBM format for black-and-white images, and XPM (pixelmap) for color images. There are also a variety of "raw" formats, which save raw data with no other information. The Portable Pixmap (PPM) and Truevision TGA formats also exist, but are less often used – or only for special purposes; for example, TGA can contain transparency information.
References[edit]
- ^ "IANA Considerations". Windows Image Media Types. sec. 5. doi:10.17487/RFC7903. RFC 7903.
- ^ a b c James D. Murray; William vanRyper (April 1996). Encyclopedia of Graphics File Formats (Second ed.). O'Reilly. bmp. ISBN 1-56592-161-5. Retrieved 2014-03-07.
- ^ a b c d e f g h James D. Murray; William vanRyper (April 1996). Encyclopedia of Graphics File Formats (Second ed.). O'Reilly. os2bmp. ISBN 1-56592-161-5. Retrieved 2014-03-07.
- ^ a b "[MS-WMF]: Windows Metafile Format". MSDN. 2014-02-13. Retrieved 2014-03-12.
- ^ a b c d e f g h i j "DIBs and Their Uses". Microsoft Help and Support. Retrieved 2015-05-14.
- ^ a b c MSDN - BITMAPINFOHEADER (Windows CE 5.0): BI_ALPHABITFIELDS in biCompression member
- ^ a b c MSDN Bitmap Header Types
- ^ a b c MSDN BITMAPINFO Structure
- ^ Feng Yuan - Windows graphics programming: Win32 GDI and DirectDraw: Packed Device-Independent Bitmap (CreateDIBPatternBrush, CreateDIBPatternBrushPt, FindResource, LoadResource, LockResource)
- ^ Summers, Jason (2015-10-30). "pal8os2v2-16.bmp". Retrieved 2016-07-06.
- ^ Summers, Jason (2015-10-30). "BMP Suite". Retrieved 2016-07-06.
- ^ Cox, Chris (2010-11-15). "Invalid BMP Format with Alpha channel". Photoshop Windows forum. Adobe. Archived from the original on 2015-01-27. Retrieved 2016-05-22.
- ^ https://www.fileformat.info/format/bmp/egff.htm
- ^ a b "JPEG and PNG Extensions for Specific Bitmap Functions and Structures".
- ^ MSDN – BITMAPV4HEADER: The member bV4AlphaMask
- ^ MSDN – RGBQUAD: rgbReserved member
- ^ see note under biClrUsed MSDN BITMAPINFOHEADER
- ^ MSDN - BITMAPINFOHEADER: The member biBitCount
- ^ "Types of Bitmaps". MSDN. 2012-06-03. Retrieved 2014-03-16.
- ^ MSDN: Windows CE - BITMAPINFOHEADER Structure
- ^ a b Adobe Photoshop: BMP Format Archived 2011-09-22 at the Wayback Machine
- ^ a b "Uncompressed RGB Video Subtypes". dshow.h. MSDN. Retrieved 2014-03-11.
- ^ "Image Formats". FFmpeg General Documentation. 2014. Retrieved 2014-02-23.
- ^ Julian Smart; Stefan Csomor & Kevin Hock (2006). Cross-Platform GUI Programming with Wxwidgets. Prentice Hall. ISBN 0-13-147381-6.
- ^ "Bitmap Image File (BMP), Version 5". Digital Preservation. Library of Congress. 2014-01-08. Retrieved 2014-03-11.
External links[edit]
- Bitmap File Structure, at digicamsoft.com
- An introduction to DIBs (Device Independent Bitmaps), at herdsoft.com
- A simple bitmap loader C++ class, at kalytta.com (A2R10G10B10 not yet[update] supported)
- The BMP File Format, Part 1 By David Charlap at Dr. Dobb's journal of software tools (drdobbs.com), March 1995