лекции / Shchupak_Yu._Win32_API_Razrabotka_prilozheniy_dlya_Windows
.pdf
Палитры |
171 |
|
|
|
|
COLORREF paletteColor[8] = { PALETTERGB(0,31,0), PALETTERGB(0,63,0), PALETTERGB(0,95,0), PALETTERGB(0,127,0), PALETTERGB(0,159,0), PALETTERGB(0,191,0), PALETTERGB(0,223,0), PALETTERGB(0,255,0)};
Модифицированная программа выведет картинку, в которой первый, второй, шестой и седьмой прямоугольники неразличимы по цвету.
Это означает, что пришло время применить специализированную логическую палитру. Для ее создания используется функция CreatePalette:
HPALETTE CreatePalette(CONST LOGPALETTE* lplgpl);
Параметр lplgpl содержит указатель на структуру LOGPALETTE, определение кото рой имеет следующий вид:
typedef struct |
tagLOGPALETTE |
{ |
WORD |
palVersion; |
// номер версии палитры |
WORD |
palNumEntries; |
// число входов в логической палитре |
PALETTEENTRY |
palPalEntry[1]; |
|
} LOGPALETTE; |
|
|
Номер версии палитры не изменился со времен ее появления в Windows 3.0 и по прежнему равен 0x300.
Поле palPalEntry содержит адрес массива структур PALETTEENTRY, определяющих цвет каждого элемента в логической палитре.
Структура PALETTEENTRY уже рассматривалась в разделе «Системная палитра». Три ее первых поля обычно описывают интенсивность компонентов RGB моде ли, а поле peFlags указывает, как данный элемент должен интерпретироваться при реализации палитры. Возможные значения поля peFlags перечислены в табл. 3.2.
Таблица 3.2. Возможные значения поля peFlags
Значение Описание
0Стандартная процедура, предписывающая искать цвет RGB в системной палитре. Если цвет отсутствует, то он включается в палитру
PC_NOCOLLAPSE |
Искать соответствие в системной палитре лишь при отсутствии свободных |
|
(неиспользуемых) элементов. В противном случае нужно использовать |
|
первый свободный элемент |
PC_EXPLICIT |
Не изменять системную палитру. В первые два байта структуры |
|
PALETTEENTRY поместить индекс элемента в системной палитре. Этот флаг |
|
позволяет приложению показать содержимое аппаратной палитры |
PC_RESERVED |
Указывает, что данный элемент палитры будет использоваться для анимации. |
|
Этот флаг запрещает другим окнам согласовывать какой-либо цвет с данным |
|
элементом палитры. Если в системной палитре есть свободные элементы, |
|
то первый из них используется для размещения данного элемента |
|
|
Отметим, что в определении структуры LOGPALETTE массив palPalEntry содержит всего один элемент, так как нельзя заранее сказать, сколько элементов может по требоваться для создания логической палитры. Поэтому в коде приложения необ ходимо либо расширить определение типа LOGPALETTE, либо выделить в куче блок памяти необходимого размера и адресоваться к нему при помощи указателя на LOGPALETTE. В рассматриваемой ниже программе демонстрируется первый подход.
После создания объекта палитры он должен быть реализован вызовом функ ции RealizePalette так же, как и в случае с полутоновой палитрой.
В листинге 3.4 приводится код программы, в которой создается логическая па литра, содержащая 128 градаций зеленого цвета, и демонстрируется вывод 16 пря моугольников, равномерно заполненных различными оттенками зеленого цвета.
172 |
Глава 3. GDI. Палитры, растры, метафайлы |
|
|
Листинг 3.4. Проект LogicPalette
//////////////////////////////////////////////////////////////////////
// LogicPalette.cpp #include <windows.h> #include "KWnd.h"
#define PAL_NUM_ENTRIES 128 #define NUM_RECT 16
typedef struct { LOGPALETTE lp;
PALETTEENTRY ape[PAL_NUM_ENTRIES - 1]; } LogPal;
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); //==================================================================== int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MSG msg;
KWnd mainWnd("Colors with logic palette", hInstance, nCmdShow, WndProc, NULL, 0, 0, 808, 200);
while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg);
}
return msg.wParam;
}
//==================================================================== LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
HDC hDC; PAINTSTRUCT ps; RECT r0;
RECT rect[NUM_RECT]; int dW, dH, i;
static LogPal pal;
LOGPALETTE* pLP = (LOGPALETTE*) &pal;
static COLORREF paletteColor[NUM_RECT]; static HBRUSH brush[NUM_RECT];
static HPALETTE hPal; HPALETTE hOldPal;
BYTE green;
BYTE stepPal, stepBrush;
switch (uMsg)
{
case WM_CREATE:
// Создаем логическую палитру
pLP->palVersion = 0x300; // номер версии Windows pLP->palNumEntries = PAL_NUM_ENTRIES; // число входов палитры stepPal = 256 / PAL_NUM_ENTRIES;
Палитры |
173 |
|
|
|
|
|
green |
= 255; |
for (i = 0; i < PAL_NUM_ENTRIES; i++) { pLP->palPalEntry[i].peRed = 0; pLP->palPalEntry[i].peGreen = green; pLP->palPalEntry[i].peBlue = 0; pLP->palPalEntry[i].peFlags = 0; green -= stepPal;
}
hPal = CreatePalette (pLP);
// Готовим кисти для рисования stepBrush = 256 / NUM_RECT; for (i = 0; i < NUM_RECT; ++i)
brush[i] = CreateSolidBrush(PALETTERGB(0, stepBrush * i, 0)); break;
case WM_PAINT:
hDC = BeginPaint(hWnd, &ps);
hOldPal = SelectPalette(hDC, hPal, FALSE); GetClientRect(hWnd, &r0);
dW = r0.right / NUM_RECT; dH = r0.bottom;
for (i = 0; i < NUM_RECT; ++i) { SetRect(&rect[i], i*dW, 0, (i+1)*dW, dH); FillRect(hDC, &rect[i], brush[i]);
}
SelectPalette(hDC, hOldPal, TRUE); EndPaint(hWnd, &ps);
break;
case WM_QUERYNEWPALETTE: hDC = GetDC(hWnd);
SelectPalette(hDC, hPal, FALSE); if (RealizePalette(hDC))
InvalidateRect(hWnd, NULL, TRUE); ReleaseDC(hWnd, hDC);
break;
case WM_PALETTECHANGED: hDC = GetDC(hWnd);
SelectPalette(hDC, hPal, FALSE); if (RealizePalette(hDC))
InvalidateRect(hWnd, NULL, TRUE); ReleaseDC(hWnd, hDC);
break;
case WM_DESTROY: DeleteObject(hPal);
for (i = 0; i < NUM_RECT; ++i) DeleteObject(brush[i]);
PostQuitMessage(0);
break;
default:
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
return 0;
}
//////////////////////////////////////////////////////////////////////
174 |
Глава 3. GDI. Палитры, растры, метафайлы |
|
|
Следует обратить внимание на определение типа LogPal в глобальной области видимости программы, которое расширяет стандартный тип LOGPALETTE. Наш пользо вательский тип включает структуру типа LOGPALETTE, после которой помещен мас сив структур PALETTEENTRY, содержащий (PAL_NUM_ENTRIES – 1) элементов. Объект типа LogPal объявляется в теле функции WndProc:
static LogPal pal;
Чтобы работать с этим объектом, интерпретируя его как переменную типа LOGPALETTE, объявляется указатель на тип LOGPALETTE, после чего ему присваивается адрес переменной pal:
LOGPALETTE* pLP = (LOGPALETTE*) &pal;
Количество входов в логической палитре не может превышать 236, так как 20 элементов системной палитры занято статическими цветами. В нашей программе это количество задано константой PAL_NUM_ENTRIES, равной 128, поскольку это даже перекрывает потребности приложения, выводящего 16 градаций зеленого цвета.
Создание логической палитры осуществляется в блоке обработки сообщения WM_CREATE. Для этого сначала инициализируются поля объекта pal, адресуемые через указатель pLP, причем массив palPalEntry равномерно заполняется распределенными градациями зеленого цвета. После этого вызывается функция CreatePalette. Реализа ция палитры происходит при обработке сообщений WM_QUERYNEWPALETTE и WM_PALETTECHANGED. И наконец, в блоке обработки сообщения WM_PAINT логичес кая палитра используется после выбора ее в контекст устройства при помощи функ ции SelectPalette.
После запуска программы вы должны получить картинку, показанную на рис. 3.5.
Рис. 3.5. Использование специализированной палитры (256-цветный режим)
Растры
Графические объекты, рассмотренные в главе 2, такие как пикселы, линии и замк нутые фигуры, могут использоваться для построения инженерных и финансовых диаграмм, чертежей, геометрических узоров и иных графических композиций. Гео метрические фигуры в этих изображениях описываются точными математически ми формулами. Соответствующая область программирования компьютерной гра фики называется векторной графикой (vector graphics).
В другой, не менее важной области компьютерной графики используются оциф рованные изображения, полученные из окружающего мира. Эта область называ ется растровой графикой (bitmap graphics). Обычно растровые изображения по лучают от таких устройств, как цифровой фотоаппарат, сканер, видеокамера, либо
Растры |
175 |
|
|
|
|
создают в каком нибудь графическом редакторе, к которым относится, например, Microsoft Paint или Adobe Photoshop.
Растровый, или битовый, образ (bitmap) — это оцифрованное представление изоб ражения. Каждый пиксел изображения представлен в растровом образе одним или несколькими битами, в которых закодирован его цвет. В монохромных битовых об разах для хранения информации о каждом пикселе достаточно одного бита. Но для кодирования цветных изображений требуется более одного бита на пиксел. Число цветов, которые могут быть представлены в битовом образе, равно 2n, где n — количество битов на пиксел. Например, для старой модели дисплея VGA с поддер жкой 256 цветов битовые образы содержали по 8 битов на пиксел. Для современных мониторов, поддерживающих до 224 цветов, битовый образ должен содержать 24 бита на пиксел, когда для каждого RGB компонента цвета используется 8 битов.
Вранних версиях Windows использовался только один формат битового об раза, получивший позже наименование аппаратно зависимого растра, или DDB (device dependent bitmap). Особенность формата DDB состоит в том, что система всегда создает битовый образ в памяти с учетом характеристик конкретного гра фического оборудования. Например, если компьютер оснащен 256 цветным дис плеем, то созданный битовый образ будет содержать по 8 битов на пиксел. Фор мат DDB не подходил для переноса растров на другие компьютеры, так как характеристики графических устройств изменяются в очень широких пределах. Более того, даже на одном компьютере дисплей может работать в разных режи мах, в зависимости от текущих настроек экрана.
Начиная с Windows 3.0, был введен новый формат битовых образов, названный
аппаратно независимым растром, или DIB (device independent bitmap). Битовый образ DIB кроме самого массива пикселов содержит справочную информацию
орастре и цветовую таблицу. В цветовой таблице отражается соответствие двоич ного представления пикселов цветам RGB, поэтому битовые образы этого формата после сохранения в файле могут быть воспроизведены на любом растровом графи ческом устройстве. Если устройство, на которое переносится DIB, имеет более уз кий диапазон поддерживаемых цветов, то цвета из таблицы преобразуются к бли жайшим цветам, которые устройство может действительно воспроизвести.
Внастоящее время аппаратно зависимые растры (DDB) используются во внут ренней работе графической системы Windows, а также для представления тех битовых образов в программе, которые не предназначены для передачи во внешний мир. Аппаратно независимые растры (DIB), напротив, применяются для обмена битовыми образами между программами как в форме файлов, так и через буфер обмена Windows.
Мы начнем наше путешествие по растровой тематике с рассмотрения DIB, потом перейдем к DDB и в завершение познакомимся с новым типом растров, поддерживаемым в Win32 GDI, — DIB секциями.
Аппаратно-независимые растры
Аппаратно независимые растры (DIB) содержат полную информацию об изоб ражении, что позволяет правильно отображать изображение на самых различных устройствах. Обычно файлы, в которых сохраняется DIB, имеют расширение .bmp. Поэтому формат DIB растров имеет альтернативное наименование «файловый формат BMP».
176 |
Глава 3. GDI. Палитры, растры, метафайлы |
|
|
Файловый формат BMP
Компоненты BMP формата, размещаемые в памяти последовательно один за дру гим, перечислены в табл. 3.3.
Таблица 3.3. Формат DIB-растра (Файловый формат BMP)
Компонент |
Размер |
Примечание |
|
|
|
Заголовок растрового файла |
|
|
BITMAPFILEHEADER bmfHeader; |
14 áàéò |
|
Заголовок информационного блока |
|
|
BITMAPINFOHEADER bmiHeader; |
40 áàéò |
Возможно использование структуры |
|
|
BITMAPV4HEADER (108 áàéò) èëè |
|
|
BITMAPV5HEADER (124 байта) |
Цветовая таблица |
Переменный |
Может отсутствовать |
RGBQUAD bmiColors[]; |
|
|
Массив пикселов |
Переменный |
|
BYTE aBitmapBits[][]; |
|
|
|
|
|
Заголовок растрового файла
Структура BITMAPFILEHEADER, используемая для объявления заголовка растрового файла bmfHeader, имеет следующее определение:
typedef |
struct tagBITMAPFILEHEADER { |
|
WORD |
bfType; |
// тип файла |
DWORD |
bfSize; |
// размер файла в байтах |
WORD |
bfReserved1; // резервное поле (должно быть равно нулю) |
|
WORD |
bfReserved2; // резервное поле (должно быть равно нулю) |
|
DWORD |
bfOffbits; |
// байтовое смещение до начала массива пикселов |
} BITMAPFILEHEADER;
Поле bfType должно содержать ASCII символы B и M, которые, разумеется, означают bitmap. Соответствующие шестнадцатеричные значения равны 0x42 и 0x4D. При любых других значениях этого поля файл не будет опознаваться Windows как растровое изображение. Учтите, что слово типа WORD размещается в памяти, начиная с младшего байта, поэтому, если вы формируете заголовок, ис пользуйте инструкцию вида bfType = 0x4d42.
Поле bfSize содержит размер всего файла в байтах.
Поле bfOffbitsзадает байтовое смещение до начала растрового изображения. Если BMP файл прочитан в память, то поле bfOffbits позволяет вычислить адрес начала массива aBitmapBits.
Заголовокинформационногоблока
После заголовка растрового файла следует заголовок информационного блока bmiHeader, в котором содержится информация о размерах и цветовом формате растра. Соответ ствующая структура BITMAPINFOHEADERопределена в файле wingdi.h:
typedef |
struct |
tagBITMAPINFOHEADER{ |
|
DWORD |
biSize; |
|
// размер структуры BITMAPINFOHEADER |
LONG |
biWidth; |
|
// ширина растра в пикселах |
LONG |
biHeight; |
|
// высота растра в пикселах + ориентация |
WORD |
biPlanes; |
|
// количество плоскостей (должно быть равно 1) |
WORD |
biBitCount; |
// количество битов на пиксел |
|
DWORD |
biCompression; |
// алгоритм сжатия |
|
DWORD |
biSizeImage; |
// размер массива пикселов в байтах |
|
Растры |
|
177 |
|
|
|
|
|
|
LONG |
biXPelsPerMeter; // горизонтальное разрешение устройства вывода |
|
|
LONG |
biYPelsPerMeter; // вертикальное разрешение устройства вывода |
|
|
DWORD |
biClrUsed; |
// количество элементов в цветовой таблице |
|
DWORD |
biClrImportant; |
// количество элементов, реально используемых для вывода |
|
|
|
// растра |
|
} BITMAPINFOHEADER; |
|
|
Поля biWidth и biHeight определяют ширину и высоту битового изображения. Высота biHeight обычно является положительной величиной, но она может быть и отрицательной. Знак этого поля определяет порядок следования строк развертки в массиве пикселов. Положительное значение соответствует обратному порядку строк (снизу вверх), при котором первый пиксел массива является первым пиксе лом последней строки развертки изображения. Такие DIB растры называют пере вернутыми (bottom up). Отрицательное значение соответствует прямому порядку строк (сверху вниз), и такие DIB растры называют неперевернутыми (top down). В большинстве BMP файлов используется обратный порядок следования строк раз вертки.
Поле biPlanes задает количество цветовых плоскостей для целевого графическо го устройства. В разных устройствах может использоваться различная структура строк развертки (с одной или несколькими цветовыми плоскостями). Формат DIB поддерживает изображения только с одной плоскостью, поэтому поле biPlanes дол жно иметь единичное значение.
Поле biBitCount содержит количество битов, используемых для кодирования цвета одного пиксела. Иногда эту характеристику называют цветовой глубиной. Возможные значения поля приведены в табл. 3.4.
Таблица 3.4. Значения поля biBitCount
Значение |
Максимальное |
Размер |
Описание |
|
количество |
пиксела, |
|
|
цветов |
áàéò |
|
|
|
|
|
0 |
Зависит от |
|
Число битов на пиксел специфицируется форматом |
|
внедренного |
|
JPEG или PNG (только для Windows 98/2000) |
|
изображения |
|
|
1 |
21 (2) |
1 / 8 |
Монохромное изображение. Цветовая таблица |
|
|
|
bmiColors содержит два элемента, соответствую- |
|
|
|
щие двум значениям типа RGBQUAD. Каждый |
|
|
|
бит из массива aBitmapBits определяет индекс |
|
|
|
элемента массива bmiColors. Если бит равен 0, |
|
|
|
то он окрашивается в соответствии с содер- |
|
|
|
жимым bmiColors[0], если 1 — в соответствии |
|
|
|
с содержимым bmiColors[1] |
4 |
24 (16) |
1 / 2 |
Изображение содержит до 16 цветов, соответ- |
|
|
|
ственно, цветовая таблица bmiColors содержит |
|
|
|
до 16 значений типа RGBQUAD. Каждый байт |
|
|
|
в массиве aBitmapBits представляет два пиксела. |
|
|
|
Цвет пиксела определяется его 4-битным |
|
|
|
индексом в цветовой таблице |
8 |
28 (256) |
1 |
Изображение содержит до 256 цветов, и bmiColors |
|
|
|
содержит до 256 элементов. В этом случае |
|
|
|
каждый байт в массиве aBitmapBits представляет |
отдельный пиксел. Значение байта используется как индекс в цветовой таблице
продолжение
178 |
|
|
Глава 3. GDI. Палитры, растры, метафайлы |
|
|
|
|
Таблица 3.4 (продолжение) |
|
|
|
|
|
|
|
Значение |
Максимальное |
Размер |
Описание |
|
количество |
пиксела, |
|
|
цветов |
áàéò |
|
|
|
|
|
16 |
216 (65 536) |
2 |
Изображение содержит до 216 цветов (пикселы |
|
|
|
типа High Color). Если поле biCompression равно |
|
|
|
BI_RGB, то цветовая таблица bmiColors обычно |
|
|
|
отсутствует. Каждое слово (WORD) в массиве |
|
|
|
aBitmapBits представляет отдельный пиксел. |
|
|
|
Относительная интенсивность синего, зеленого |
|
|
|
и красного цветов представлена пятью битами для |
|
|
|
каждого цветового компонента. Старший знаковый |
|
|
|
разряд слова не используется |
|
|
|
Если поле biCompression равно BI_BITFIELDS, |
|
|
|
то после заголовка информационного блока |
|
|
|
и перед цветовой таблицей добавляются три |
|
|
|
двойных слова — маски для извлечения синей, |
|
|
|
зеленой и красной составляющих из слова |
|
|
|
в массиве aBitmapBits |
24 |
224 (16 777 216) |
3 |
Изображение содержит до 224 цветов (24- |
битные |
|
|
пикселы True Color). |
|
|
|
Цветовая таблица bmiColors обычно |
отсутствует. |
|
|
Каждый трехбайтный триплет в массиве |
|
|
|
aBitmapBits характеризует относительную интен- |
|
|
|
сивность синей, зеленой и красной составляющих |
|
|
|
для цвета очередного пиксела. Иногда таблица |
|
|
|
bmiColors может использоваться для оптимизации |
|
|
|
вывода на устройствах, работающих с палитрой. |
|
|
|
В этом случае цветовая таблица содержит число |
|
|
|
входов, специфицированное в поле biClrUsed |
32 |
224 (16 777 216) |
4 |
Изображение содержит до 224 цветов (32-битные |
|
|
|
пикселы True Color). Если поле biCompression |
|
|
|
равно BI_RGB, то цветовая таблица bmiColors |
|
|
|
обычно отсутствует. Каждое двойное слово |
(DWORD) в массиве aBitmapBits характеризует отдельный пиксел. Относительная интенсивность синего, зеленого и красного цветов задана тремя байтами в двойном слове. Старший байт не используется.
Если поле biCompression равно BI_BITFIELDS, то после заголовка информационного блока и перед цветовой таблицей добавляются три
двойных слова — маски для извлечения синей, зеленой и красной составляющих из двойного слова в массиве aBitmapBits5
Иногда старший байт в 32 битных пикселах True Color используется для хране ния альфа канала, то есть данных о прозрачности пиксела.
Поле biCompression определяет алгоритм сжатия, применяемый к массиву пик селов. Допустимые значения поля приведены в табл. 3.5.
Если поле biHeight имеет отрицательное значение, то поле biCompression может принимать только значения BI_RGB или BI_BITFIELDS, поскольку неперевернутые растры не допускают сжатие.
Растры |
|
179 |
|
|
|
||
|
Таблица 3.5. Значения поля biCompression |
||
|
|
|
|
Константа |
Êîä |
Описание |
|
|
|
|
|
|
BI_RGB |
0x0 |
Несжатое изображение |
|
BI_RLE8 |
0x1 |
Изображение с кодировкой 8 бит/пиксел, сжатое с использованием |
|
|
|
алгоритма RLE |
|
BI_RLE4 |
0x2 |
Изображение с кодировкой 4 бит/пиксел, сжатое с использованием |
|
|
|
алгоритма RLE |
|
BI_BITFIELDS |
0x3 |
Несжатые изображения с кодировкой 16 и 32 бит/пиксел. В изобра- |
|
|
|
жение включаются три битовые маски, определяющие способ |
|
|
|
хранения компонентов RGB |
|
|
|
|
Чаще всего поле biCompression содержит значение BI_RGB. Графические редакто ры от Microsoft, а также среда разработки Visual Studio генерируют BMP файлы только в несжатом формате. При отсутствии сжатия каждая строка развертки изоб ражения представляет собой упакованный массив пикселов. Размер пиксела в бай тах указан в табл. 3.4. Строка развертки всегда выравнивается по ближайшей гра нице двойного слова, а при необходимости строка дополняется нулями.
В растре DIB с кодировкой 4 и 8 бит/пиксел для уменьшения размеров растра может применяться необязательное сжатие по алгоритму RLE (Run Length Encoding). Для 8 битных изображений этот алгоритм ищет последовательность смежных байтов с одинаковым значением, после чего заменяет их двумя байтами, в которых указывается счетчик повторений и код повторяющегося байта. Пре дусмотрены особые служебные последовательности для неповторяющихся бай тов, для конца строки и конца изображения. Более подробное описание алгоритма RLE можно найти в книге [6].
Следующим полем в структуре BITMAPINFOHEADER является поле biSizeImage, содержащее размер массива пикселов в байтах. Если значением biCompression явля ется BI_RGB, то поле biSizeImage может быть равно нулю. В этом случае GDI вычис лит размер изображения по ширине, высоте и количеству битов на пиксел. Но при использовании сжатия RLE, а также для файлов формата JPEG или PNG это поле должно содержать фактический размер данных изображения.
Поля biXPelsPerMeter и biYPelsPerMeter содержат, соответственно, горизонтальное и вертикальное разрешение в пикселах на метр для целевого графического устрой ства. Приложение может использовать это значение, чтобы выбрать растр из груп пы доступных растров, который наиболее близок к характеристикам текущего уст ройства вывода.
Поле biClrUsed задает количество элементов в цветовой таблице. Для DIB рас тров с количеством цветов, не превышающим 256, нулевое значение поля biClrUsed означает максимально возможное количество цветов, указанное в табл. 3.4. Обыч ный BMP файл, хранящийся на диске, должен содержать полную цветовую таб лицу с максимальным количеством элементов. Неполная цветовая таблица мо жет использоваться только в DIB растрах, которые хранятся в памяти.
Поле biClrImportant определяет количество элементов, реально необходимых для отображения растра. Нулевое значение поля означает, что используются все цвета из цветовой таблицы.
Следует отметить, что структура BITMAPINFOHEADER обычно называется «верси ей 3» описания растра. Этот номер версии принято относить к тем аспектам Win32
180 |
Глава 3. GDI. Палитры, растры, метафайлы |
|
|
API, которые появились в Windows 3.1. Соответственно, новые возможности, до бавленные в Windows 95 и Windows NT 4.0, именуются «версией 4», а новые воз можности Windows 98 и Windows 2000 относятся к «версии 5».
В Windows 95 и Windows NT 4.0 появилась новая структура BITMAPV4HEADER, а в Windows 98 и Windows 2000 была добавлена структура BITMAPV5HEADER. Начало этих новых структур совпадает с типом BITMAPINFOHEADER. В структуре версии 4 появились новые поля для цветовых масок RGBA1, цветовых пространств, конеч ных точек и гамма коррекции (для поддержки ICM 1.02). В структуре версии 5 добавились новые типы цветовых пространств, рекомендации по воспроизведению и данные цветового профиля, ориентированные на поддержку ICM 2.0. Подробные описания этих структур приведены в MSDN.
Цветовая таблица
Цветовая таблица является массивом структур типа RGBQUAD. Этот тип определен следующим образом:
typedef |
struct tagRGBQUAD { |
BYTE |
rgbBlue; |
BYTE |
rgbGreen; |
BYTE |
rgbRed; |
BYTE |
rgbReserved; |
} RGBQUAD;
Поля структуры задают относительную интенсивность для синей, зеленой и красной составляющих цвета пиксела. Последнее поле в структуре является ре зервным.
Обычно цветовая таблица используется в DIB растрах, содержащих не более 256 цветов. В этом случае каждый пиксел массива aBitmapBits содержит индекс в цветовой таблице. Иногда цветовую таблицу включают и в DIB растры формата True Color (Hi Color), что, на первый взгляд, кажется избыточным. Но это позволяет отображать указанные растры с требуемым качеством передачи цветов на устрой ствах, не поддерживающих формат True Color, а работающих с цветовой палитрой.
Количество элементов в цветовой таблице задается в поле biClrUsed заголовка информационного блока. Если это поле имеет нулевое значение, то используется максимальное количество элементов для заданной цветовой глубины.
Массив пикселов
Пикселы изображения хранятся в массиве пикселов aBitmapBits. Если поле biHeight заголовка информационного блока содержит положительное значение, то строки развертки хранятся в обратном порядке, если же значение отрицательное — то в пря мом порядке.
Пикселы упаковываются внутри строки развертки для экономии места. Стро ки дополняются битами до границы двойного слова.
Количество байтов на строку вычисляется по следующей формуле:
bytesPerLine = ((width * bitCount + 31) / 32) * 4;
где width — ширина изображения в пикселах, а bitCount — количество бит на пиксел.
1 В режиме RGBA цвета сохраняются как совокупность Red , Green , Blue и Alpha компонентов.
2ICM — Integrated Color Management — набор функций уровня API и встроенных программных мо дулей, предназначенный для сквозного управления цветопередачей при воспроизведении изобра жений на разном периферийном оборудовании.
