Просмотр кода страницы BMP

{{другие значения термина|Bitmap|Bitmap}}
{{значения}}
{{Файловый формат
| name = Windows Bitmap
| type code =
| uniform type = com.microsoft.bmp
| magic =
| genre = [[растровая графика]]
| container for =
| contained by =
| extended from =
| extended to =
| standard =
}}
'''{{ltn|BMP}}''' (от {{lang-en|[[Битовая карта|'''B'''it'''m'''ap]] '''P'''icture}}) — формат хранения [[Растровая графика|растровых изображений]], разработанный компанией [[Microsoft]].
Файлы формата BMP могут иметь расширения <tt>.bmp</tt>, <tt>.dib</tt> и <tt>.rle</tt>.

Формат BMP пользуется широкой поддержкой среди множества программных продуктов, так как он интегрирован в операционные системы [[Windows]] и [[OS/2]]. Кроме того, данные в этом формате могут быть включены в двоичные файлы ресурсов ([[RES]]) и PE-файлы.

Формат BMP предназначен для хранения однослойных растровых изображений. В разных файлах каждый пиксель может иметь различное количество бит, что определяет глубину цвета. [[Microsoft]] предлагает следующие битностные глубины: 1, 2, 4, 8, 16, 24, 32, 48 и 64 бита.

При битностях 8 и ниже цвет кодируется индексом из таблицы цветов (палитры), а при более высоких битностях задается непосредственно значением. В любом случае цвет определяется в цветовой модели [[RGB]], как при указании в пикселе, так и в таблице цветов. Однако в битностях 16 и 32 можно получить оттенки серого с глубиной до 16 и 32 бит соответственно. Частичная прозрачность реализуется с помощью альфа-канала, доступного в битностях от 16 бит и выше.

Пиксели в BMP-файлах обычно организованы в виде двумерного массива. Для битностей 4 и 8 применяется сжатие по алгоритму [[RLE]], что позволяет уменьшить размер файла. Формат BMP также поддерживает встраивание данных в форматах [[JPEG]] и [[PNG]]. Однако последнее чаще используется не для компактного хранения, а для преодоления ограничений архитектуры [[GDI]], которая не поддерживает работу с изображениями, отличными от BMP.

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

== {{якорь|DIPnDDB}}DIB и DDB ==
При использовании формата DIB ({{lang-en|Device Independent Bitmap}}, аппаратно-независимый растр) программист может получить доступ ко всем элементам структур, описывающих изображение, при помощи обычного указателя.
Но эти данные не используются для непосредственного управления экраном, так как они всегда хранятся в системной памяти, а не в специализированной [[Видеопамять|видеопамяти]].
Формат [[Пиксель|пикселя]] в оперативной памяти может отличаться от того формата, который должен заноситься в видеопамять для индикации точки такого же цвета.
Например, в DIB-формате может использоваться 24 бита для задания пикселя, а графический адаптер в этот момент может работать в режиме [[HiColor]] с цветовой глубиной 16 бит.
При этом ярко-красная точка в аппаратно-независимом формате будет задаваться тремя байтами 0000FF<sub>16</sub>, а в видеопамяти — словом F800<sub>16</sub>.
При копировании картинки на экран система будет тратить дополнительное время на преобразование кодов цвета из 24-битного формата в формат [[Кадровый буфер|видеобуфера]].

Формат DDB ({{lang-en|Device Dependent Bitmap}}, аппаратно-зависимый растр) всегда содержит цветовые коды, совпадающие с кодами видеобуфера, но храниться он может как в системной, так и в видеопамяти.
В обоих случаях он содержит только коды цвета в том формате, который обеспечит пересылку изображения из [[Оперативная память|ОЗУ]] в видеопамять при помощи простого копирования<ref>Евченко А. И. OpenGL и DirectX. Программирование графики (Для профессионалов), 2006 г. С. 183.</ref>.

== Внутреннее строение ==
{| style="float:right"
|[[Файл:BMPfileFormat.svg|thumb|320px|Структура файла BMP]]
|}
Официальную информацию по формату BMP можно найти в [[Microsoft Developer Network|MSDN]] или справке Microsoft Windows SDK (может идти в комплекте с некоторыми IDE).
В файле WinGDI.h от компании Microsoft есть все объявления на языке [[C++]], которые касаются данного формата.
В данную статью же не были включены объявления типов, так как от этого она может быть слишком громоздкой.
К тому же официальные объявления некоторые разработчики могут посчитать неудобными и поэтому их востребованность сомнительна.
Если вам потребуются оригинальные имена констант, структур, типов и их полей, то они все есть в тексте данной статьи.

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

