Bmp windows device independent bitmap

This article is about the file format. For the data structure/type of image, see Bitmap graphics.

Windows Bitmap

The BMP file format, or bitmap, is a raster graphics image file format used to store bitmap digital images, independently of the display device (such as a graphics adapter), especially on Microsoft Windows^[2] and OS/2^[3] operating systems.

The BMP file format is capable of storing two-dimensional digital images in various color depths, and optionally with data compression, alpha channels, and color profiles. The Windows Metafile (WMF) specification covers the BMP file format.^[4]

Microsoft has defined a particular representation of color bitmaps of different color depths, as an aid to exchanging bitmaps between devices and applications with a variety of internal representations. They called these device-independent bitmaps or DIBs, and the file format for them is called DIB file format or BMP image file format.

According to Microsoft support:^[5]

A device-independent bitmap (DIB) is a format used to define device-independent bitmaps in various color resolutions. The main purpose of DIBs is to allow bitmaps to be moved from one device to another (hence, the device-independent part of the name). A DIB is an external format, in contrast to a device-dependent bitmap, which appears in the system as a bitmap object (created by an application…). A DIB is normally transported in metafiles (usually using the StretchDIBits() function), BMP files, and the Clipboard (CF_DIB data format).

The following sections discuss the data stored in the BMP file or DIB in detail. This is the standard BMP file format.^[5] Some applications create bitmap image files which are not compliant with the Microsoft documentation. Also, not all fields are used; a value of 0 will be found in these unused fields.

The bitmap image file consists of fixed-size structures (headers) as well as variable-sized structures appearing in a predetermined sequence. Many different versions of some of these structures can appear in the file, due to the long evolution of this file format.

Referring to the diagram 1, the bitmap file is composed of structures in the following order:

A bitmap image file loaded into memory becomes a DIB data structure – an important component of the Windows GDI API. The in-memory DIB data structure is almost the same as the BMP file format, but it does not contain the 14-byte bitmap file header and begins with the DIB header. For DIBs loaded in memory, the color table can also consist of 16-bit entries that constitute indexes to the currently realized palette^[8] (an additional level of indirection), instead of explicit RGB color definitions. In all cases, the pixel array must begin at a memory address that is a multiple of 4 bytes. In non-packed DIBs loaded in memory, the optional color profile data should be located immediately after the color table and before the gap1 and pixel array (unlike in diag. 1).

When the size of gap1 and gap2 is zero, the in-memory DIB data structure is customarily referred to as «packed DIB» and can be referred to by a single pointer pointing to the beginning of the DIB header. In all cases, the pixel array must begin at a memory address that is a multiple of 4 bytes. In some cases it may be necessary to adjust the number of entries in the color table in order to force the memory address of the pixel array to a multiple of 4 bytes.^[8] For «packed DIBs» loaded in memory, the optional color profile data should immediately follow the pixel array, as depicted in diag. 1 (with gap1=0 and gap2=0).
«Packed DIBs» are required by Windows clipboard API functions as well as by some Windows patterned brush and resource functions.^[9]

This block of bytes is at the start of the file and is used to identify the file. A typical application reads this block first to ensure that the file is actually a BMP file and that it is not damaged. The first 2 bytes of the BMP file format are the character «B» then the character «M» in ASCII encoding. All of the integer values are stored in little-endian format (i.e. least-significant byte first).

This block of bytes tells the application detailed information about the image, which will be used to display the image on the screen. The block also matches the header used internally by Windows and OS/2 and has several different variants. All of them contain a dword (32-bit) field, specifying their size, so that an application can easily determine which header is used in the image. The reason that there are different headers is that Microsoft extended the DIB format several times. The new extended headers can be used with some GDI functions instead of the older ones, providing more functionality. Since the GDI supports a function for loading bitmap files, typical Windows applications use that functionality. One consequence of this is that for such applications, the BMP formats that they support match the formats supported by the Windows version being run. See the table below for more information.

Windows and OS/2 bitmap headers

OS/2 1.x bitmaps are uncompressed and cannot be 16 or 32 bpp.

The Windows 2.x BITMAPCOREHEADER differs from the OS/2 1.x BITMAPCOREHEADER (shown in the table above) in the one detail that the image width and height fields are signed integers, not unsigned.^[13]

Versions after BITMAPINFOHEADER only add fields to the end of the header of the previous version.
For example: BITMAPV2INFOHEADER adds fields to BITMAPINFOHEADER, and BITMAPV3INFOHEADER adds fields to BITMAPV2INFOHEADER.

An integrated alpha channel has been introduced with the undocumented BITMAPV3INFOHEADER and with the documented BITMAPV4HEADER (since Windows 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, Microsoft PowerPoint and Microsoft Word.

For compatibility reasons, most applications use the older DIB headers for saving files. With OS/2 no longer supported after Windows 2000, for now the common Windows format is the BITMAPINFOHEADER header. See next table for its description. All values are stored as unsigned integers, unless explicitly noted.

The compression method (offset 30) can be:

An OS/2 2.x OS22XBITMAPHEADER (BITMAPINFOHEADER2 in IBM’s documentation) contains 24 additional bytes:^[3]

The halftoning algorithm (offset 60) can be:

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 2ⁿ (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 in the structure member 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 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 palettization.

The colors in the color table are usually specified in the 4-byte per entry ARGB32 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.

The bits representing the bitmap pixels are packed in rows (also known as strides or scan lines). The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding.^[18]

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:

Картинка с сайта: en.wikipedia.org

The total number of bytes necessary to store an array of pixels in an n bits per pixel (bpp) image, with 2ⁿ 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:

ImageHeight is expressed in pixels. The absolute value is necessary because ImageHeight is expressed as a negative number for top-down images.

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).^[19] GDI+ also permits 64 bits per pixel.^[20]

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.

• 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.

• 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:^[21]). 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 per 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:

Картинка с сайта: en.wikipedia.org

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, 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).

Картинка с сайта: en.wikipedia.org

Diag. 3 – The pixel format with an alpha channel for a 16-bit pixel (in RGBAX sample Length notation) actually generated by Adobe Photoshop^[22]

Картинка с сайта: en.wikipedia.org

All of the possible pixel formats in a DIB

The BITFIELD mechanism described above allows for the definition of tens of thousands of different pixel formats, however only several of them are used in practice,^[22] all palettized formats RGB8, RGB4, and RGB1 (marked in yellow in the table above, defined in dshow.h.MEDIASUBTYPE names):

Uncompressed RGB Video Subtypes^[23]

Bit fields for ten RGB bits^[23]

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.^[24]

Following is an example of a 2×2 pixel, 24-bit bitmap (Windows DIB header BITMAPINFOHEADER) with pixel format RGB24.

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.

Note that the bitmap data starts with the lower left hand corner of the image.

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 has an open format, makes BMP a very common format that image processing programs from many operating systems can read and write. ICO and CUR files contain bitmaps starting with a BITMAPINFOHEADER.

Many older graphical user interfaces used bitmaps in their built-in graphics subsystems;^[25] 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.^[26]

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.

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.

• 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 supported)
• The BMP File Format, Part 1 By David Charlap at Dr. Dobb’s journal of software tools (drdobbs.com), March 1995

У этого термина существуют и другие значения, см. BMP (значения).

(от англ. Bitmap Picture) — формат хранения растровых изображений, разработанный компанией Microsoft.
Файлы формата BMP могут иметь расширения .bmp, .dib и .rle.

С форматом BMP работает огромное количество программ, так как его поддержка интегрирована в операционные системы Windows и OS/2.
Кроме того, данные этого формата включаются в двоичные файлы ресурсов RES и в PE-файлы.

В данном формате можно хранить только однослойные растры.
На каждый пиксель в разных файлах может приходиться разное количество бит (глубина цвета).
Microsoft предлагает битности 1, 2, 4, 8, 16, 24, 32, 48 и 64.
В битностях 8 и ниже цвет указывается индексом из таблицы цветов (палитры), а при бо́льших — непосредственным значением.
Цвет же в любом случае можно задать только в цветовой модели RGB (как при непосредственном указании в пикселе, так и в таблице цветов), но в битностях 16 и 32 можно получить Grayscale с глубиной до 16 и 32 бит, соответственно.
Частичная прозрачность реализована альфа-каналом битностей от 16 бит и выше.

В большинстве случаев пиксели хранятся в виде относительно простого двумерного массива. Для битностей 4 и 8 доступно RLE-кодирование, которое может уменьшить их размер. Формат BMP также поддерживает встраивание данных в форматах JPEG и PNG. Но последнее скорее больше предназначено не для компактного хранения, а для обхода ограничений архитектуры GDI, которая не предусматривает прямую работу с изображениями отличных от BMP форматов.
В последних версиях формата BMP также появились возможности по управлению цветом. В частности, можно указывать конечные точки, производить гамма-коррекцию и встраивать цветовые профили ICC.

При использовании формата DIB (англ. Device Independent Bitmap, аппаратно-независимый растр) программист может получить доступ ко всем элементам структур, описывающих изображение, при помощи обычного указателя.
Но эти данные не используются для непосредственного управления экраном, так как они всегда хранятся в системной памяти, а не в специализированной видеопамяти.
Формат пикселя в оперативной памяти может отличаться от того формата, который должен заноситься в видеопамять для индикации точки такого же цвета.
Например, в DIB-формате может использоваться 24 бита для задания пикселя, а графический адаптер в этот момент может работать в режиме HiColor с цветовой глубиной 16 бит.
При этом ярко-красная точка в аппаратно-независимом формате будет задаваться тремя байтами 0000FF₁₆, а в видеопамяти — словом F800₁₆.
При копировании картинки на экран система будет тратить дополнительное время на преобразование кодов цвета из 24-битного формата в формат видеобуфера.

Формат DDB (англ. Device Dependent Bitmap, аппаратно-зависимый растр) всегда содержит цветовые коды, совпадающие с кодами видеобуфера, но храниться он может как в системной, так и в видеопамяти.
В обоих случаях он содержит только коды цвета в том формате, который обеспечит пересылку изображения из ОЗУ в видеопамять при помощи простого копирования^[6].

Официальную информацию по формату BMP можно найти в MSDN или справке Microsoft Windows SDK (может идти в комплекте с некоторыми IDE).
В файле WinGDI.h от компании Microsoft есть все объявления на языке C++, которые касаются данного формата.
В данную статью же не были включены объявления типов, так как от этого она может быть слишком громоздкой.
К тому же официальные объявления некоторые разработчики могут посчитать неудобными и поэтому их востребованность сомнительна.
Если вам потребуются оригинальные имена констант, структур, типов и их полей, то они все есть в тексте данной статьи.

Максимальный размер неделимых ячеек (исключая поля битовых структур): 32 бита и поэтому формат можно классифицировать как 32-битный.
Исключением могут быть 64-битные пиксели, но значения их каналов можно обрабатывать и 16-битными словами.
Порядок байт в 16-битных и 32-битных ячейках повсюду от младшего к старшему (little-endian).
Целые числа записываются в прямом коде, со знаком — в дополнительном.
Если сравнивать с аппаратными архитектурами, то порядок байт и формат чисел соответствует x86.

В данной статье для указания типов используются имена типов WinAPI как в документации Microsoft.
Кроме специфических (описаны отдельно в тексте статьи) можно встретить четыре числовых типа:

• BYTE — 8-битное беззнаковое целое.
• WORD — 16-битное беззнаковое целое.
• DWORD — 32-битное беззнаковое целое.
• LONG — 32-битное целое со знаком.

В формате Windows Bitmap под структурами понимается блок с идущими подряд ячейками различного фиксированного размера, у которых есть условные имена (есть во многих языках программирования), а не что-то сложнее (например, поток команд произвольного размера).

У некоторых элементов формата указана версия Windows, начиная с которой он поддерживается.
Речь идёт в первую очередь об основных библиотеках WinAPI таких как gdi32.dll, shell32.dll, user32.dll и kernel32.dll.
Другие компоненты операционной системы (например, GDI+, .NET, DirectX) могут иметь другие более широкие возможности.

Общая структура[править | править код]

Данные в формате BMP состоят из трёх основных блоков различного размера:

1. Заголовок из структуры BITMAPFILEHEADER и блока BITMAPINFO. Последний содержит:
   1. Информационные поля.
   2. Битовые маски для извлечения значений цветовых каналов (опциональные).
   3. Таблица цветов (опциональная).
2. Цветовой профиль (опциональный).
3. Пиксельные данные.

При хранении в файле все заголовки идут с самого первого байта.
Пиксельные данные могут находиться на произвольной позиции в файле (она указывается в поле OffBits структуры BITMAPFILEHEADER), в том числе и в удалении от заголовков.
Опциональный цветовой профиль появился в версии 5 и он также может свободно располагаться, но его позиция указывается от начала BITMAPINFO (в поле ProfileData).

В оперативной памяти (например, при взаимодействии с WinAPI-функциями GDI) из заголовков исключается структура BITMAPFILEHEADER.
При этом Microsoft рекомендует располагать цветовой профиль сразу за заголовками в едином блоке^[7].
Пиксельные данные могут иметь произвольное расположение в памяти и их адрес указывается в параметрах процедур.
В любом случае рекомендуется в памяти все блоки содержать по адресам кратным четырём: в заголовках присутствуют 32-битные ячейки, а к пиксельным данным такое требование указано в документации^[8].
Это требование справедливо только для оперативной памяти: при хранении в файле его придерживаться не обязательно.

[править | править код]

BITMAPFILEHEADER — 14-байтная структура, которая располагается в самом начале файла.
Обратите внимание на то, что с самого начала структуры сбивается выравнивание ячеек.
Если для вас оно важно, то в оперативной памяти данный заголовок располагайте по чётным адресам, которые не кратны четырём (тогда 32-битные ячейки попадут на выравненные позиции).

Сигнатура формата при просмотре содержимого файла текстом в двоичном режиме выглядит как пара ASCII-символов «BM».

BITMAPINFO[править | править код]

BITMAPINFO в файле идёт сразу за BITMAPFILEHEADER.
Адрес этого блока в памяти напрямую также передаётся некоторым функциям WinAPI (например, SetDIBitsToDevice или CreateDIBitmap).
Кроме этого, этот же блок используется в форматах значков и курсоров Windows, но в данной статье этот момент не рассматривается (см. отдельные описания этих форматов).
Данная структура является основной и описательной в формате BMP и поэтому когда просто упомянуто имя поля, то речь идёт о поле в данной структуре.

Блок BITMAPINFO состоит из трёх частей:

1. Структура с информационными полями.
2. Битовые маски для извлечения значений цветовых каналов (присутствуют не всегда).
3. Таблица цветов (присутствует не всегда).

Про битовые маски и таблицу цветов смотрите ниже в отдельных разделах.
Здесь далее пойдёт описание структуры с информационными полями.

В момент написания данной статьи структура с информационными полями имела четыре версии: CORE, 3, 4 и 5 (обозначения версий приведены условные в рамках данной статьи для краткости).
Для каждой версии Microsoft объявила четыре отдельные структуры с разными именами полей.
В данной статье при упоминании поля, которое присутствует в нескольких структурах, берётся общая для всех структур часть в конце имени (например, BitCount вместо bcBitCount, biBitCount, bV4BitCount или bV5BitCount).
Версию структуры можно определить по первой 32-битной ячейке (WinAPI-тип DWORD), которая содержит её размер в байтах (беззнаковым целым).
Версия CORE отличается от всех своей компактностью и использованием исключительно 16-битных беззнаковых полей.
Остальные три содержат идентичные ячейки, к которым в каждой новой версии добавлялись новые.