В данной статье для указания типов используются имена типов [[Windows API|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 состоят из трёх основных блоков различного размера:

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

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

В оперативной памяти (например, при взаимодействии с WinAPI-функциями GDI) из заголовков исключается структура BITMAPFILEHEADER.
При этом Microsoft рекомендует располагать цветовой профиль сразу за заголовками в едином блоке<ref>См. раздел «Remarks» статьи «[http://msdn.microsoft.com/en-us/library/windows/desktop/dd183381%28v=vs.85%29.aspx BITMAPV5HEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/windows/desktop/dd183381%28v=vs.85%29.aspx |date=20140321154459 }}» на MSDN.</ref>.
Пиксельные данные могут иметь произвольное расположение в памяти и их адрес указывается в параметрах процедур.
В любом случае рекомендуется в памяти все блоки содержать по адресам кратным четырём: в заголовках присутствуют 32-битные ячейки, а к пиксельным данным такое требование указано в документации<ref name="msdn-bitmapinfo">См. раздел «Remarks» в статье «[http://msdn.microsoft.com/en-us/library/windows/desktop/dd183375%28v=vs.85%29.aspx BITMAPINFO structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/windows/desktop/dd183375%28v=vs.85%29.aspx |date=20140227094259 }}» на MSDN.</ref>.
Это требование справедливо только для оперативной памяти: при хранении в файле его придерживаться не обязательно.

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

{| class="standard" style="text-align:left"
! style="text-align: center" | Поз.<br><small>(hex)</small>
! style="text-align: center" | Размер<br> <small>(байты)</small>
! Имя
! Тип WinAPI
! Описание
|-
| style="text-align: center" | <tt>00</tt>
| style="text-align: center" | 2
| bfType
| WORD
| Отметка для отличия формата от других (сигнатура формата). Может содержать единственное значение 4D42<sub>16</sub>/424D<sub>16</sub> (little-endian/big-endian).
|-
| style="text-align: center" | <tt>02</tt>
| style="text-align: center" | 4
| bfSize
| DWORD
| Размер файла в байтах.
|-
| style="text-align: center" | <tt>06</tt>
| style="text-align: center" | 2
| bfReserved1
| WORD
| rowspan="2"| Зарезервированы и должны содержать ноль.
|-
| style="text-align: center" | <tt>08</tt>
| style="text-align: center" | 2
| bfReserved2
| WORD
|-
| style="text-align: center" | <tt>0A</tt>
| style="text-align: center" | 4
| bfOffBits
| DWORD
| Положение пиксельных данных относительно начала данной структуры (в байтах).
|}

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

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

Блок BITMAPINFO состоит из трёх частей:
# Структура с информационными полями.
# [[#Маски каналов|Битовые маски для извлечения значений цветовых каналов]] (присутствуют не всегда).
# [[#Таблица цветов|Таблица цветов]] (присутствует не всегда).

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

В момент написания данной статьи структура с информационными полями имела четыре версии<ref name="msdn-bitmap-header-types">См. статью «[http://msdn.microsoft.com/en-us/library/dd183386%28v=vs.85%29.aspx Bitmap Header Types] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183386%28v=vs.85%29.aspx |date=20140922041510 }}» в MSDN.</ref>: CORE, 3, 4 и 5 (обозначения версий приведены условные в рамках данной статьи для краткости).
Для каждой версии Microsoft объявила четыре отдельные структуры с разными именами полей.
В данной статье при упоминании поля, которое присутствует в нескольких структурах, берётся общая для всех структур часть в конце имени (например, BitCount вместо bcBitCount, biBitCount, bV4BitCount или bV5BitCount).
Версию структуры можно определить по первой 32-битной ячейке (WinAPI-тип DWORD), которая содержит её размер в байтах (беззнаковым целым).
Версия CORE отличается от всех своей компактностью и использованием исключительно 16-битных беззнаковых полей.
Остальные три содержат идентичные ячейки, к которым в каждой новой версии добавлялись новые.

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

{| class="standard" style="text-align:left"
! style="text-align: center" | Версия
! style="text-align: center" | Размер<br> <small>(байты)</small>
! Имя структуры
! Версия Windows [[Windows 9x|9x]]/[[Windows NT|NT]]<ref>Информация о версиях взята из справки по Microsoft Windows SDK, идущая в комплекте с Microsoft Visual Studio 2008 и Embarcadero RAD Studio 2010 (раздел «Requirements» в статьях про данные структуры).</ref>
! Версия Windows [[Windows CE|CE]]/[[Windows Mobile|Mobile]]<ref>См. разделы «Requirements» в статьях «[http://msdn.microsoft.com/en-us/library/aa931790.aspx BITMAPCOREHEADER] {{Wayback|url=http://msdn.microsoft.com/en-us/library/aa931790.aspx |date=20140916120950 }}» и «[http://msdn.microsoft.com/en-us/library/aa930622.aspx BITMAPINFOHEADER] {{Wayback|url=http://msdn.microsoft.com/en-us/library/aa930622.aspx |date=20140419203951 }}» применительно к Windows Mobile 6.5 на MSDN.</ref>
! Примечания
|-
| style="text-align: center" | CORE
| style="text-align: center" | 12
| BITMAPCOREHEADER
| 95/NT 3.1 и старше
| CE 2.0/Mobile 5.0 и старше
| Содержит только ширину, высоту и битность растра.
|-
| style="text-align: center" | 3
| style="text-align: center" | 40
| BITMAPINFOHEADER
| 95/NT 3.1 и старше
| CE 1.0/Mobile 5.0 и старше
| Содержит ширину, высоту и битность растра, а также формат пикселей, информацию о цветовой таблице и разрешении.
|-
| style="text-align: center" | 4
| style="text-align: center" | 108
| BITMAPV4HEADER
| 95/NT 4.0 и старше
| не поддерживается
| Отдельно выделены маски каналов, добавлена информация о цветовом пространстве и гамме.
|-
| style="text-align: center" | 5
| style="text-align: center" | 124
| BITMAPV5HEADER
| 98/2000 и старше
| не поддерживается
| Добавлено указание предпочтительной стратегии отображения и поддержка профилей ICC.
|}

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

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

{| class="standard" style="text-align: left"
! style="text-align: center" | Позиция<br>в файле<br><small>(hex)</small>
! style="text-align: center" | Позиция<br>в структуре<br><small>(hex)</small>
! style="text-align: center" | Размер<br> <small>(байты)</small>
! Имя
! Тип WinAPI
! Описание
|-
| style="text-align: center" | <tt>0E</tt>
| style="text-align: center" | <tt>00</tt>
| style="text-align: center" | 4
| bcSize
| DWORD
| Размер данной структуры в байтах, указывающий также на версию структуры (здесь должно быть значение 12).
|-
| style="text-align: center" | <tt>12</tt>
| style="text-align: center" | <tt>04</tt>
| style="text-align: center" | 2
| bcWidth
| WORD
| rowspan="2" | Ширина (bcWidth) и высота (bcHeight) растра в пикселях. Указываются целым числом без знака. Значение 0 не документировано.
|-
| style="text-align: center" | <tt>14</tt>
| style="text-align: center" | <tt>06</tt>
| style="text-align: center" | 2
| bcHeight
| WORD
|-
| style="text-align: center" | <tt>16</tt>
| style="text-align: center" | <tt>08</tt>
| style="text-align: center" | 2
| bcPlanes
| WORD
| В BMP допустимо только значение 1. Это поле используется в значках и курсорах Windows.
|-
| style="text-align: center" | <tt>18</tt>
| style="text-align: center" | <tt>0A</tt>
| style="text-align: center" | 2
| bcBitCount
| WORD
| Количество бит на пиксель (список поддерживаемых смотрите в отдельном разделе ниже).
|}

==== 32-битные информационные поля (версии 3, 4 и 5) ====
В таблице ниже поля представлены обзорно.
Подробную информацию вы можете найти в разделах далее.

{| class="standard" style="text-align: left"
! style="text-align: center" | Позиция<br>в файле<br><small>(hex)</small>
! style="text-align: center" | Позиция<br>в структуре<br><small>(hex)</small>
! style="text-align: center" | Размер<br> <small>(байты)</small>
! Имя<br><small>(версии 3/4/5)</small>
! Тип WinAPI
! Описание
|-
| style="text-align: center" | <tt>0E</tt>
| style="text-align: center" | <tt>00</tt>
| style="text-align: center" | 4
| biSize<br>bV4Size<br>bV5Size
| DWORD
| Размер данной структуры в байтах, указывающий также на версию структуры (см. таблицу версий выше).
|-
| style="text-align: center" | <tt>12</tt>
| style="text-align: center" | <tt>04</tt>
| style="text-align: center" | 4
| biWidth<br>bV4Width<br>bV5Width
| LONG
| Ширина растра в пикселях. Указывается целым числом со знаком. Ноль и отрицательные не документированы.
|-
| style="text-align: center" | <tt>16</tt>
| style="text-align: center" | <tt>08</tt>
| style="text-align: center" | 4
| biHeight<br>bV4Height<br>bV5Height
| LONG
| Целое число со знаком, содержащее два параметра: высота растра в пикселях (абсолютное значение числа) и порядок следования строк в двумерных массивах (знак числа). Нулевое значение не документировано.
|-
| style="text-align: center" | <tt>1A</tt>
| style="text-align: center" | <tt>0C</tt>
| style="text-align: center" | 2
| biPlanes<br>bV4Planes<br>bV5Planes
| WORD
| В BMP допустимо только значение 1. Это поле используется в значках и курсорах Windows.
|-
| style="text-align: center" | <tt>1C</tt>
| style="text-align: center" | <tt>0E</tt>
| style="text-align: center" | 2
| biBitCount<br>bV4BitCount<br>bV5BitCount
| WORD
| Количество бит на пиксель (список поддерживаемых смотрите в [[#Битность изображения (поле BitCount)|отдельном разделе ниже]]).
|-
| style="text-align: center" | <tt>1E</tt>
| style="text-align: center" | <tt>10</tt>
| style="text-align: center" | 4
| biCompression<br>bV4V4Compression<ref>Имя поля «bV4V4Compression» с удвоенным «V4» указано в документациях и объявлении структуры в файле WinGDI.h (смотрите, например, «[http://msdn.microsoft.com/en-us/library/dd183380%28v=vs.85%29.aspx BITMAPV4HEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183380%28v=vs.85%29.aspx |date=20131011193915 }}» на MSDN.).</ref><br>bV5Compression
| DWORD
| Указывает на способ хранения пикселей (см. в [[#Поле Compression|разделе ниже]]).
|-
| style="text-align: center" | <tt>22</tt>
| style="text-align: center" | <tt>14</tt>
| style="text-align: center" | 4
| biSizeImage<br>bV4SizeImage<br>bV5SizeImage
| DWORD
| Размер пиксельных данных в байтах. Может быть обнулено если хранение осуществляется двумерным массивом.
|-
| style="text-align: center" | <tt>26</tt>
| style="text-align: center" | <tt>18</tt>
| style="text-align: center" | 4
| biXPelsPerMeter<br>bV4XPelsPerMeter<br>bV5XPelsPerMeter
| LONG
| rowspan="2" | Количество пикселей на метр по горизонтали и вертикали (см. раздел «[[#Разрешение изображения|Разрешение изображения]]» данной статьи).
|-
| style="text-align: center" | <tt>2A</tt>
| style="text-align: center" | <tt>1C</tt>
| style="text-align: center" | 4
| biYPelsPerMeter<br>bV4YPelsPerMeter<br>bV5YPelsPerMeter
| LONG
|-
| style="text-align: center" | <tt>2E</tt>
| style="text-align: center" | <tt>20</tt>
| style="text-align: center" | 4
| biClrUsed<br>bV4ClrUsed<br>bV5ClrUsed
| DWORD
| Размер [[#Таблица цветов|таблицы цветов]] в ячейках.
|-
| style="text-align: center" | <tt>32</tt>
| style="text-align: center" | <tt>24</tt>
| style="text-align: center" | 4
| biClrImportant<br>bV4ClrImportant<br>bV5ClrImportant
| DWORD
| Количество ячеек от начала таблицы цветов до последней используемой (включая её саму).
|-
! colspan="6" | Добавлены в версии 4
|-
! style="text-align: center" | Позиция<br>в файле<br><small>(hex)</small>
! style="text-align: center" | Позиция<br>в структуре<br><small>(hex)</small>
! style="text-align: center" | Размер<br> <small>(байты)</small>
! Имя<br><small>(версии 4/5)</small>
! Тип WinAPI
! Описание
|-
| style="text-align: center" | <tt>36</tt>
| style="text-align: center" | <tt>28</tt>
| style="text-align: center" | 4
| bV4RedMask<br>bV5RedMask
| DWORD
| rowspan="4" | [[#Маски каналов|Битовые маски для извлечения значений каналов]]: интенсивность красного, зелёного, синего и значение альфа-канала.
|-
| style="text-align: center" | <tt>3A</tt>
| style="text-align: center" | <tt>2C</tt>
| style="text-align: center" | 4
| bV4GreenMask<br>bV5GreenMask
| DWORD
|-
| style="text-align: center" | <tt>3E</tt>
| style="text-align: center" | <tt>30</tt>
| style="text-align: center" | 4
| bV4BlueMask<br>bV5BlueMask
| DWORD
|-
| style="text-align: center" | <tt>42</tt>
| style="text-align: center" | <tt>34</tt>
| style="text-align: center" | 4
| bV4AlphaMask<br>bV5AlphaMask
| DWORD
|-
| style="text-align: center" | <tt>46</tt>
| style="text-align: center" | <tt>38</tt>
| style="text-align: center" | 4
| bV4CSType<br>bV5CSType
| DWORD
| Вид [[#Цветовое пространство|цветового пространства]].
|-
| style="text-align: center" | <tt>4A</tt>
| style="text-align: center" | <tt>3C</tt>
| style="text-align: center" | 36
| bV4Endpoints<br>bV5Endpoints
| CIEXYZTRIPLE
| rowspan="4" | Значение этих четырёх полей берётся во внимание только если поле CSType содержит 0 (LCS_CALIBRATED_RGB). Тогда [[#Конечные точки и значение гаммы|конечные точки и значения гаммы]] для трёх цветовых компонент указываются в этих полях.
|-
| style="text-align: center" | <tt>6E</tt>
| style="text-align: center" | <tt>60</tt>
| style="text-align: center" | 4
| bV4GammaRed<br>bV5GammaRed
| DWORD<ref name="gamma-type">Microsoft объявила поля Gamma* с типом DWORD, но при этом в GDI есть специальный для таких полей тип FXPT16DOT16.</ref>
|-
| style="text-align: center" | <tt>72</tt>
| style="text-align: center" | <tt>64</tt>
| style="text-align: center" | 4
| bV4GammaGreen<br>bV5GammaGreen
| DWORD<ref name="gamma-type" />
|-
| style="text-align: center" | <tt>76</tt>
| style="text-align: center" | <tt>68</tt>
| style="text-align: center" | 4
| bV4GammaBlue<br>bV5GammaBlue
| DWORD<ref name="gamma-type" />
|-
! colspan="6" | Добавлены в версии 5
|-
! style="text-align: center" | Позиция<br>в файле<br><small>(hex)</small>
! style="text-align: center" | Позиция<br>в структуре<br><small>(hex)</small>
! style="text-align: center" | Размер<br> <small>(байты)</small>
! Имя
! Тип WinAPI
! Описание
|-
| style="text-align: center" | <tt>7A</tt>
| style="text-align: center" | <tt>6C</tt>
| style="text-align: center" | 4
| bV5Intent
| DWORD
| [[#Предпочтения при рендеринге|Предпочтения при рендеринге]] растра.
|-
| style="text-align: center" | <tt>7E</tt>
| style="text-align: center" | <tt>70</tt>
| style="text-align: center" | 4
| bV5ProfileData
| DWORD
| Смещение в байтах цветового профиля от начала BITMAPINFO (см. также раздел «[[#Цветовой профиль|Цветовой профиль]]» ниже в этой статье).
|-
| style="text-align: center" | <tt>82</tt>
| style="text-align: center" | <tt>74</tt>
| style="text-align: center" | 4
| bV5ProfileSize
| DWORD
| Если в BMP непосредственно включается цветовой профиль, то здесь указывается его размер в байтах.
|-
| style="text-align: center" | <tt>86</tt>
| style="text-align: center" | <tt>78</tt>
| style="text-align: center" | 4
| bV5Reserved
| DWORD
| Зарезервировано и должно быть обнулено.
|}

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

{| class="standard" style="text-align:center; border-style: none"
! rowspan="2" | Бит
! rowspan="2" | Байт
! colspan="2" | BITMAPINFO
! rowspan="2" | RLE
! rowspan="2" | Маски каналов
! colspan="3" | Поддержка программным обеспечением
|-
! CORE
! 3, 4, 5
! Windows 9x и NT
! Windows CE и Mobile
! [[GDI+]] и [[.NET Framework|.NET]]
|-
| 1
| ⅛
| {{да}}
| {{да}}
| {{нет}}
| {{нет}}
| {{да}}
| {{да}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; width: 2px; white-space: nowrap; border: 1px solid #000; cursor: help; background-color: orange;" title="бит индекса в таблице цветов"></span>
|-
| 2
| ¼
| {{да}}
| {{да}}
| {{нет}}
| {{нет}}
| {{нет}}
| {{да}}
| {{нет}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; width: 4px; white-space: nowrap; border: 1px solid #000; cursor: help; background-color: orange;" title="2 бита индекса в таблице цветов"></span>
|-
| 4
| ½
| {{да}}
| {{да}}
| {{да}}
| {{нет}}
| {{да}}
| {{да}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; width: 8px; white-space: nowrap; border: 1px solid #000; cursor: help; background-color: orange;" title="ниббл (полубайт) индекса в таблице цветов"></span>
|-
| 8
| 1
| {{да}}
| {{да}}
| {{да}}
| {{нет}}
| {{да}}
| {{да}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; width: 16px; white-space: nowrap; border: 1px solid #000; cursor: help; background-color: orange;" title="байт индекса в таблице цветов"></span>
|-
| 16
| 2
| {{нет}}
| {{да}}
| {{нет}}
| {{да}}
| {{да}}
| {{да}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; white-space: nowrap; border: 1px solid #000; cursor: help;"><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 10px; background-color: blue;" title="5 бит синего"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 10px; background-color: green" title="5 бит зелёного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 10px; background-color: red;" title="5 бит красного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 2px; background-color: silver;" title="неиспользуемый бит"></span></span>
|-
| 24
| 3
| {{да}}
| {{да}}
| {{нет}}
| {{нет}}
| {{да}}
| {{да}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; white-space: nowrap; border: 1px solid #000; cursor: help;"><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 16px; background-color: blue;" title="байт синего"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 16px; background-color: green" title="байт зелёного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 16px; background-color: red;" title="байт красного"></span></span>
|-
| 32
| 4
| {{нет}}
| {{да}}
| {{нет}}
| {{да}}
| {{да}}
| {{да}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; white-space: nowrap; border: 1px solid #000; cursor: help;"><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 16px; background-color: blue;" title="байт синего"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 16px; background-color: green" title="байт зелёного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 16px; background-color: red;" title="байт красного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 16px; background-color: silver;" title="неиспользуемый байт"></span></span>
|-
| 48
| 6
| {{нет}}
| {{да}}
| {{нет}}
| {{нет}}
| {{нет}}
| {{нет}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; white-space: nowrap; border: 1px solid #000; cursor: help;"><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 32px; background-color: blue;" title="16 бит синего"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 32px; background-color: green" title="16 бит зелёного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 32px; background-color: red;" title="16 бит красного"></span></span>
|-
| 64
| 8
| {{нет}}
| {{да}}
| {{нет}}
| {{нет}}
| {{нет}}
| {{нет}}
| {{да}}
| style="text-align: left; border-style: none none none solid; padding-left: 4px; padding-right: 4px;" | <span style="display: inline-block; overflow: hidden; height: 9px; white-space: nowrap; border: 1px solid #000; cursor: help;"><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 32px; background-color: blue;" title="16 бит синего"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 32px; background-color: green" title="16 бит зелёного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 32px; background-color: red;" title="16 бит красного"></span><span style="display: inline-block; vertical-align: top; overflow: hidden; height: 9px; width: 32px; background-color: gray;" title="16 бит альфа-канала"></span></span>
|}

<small>Примечания к таблице:
<br>1. В колонке «BITMAPINFO» указана поддержка битностей только со стороны Microsoft.
<br>2. Windows CE 1.0 и 1.01 поддерживает только битности 1 и 2<ref>См. раздел «Remarks» в статье [http://msdn.microsoft.com/en-us/library/aa930622.aspx BITMAPINFOHEADER] {{Wayback|url=http://msdn.microsoft.com/en-us/library/aa930622.aspx |date=20140419203951 }} (рубрика «Windows Mobile 6.5») на MSDN.</ref>.
<br>3. GDI+ версии 1.0 16-битные цветовые каналы умеет только считывать, сразу переводя их в 8-битные<ref>См. раздел «Remarks» в статье «[http://msdn.microsoft.com/en-us/library/ms534412%28v=vs.85%29.aspx Image Pixel Format Constants] {{Wayback|url=http://msdn.microsoft.com/en-us/library/ms534412%28v=vs.85%29.aspx |date=20140504113127 }}» (рубрика «GDI+») на MSDN.</ref>.
</small>

В битностях 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 документировала следующие значения (в таблице указаны имена констант от этой корпорации):

{| class="standard" style="text-align:center"
! rowspan="2" | Значение
! rowspan="2" style="text-align: left" | Имя константы
! rowspan="2" | Применимо<br>к BitCount
! rowspan="2" style="text-align: left" | Хранение пикселей
! rowspan="2" | Знак Height
! colspan="2" | Версия Windows
|-
! 9x/NT
! CE
|-
| 0
| style="text-align: left" | BI_RGB
| любым кроме нуля
| style="text-align: left" | [[#Двумерный массив|двумерный массив]]
| +/−
| {{да|95/NT 3.1}}
| {{да|CE 1.0}}
|-
| 1
| style="text-align: left" | BI_RLE8
| 8
| style="text-align: left" | [[#RLE|RLE-кодирование]]
| +
| {{да|95/NT 3.1}}
| {{нет|(не подд.)}}
|-
| 2
| style="text-align: left" | BI_RLE4
| 4
| style="text-align: left" | RLE-кодирование
| +
| {{да|95/NT 3.1}}
| {{нет|(не подд.)}}
|-
| 3
| style="text-align: left" | BI_BITFIELDS
| 16 и 32
| style="text-align: left" | двумерный массив с масками цветовых каналов
| +/−
| {{да|95/NT 3.1}}
| {{да|CE 2.0}}
|-
| 4
| style="text-align: left" | BI_JPEG
| 0
| style="text-align: left" | [[#JPEG-PNG|во встроенном JPEG-файле]]
| ?/−<ref name="height-sign-width-jpeg">В MSDN в самом начале раздела «Remarks» [http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx страницы структуры BITMAPV5HEADER] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx |date=20131011235215 }} есть предложение ''«If bV5Height is negative, indicating a top-down DIB, bV5Compression must be either BI_RGB or BI_BITFIELDS.»'' (перевод: ''«Если bV5Height отрицательный, обозначая DIB вида „сверху вниз“, то bV5Compression должен быть либо BI_RGB, либо BI_BITFIELDS»''). Здесь возможно не уточнили, что это касается только RLE-кодирования, так как в одном из примеров прорисовки JPEG-растра указывается именно отрицательная высота (ищите строку «bmi.bmiHeader.biHeight» в статье «[http://msdn.microsoft.com/en-us/library/windows/desktop/dd145131%28v=vs.85%29.aspx Testing a Printer for JPEG or PNG Support] {{Wayback|url=http://msdn.microsoft.com/en-us/library/windows/desktop/dd145131%28v=vs.85%29.aspx |date=20131114005411 }}» на MSDN).</ref>
| {{да|98/2000}}
| {{нет|(не подд.)}}
|-
| 5
| style="text-align: left" | BI_PNG
| 0
| style="text-align: left" | во встроенном PNG-файле
| ?/−<ref name="height-sign-width-jpeg" />
| {{да|98/2000}}
| {{нет|(не подд.)}}
|-
| 6
| style="text-align: left" | BI_ALPHABITFIELDS
| 16 и 32
| style="text-align: left" | двумерный массив с масками цветовых и альфа-канала
| +/−
| {{нет|(не подд.)}}
| {{да|.NET 4.0}}
|}

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

Позиция таблицы цветов указывается от его начала блока BITMAPINFO.
По умолчанию она идёт сразу за информационной структурой (её беззнаковый размер в байтах можно прочитать из первого 32-битного поля).
Но между структурой с полями и цветовой таблицей могут идти четырёхбайтные битовые маски для извлечения цветовых каналов (касается только битностей 16 и 32).
Они там находятся только если используется информационная структура 3-й версии (Size = 40) и поле Compression содержит 3 (BI_BITFIELDS) или 6 (BI_ALPHABITFIELDS).
Тогда к размеру информационных полей нужно прибавить 12 (при значении BI_BITFIELDS) или 16 байт (если указано BI_ALPHABITFIELDS)<ref>Будьте внимательны.
В MSDN в статье «[http://msdn.microsoft.com/en-us/library/aa930622.aspx BITMAPINFOHEADER] {{Wayback|url=http://msdn.microsoft.com/en-us/library/aa930622.aspx |date=20140419203951 }}»
для Windows Mobile 6.5 в описании к полю biClrUsed есть предложение
''«If biBitCount equals 16 or 32, the optimal color palette starts immediately following the three DWORD masks.»''
(перевод: ''«Если biBitCount равно 16 или 32, то оптимальная цветовая палитра начинается следуя сразу за тремя DWORD-масками»'').
В этой же статье выше, в описании к полю biCompression сказано ''«Specifies that the bitmap is not compressed and that the color table consists of three DWORD color masks…»''
и ниже аналогичное с ''«consists of four DWORD color masks»'' (переводы: ''«Указывает, что битмап не сжат и что таблица цветов состоит из трёх цветовых DWORD-масок»''
и ''«состоит из четырёх цветовых DWORD-масок»'').
Аналогичная информация содержится в статье «[http://msdn.microsoft.com/en-us/library/dd183376%28v=vs.85%29.aspx BITMAPINFOHEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183376%28v=vs.85%29.aspx |date=20140209154803 }}» для Windows 9x/NT.

Всё это можно интерпретировать так, что в битности 16 и 32 за информационными полями (структурой BITMAPINFOHEADER) обязательно присутствуют три 32-битных маски для извлечения значений цветовых каналов.
При этом если Compression содержит 3 (BI_BITFIELDS) или 6 (BI_ALPHABITFIELDS), то за ними добавляется ещё три или четыре аналогичных маски,
которые в свою очередь занимают таблицу цветов делая невозможным использование 16-битных индексов оптимальных цветов в логической палитре
(возможно при этом в поле biClrUsed нужно записать значение 6 или 8, а в biClrImportant обязательно 0, чтобы дополнительные маски случайно не обработались как индексы в палитре).
<br>
В действительности всё несколько иначе.</ref>.
Получается 6 вариантов расположения таблицы:

{| class="standard" style="text-align:center"
! rowspan="2" | Версия<br>заголовка
! colspan="2" | Позиция <small>(hex)</small>
! rowspan="2" style="text-align: left" | Примечания
|-
! В файле
! В BITMAPINFO
|-
| CORE
| <tt>1A</tt>
| <tt>0C</tt>
| style="text-align: left" | маски каналов не поддерживаются
|-
| rowspan="3" | 3
| <tt>36</tt>
| <tt>28</tt>
| style="text-align: left" | Compression не содержит 3 или 6
|-
| <tt>42</tt>
| <tt>34</tt>
| style="text-align: left" | Compression = 3 (BI_BITFIELDS)
|-
| <tt>46</tt>
| <tt>38</tt>
| style="text-align: left" | Compression = 6 (BI_ALPHABITFIELDS)
|-
| 4
| <tt>7A</tt>
| <tt>6C</tt>
| rowspan="2" style="text-align: left" | маски каналов встроены<br>в информационные поля
|-
| 5
| <tt>8A</tt>
| <tt>7B</tt>
|}

Количество ячеек в таблице определяется по полям BitCount и ClrUsed.
При битностях 8 и ниже максимальное количество ячеек в таблице принимается за 2<sup>''битность''</sup>: 2 в однобитном растре, 4 в двухбитном, 16 в 4-битном и 256 в 8-битном.
В данных битностях таблица всегда содержит это максимальное количество ячеек если используется заголовок версии CORE (Size = 12) или если в других версиях поле ClrUsed содержит 0.
Во всех остальных случаях, независимо от битности, в таблице находится столько же ячеек, сколько указано в поле ClrUsed<ref>В документации MSDN на странице «[http://msdn.microsoft.com/en-us/library/dd183386%28v=vs.85%29.aspx Bitmap Header Types] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183386%28v=vs.85%29.aspx |date=20140922041510 }}» есть предложение
''«Bitmaps that are 1, 4, or 8 bpp must have a color table with a maximum size based on the bpp.»''
(перевод: ''«Битмапы с битностью 1, 4 или 8 должны содержать таблицу цветов с максимальным соответствующим битности размером.»'').
Это явно ошибка и писавший применил условия структуры CORE, у которой действительно должен быть максимум
(см. раздел «Remarks» в статье «[http://msdn.microsoft.com/en-us/library/dd183373%28v=vs.85%29.aspx BITMAPCOREINFO structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183373%28v=vs.85%29.aspx |date=20150503064141 }}»),
ко всем остальным версиям структур.
В другой статье «[http://msdn.microsoft.com/en-us/library/dd183375%28v=vs.85%29.aspx BITMAPINFO structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183375%28v=vs.85%29.aspx |date=20140624155245 }}» про таблицу цветов сказано
''«The number of entries in the array depends on the values of the biBitCount and biClrUsed members of the BITMAPINFOHEADER structure.»''
(перевод: ''«количество элементов в массиве зависит от значений полей biBitCount и biClrUsed структуры BITMAPINFOHEADER»''),
а в статьях структур версий 3, 4, 5
(см., например, «[http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx BITMAPV5HEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx |date=20131011235215 }}»)
в описании поля BitCount везде написано
''«the bmiColors member of BITMAPINFO contains <u>up to</u> 256 entries»''
(аналогично про другие битности; перевод фразы: ''«член bmiColors BITMAPINFO содержит <u>до</u> 256 элементов»'').</ref>.

Сама же таблица представляет собой одномерный массив, который может содержать ячейки трёх типов:
# 32-битная структура '''RGBQUAD'''. Применяется если в BITMAPINFO использована информационная структура версии 3, 4 или 5. В самой же структуре RGBQUAD указывается цвет в модели [[RGB]] в четырёх байтовых ячейках (все имеют WinAPI-тип BYTE): rgbBlue (синий), rgbGreen (зелёный), rgbRed (красный) и rgbReserved (зарезервирована и должна быть обнулена).
# 24-битная структура '''RGBTRIPLE'''. Применяется если BITMAPINFO начинается со структуры BITMAPCOREHEADER. RGBTRIPLE состоит из трёх байтовых ячеек (WinAPI-тип BYTE), в которых указывается цвет в модели [[RGB]]: rgbtBlue (синий), rgbtGreen (зелёный) и rgbtRed (красный).
# 16-битные индексы цветов (беззнаковые целые числа) в текущей логической палитре контекста устройства (системные объекты [[GDI|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<sub>h</sub> во всём файле или 28<sub>h</sub> от начала блока BITMAPINFO.
В версиях 4 и 5 на этом месте располагаются предназначенные специально для них поля.
В версии же 3 битовые маски должны располагаться сразу за информационными полями и таким образом они точно попадают на позиции соответствующих полей в старших версиях.
Обратите внимание на то, что в третьей версии при наличии масок сдвигается таблица цветов на 12 или 16 байт вперёд, располагаясь сразу за ними.
4-байтные маски цветов следуют в порядке красная, зелёная, синяя.
Маска альфа-канала располагается уже за ними.

В документации Microsoft к битовым маскам применяется только одно обязательное требование: каждая маска должна быть непрерывной.
Про случай пересечения масок там сказано, что желательно этого не делать<ref>См., например, описания к битностям 16 и 32 у поля bV5BitCount в статье «[http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx BITMAPV5HEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx |date=20131011235215 }}» на MSDN.</ref>.
Microsoft также говорит о том, что не обязательно задействовать все биты пикселя<ref>На MSDN и справке Microsoft Windows SDK в статье «[http://msdn.microsoft.com/en-us/library/dd183376%28v=vs.85%29.aspx BITMAPINFOHEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183376%28v=vs.85%29.aspx |date=20140209154803 }}» в описании значения 16 поля biBitCount есть сбивающее с толку предложение ''«All the bits in the pixel do not have to be used.»'' (перевод: ''«Не задействовать все биты в пикселе»''). Это опечатка (написали «have» вместо «need»), которая отсутствует в аналогичном блоке в [http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx статье про пятую версию] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx |date=20131011235215 }} (в четвёртой это предложение отсутствует).</ref>.
Какие-либо требования к содержимому неиспользуемых бит отсутствуют.

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

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

{| class="standard" style="text-align:center"
! rowspan="2" | Битность
! rowspan="2" | *
! colspan="5" | Значения масок <small>(hex)</small>
! colspan="2" | Поддержка в ПО
|-
! Красный
! Зелёный
! Синий
! Альфа
! Неиспользуемые
! Windows 9x<ref>Данная информация есть в справке по Microsoft Windows SDK, которая идёт в комплекте вместе с крупными IDE.</ref>
! GDI+<ref>См. «[http://msdn.microsoft.com/en-us/library/ms534412%28v=vs.85%29.aspx Image Pixel Format Constants] {{Wayback|url=http://msdn.microsoft.com/en-us/library/ms534412%28v=vs.85%29.aspx |date=20140504113127 }}» про GDI+ в MSDN.</ref> и .NET<ref>См. «[http://msdn.microsoft.com/en-us/library/system.drawing.imaging.pixelformat%28v=vs.71%29.aspx PixelFormat Enumeration] {{Wayback|url=http://msdn.microsoft.com/en-us/library/system.drawing.imaging.pixelformat%28v=vs.71%29.aspx |date=20130623025643 }}» про .NET Framework 1.1 в MSDN.</ref>
|-
| rowspan="4" | 16
| (a)
| <tt>7C00</tt>
| <tt>03E0</tt>
| <tt>001F</tt>
| <tt>0000</tt>
| <tt>8000</tt>
| {{да}}
| {{да}}
|-
|
| <tt>7C00</tt>
| <tt>03E0</tt>
| <tt>001F</tt>
| <tt>8000</tt>
| <tt>0000</tt>
| {{нет}}
| {{да}}
|-
|
| <tt>F800</tt>
| <tt>07E0</tt>
| <tt>001F</tt>
| <tt>0000</tt>
| <tt>0000</tt>
| {{да}}
| {{да}}
|-
| (b)
| <tt>FFFF</tt>
| <tt>FFFF</tt>
| <tt>FFFF</tt>
| <tt>0000</tt>
| <tt>0000</tt>
| {{нет}}
| {{да}}
|-
| rowspan="2" | 32
| (a)
| <tt>00FF:0000</tt>
| <tt>0000:FF00</tt>
| <tt>0000:00FF</tt>
| <tt>0000:0000</tt>
| <tt>FF00:0000</tt>
| {{да}}
| {{да}}
|-
|
| <tt>00FF:0000</tt>
| <tt>0000:FF00</tt>
| <tt>0000:00FF</tt>
| <tt>FF00:0000</tt>
| <tt>0000:0000</tt>
| {{нет}}
| {{да}}
|}

<small>Примечания к таблице:
<br>(a) Эти наборы используются по умолчанию в битностях 16 и 32, если маски для извлечения цветов не заданы.
<br>(b) Данный набор масок по своей сути реализует 16-битный Grayscale.
</small>

=== Пиксельные данные ===
В файле положение пиксельных данных можно узнать из поля OffBits структуры BITMAPFILEHEADER.
Во время выполнения приложение хранит адрес пиксельных данных там, где удобней.
В документации Microsoft также упоминаются так называемые упакованные (англ. ''packed'') битмапы, которые указываются одним адресом блока BITMAPINFO.
У таких битмапов пиксельные данные следуют сразу за заголовком (включая помимо информационных полей битовые маски и таблицу цветов)<ref>См. раздел «[http://msdn.microsoft.com/en-us/library/dd183375%28v=vs.85%29.aspx Remarks] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183375%28v=vs.85%29.aspx |date=20140624155245 }}» в статье «BITMAPINFO» на MSDN.</ref>.

Размер пиксельных данных в байтах записывается в поле SizeImage структуры BITMAPINFO.
Туда записываются именно «сырой» размер того непрерывного блока, который содержит данные для формирования пикселей (независимо от формата), а не какой-нибудь распакованный.
По умолчанию это поле обязательно должно содержать актуальное значение, так как по нему можно точно узнать сколько именно байт нужно считать из файла для получения пикселей.
Тем не менее, допустимо содержать в этом поле ноль при хранении пикселей двумерными массивами (когда поле Compression содержит значение 0 (BI_RGB), 3 (BI_BITFIELDS) или 6 (BI_ALPHABITFIELDS)<ref>В документации (например, в статье «[http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx BITMAPV5HEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx |date=20131011235215 }}» на MSDN) сказано, что нулевой размер можно указывать при значении 0 (BI_RGB) поля Compression. Очевидно, что это применимо и к значениям 3 (BI_BITFIELDS) и 6 (BI_ALPHABITFIELDS), так как они вносят различие лишь во внутреннюю структуру пикселей, а не в их размер.</ref>).
Тогда размер пикселей при необходимости можно относительно быстро рассчитать исходя из битности, ширины и высоты растра.

В формате Windows Bitmap доступно три способа хранения пикселей (см. также раздел «[[#Поле Compression|Поле Compression]]» данной статьи):
# [[#Двумерный массив|Двумерный массив]].
# [[#RLE|RLE]] (только для битностей 4 и 8).
# [[#JPEG-PNG|В форматах JPEG или PNG]].

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

==== Указание цвета и значения альфа-канала ====
Для указания цвета при хранении в формате BMP независимо от способа задания используются только беззнаковые целые числа.
Сам же цвет пикселя может задаваться двумя способами:
# Индексом в таблице цветов (при битностях 8 и ниже).
# Непосредственным значением в [[RGB|цветовой модели RGB]] (при битностях выше 8).
Второй целесообразно использовать когда набор цветов довольно большой или непредсказуем (например, во время обработки изображения).
Первый же способ обеспечивает как компактную компоновку при малом наборе цветов, так и некоторое удобство в управлении используемыми цветами (достаточно изменить значение цвета в палитре).
В самой таблице цветов указываются или 16-битные беззнаковые индексы в системной палитре (см. раздел «[[#Таблица цветов|Таблица цветов]]» в данной статье), или же в RGB как в пикселе, но исключительно 8-битными значениями каналов.

Индекс в таблице цветов — это номер ячейки в ней от начала таблицы (используется непрерывная нумерация начиная с нуля).
Для каждой битности максимальный индекс принципиально ограничен значением 2<sup>''битность''</sup> − 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: начиная с самого нижнего ({{lang-en|bottom-up bitmap}}), а при отрицательном: с самого верхнего ({{lang-en|top-down bitmap}}).
Внутри каждого горизонтального ряда пиксели записываются строго только от левого к правому.
Пиксели меньше 8 бит размещаются в байтах, заполняя биты от старших к младшим, в результате чего шестнадцатиричные/двоичные числовые значения пикселей более похожи на выводимое изображение.
Если битность 16 или 32, то обработка осуществляется цельными машинными словами аналогичного размера с порядком бит от младшего к старшему (little-endian).
'''Ряды, независимо от размера ячеек, обязательно должны дополняться нулями до кратного четырём байтам размера'''<ref name="msdn-bitmapinfo" />.
Из-за этого, при некратной ширине изображения, в конце рядов могут оказываться неиспользуемые биты или целые байты.
Но благодаря гарантированной кратности размера ряда, обработку можно производить 8-, 16- или 32-битными машинными словами, по выбору.
И у Microsoft ещё прослеживается следующая тенденция в битностях больше 8: компонент Blue (синий цвет) размещается в младших битах/первых байтах, Green (зелёный) в последующих, а Red (красный) старше/дальше всех, и если есть альфа-канал, то он находится в самых старших битах/последних байтах.

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

{|  style="font-size: 0.8em; text-align: center; border: 1px solid #000"
| style="text-align: left" | Биты
| style="width: 3ex" | 7
| style="width: 3ex" | 6
| style="width: 3ex" | 5
| style="width: 3ex" | 4
| style="width: 3ex" | 3
| style="width: 3ex" | 2
| style="width: 3ex" | 1
| style="width: 3ex" | 0
|-
| style="text-align: left" | 1 бит
| 0
| 1
| 2
| 3
| 4
| 5
| 6
| 7
|-
| style="text-align: left" | 2 бита
| colspan="2" | 0
| colspan="2" | 1
| colspan="2" | 2
| colspan="2" | 3
|-
| style="text-align: left" | 4 бита
| colspan="4" | 0
| colspan="4" | 1
|}

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

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

==== {{якорь|RLE}}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-битную границу).
Существует пять команд, которые определяются парой байт:

{| class="standard" style="text-align:center"
! Байт 1<br><small>(hex)</small>
! Байт 2<br><small>(hex)</small>
! style="text-align: left" | Описание
|-
| <tt>01</tt>..<tt>FF</tt>
| <tt>00</tt>..<tt>FF</tt>
| style="text-align: left" | Начиная с текущей позиции и далее вправо прорисовать столько пикселей, сколько указано в первом байте. Значения для пикселей берутся из второго байта. В 8-битных BMP весь байт целиком является значением. В 4-битных из него по-очереди берётся сначала старший, а потом младший [[ниббл]] (четвёрка бит).
|-
| <tt>00</tt>
| <tt>00</tt>
| style="text-align: left" | Переместить курсор в начало (самое лево) следующей (верхней) горизонтали.
|-
| <tt>00</tt>
| <tt>01</tt>
| style="text-align: left" | Прекратить прорисовку (достигнут конец).
|-
| <tt>00</tt>
| <tt>02</tt>
| style="text-align: left" | Переместить курсор вправо и вверх на указанные в следующих далее двух байтах значения. В первом следующем байте содержится значение для горизонтального сдвига, а в следующем — для вертикального. Оба значения: целые беззнаковые числа (влево и вниз сдвинуть нельзя).
|-
| <tt>00</tt>
| <tt>03</tt>..<tt>FF</tt>
| style="text-align: left" | С текущей позиции и далее вправо зарисовать пиксели значениями, которые идут после этой пары байт. Во втором байте команды содержится количество пикселей, которое нужно закрасить (именно пикселей, а не байт). В 8-битном растре берётся поток байт как есть. В 4-битном считывается уже нибблы: старшие 4 бита из байта для первого пикселя, младшие 4 бита — для следующего, и так из последующих байт. Данный поток может закончиться нечётным количеством байт, а команды требуют 16-битного выравнивания. Если это произошло, то дописывается дополнительный байт (его содержимое значения не имеет).
|}

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

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

Для встраивания JPEG или PNG нужно в BITMAPINFO обнулить поле BitCount, а в Compression указать значение 4 (BI_JPEG) или 5 (PI_PNG).
Значение поля SizeImage в данном случае будет равно размеру JPEG или PNG-файла, который встраивается на место пиксельных данных как есть.
Ширина же с высотой в заголовке указываются уже для раскодированного изображения.
Про знак поля Height именно для этого случая в документации напрямую ничего не сказано, но судя по всему нужно записывать отрицательное значение<ref name="height-sign-width-jpeg" />.

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

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

: <math>PPM = \frac{PPI}{25,4} * 1000</math>

: <math>PPI = \frac{PPM}{1000} * 25,4</math>

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

: <code>''PPM'' = (''PPI'' * 5000 + 64) / 127</code>

: <code>''PPI'' = (''PPM'' * 127 + 2500) / 5000</code>

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

Ниже представлены заранее вычисленные значения 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.
Допустимые его значения приведены в таблице ниже:

{| class="standard" style="text-align:center"
! colspan="2" | Значение
! rowspan="2" | Версия<br>BITMAPINFO<ref>На MSDN в статье «[http://msdn.microsoft.com/en-us/library/dd183380%28v=vs.85%29.aspx BITMAPV4HEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183380%28v=vs.85%29.aspx |date=20131011193915 }}» упоминается только одно значение поля CSType (LCS_CALIBRATED_RGB).
Полный список доступных значений для версий 4 и 5 можно посмотреть в статье «[http://msdn.microsoft.com/en-us/library/dd372216%28v=vs.85%29.aspx Using Structures in WCS 1.0] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd372216%28v=vs.85%29.aspx |date=20150503064155 }}».</ref>
! rowspan="2" style="text-align: left" | Имя константы
! rowspan="2" style="text-align: left; text-align: left" | Описание
|-
! Hex
! style="text-align: left" | Текст
|-
| <tt>0</tt>
| style="text-align: left" | (нет)
| 4
| style="text-align: left" | LCS_CALIBRATED_RGB
| style="text-align: left" | Корректировка исходя из значений Endpoints, GammaRed, GammaGreen и GammaBlue.
|-
| <tt>73524742</tt>
| style="text-align: left" | <tt>'sRGB'</tt>
| 4
| style="text-align: left" | LCS_sRGB
| style="text-align: left" | Используется цветовое пространство [[sRGB]].
|-
| <tt>57696E20</tt>
| style="text-align: left" | <tt>'Win '<ref>Здесь после «Win» идёт ещё пробел.</ref></tt>
| 4
| style="text-align: left" | LCS_WINDOWS_COLOR_SPACE
| style="text-align: left" | Системное пространство по умолчанию (sRGB).
|-
| <tt>4C494E4B</tt>
| style="text-align: left" | <tt>'LINK'</tt>
| 5
| style="text-align: left" | PROFILE_LINKED
| style="text-align: left" | Цветовой профиль в другом файле.
|-
| <tt>4D424544</tt>
| style="text-align: left" | <tt>'MBED'</tt>
| 5
| style="text-align: left" | PROFILE_EMBEDDED
| style="text-align: left" | Включённый в данный файл цветовой профиль.
|}

Microsoft объявила значения констант не числовыми значениями, а текстовыми из четырёх символов<ref>Использование такого стиля значений констант только в поле CSType является скорее всего результатом влияния спецификации ICC, у которой в файлах цветовых профилей 32-битным меткам ({{lang-en|tags}}) значения выданы аналогично.</ref>.
В данном случае коды символов формируют байты 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 на страницах про структуры [http://msdn.microsoft.com/en-us/library/dd183380%28v=vs.85%29.aspx BITMAPV4HEADER] и [http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx BITMAPV5HEADER] только это и сказано.
В статье же про структуру LOGCOLORSPACE сказано, что у неё в аналогичных полях должны быть обнулены старший и младший байт (по сути вместо формата 16.16 используется формат 8.8, который располагается в середине 32-битной ячейки)<ref>См. раздел «Remarks» в статье «[http://msdn.microsoft.com/en-us/library/dd372165%28v=vs.85%29.aspx LOGCOLORSPACE Structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd372165%28v=vs.85%29.aspx |date=20130414092556 }}» на MSDN.</ref>.

Ниже приведены значения указанных выше четырёх полей в соответствии с цветовым пространством [[sRGB]]<ref>Числа взяты из стандарта «[http://www.w3.org/Graphics/Color/sRGB.html A Standard Default Color Space for the Internet — sRGB] {{Wayback|url=http://www.w3.org/Graphics/Color/sRGB.html |date=20110820080816 }}». Все значения округлялись вверх если был установлен самый первый отброшенный права бит.</ref>:

{| class="standard" style="text-align: left"
! rowspan="2" style="text-align: left" | Поле
! colspan="2" | Значение
|-
! Дробное
! Hex
|-
| style="text-align: left" | EndPoints.ciexyzRed.ciexyzX
| 0,64
| <tt>28F5C28F</tt>
|-
| style="text-align: left" | EndPoints.ciexyzRed.ciexyzY
| 0,33
| <tt>151EB852</tt>
|-
| style="text-align: left" | EndPoints.ciexyzRed.ciexyzZ
| 0,03
| <tt>01EB851F</tt>
|-
| style="text-align: left" | EndPoints.ciexyzGreen.ciexyzX
| 0,30
| <tt>13333333</tt>
|-
| style="text-align: left" | EndPoints.ciexyzGreen.ciexyzY
| 0,60
| <tt>26666666</tt>
|-
| style="text-align: left" | EndPoints.ciexyzGreen.ciexyzZ
| 0,10
| <tt>06666666</tt>
|-
| style="text-align: left" | EndPoints.ciexyzBlue.ciexyzX
| 0,15
| <tt>0999999A</tt>
|-
| style="text-align: left" | EndPoints.ciexyzBlue.ciexyzY
| 0,06
| <tt>03D70A3D</tt>
|-
| style="text-align: left" | EndPoints.ciexyzBlue.ciexyzZ
| 0,79
| <tt>328F5C29</tt>
|-
| style="text-align: left" | GammaRed<br>GammaGreen<br>GammaBlue
| 2,20
| <tt>0002199A</tt><ref>С обнулённым младшим байтом будет значение 00001A00<sub>16</sub> (округлено вверх).</ref>
|}

==== Цветовой профиль ====
В файле BMP при необходимости может быть указан [[ICC-профиль|цветовой профиль]] как непосредственным включением, так и ссылкой на другой файл.
Профили появились в пятой версии BMP, и пока только здесь есть специальные для них поля.
Поддерживаются же цветовые профили только в формате ICC<ref>Описание данного формата есть в спецификации ICC.1:2010, ссылка на которую есть в конце данной статьи.</ref><ref>См. раздел «Remarks» статьи «[http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx BITMAPV5HEADER structure] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx |date=20131011235215 }}» на MSDN.</ref>.

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

* 4C494E4B<sub>16</sub> (PROFILE_LINKED) — если используется профиль в другом файле.
* 4D424544<sub>16</sub> (PROFILE_EMBEDDED) — если профиль непосредственно встраивается в BMP.

В любом случае в поле ProfileData указывается смещение профиля в байтах от начала блока BITMAPINFO.
Если профиль встроенный, то в ProfileSize нужно указать его размер в байтах (если он подключаемый, то это поле должно быть обнулено).
Независимо от варианта, Microsoft рекомендует размещать профиль при хранении в файле за пиксельными данными, а в оперативной памяти при взаимодействии с WinAPI-функциями: сразу за заголовком<ref name="wcs-structures">См. статью «[http://msdn.microsoft.com/en-us/library/dd372216%28v=vs.85%29.aspx Using Structures in WCS 1.0] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd372216%28v=vs.85%29.aspx |date=20150503064155 }}» на MSDN.</ref>.

Формат ICC в своём заголовке использует преимущественно 32-битные или кратные этому размеру ячейки<ref>См. раздел «7.2 Profile header» в спецификации ICC.1:2010.</ref>.
Исходя из этого, если профиль непосредственно включается в BMP, то в оперативной памяти его рекомендуется хранить по кратному четырём байтам адресу.

Когда профиль внешний, то вместо его содержимого в BMP размещается текстовая строка с путём к файлу.
Он обязательно должен быть в однобайтовой кодировке [[ISO 8859-1|Windows 1252]] (стандартная кодировка для западноевропейских языков) и заканчиваться нулевым байтом.
Про разделители компонентов пути в документации ничего не сказано и поэтому скорее всего можно использовать как [[Обратная косая черта|левые слэши «<tt>\</tt>»]], так и [[Косая черта|«правые» <tt>«/»</tt>]].
Путь же может быть как относительным, так и полным и сетевым<ref name="wcs-structures" />.
И так как в указании пути используется однобайтовая кодировка, то эту строку в оперативной памяти выравнивать не обязательно.

==== Предпочтения при рендеринге ====
'''Предпочтения при рендеринге''' ({{lang-en|rendering intents}}) были введены [[международный консорциум по цвету|Международным концорциумом по цвету]] (International Color Consortium) и определяют приоритеты в случае когда при переходе из цветового подпространства, поддерживаемого одним устройством ({{lang-en|gamut}}), в подпространство другого, в изображении использованы цвета, отсутствующие в целевом.
Также есть определение от ICC, которое определяется предпочтения при рендеринге как стиль сопоставления цветовых значений из одного описателя изображения в другое (оригинал на английском языке: ''«style of mapping colour values from one image description to another»'')<ref>Определение дано в спецификации ICC.1:2010 в разделе 3.1.27 на с. 21.</ref>.
Корпорация Microsoft включила в формат BMP специальное поле Intent, которое может принимать значения полностью по спецификации ICC.
Поэтому за подробной информации обращайтесь к документации консорциума, последнюю версию которой можно скачать с сайта [http://color.org/ color.org]<ref>В версии 4.3 спецификации (последняя на момент написания статьи) данная тема широко освещается в разделах «0.4 Rendering intents» (во вступлении; с. 8), «6.2 Rendering intent» (в основном содержимом; с. 26) и «D.6 Discussion of colorimetric intents» (в приложениях; с. 109).</ref>.
У Microsoft же эти предпочтения коротко описаны в статье «[http://msdn.microsoft.com/en-us/library/dd372183%28v=vs.85%29.aspx Rendering Intents]» на MSDN.

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

{| class="standard" style="text-align: left"
! style="text-align: center" | Значение
! Имя константы<br>для BMP
! Название<br>ICC
! Название<br>Microsoft
! Константа<br>из файла Icm.h
! Константа<br>для DEVMODE
|-
| style="text-align: center" | 1
| LCS_GM_BUSINESS
| saturation
| Graphic
| INTENT_SATURATION (2)
| DMICM_SATURATE (1)
|-
| style="text-align: center" | 2
| LCS_GM_GRAPHICS
| media-relative colorimetric
| Proof
| INTENT_RELATIVE_COLORIMETRIC (1)
| DMICM_COLORIMETRIC (3)
|-
| style="text-align: center" | 4
| LCS_GM_IMAGES
| perceptual
| Picture
| INTENT_PERCEPTUAL (0)
| DMICM_CONTRAST (2)
|-
| style="text-align: center" | 8
| LCS_GM_ABS_COLORIMETRIC
| ICC-absolute colorimetric<br>(relative colometric)
| Match
| INTENT_ABSOLUTE_COLORIMETRIC (3)
| DMICM_ABS_COLORIMETRIC (4)
|}

Microsoft для данной характеристики объявила как минимум три набора констант, которые отличаются своими значениями и используются в разных местах<ref>Сопоставления констант взяты из файла Icm.h (закомментированный блок прямо над объевлениями констант «INTENT_»).</ref>.
Здесь они приведены на случай если вам нужно будет быстро их сопоставить.
Значения констант с префиксом «INTENT_» полностью совпадают с теми значениями, которые используются в файлах профилей ICC<ref>См. раздел «7.2.15 Rendering intent field (bytes 64 to 67)» спецификации ICC.</ref>.
Константы с префиксом «DMICM_» объявлены в файле WinGDI.h для структуры DEVMODE.
Константы «LCS_GM_», которые используются в BMP, объявлены там же и предназначены в первую очередь для структуры LOGCOLORSPACE.
Есть также названия для свойств принтеров.
Они аналогичны тем, что в колонке «Название Microsoft», но с «Graphics» и «Pictures».

За значение по умолчанию, которое в первую очередь подходит для фотографий и картинок, можно принимать 4 (LCS_GM_IMAGES).
В таком качестве его рекомендует как Microsoft<ref>См. раздел «Picture Intent» в статье «[http://msdn.microsoft.com/en-us/library/dd372183%28v=vs.85%29.aspx Rendering Intents] {{Wayback|url=http://msdn.microsoft.com/en-us/library/dd372183%28v=vs.85%29.aspx |date=20120918234609 }}» на MSDN.</ref>, так и ICC<ref>В спецификации внизу страницы 41.</ref>.

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

<source lang="C">
/* Компилируется строкой: 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;
}
</source>

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

== Примечания ==
{{примечания|2}}

== Литература ==

=== Microsoft (MSDN и SDK) ===
[[Platform SDK|Microsoft Windows SDK]] — комплект для разработчиков, который включает в себя справку и включаемые файлы на языке C++.
По теме данной статьи актуальны файлы WinGDI.h и Icm.h, из которых были взяты в первую очередь значения констант.
Последнюю версию данного комплекта можно [http://search.microsoft.com/en-us/DownloadResults.aspx?q=Microsoft%20Windows%20SDK&first=11&FORM=PEME бесплатно скачать с сайта Microsoft] (в данной статье использовались версии 6.0 и 7.1).

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

Основная информацию находится в справке по GDI, которая относится к платформам Windows 9x и NT.
Ссылки на страницы этого раздела, которые относятся только к формату, а не к WinAPI-функциям работы с ним:
* «[http://msdn.microsoft.com/en-us/library/dd183382%28v=vs.85%29.aspx Bitmap Classifications]» — описание аппаратно-зависимых и аппаратно-независимых битмапов.
* «[http://msdn.microsoft.com/en-us/library/dd183391%28v=vs.85%29.aspx Bitmap Storage]» — общее описание формата файла BMP.
* «[http://msdn.microsoft.com/en-us/library/dd183386%28v=vs.85%29.aspx Bitmap Header Types]» — обзор по версиям заголовков BMP.
* «[http://msdn.microsoft.com/en-us/library/dd183383%28v=vs.85%29.aspx Bitmap Compression]» — описание RLE-кодирования.
* «[http://msdn.microsoft.com/en-us/library/dd183392%28v=vs.85%29.aspx Bitmap Structures]» — раздел с описаниями структур с полями. Для удобства прямые ссылки на ключевые:
** [http://msdn.microsoft.com/en-us/library/dd183374%28v=vs.85%29.aspx BITMAPFILEHEADER]
** [http://msdn.microsoft.com/en-us/library/dd183372%28v=vs.85%29.aspx BITMAPCOREHEADER]
** [http://msdn.microsoft.com/en-us/library/dd183376%28v=vs.85%29.aspx BITMAPINFOHEADER]
** [http://msdn.microsoft.com/en-us/library/dd183380%28v=vs.85%29.aspx BITMAPV4HEADER]
** [http://msdn.microsoft.com/en-us/library/dd183381%28v=vs.85%29.aspx BITMAPV5HEADER]

У платформ Windows Compact 2013 (CE 6.0) и Mobile 6.5 есть только описания трёх структур, но применительно к данным платформам:
* [http://msdn.microsoft.com/en-us/library/aa930979.aspx BITMAPFILEHEADER]
* [http://msdn.microsoft.com/en-us/library/aa931790.aspx BITMAPCOREHEADER]
* [http://msdn.microsoft.com/en-us/library/aa930622.aspx BITMAPINFOHEADER]

Ссылки на другие страницы из MSDN, которые относятся к формату BMP:
* «[http://msdn.microsoft.com/en-us/library/ms534412%28v=vs.85%29.aspx Image Pixel Format Constants]» — константы форматов пикселей GDI+.
* «[http://msdn.microsoft.com/en-us/library/system.drawing.imaging.pixelformat%28v=vs.71%29.aspx PixelFormat Enumeration]» — описание значений перечисляемого типа PixelFormat для .NET Framework 1.1 (самая ранняя версия).
* «[http://msdn.microsoft.com/en-us/library/dd372216%28v=vs.85%29.aspx Using Structures in WCS 1.0]» — про используемые в управлении цветом в Windows структуры.
* «[http://msdn.microsoft.com/en-us/library/dd372183%28v=vs.85%29.aspx Rendering Intents]» — описание предпочтений при рендеринге.

=== Другие ===
В спецификации ICC по управлению цветом можно найти информацию о цветовых профилях (в том числе о формате файлов ICC), а также о предпочтениях рендеринга.
Данную спецификацию можно скачать с официального сайта концорциума [http://color.org/ color.org].
В момент написания статьи последней версией была 4.3 (декабрь 2010).
Прямая ссылки на PDF с сайта ICC:
* [http://www.color.org/specification/ICC1v43_2010-12.pdf Specification ICC.1:2010] (Profile version 4.3.0.0) «Image technology colour management — Architecture, profile format, and data structure».
* [http://www.color.org/specification/ICC1-2010_Cumulative_Errata_List_2013-09-24.pdf Errata] к спецификации (обнаруженные ошибки и опечатки; опубликованы 24 сентября 2013 года).

{{Медиаконтейнеры}}

[[Категория:Графические форматы]]