Ниже представлена обзорная таблица по информационным структурам:

Из-за идентичности полей в версиях 3, 4 и 5 может показаться, что полем Size можно регулировать количество полей, убирая неиспользуемые.
В действительности это не корректно, так как здесь размер играет роль версии (в версии CORE хоть и тоже идентичные поля, но другого размера и типа).
Никто не гарантирует, что вам не могут попасться заголовки меньших или больших размеров с другим набором полей.
Тем не менее, Adobe Photoshop может при сохранении файлов BMP записывать структуры информационных полей с размерами 52 и 56 байт.
По сути это урезанная 4-я версия, которая содержат только битовые маски каналов (56 байт — версия с альфа-каналом).

16-битные информационные поля (версия CORE)[править | править код]

Обратите внимание на то, что здесь поля ширины и высоты содержат беззнаковые целые, в то время как 32-битные структуры хранят значения со знаком.

32-битные информационные поля (версии 3, 4 и 5)[править | править код]

В таблице ниже поля представлены обзорно.
Подробную информацию вы можете найти в разделах далее.

Битность изображения (поле BitCount)[править | править код]

Поле BitCount содержит количество бит, которое приходится на каждый пиксель.
Если там указано отличное от нуля значение, то это и есть реальная битность.
Нулевое же содержимое поля BitCount указывается если пиксели хранятся в формате JPEG или PNG.
Тогда действительная битность будет определяться уже этими форматами.
Битности чисто BMP формата представлены в таблице ниже:

Примечания к таблице:

1. В колонке «BITMAPINFO» указана поддержка битностей только со стороны Microsoft.

2. Windows CE 1.0 и 1.01 поддерживает только битности 1 и 2^[14].

3. GDI+ версии 1.0 16-битные цветовые каналы умеет только считывать, сразу переводя их в 8-битные^[15].

В битностях 8 и ниже цвет пикселя указывается индексом в таблице цветов, в высших: непосредственным значением в цветовой модели RGB.
Альфа-канал опционально может быть добавлен в битностях 16 и 32.
В битности 64 он присутствует перманентно.

В таблице представлены только битности, которые документировала корпорация Microsoft.
Сам формат не содержит никаких принципиальных ограничений на использование каких-либо не упомянутых здесь битностей.

1-битные BMP-файлы с чисто чёрным (сброшенный бит) и белым (установленный бит) цветами называют монохромными.
Такие файлы обычно используются в качестве масок для других растров.
Возможно вам постоянно попадались на глаза именно такие 1-битные растры.
В действительности формат Windows Bitmap не накладывает никаких ограничений на то, какие цвета будут использоваться для каждого из значений бит.

Вы можете также встретить следующие названия битностей: CGA для двух бит, EGA для четырёх, HiColor (HighColor) для 16 бит, TrueColor для 24 и 32 бит с полупрозрачностью, DeepColor для больших битностей и возможно другие.
Эти названия появились в период развития цветных растровых дисплеев и относятся больше к их глубине цвета.
К моменту написания данной статьи (2014 год) такие названия уже давно не используются из-за сильного распространения 24-битных устройств (вместо этого просто указывается глубина цвета в битах или их количество).
А BMP-файлы в меньшей битности сохраняются в большей степени не для отображения на CGA или EGA-устройствах, а для компактности по сравнению с 24-битными и 32-битными форматами если используется малое количество цветов.

Поле Compression[править | править код]

Для каждой группы битностей используются отдельные ограниченные значения Compression, но в совокупности их значения уникальны.
Microsoft документировала следующие значения (в таблице указаны имена констант от этой корпорации):

Таблица цветов[править | править код]

Таблица цветов является частью блока BITMAPINFO и может использоваться в двух случаях:

1. Она обязательно присутствует при битностях 8 и ниже, в которых цвет пикселей задаётся индексом ячейки из неё.
2. При битностях 8 и выше, в которых цвет указывается непосредственным значением, таблица присутствует если используется заголовок не CORE-версии, у которого поле ClrUsed содержит ненулевое значение. Здесь она задействуется уже для оптимизации цветов при работе с использующими палитры устройствами (как именно производится оптимизация в документации не сказано).

Позиция таблицы цветов указывается от его начала блока BITMAPINFO.
По умолчанию она идёт сразу за информационной структурой (её беззнаковый размер в байтах можно прочитать из первого 32-битного поля).
Но между структурой с полями и цветовой таблицей могут идти четырёхбайтные битовые маски для извлечения цветовых каналов (касается только битностей 16 и 32).
Они там находятся только если используется информационная структура 3-й версии (Size = 40) и поле Compression содержит 3 (BI_BITFIELDS) или 6 (BI_ALPHABITFIELDS).
Тогда к размеру информационных полей нужно прибавить 12 (при значении BI_BITFIELDS) или 16 байт (если указано BI_ALPHABITFIELDS)^[17].
Получается 6 вариантов расположения таблицы:

Количество ячеек в таблице определяется по полям BitCount и ClrUsed.
При битностях 8 и ниже максимальное количество ячеек в таблице принимается за 2^{битность}: 2 в однобитном растре, 4 в двухбитном, 16 в 4-битном и 256 в 8-битном.
В данных битностях таблица всегда содержит это максимальное количество ячеек если используется заголовок версии CORE (Size = 12) или если в других версиях поле ClrUsed содержит 0.
Во всех остальных случаях, независимо от битности, в таблице находится столько же ячеек, сколько указано в поле ClrUsed^[18].

Сама же таблица представляет собой одномерный массив, который может содержать ячейки трёх типов:

1. 32-битная структура RGBQUAD. Применяется если в BITMAPINFO использована информационная структура версии 3, 4 или 5. В самой же структуре RGBQUAD указывается цвет в модели RGB в четырёх байтовых ячейках (все имеют WinAPI-тип BYTE): rgbBlue (синий), rgbGreen (зелёный), rgbRed (красный) и rgbReserved (зарезервирована и должна быть обнулена).
2. 24-битная структура RGBTRIPLE. Применяется если BITMAPINFO начинается со структуры BITMAPCOREHEADER. RGBTRIPLE состоит из трёх байтовых ячеек (WinAPI-тип BYTE), в которых указывается цвет в модели RGB: rgbtBlue (синий), rgbtGreen (зелёный) и rgbtRed (красный).
3. 16-битные индексы цветов (беззнаковые целые числа) в текущей логической палитре контекста устройства (системные объекты Windows GDI). Этот вид доступен только во время выполнения приложения. Формат BMP не поддерживает явное указание, что используется такая таблица и поэтому приложение само извещает WinAPI-функции об этом в специальных параметрах (как правило константой DIB_PAL_COLORS).

Во всей таблице могут быть задействованы не все ячейки и в поле ClrImportant помещается количество ячеек от начала таблицы до последней используемой (включая её саму).
Содержимое 0 поля ClrImportant указывает на то, что используется вся таблица.
Задействованные ячейки лучше размещать в самом начале таблицы и рекомендуется при этом отсортировать их по убыванию степени важности (на случай если придётся уменьшить их количество).

Маски для извлечения значений цветовых каналов[править | править код]

Если битность изображения 16 или 32, то могут быть указаны 32-битные маски для извлечения цветовых каналов.
Это связано с тем, что 16 не кратно трём и поэтому биты могут быть распределены разными способами.
В 32-битных изображениях из-за удобства используют 8-битные каналы и поэтому поддержка для них может показаться избыточной.
В действительности здесь маска даёт возможность включить/отключить альфа-канал или установить удобный вам порядок следования компонент, а не только регулировать их разрешение.
При применении масок ячейка пикселя считывается целиком как соответствующее машинное слово в little-endian.

Наличие битовых масок зависит от версии информационных полей структуры BITMAPINFO и поля Compression в ней.
Для версии CORE произвольные маски указать нельзя, так как там отсутствует поле Compression и отдельные поля масок.
В остальных версиях цветовые маски задействуются если Compression содержит 3 (BI_BITFIELDS).
Маска альфа-канала используется всегда в версиях 4 и 5.
Так как Windows CE не поддерживает эти две версии, в которых для неё есть специальное поле, для третьей версии было введено значение 6 (BI_ALPHABITFIELDS) поля Compression, которое добавляет сразу цветовые маски и маску альфа-канала (поддерживается начиная с Windows CE .NET 4.0).

Положение битовых масок фиксировано независимо от версии заголовка: 36_h во всём файле или 28_h от начала блока BITMAPINFO.
В версиях 4 и 5 на этом месте располагаются предназначенные специально для них поля.
В версии же 3 битовые маски должны располагаться сразу за информационными полями и таким образом они точно попадают на позиции соответствующих полей в старших версиях.
Обратите внимание на то, что в третьей версии при наличии масок сдвигается таблица цветов на 12 или 16 байт вперёд, располагаясь сразу за ними.
4-байтные маски цветов следуют в порядке красная, зелёная, синяя.
Маска альфа-канала располагается уже за ними.

В документации Microsoft к битовым маскам применяется только одно обязательное требование: каждая маска должна быть непрерывной.
Про случай пересечения масок там сказано, что желательно этого не делать^[19].
Microsoft также говорит о том, что не обязательно задействовать все биты пикселя^[20].
Какие-либо требования к содержимому неиспользуемых бит отсутствуют.

Обратите внимание на то, что никто не гарантирует, что могут быть использованы маски шире 8 бит.
И ничего не сказано про случай, когда у какого-либо канала будет нулевая маска (например, когда он действительно не используется).
Здесь возможна ситуация когда нулевые маски будут у всех компонентов и останется один альфа-канал (который при этом может занять все биты).
Нулевую маску цветового канала можно трактовать двумя способами: его значение принимается за ноль или же при прорисовке пиксели этого канала не затрагиваются.
Если взять первый вариант интерпретации с единственным альфа-каналом, то альфа-канал по сути будет задавать степень зачернения пикселя.
Кроме неопределённых вариантов есть также и интересный.
Так как пересечения не запрещены, то можно все каналы выставить на одну позицию и тем самым получить Grayscale.

Некоторое ПО имеет ограниченный набор поддерживаемых битовых масок.
В таблице ниже приведены доступные варианты в таких ограниченных средах:

Примечания к таблице:

(a) Эти наборы используются по умолчанию в битностях 16 и 32, если маски для извлечения цветов не заданы.

(b) Данный набор масок по своей сути реализует 16-битный Grayscale.

Пиксельные данные[править | править код]

В файле положение пиксельных данных можно узнать из поля OffBits структуры BITMAPFILEHEADER.
Во время выполнения приложение хранит адрес пиксельных данных там, где удобней.
В документации Microsoft также упоминаются так называемые упакованные (англ. packed) битмапы, которые указываются одним адресом блока BITMAPINFO.
У таких битмапов пиксельные данные следуют сразу за заголовком (включая помимо информационных полей битовые маски и таблицу цветов)^[24].

Размер пиксельных данных в байтах записывается в поле SizeImage структуры BITMAPINFO.
Туда записываются именно «сырой» размер того непрерывного блока, который содержит данные для формирования пикселей (независимо от формата), а не какой-нибудь распакованный.
По умолчанию это поле обязательно должно содержать актуальное значение, так как по нему можно точно узнать сколько именно байт нужно считать из файла для получения пикселей.
Тем не менее, допустимо содержать в этом поле ноль при хранении пикселей двумерными массивами (когда поле Compression содержит значение 0 (BI_RGB), 3 (BI_BITFIELDS) или 6 (BI_ALPHABITFIELDS)^[25]).
Тогда размер пикселей при необходимости можно относительно быстро рассчитать исходя из битности, ширины и высоты растра.

В формате Windows Bitmap доступно три способа хранения пикселей (см. также раздел «Поле Compression» данной статьи):

1. Двумерный массив.
2. RLE-кодирование (только для битностей 4 и 8).
3. В форматах JPEG или PNG.

В подразделах далее отдельно описан каждый из них.

Указание цвета и значения альфа-канала[править | править код]

Для указания цвета при хранении в формате BMP независимо от способа задания используются только беззнаковые целые числа.
Сам же цвет пикселя может задаваться двумя способами:

1. Индексом в таблице цветов (при битностях 8 и ниже).
2. Непосредственным значением в цветовой модели RGB (при битностях выше 8).

Второй целесообразно использовать когда набор цветов довольно большой или непредсказуем (например, во время обработки изображения).
Первый же способ обеспечивает как компактную компоновку при малом наборе цветов, так и некоторое удобство в управлении используемыми цветами (достаточно изменить значение цвета в палитре).
В самой таблице цветов указываются или 16-битные беззнаковые индексы в системной палитре (см. раздел «Таблица цветов» в данной статье), или же в RGB как в пикселе, но исключительно 8-битными значениями каналов.

Индекс в таблице цветов — это номер ячейки в ней от начала таблицы (используется непрерывная нумерация начиная с нуля).
Для каждой битности максимальный индекс принципиально ограничен значением 2^{битность} − 1.
В действительности же он ограничен ещё и количеством элементов в таблице (подробности в разделе «Таблица цветов» данной статьи).
Microsoft не документировала поведение в случае когда указывается индекс за пределами таблицы, но GDI в этом случае берёт чёрный цвет.

В битностях выше 8 цвет пикселя указывается непосредственно в цветовой модели RGB: отдельно указывается уровень красного цвета, зелёного и синего.
Нулевое значение любого из каналов означает полное отсутствие соответствующего оттенка, а максимальное: полное его присутствие.
Разрешение же значений каналов переменное и в каждой битности оно своё (конкретные значения смотрите в разделе про хранение пикселей в двумерном массиве этой статьи).
При этом в битностях 16 и 32 может быть задано не только произвольное разрешение, но и индивидуальное для каждого канала (например, 5 бит для красной и синей, но 6 бит для зелёной).
Несмотря на большое количество вариантов задания разрешения значений, в документации Microsoft не сказано как производить изменение разрешения значения.
Из-за этого у разных производителей программного обеспечения могут получаться различные результаты при смене битности.

При непосредственном задании цвета пикселя кроме значений RGB формат Windows Bitmap опционально позволяет ещё задать значения альфа-канала.
В плане битности и кодировании значений он идентичен цветовым каналам: у него произвольная битность и используются беззнаковые целые.
Что же касается сопоставления значений, то ноль соответствует полной прозрачности, а максимальное доступное число — полной заполненности.

Двумерный массив[править | править код]

В двумерном массиве можно хранить пиксели любой битности.
При таком способе хранения поле Compression содержит значение 0 (BI_RGB), 3 (BI_BITFIELDS) или 6 (BI_ALPHABITFIELDS).
Если используется заголовок версии CORE, то пиксели в любом случае хранятся только двумерным массивом.

В данной компоновке пиксели растра записываются однопиксельными горизонтальными полосками, которые Microsoft в своей документации часто называет «scans» (в русском языке наиболее близкое слово: строки).
В памяти эти ряды записываются по-порядку, но при положительном Height: начиная с самого нижнего (англ. bottom-up bitmap), а при отрицательном: с самого верхнего (англ. top-down bitmap).
Внутри каждого горизонтального ряда пиксели записываются строго только от левого к правому.
Пиксели меньше 8 бит размещаются в байтах, заполняя биты от старших к младшим, в результате чего шестнадцатиричные/двоичные числовые значения пикселей более похожи на выводимое изображение.
Если битность 16 или 32, то обработка осуществляется цельными машинными словами аналогичного размера с порядком бит от младшего к старшему (little-endian).
Ряды, независимо от размера ячеек, обязательно должны дополняться нулями до кратного четырём байтам размера^[8].
Из-за этого, при некратной ширине изображения, в конце рядов могут оказываться неиспользуемые биты или целые байты.
Но благодаря гарантированной кратности размера ряда, обработку можно производить 8-, 16- или 32-битными машинными словами, по выбору.
И у Microsoft ещё прослеживается следующая тенденция в битностях больше 8: компонент Blue (синий цвет) размещается в младших битах/первых байтах, Green (зелёный) в последующих, а Red (красный) старше/дальше всех, и если есть альфа-канал, то он находится в самых старших битах/последних байтах.

Диаграмма ниже отображает расположение пикселей в битностях меньше 8:

В битностях 16 и 32 пиксели обрабатываются машинными словами аналогичного размера (предполагается порядок байт little-endian), которым применяются битовые маски каналов.
Если индивидуальные битовые маски не заданы, то структура будет следующая.
При 16 бит на каждый канал отводится по 5 бит.
Синий располагается в младших битах (маска 001F₁₆), зелёный на позиции 5 (маска 03E0₁₆), красный: начиная с 10-го бита (маска 7C00₁₆), а старший оставшийся бит 15 не используется.
Если используется битность 32, то по умолчанию на каждый канал отводится уже по байту (8 бит).
Компоненты располагаются аналогично: синий в младших битах (маска 0000:00FF₁₆), зелёный начиная с бита 8 (маска 0000:FF00₁₆), красный начинается с бита 16 (маска 00FF:0000₁₆), а старший байт не используется (он используется в качестве альфа-канала только если прямо это показать)^[26].
Так как предполагается чтение в порядке байта little-endian, то если читать значения из памяти по-байтово, они будут располагать в таком же порядке (синий будет идти первым).

При битности 24 на каждый канал приходится по байту, а в битностях 48 и 64: по 16-битному машинному слову.
Во всех трёх случаях в памяти цветовые компоненты идут в порядке: синий, зелёный, красный.
В 64-битных BMP за цветами дополнительно следует 16-битный альфа-канал.
Если захотите 64-битный пиксель обработать цельным машинным словом, то в little-endian синий окажется в младших 16 битах, а альфа-канал: в старших.
Зелёный, соответственно, будет рядом к красным, а синий — рядом с альфа.
И можно заметить что в 24 битах формат пикселя соответствует структуре RGBTRIPLE из таблицы цветов.

RLE-кодирование[править | править код]

Применение RLE-кодирования компанией Microsoft документировано только для битностей 4 и 8.
При её использовании в BITMAPINFO поле Compression должно содержать 2 (BI_RLE4) при битности 4 или 1 (BI_RLE8) с восьмибитными пикселями.
Высота растра при этом должна быть указана положительным числом.

В формате Windows Bitmap RLE-кодирование можно сравнить с прорисовкой простыми командами.
Прорисовка начинается с левого нижнего пикселя (будьте внимательней: в растрах в целом привычней может быть верхний левый) и осуществляется вправо и вверх.
Пиксели за пределами размера растра не прорисовываются (об этом в документации не сказано, но GDI проявляет такое поведение).
Инструкции RLE позволяют прерывать прорисовку горизонтали, всего изображения, а также перемещать курсор прорисовки на другую позицию.
В результате некоторые пиксели могут оказаться не зарисованными.
Документация явно не предусматривает цвета для незарисованных пикселей, в результате чего трактовка может варьироваться: пропущенные пиксели либо остаются прозрачными, либо приобретают цвет с индексом 0.
Если делать первое допущение, то можно говорить о том, что 4- и 8-битные режимы благодаря RLE косвенно поддерживают прозрачность, но такое поведение не гарантировано.

Формирование изображения при RLE-кодировании осуществляется командами.
Каждая команда обязательно должна начинаться с чётного адреса (выравнена на 16-битную границу).
Существует пять команд, которые определяются парой байт:

Когда достигается правый край горизонтали, то на следующую перевод не производится.
Поэтому нужно специально вставлять команду окончания ряда.
И как видно из таблицы, набор команд не позволяют двигаться вниз или вернуться назад в горизонтали.
Поэтому можно прекращать прорисовку если будет достигнут верхний край.

Встраивание данных в форматах JPEG и PNG[править | править код]

Начиная с версий Windows 98/ME и 2000/XP системные функции позволяют хранить пиксели в форматах JPEG и PNG.
Про степень поддержки этих двух форматов системой ничего не известно.

Для встраивания JPEG или PNG нужно в BITMAPINFO обнулить поле BitCount, а в Compression указать значение 4 (BI_JPEG) или 5 (PI_PNG).
Значение поля SizeImage в данном случае будет равно размеру JPEG или PNG-файла, который встраивается на место пиксельных данных как есть.
Ширина же с высотой в заголовке указываются уже для раскодированного изображения.
Про знак поля Height именно для этого случая в документации напрямую ничего не сказано, но судя по всему нужно записывать отрицательное значение^[16].

Разрешение изображения[править | править код]

Для сопоставления безразмерных пикселей с материальными размерами используются поля XPelsPerMeter и YPelsPerMeter.
В этих полях целым числом указывается сколько в данном изображении пикселей приходится на один линейный метр, отдельно по горизонтали (XPelsPerMeter) и вертикали (YPelsPerMeter).
Microsoft объявила эти два поля числовым типом со знаком, но в документации ничего не сказано про отрицательные значения.
Про значение ноль также ничего не сказано, но логичней его принимать за неопределённое разрешение, когда оно неизвестно или не имеет значения.

Разрешение часто указывается с привязкой не к метрическим размерностям, а в точках на дюйм (DPI/PPI).
Для перевода туда и обратно дюйм принимается равным 25,4 мм (английский дюйм).
Математические формулы для перевода пиксели/дюйм (PPI) в пиксели/метр (PPM) и наоборот:

Если интересует точный целочисленный перевод, то выходят следующие выражения:

PPM = (PPI * 5000 + 64) / 127

PPI = (PPM * 127 + 2500) / 5000

После них округление будет произведено к ближайшему целому.
Если хотите округление вниз, то не прибавляйте половину делителя.
Если хотите вверх, то прибавляйте уменьшенный на единицу делитель.

Ниже представлены заранее вычисленные значения PPM для некоторых PPI/DPI:

• 96 ppi ≈ 3780 ppm (для мониторов у Microsoft)
• 72 ppi ≈ 2835 ppm (Apple для мониторов)
• 150 dpi ≈ 5906 ppm
• 300 dpi ≈ 11811 ppm
• 600 dpi ≈ 23622 ppm

Цветовое пространство[править | править код]

В информационных полях основным полем задающим цветовое пространство является поле CSType.
Допустимые его значения приведены в таблице ниже:

Microsoft объявила значения констант не числовыми значениями, а текстовыми из четырёх символов^[29].
В данном случае коды символов формируют байты 32-битного значения (ASCII-код самого правого символа является младшим байтом, код самого левого — старшим).
При просмотре двоичного содержимого файла в виде текста такие значения в кодировке ASCII будут отображаться задом-наперёд (например, «KNIL», а не «LINK»).

Конечные точки и значение гаммы[править | править код]

Формат Windows Bitmap позволяет производить цветокоррекцию указанием конечных точек для красного, зелёного и синего цветов, а также значений гаммы.
Для этого поле CSType должно содержать значение 0 (LCS_CALIBRATED_RGB).
Корректирующие же значения записываются в поля Endpoints, GammaRed, GammaGreen и GammaBlue (при других значениях CSType эти четыре поля игнорируются).

36-байтное поле EndPoints является структурой CIEXYZTRIPLE, которая состоит из трёх полей ciexyzRed (конечная точка красного), ciexyzGreen (точка зелёного) и ciexyzBlue (синяя).
Эти три поля в свою очередь также являются структурами CIEXYZ с тремя полями ciexyzX, ciexyzY и ciexyzZ типа FXPT2DOT30.
PXPT2DOT30 — это 32-битное беззнаковое число с фиксированной запятой, у которого 2 старших бита отводятся под целую часть, а 30 младших — под дробную.

Значение гаммы записывается в соответствующие поля для каждого цветового канала отдельно: GammaRed (красный), GammaGreen (зелёный) и GammaBlue (синий).
В объявлении информационных структур Microsoft указала у данных полей тип DWORD.
В это же время в файле WinGDI.h есть более подходящее объявление типа FXPT16DOT16 (на основе типа long), который представляет собой 32-битное беззнаковое число с дробной частью в младших 16 битах и целой — в 16 старших.
Следует отметить, что в MSDN на страницах про структуры BITMAPV4HEADER и BITMAPV5HEADER только это и сказано.
В статье же про структуру LOGCOLORSPACE сказано, что у неё в аналогичных полях должны быть обнулены старший и младший байт (по сути вместо формата 16.16 используется формат 8.8, который располагается в середине 32-битной ячейки)^[30].

Ниже приведены значения указанных выше четырёх полей в соответствии с цветовым пространством sRGB^[31]:

Цветовой профиль[править | править код]

В файле BMP при необходимости может быть указан цветовой профиль как непосредственным включением, так и ссылкой на другой файл.
Профили появились в пятой версии BMP, и пока только здесь есть специальные для них поля.
Поддерживаются же цветовые профили только в формате ICC^[33][34].

При использовании цветовых профилей в первую очередь нужно указать следующие значения поля CSType:

• 4C494E4B₁₆ (PROFILE_LINKED) — если используется профиль в другом файле.
• 4D424544₁₆ (PROFILE_EMBEDDED) — если профиль непосредственно встраивается в BMP.

В любом случае в поле ProfileData указывается смещение профиля в байтах от начала блока BITMAPINFO.
Если профиль встроенный, то в ProfileSize нужно указать его размер в байтах (если он подключаемый, то это поле должно быть обнулено).
Независимо от варианта, Microsoft рекомендует размещать профиль при хранении в файле за пиксельными данными, а в оперативной памяти при взаимодействии с WinAPI-функциями: сразу за заголовком^[35].

Формат ICC в своём заголовке использует преимущественно 32-битные или кратные этому размеру ячейки^[36].
Исходя из этого, если профиль непосредственно включается в BMP, то в оперативной памяти его рекомендуется хранить по кратному четырём байтам адресу.

Когда профиль внешний, то вместо его содержимого в BMP размещается текстовая строка с путём к файлу.
Он обязательно должен быть в однобайтовой кодировке Windows 1252 (стандартная кодировка для западноевропейских языков) и заканчиваться нулевым байтом.
Про разделители компонентов пути в документации ничего не сказано и поэтому скорее всего можно использовать как левые слэши «\», так и «правые» «/».
Путь же может быть как относительным, так и полным и сетевым^[35].
И так как в указании пути используется однобайтовая кодировка, то эту строку в оперативной памяти выравнивать не обязательно.

Предпочтения при рендеринге[править | править код]

Предпочтения при рендеринге (англ. rendering intents) были введены Международным концорциумом по цвету (International Color Consortium) и определяют приоритеты в случае когда при переходе из цветового подпространства, поддерживаемого одним устройством (англ. gamut), в подпространство другого, в изображении использованы цвета, отсутствующие в целевом.
Также есть определение от ICC, которое определяется предпочтения при рендеринге как стиль сопоставления цветовых значений из одного описателя изображения в другое (оригинал на английском языке: «style of mapping colour values from one image description to another»)^[37].
Корпорация Microsoft включила в формат BMP специальное поле Intent, которое может принимать значения полностью по спецификации ICC.
Поэтому за подробной информации обращайтесь к документации консорциума, последнюю версию которой можно скачать с сайта color.org^[38].
У Microsoft же эти предпочтения коротко описаны в статье «Rendering Intents» на MSDN.

Предпочтение указывается в поле Intent блока BITMAPINFO и доступны только с 5-й версией информационных полей.
Значения же могут быть следующими:

Microsoft для данной характеристики объявила как минимум три набора констант, которые отличаются своими значениями и используются в разных местах^[39].
Здесь они приведены на случай если вам нужно будет быстро их сопоставить.
Значения констант с префиксом «INTENT_» полностью совпадают с теми значениями, которые используются в файлах профилей ICC^[40].
Константы с префиксом «DMICM_» объявлены в файле WinGDI.h для структуры DEVMODE.
Константы «LCS_GM_», которые используются в BMP, объявлены там же и предназначены в первую очередь для структуры LOGCOLORSPACE.
Есть также названия для свойств принтеров.
Они аналогичны тем, что в колонке «Название Microsoft», но с «Graphics» и «Pictures».

За значение по умолчанию, которое в первую очередь подходит для фотографий и картинок, можно принимать 4 (LCS_GM_IMAGES).
В таком качестве его рекомендует как Microsoft^[41], так и ICC^[42].

Следующая программа открывает 24 битный BMP файл в окне XWindow, глубина цвета должна составлять 32 бита, на меньшей цветопередаче не работает, так как это усложняет пример:

/* Компилируется строкой: cc -o xtest xtest.c -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lm  */
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>
#include <X11/keysym.h>
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <math.h>
#include "bitmap.h" /* Здесь определения заголовков BMP как было описано выше в этой статье (структуры должны быть упакованы на 2 байта!) */

static XImage *CreateImageFromBuffer(Display*, unsigned char *, int, int);

main(int argc, char *argv[])
{
    Display *dis;
    Window win;/* Наше окно */
    XEvent event;/* События */
    GC gc;/* Графический контекст */

    XImage *image;
    int  n, width, height, fd, size;
    unsigned char *data;
    BITMAPFILEHEADER bmp;
    BITMAPINFOHEADER inf;
    char* buf;

    if (argc < 2) {
	perror("use: xtest file.bmp\n");
	exit(1);
    }

  if ((fd = open(argv[1], O_RDONLY)) == -1) {
        printf("Error open bitmap\n");
        exit(1);
    }

  read(fd, &bmp, sizeof(BITMAPFILEHEADER));
  read(fd, &inf,sizeof(BITMAPINFOHEADER));

  width = inf.biWidth;
  height = inf.biHeight;

    if ((dis = XOpenDisplay(getenv("DISPLAY"))) == NULL) {
	printf("Can't connect X server:%s\n", strerror(errno));
	exit(1);
    }

    win = XCreateSimpleWindow(dis, RootWindow(dis, DefaultScreen(dis)), 0, 0, width, height, 5,
                   BlackPixel(dis, DefaultScreen(dis)), WhitePixel(dis, DefaultScreen(dis)));

    XSetStandardProperties(dis, win, argv[1], argv[0], None, argv, argc, NULL);
    gc = DefaultGC(dis, DefaultScreen(dis));

 /* Иногда в структуре это место не заполнено */
    if(inf.biSizeImage == 0)  {
    /* Вычислим размер */
     size = width * 3 + width % 4;
     size = size * height;
    } else {
      size = inf.biSizeImage;
     }
    
    buf = malloc(size);
    if(buf == NULL) {
	perror("malloc");
	exit(1);
    }
    printf("size =%d байтов выделено\n", size);

     /* Сместимся на начало самого изображения */
    lseek(fd, bmp.bfOffBits, SEEK_SET);

    /* Читаем в буфер */
    n = read(fd, buf, size);
    printf("size =%d байт прочитано\n", n);

   image = CreateImageFromBuffer(dis, buf, width, height);

   /* Удалим буфер - он нам больше не нужен */
   free(buf);

    XMapWindow(dis, win);
    XSelectInput(dis, win, ExposureMask | KeyPressMask);
    while (1) {
	XNextEvent(dis, &event);
	if (event.xany.window == win) {
	    switch (event.type) {
	    case Expose:
		XPutImage(dis, win, gc, image, 0, 0, 0, 0, image->width, image->height);
		break;

	    case KeyPress:
		if (XLookupKeysym(&event.xkey, 0) == XK_q) {
		    XDestroyImage(image);
		    XCloseDisplay(dis);
    	    	    close(fd);
		    exit(EXIT_SUCCESS);
		}
		break;

	    default:
		break;
	    }
	}
    }
}

/* Создает Ximage из файла BMP, так как изображение BMP хранится первернутым
 * и зеркальным-в цикле это исправляется */ 
XImage *CreateImageFromBuffer(Display * dis, unsigned char *buf, int width,  int height)
{
    int depth, screen;
    XImage *img = NULL;
    int i, j;
    int numBmpBytes;
    size_t numImgBytes;
    int32_t *imgBuf;
    int ind = 0;
    int line;
    int temp;
    int ih, iw; /* Номера строки и столбца для отражения  */
    int new_ind; /* Новый индекс */

    screen = DefaultScreen(dis);
    depth = DefaultDepth(dis, screen);
    temp = width * 3;
    line = temp + width % 4; /* Длина строки с учетом выравнивания */
    numImgBytes = (4 * (width * height));
    imgBuf = malloc(numImgBytes);

    /* Размер, отведенный на BMP в файле с учетом выравнивания */
    numBmpBytes = line * height;
    for (i = 0; i < numBmpBytes; i++) {
	unsigned int r, g, b;

	/* Пропускаем padding */
	if (i >= temp && (i % line) >= temp)
	    continue;
	
	b = buf[i];
	i++;
	g = buf[i];
	i++;
	r = buf[i];

	
	/* Вычисляем новый индекс для отражения по вертикали */
	iw = ind % width;
	ih = ind / width;
	new_ind = iw + (height - ih - 1) * width;
	
	imgBuf[new_ind] = (r | g << 8 | b << 16) << 8;
	ind++;
    }

    img = XCreateImage(dis, CopyFromParent, depth, ZPixmap, 0, (char *) imgBuf, width, height, 32, 0);
    XInitImage(img);

    /* Порядок битов и байтов на PC должен быть таким */
    img->byte_order = MSBFirst;

    img->bitmap_bit_order = MSBFirst;
    return img;
}

• ICO (формат файлов) — родственный формат от Microsoft для хранения значков и курсоров мыши.

Microsoft (MSDN и SDK)[править | править код]

Microsoft Windows SDK — комплект для разработчиков, который включает в себя справку и включаемые файлы на языке C++.
По теме данной статьи актуальны файлы WinGDI.h и Icm.h, из которых были взяты в первую очередь значения констант.
Последнюю версию данного комплекта можно бесплатно скачать с сайта Microsoft (в данной статье использовались версии 6.0 и 7.1).

У Microsoft нет отдельной специальной документации именно по формату BMP.
Но его структуры и прочие элементы описаны в рамках подсистемы GDI.
Это описание есть в справке, которая включается в вышеупомянутое SDK, а также на MSDN.
Причём в последнем она присутствует для разных платформ и независимо в справке по Visual Studio.
В большинстве случаев там представлена идентичная информация, но в некоторых местах может быть немного больше фактов (например, в справке SDK больше информации о поддержке Windows).

Основная информацию находится в справке по GDI, которая относится к платформам Windows 9x и NT.
Ссылки на страницы этого раздела, которые относятся только к формату, а не к WinAPI-функциям работы с ним:

• «Bitmap Classifications» — описание аппаратно-зависимых и аппаратно-независимых битмапов.
• «Bitmap Storage» — общее описание формата файла BMP.
• «Bitmap Header Types» — обзор по версиям заголовков BMP.
• «Bitmap Compression» — описание RLE-кодирования.
• «Bitmap Structures» — раздел с описаниями структур с полями. Для удобства прямые ссылки на ключевые:
  • BITMAPFILEHEADER
  • BITMAPCOREHEADER
  • BITMAPINFOHEADER
  • BITMAPV4HEADER
  • BITMAPV5HEADER

У платформ Windows Compact 2013 (CE 6.0) и Mobile 6.5 есть только описания трёх структур, но применительно к данным платформам:

• BITMAPFILEHEADER
• BITMAPCOREHEADER
• BITMAPINFOHEADER

Ссылки на другие страницы из MSDN, которые относятся к формату BMP:

• «Image Pixel Format Constants» — константы форматов пикселей GDI+.
• «PixelFormat Enumeration» — описание значений перечисляемого типа PixelFormat для .NET Framework 1.1 (самая ранняя версия).
• «Using Structures in WCS 1.0» — про используемые в управлении цветом в Windows структуры.
• «Rendering Intents» — описание предпочтений при рендеринге.

Другие[править | править код]

В спецификации ICC по управлению цветом можно найти информацию о цветовых профилях (в том числе о формате файлов ICC), а также о предпочтениях рендеринга.
Данную спецификацию можно скачать с официального сайта концорциума color.org.
В момент написания статьи последней версией была 4.3 (декабрь 2010).
Прямая ссылки на PDF с сайта ICC:

• Specification ICC.1:2010 (Profile version 4.3.0.0) «Image technology colour management — Architecture, profile format, and data structure».
• Errata к спецификации (обнаруженные ошибки и опечатки; опубликованы 24 сентября 2013 года).

What is the File Format BMP?

BMP stands for «Bitmap Image File,» and is a type of image file format used to store digital images. BMP files are widely supported and can be viewed on most computers, as well as on many mobile devices and web browsers.

The common format was originally developed by Microsoft and is still in widespread use today. It is a relatively simple file format that stores a bitmap image as a grid of pixels, where each pixel is represented by a color value. BMP files can be uncompressed or compressed using a lossless compression algorithm called RLE (Run Length Encoding).

One of the main advantages of the BMP format is that it is widely supported and can be opened by most image editing software and web browsers. However, BMP files are generally larger in size than other image file formats, such as JPEG and PNG, which can make them less suitable for use in situations where file size is a concern, such as when storing large numbers of images or when uploading images to the internet.

In addition to standard BMP files, there are also several variations of the BMP file format, including:

• DIB (Device Independent Bitmap): This is a version of the BMP file format that includes additional metadata, such as the color depth and resolution of the image.
• RLE: This is a version of the BMP file format that uses RLE compression to reduce the image size.
• OS/2 BMP: This is a version of the BMP file format that was developed for use on the OS/2 operating system.

Overall, the BMP file format is a simple and widely supported image file format that is suitable for a wide range of applications. It is a good choice for storing images that need to be viewed on a variety of devices and platforms, but may not be the most efficient choice when file size is a concern.

BMP files at a glance#

• BMP files can store images with a range of color depths, including 1-bit (black and white), 4-bit (16 colors), 8-bit (256 colors), 24-bit (true color), and 32-bit (true color with alpha channel).
• The format includes a header that contains metadata about the image, such as the image width and height, the color depth, and the number of bytes in the bitmap image data.
• The pixel data stored in the bmp file is organized in rows from bottom to top, with each row being padded to a multiple of 4 bytes. This means that the actual size of a data block is often larger than the size of the raw data containing pixels itself.
• The format does not support transparent pixels, but a variation called the Alpha Bitmap (ABM) file format can be used to store images with an alpha channel for transparency.
• BMP files can be edited using image editing software, such as Photoshop or GIMP, or using a hex editor if more advanced changes to the raw bitmap data are needed.
• BMP files are often used in Microsoft Windows operating systems and are the default image format for saving screen captures in Windows.
• While the format is not as widely used as other image formats, such as JPEG or PNG, it is still a common choice for storing simple images and is supported by most image editing software and web browsers.

The start of the file contains a header structure. This structure contains metadata about the image, such as the size, color depth, and resolution of the image. All integer values are stored in little-endian format Here is an example of the structure of a BMP file header:

typedef struct tagBITMAPFILEHEADER {
WORD bfType;
DWORD bfSize;
WORD bfReserved1;
WORD bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;

The BITMAPFILEHEADER structure contains the following fields:

• bfType: This field specifies the type of the BMP file in the first 2 bytes of the BMP. It should be set to the value «BM» to indicate that the file is a bitmap file.
• bfSize: This field specifies the size of the BMP in bytes.
• bfReserved1 and bfReserved2: These fields are reserved for future use and should be set to 0.
• bfOffBits: This field specifies the offset from the beginning of the file to the start of the pixel data.

In addition to the BITMAPFILEHEADER structure, a BMP file also includes a BITMAPINFOHEADER structure, which contains additional metadata about the image, such as the image height and width, the number of planes, and the color depth.

Here is an example of the structure of a BITMAPINFOHEADER:

typedef struct tagBITMAPINFOHEADER {
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;

The BITMAPINFOHEADER structure contains the following fields:

• biSize: This field specifies the size of the BITMAPINFOHEADER structure in bytes.
• biWidth and biHeight: These fields specify the width and height of the image in pixels.
• biPlanes: This field specifies the number of color planes in the image. It should be set to 1.
• biBitCount: This field specifies the color depth of the image, in bits per pixel.
• biCompression: This field specifies the type of compression used in the image, if any.
• biSizeImage: This field specifies the size of the image data in bytes.
• biXPelsPerMeter and biYPelsPerMeter: These fields specify the horizontal and vertical resolution of the image, in pixels per meter.
• biClrUsed: This field specifies the number of colors in the image’s color table.
• biClrImportant: This field specifies the number of important colors in the image’s color table.

After the BITMAPINFOHEADER structure may follow a color table and the pixel data itself. The color table is a list of colors that are used in the image, and is present if the image has a color depth of less than 24 bits per pixel.

Pixel format of the image data in BMP files#

In BMP files, the pixel data is stored as a grid of pixels, with each pixel being represented by a color value. The pixel data is stored in rows from bottom to top, with each row being padded to a multiple of 4 bytes. This means that the actual size of a BMP file may be larger than the size of the image data itself.

The format supports a range of color depths, including 1-bit (black and white), 4-bit (16 colors), 8-bit (256 colors), 24-bit (true color), and 32-bit (true color with alpha channel). The color depth of a BMP file determines the number of bits used to represent the color of each pixel, and therefore the number of colors that can be displayed in the image. For example, a BMP file with a color depth of 8 bits per pixel can display up to 256 different colors.

In addition to the pixel data, BMP files may also include a color table, which is a list of colors used in the image. The color table is present if the image has a color depth of less than 24 bits per pixel. The color table is used to map the pixel values in the image data to actual colors.

Run Length Encoding#

In the BMP file format, run length encoding (RLE) is a lossless compression algorithm that is used to reduce the size of the file. RLE works by replacing consecutive runs of the same data value with a single value and a count of the number of times that value appears. For example, if the bitmap data contained the following sequence of pixel values:

0 0 0 0 1 1 1 1 1 2 2 2 0 0 0 0

Using RLE compression, this sequence could be represented as:

4 0 9 1 6 2 4 0

The first number (4) indicates the number of times the value 0 appears, and the second number (9) indicates the number of times the value 1 appears, and so on. By using RLE compression, the size of the image file can be reduced, which can be beneficial in situations where file size is a concern.

RLE compression is a simple and effective compression algorithm, but it is not as efficient as other algorithms, such as JPEG or PNG. As a result, BMP files that use RLE compression may still be larger in size than other image file formats.

How to Identify a BMP File#

There are several ways to identify a bitmap file:

1. File extension: BMP files are typically identified by their file extension, which is «.bmp». If a file has this extension, it is likely it contains a bitmap.
2. File header: As explained above a specific file header can be used to identify them. The first two bytes of the BMP file contain the characters «B» and «M».
3. File content: BMP image files are composed of a series of blocks of data, including the file header, image metadata, and image data. By examining the content of a file, it is possible to determine whether it is a BMP file or not. For example, the file length can be found in the `bfSize` field of the Bitmap File Header.
4. File utilities: There are various file utilities and tools that can be used to identify the file type. For example, the «file» command on Linux systems can be used to identify the type of a file based on its content.

It is also worth noting that BMP images can be disguised by changing their file extension, so simply checking the file extension may not be sufficient to determine whether a file is a BMP file or not. In these cases, examining the file header or the file content may be necessary to identify the file correctly.

Versions of the BMP File Format#

There are several versions of BMP. The original version of the bitmap file format, also known as the «Windows BMP» or «Device-Independent Bitmap (DIB)» format, was developed by Microsoft and is still in widespread use today. This version is supported by most image editing software and web browsers.

In addition to the original format, there are also several variations of the it, including:

• OS/2 BMP: This is a version of the file format that was developed for use on the OS/2 operating system. It is similar to the original format, but has some differences in the file header and color table format.
• Alpha Bitmap (ABM): This is a version of the format that includes support for an alpha channel, which allows for transparency in the image.
• Windows V3 BMP: This is a newer version of the format that includes support for additional metadata and color spaces, such as the sRGB color space.
• Windows V4 BMP: This is an even newer version of the format that includes support for additional metadata and color spaces, such as the scRGB color space.

Overall, there are several variations of the this format, but the original version is the most widely supported and is the one that is most commonly used.

How can a BMP file be opened?#

BMP files can be opened using most image editing software, as well as many web browsers and operating system image viewers. Some common applications that can be used to open BMP files include:

• Microsoft Paint: This is a basic image editing application that is included with most versions of the Windows operating system. It can be used to view and edit BMP files.
• Adobe Photoshop: This is a professional image editing application that can be used to view and edit BMP files, as well as other image file formats.
• GIMP: This is a free, open-source image editing application that can be used to edit and display the image, as well as other image file formats.
• Web browsers: Most web browsers can be used to open a BMP file by simply dragging the file into the browser window or by opening the file using the browser’s «File» menu.
• Operating system image viewers: Most operating systems include a default image viewer that can be used to view BMP files. For example, on Windows systems, the Photos app can be used to view BMP files, and on macOS systems, the Preview app can be used.

In addition to these applications, there are also many other programs that can be used to open BMP files, including specialized image viewing and editing software, as well as hex editors, which can be used to view and edit the raw data of the file.

Synalyze It! and Hexinator allow to display the data fields of the `BITMAPFILEHEADER` and `BITMAPINFOHEADER` structures directly.

Картинка с сайта: www.synalysis.blog

References#

1. Wikipedia has detailed information about the image format in this article. It explains many details about the different structures and data fields.
2. Microsoft’s specifications and explanations of bitmaps used by Windows: https://learn.microsoft.com/en-gb/windows/win32/gdi/about-bitmaps