14752

Форматы графических файлов .BMP и .PCX. Групповое кодирование изображения в этих форматах

Лабораторная работа

Информатика, кибернетика и программирование

Лабораторная работа №3 Тема: Форматы графических файлов .BMP и .PCX. Групповое кодирование изображения в этих форматах. Название: Microsoft Windows Bitmap Известен также как: BMP DIB Windows BMP Windows DIB Compatible Bitmap Тип: Растровый Цвета: 1 4 8 16 24 и 32битовые Сжатие: RLE без сжати

Русский

2013-06-09

242.5 KB

26 чел.

Лабораторная работа №3

Тема: Форматы графических файлов .BMP и .PCX. Групповое кодирование изображения в этих форматах.

Название:  Microsoft Windows Bitmap

Известен также как:  BMP, DIB, Windows BMP, Windows DIB, Compatible Bitmap

Тип:   Растровый

Цвета:   1-, 4-, 8-, 16-, 24- и 32-битовые Сжатие:   RLE, без сжатия

Максимальный размер изображения:   32 К х 32 К и 2 Г х 2 Г пикселей Больше одного изображения в файле:   Нет

Формат чисел:  "Младший в младшем" Разработчик:  Microsoft Corporation

Платформы:  Intel-машины с Microsoft Windows, Windows NT, Windows 95, OS/2 и MS-DOS

Поддерживается приложениями:   Их слишком много для того, чтобы перечислять

Применение:  Используется как стандартный формат хранения растровых изображений в среде Microsoft Windows. Формат основан на внутренних структурах представления растровых данных Windows, но несмотря на это поддерживается многими не Windows"- и даже "не РС"-приложениями.

Комментарии:  Предназначен для программистов, имеющих доступ к Developer's Network Knowledge Base и Software Development Kits (SDKs) фирмы Microsoft. Используемая в BMP простая схема сжатия по алгоритму группового кодирования не очень эффективна при обработке сложных изображений. Многочисленные варианты этого формата и его несоответствие формату OS/2 BMP могут стать причиной недоразумений.

Обзор

Microsoft Windows Bitmap (BMP) является одним из немногих графических форматов, поддерживаемых операционной средой Microsoft Windows. BMP это собственный растровый формат Windows, который используется для хранения практически всех типов растровых данных. Большинство приложений, работающих с графикой и изображениями в среде Microsoft Windows, поддерживают создание и отображение файлов в формате BMP. Он очень популярен в операционной системе MS-DOS, является "родным" форматом растровых файлов для системы OS/2.

Исходный растровый формат, созданный еще для Windows 1.0, был очень простым. Он содержал палитру с фиксированным количеством цветов, не поддерживал сжатие растровых данных и был рассчитан на самые популярные в то время графические платы для IBM PC (CGA, EGA, Hercules и другие). Этот отживший свое формат сейчас часто называют исходным аппаратно-зависимым растром для Windows (DDB).

В процессе разработки Windows 2.0 и в саму среду, и в формат BMP была введена поддержка программируемой цветовой палитры. Это позволило сохранять определяемые пользователем цветовые данные вместе с растровыми данными, в которых эти цвета применялись. Такая обобщенная информация, записанная в памяти, называется аппаратно-независимым растром Microsoft (DIB). Эта же информация, переписанная в файл, называется растровым форматом Microsoft, или BMP. Когда ссылаются на формат DIB, имейте в виду, что на самом деле подразумевают BMP.

Благодаря формату BMP фирма Microsoft даже стала "соучастницей" разработки ранних версий операционной системы IBM OS/2: в качестве растрового формата для графического интерфейса пользователя системы OS/2 (Presentation Manager) взяли формат Windows BMP. Таким образом, форматы BMP в Windows 2.х и OS/2 1 .х идентичны.

Формат BMP, модифицированный для Windows 3.0, мало отличается от своего предшественника, растрового формата OS/2 Presentation Manager. Однако последующие модификации растрового формата IBM, вызванные необходимостью поддержки OS/2 Presentation Manager 2.x, привели уже к значительному расхождению между вариантами формата BMP для Windows и OS/2. Нынешняя версия BMP для Windows 4.0 (Windows 95) содержит все свойства и возможности вариантов BMP для Windows 2.x, Windows З.х и Windows NT, однако весьма далека от OS/2 BMP 2.x.

Структура файлов в формате BMP тесно связана с интерфейсом прикладного программирования (API) и для Windows, и для OS/2. В этом отношении BMP никогда не рассматривался как переносимый формат и не использовался для обмена растровыми данными между различными операционными системами. По мере изменения API этих систем изменялся и BMP.

Сейчас существуют три версии BMP для Windows (2.x, З.х и 4.х [Windows 95]), две версии для OS/2 (1.х и 2.х, в шести вариантах) и одна для Windows NT. Мы рассмотрим все Windows-версии, в том числе и версию для Windows NT. Не будет забыт и исходный аппаратно-зависимый растровый формат Microsoft. Сведения о версиях и вариантах BMP для OS/2 рассматриваются в параграфе о формате OS/2 BMP.

Все версии BMP разрабатывались для компьютеров, базирующихся на процессорах Intel, поэтому их общей чертой является хранение данных в порядке байтов "младший в младшем". Текущая версия формата BMP независима от устройств и позволяет записывать изображения различного качества, вплоть до 32-битовых цветных. Основательная переработка формата превратила его в хороший формат общего назначения, который может использоваться для хранения цветных и черно-белых изображений, если размер файла не является критическим. Основными достоинствами этого формата можно считать простоту и широкую поддержку на рынке PC.

Метод сжатия, применяемый в формате BMP, является одним из вариантов группового кодирования (RLE), но большинство файлов BMP хранятся в несжатом виде. Исключение составляет заставка Microsoft Windows, поставляемая со всеми версиями этого продукта. Хотя RLE позволяет кодировать данные без потерь и отличается простотой и скоростью распаковки, он не считается лучшим методом сжатия.

Несмотря на то, что формат BMP прекрасно описан, спецификационного документа, официально распространяемого фирмой Microsoft, не существует. Описание структуры и методов кодирования данных можно встретить во многих справочниках программиста, руководствах, интерактивных подсказках и файлах, связанных с Developer's Network Knowledge Base и Software Development Toolkits фирмы Microsoft.

Организация файла

Файлы DDB для Windows l.x содержат два раздела: заголовок файла и растровые данные. Цветовая палитра, равно как и другие элементы, которые могли бы сделать этот формат аппаратно-независимым, не предусмотрены; сжатие растровых данных не поддерживается.

Заголовок файла

Растровые данные

Файлы BMP для Windows 2.x, З.х и 4.х содержат четыре раздела: заголовок файла, информационный заголовок растра, цветовую палитру и растровые данные. Из них только палитра не обязательна ее наличие зависит от битовой глубины растровых данных. Заголовок файла BMP имеет длину 14 байтов и практически идентичен заголовку файла DDB версии l.x. За заголовком файла следует еще один заголовок, который называют заголовком растра, а за ним

палитра переменной длины и растровые данные.

Заголовок файла

Заголовок растра

Цветовая палитра

Растровые данные


Подробное описание файла

Ниже подробно описываются исходный формат Windows DDB и версии формата BMP 2.x, З.х и 4.х.

Версия I — Device-Dependent Bitmap (Microsoft Windows l.x)

Файлы DDB содержат только заголовок, за которым следуют несжатые растровые данные. Ниже показана структура этого 10-байтового заголовка.

typedef struct _WinlxHeader {

WORD Type;         /* Идентификатор типа файла (всегда 0) */

WORD Width;        /* Ширина растра в пикселях */

WORD Height;       /* Высота растра в строках развертки */

WORD ByteWidth;    /* Ширина растра в байтах */

BYTE Planes;       /* Количество цветовых плоскостей */

BYTE BitsPerPixel; /* Количество битов на пиксель */

} WIN1XHEADER;

Поле Type указывает тип файла, и в версии 1 .х его значение всегда равно 0. Поля Width и Height определяют размеры растра в пикселях (Width) и строках развертки (Height).

Поле ByteWidth содержит информацию о ширине растра в байтах. Предполагается, что в значении этого поля учтено и наличие заполнителя строк развертки (если таковой имеется).

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

Значение поля BitsPerPixel — это размер пикселя в битах. Обычно оно равно 1, 4 или 8.

Непосредственно за заголовком следуют несжатые данные изображения. Каждый пиксель хранится в виде индекса фиксированной системной цветовой таблицы Windows 1.0. Наличие заполнителя строк развертки можно определить путем сравнения выраженной в байтах расчетной ширины строки с ее реальной шириной (записана в поле ByteWidth).

BMP версии 2 (Microsoft Windows 2. ж)

Все версии формата BMP начинаются с 14-байтового заголовка:

typedef struct _WinBMPFileHeader {

WORD FileType;      /* Тип файла, всегда 4D42h ("BM") */

DWORD FileSize;      /* Размер файла в байтах */

WORD Reservedl;     /* Всегда 0 */

WORD Reserved2;     /* Всегда 0 */

DWORD BitmapOffset; /* Начало данных изображения (в байтах) */

} WINBMPFILEHEADER;

Поле FileType содержит 2-байтовое магическое число, используемое для идентификации типа файла; его значение всегда равно 4D42h, или BM (в формате ASCII). Приложение, читающее файлы Windows BMP, прежде чем приступить к обработке данных, должно проверить, есть ли в файле этот идентификатор.

Поле FileSize содержит общий размер файла BMP в байтах, который должен совпадать с размером, сообщаемым файловой системой. В этом поле полезное значение хранится только в том случае, если растровые данные сжаты; в несжатых файлах BMP оно обычно равно 0.

Поля Reservedl и Reserved2 не содержат полезных данных и в BMP-заголовке, записываемом на диск, обычно устанавливаются в 0. Эти поля часто используются приложениями после считывания заголовка в память.

В поле BitmapOffset хранятся сведения о начальном смещении растровых данных от начала файла (в байтах).

В файлах BMP версии 2.х за заголовком файла следует второй заголовок, называемый заголовком растра. Он содержит информацию, относящуюся к растровым данным, имеет длину 12 байтов и следующий формат:

typedef struct  _Win2xBitmapHeader {

DWORD Size;          /* Размер заголовка в байтах */

SHORT Width;         /* Ширина изображения в пикселях */

SHORT Height;        /* Высота изображения в пикселях */

WORD Planes;         /* Количество цветовых плоскостей */

WORD BitsPerPixel;   /* Количество битов на пиксель */ } WIN2XBITMAPHEADER;

Поле Size указывает размер заголовка в байтах. В BMP-файлах Microsoft Windows 2.x его значение всегда равно 12.

Поля Width и Height определяют соответственно ширину и высоту изображения в пикселях. Если Height — положительное число, то изображение представляет собой "восходящий" растр с началом в левом нижнем углу. Если Height — отрицательное число, то изображение представляет собой "нисходящий" растр с началом в левом верхнем углу. Наличие заполнителя строк развертки в значении поля Width не учитывается. В поле Planes задается количество цветовых плоскостей, используемых для представления растровых данных. Файлы BMP всегда состоят из одной цветовой плоскости, поэтому это поле содержит 1.

В поле BitsPerPixel указывается количество битов на пиксель в каждой плоскости. Диапазон его значений от 1 до 24. Для API Windows 2.x допустимы только значения 1, 4, 8 и 24.

Заголовок растра в версии Windows 2.x идентичен заголовку растра в OS/2 1.х. Их различие состоит лишь в том, что в файлах Windows BMP в полях Width и Height хранятся значения со знаком.

За заголовком растра следуют данные цветовой палитры. Если растровые данные состоят из 1-, 4- или 8-битовых элементов, то в BMP-файле всегда присутствует цветовая палитра. В случае 24-битовых растровых данных цветовая палитра никогда не используется (да она и не нужна). Элемент палитры имеет длину 3 байта и следующую структуру:

typedef struct _Win2xPaletteElement {

BYTE Blue;          /* Синяя составляющая */

BYTE Green;         /* Зеленая составляющая */

BYTE Red;           /* Красная составляющая */ } 

WIN2XPALETTEELEMENT;

В полях Blue, Green и Red содержатся значения цветовых составляющих пикселя. Диапазон значений каждой из этих составляющих колеблется от 0 до 255.

Размер цветовой палитры вычисляется из значения BitsPerPixel. Цветовая палитра может состоять из 2, 16, 256 или 0 элементов, что соответствует значениям BitsPerPixel, равным 1, 4, 8 и 24. Количество элементов цветовой палитры определяется следующим образом:

NumberOfEntries = 1 << BitsPerPixel;

Чтобы узнать, содержит ли BMP-файл цветовую палитру, нужно вычислить количество байтов, расположенных между заголовком растра и растровыми данными, а полученное значение разделить на размер одного элемента палитры. Предполагая, что ваш код компилируется с выравниванием по 1-байтовым структурным элементам, получим формулу:

NumberOfEntries = (BitmapOffset - sizeof(WINBMPFILEHEADER) -

sizeof(WIN2XBITMAPHEADER)) / sizeof(WIN2XPALETTEELEMENT);

Если значение NumberOfEntries равно 0, то данные палитры отсутствуют; в противном случае значение NumberOfEntries равно количеству элементов в цветовой палитре.

BMP версии 3 (Microsoft Windows З.x)

Файлы BMP версии З.х начинаются с такого же 14-байтового заголовка, что и файлы версии 2.х. За заголовком файла также следует заголовок растра, который представляет собой расширенную версию заголовка растра версии 2.х:

его длина составляет 40 байтов и он содержит шесть дополнительных полей:             '

typedef struct _Win3xBitmapHeader {

DWORD Size;            /* Размер этого заголовка в байтах */

SHORT Width;           /* Ширина изображения в пикселях */

SHORT Height;          /* Высота изображения в пикселях */

WORD Planes;          /* Количество цветовых плоскостей */

WORD BitsPerPixel;    /* Количество битов на пиксель */

/* Далее следуют поля, добавленные в Windows З.х */

DWORD Compression;     /* Используемые методы сжатия */

DWORD SizeOfBitmap;    /* Размер растра в байтах */

LONG HorzResolution; /* Горизонтальное разрешение в пикселях на метр*/

LONG VertRezolution; /* Вертикальное разрешение в пикселях на метр */ DWORD ColorsUsed;      /* Количество цветов в изображении */ DWORD Colorslmportant; /* Минимальное число "важных" цветов */ } WIN3XBITMAPHEADER;

Поле Size указывает размер заголовка в байтах. Для файлов Microsoft Windows 3-х его значение всегда равно 40.

Поля Width и Height определяют соответственно ширину и высоту изображения в пикселях. Если Height —положительное число, то изображение представляет собой "восходящий" растр с началом в левом нижнем углу. Если Height — число отрицательное, то изображение представляет собой "нисходящий" растр с началом в левом верхнем углу. Наличие заполнителя строк развертки в значении Width не учитывается.

Значение поля Planes — это количество цветовых плоскостей, используемых для представления растровых данных..

Файлы BMP всегда состоят из одной цветовой плоскости, поэтому значением этого поля всегда является 1.

В поле BitsPerPixel указывается количество битов на пиксель в каждой плоскости. Диапазон его значений от 1 до 24. Для API Windows З.х допустимы только значения 1, 4, 8 и 24.

Поле Compression определяет метод кодирования растровых данных. Значение 0 указывает на то, что данные не сжаты,

1 — что был применен 8-битовый алгоритм RLE; 2 — что был применен 4-битовый алгоритм RLE. (Более подробная информация о методах группового кодирования, применяемых в формате BMP, будет изложена ниже.)

Поле SizeOfBitmap задает размер растра в байтах. Значение этого поля равно 0, если растр не сжат (в этом случае декодер вычисляет величину изображения по его размерам).

Поля HorzResolution и VertResolution содержат информацию соответственно о горизонтальном и вертикальном разрешении, выраженном в пикселях на метр. Эти поля помогают программе чтения BMP выбирать необходимое разрешение при печати и воспроизведении BMP-файла.

В поле ColorsUsed указывается количество цветов в палитре. Если значением этого поля является 0, а значение BitsPerPixel меньше 16, то количество элементов равно максимально возможному для этой цветовой таблицы. В файлах BMP, значение поля BitsPerPixel которых больше или равно 16, цветовая палитра отсутствует. Значение поля ColorsUsed вычисляется из значения поля BitsPerPixel:

ColorsUsed = 1 <<BitsPerPixel;

Поле Colorslmportant содержит сведения о количестве наиболее необходимых цветов в палитре, определяемом частотой их появления в растровых данных. Чем чаще цвет встречается в растре, тем он более важен. Это поле используется для обеспечения максимально точного воспроизведения изображения на графических устройствах, которые не поддерживают необходимое количество цветов. Так, в 8-битовом изображении, содержащем, например, 142 цвета, можно выделить всего десяток-другой цветов, составляющих основную часть этого изображения. Если эти цвета будут определены, то 16-цветный адаптер дисплея отобразит данное изображение достаточное точно, использовав для этой цели 16 наиболее часто встречающихся цветов. Самые важные цвета в палитре всегда хранятся первыми. Если все цвета в цветовой таблице должны рассматриваться как важные, то значение поля ColorsImportant равно 0.

Цветовая палитра, которая может следовать за заголовком растра, в основном совпадает с палитрой версии 2.х, но в ее элемент включен дополнительный байт заполнителя, из-за чего размер элемента увеличился до 4 байтов. Такое решение позволяет читать элементы палитры как 4-байтовые значения, что повышает эффективность считывания элементов в память и упрощает их просмотр в шестнадцатеричном дампе или отладчике.

typedef struct Win3xPaletteElement {

BYTE Blue;     /* Синяя составляющая */

BYTE Green;    /* Зеленая составляющая */

BYTE Red;      /* Красная составляющая */

BYTE Reserved; /* Заполнитель (всегда 0) */

} WIN3XPALETTEELEMENT;

В полях Blue, Green и Red содержатся значения цветовых составляющих для пикселя. Значения каждой из них могут находиться в диапазоне от 0 до 255.

Поле Reserved служит для заполнения структуры до границы двойного слова и всегда равно 0.

BMP версии 3 (Microsoft Windows NT)

В Windows NT с целью хранения 16- и 32-битовых данных используется разновидность формата BMP для Windows З.х. Здесь имеются три дополнительных поля, размещенных после заголовка растра, на месте цветовой палитры. Длина заголовка растра — 40 байтов. Он имеет следующий формат:

typedef struct _WinNtBitmapHeader {

DWORD Size;              /* Размер заголовка в байтах */

LONG Width;              /* Ширина изображения в пикселях */

LONG Height              /* Высота изображения в пикселях */

WORD Planes;            /* Количество цветовых плоскостей */

WORD BitsPerPixel;      /* Количество битов на пиксель */

DWORD Compression;       /* Используемые методы сжатия */

DWORD SizeOfBitmap;      /* Размер растра в байтах */

LONG HorzResolution     /* Горизонтальное разрешение в пикселях на метр */

LONG VertRezolution;    /* Вертикальное разрешение в пикселях на метр */

DWORD ColorsUsed;        /* Количество цветов в изображении */

DWORD Colorslmportant;   /* Минимальное число "важных" цветов */

} WINNTBITMAPHEADER;

Все поля, за исключением Compression, соответствуют аналогичным полям формата BMP v3.x. Поле Compression определяет метод кодирования, применяемый для сжатия растровых данных. Значение О указывает на то, что данные не сжаты, 1 — что был использован 8-битовый алгоритм RLE, 2 — что был использован 4-битовый алгоритм RLE, 3 — что применялось кодирование битовых полей. Если битовая глубина растра равна 16 или 32 битам на пиксель, то поддерживается только значение 3 и после заголовка вместо цветовой палитры будут присутствовать поля RedMask, GreenMask и BlueMask. Если значение Compression не равно 3, то такой файл идентичен BMP-файлу версии Windows З.х.

typedef _WinNtBitЈieldMasks{

DWORD RedMask;     /* Маска, обозначающая биты красной составляющей */

DWORD GreenMask;   /* Маска, обозначающая биты зеленой составляющей */

DWORD BlueMask;    /* Маска, обозначающая биты синей составляющей */

} WINNTBITFIELDMASKS;

В полях RedMask, GreenMask и BlueMask указывается, какие биты в пиксельном значении соответствуют конкретному цвету 16- и 32-битовых растров. Биты в этих масках обязательно должны быть смежными и не должны содержать перекрывающихся полей. Биты пикселя располагаются в порядке от старшего к младшему. Для 16-битовых растров часто применяется формат RGB565, который определяет по 5 битов для представления красного и синего цветов и 6 битов для представления зеленого:

RedMask   = OxFSOOOOOO; /* 1111 1000 0000 0000 0000 0000 0000 0000 */ GreenMask = Ox07EOOOOO; /* 0000 0111 1110 0000 0000 0000 0000 0000 */ BlueMask = OxOOlFOOOO; /* 0000 0000 0001 1111 0000 0000 0000 0000 */

Для 32-битовых растров применяется формат RGB101010, определяющий по 10 битов для представления красного, синего и зеленого цветов:

RedMask   = OxFFCOOOOO /* 1111 1111 1100 0000 0000 0000 0000 0000 */ GreenMask = Ox003FFOOO /* 0000 0000 0011 1111 1111 0000 0000 0000 */ BlueMask = OxOOOOOFFC /* 0000 0000 0000 0000 0000 1111 1111 1100 */

Версия 4 (Microsoft Windows 95)

Файлы BMP версии 4.х начинаются с такого же 14-байтового заголовка, как и файлы версий 2.х и З.х. За заголовком файла также следует заголовок растра, который представляет собой расширенный вариант заголовка растра версии З.х и включает поля маски из формата BMP для NT. Длина заголовка растра равна 108 байтам и он содержит 17 дополнительных полей:

typedef struct _Win4xBitmapHeader (

DWORD Size;            /* Размер заголовка в байтах */

LONG Width;            /* Ширина изображения в пикселях */

LONG Height;           /* Высота изображения в пикселях */

WORD Planes;           /* Количество цветовых плоскостей */

WORD BitsPerPixel;     /* Количество битов на пиксель */

DWORD Compression;     /* Используемые методы сжатия */

DWORD SizeOfBitmap;    /* Размер растра в байтах */

LONG HorzResolution;/* Горизонтальное разрешение в пикселях на метр */

LONG ^ertRezolution;  /* Вертикальное разрешение в пикселях на метр */

DWORD ColorsUsed;       /* Количество цветов в изображении */

DWORD Colors Important;    /* Минимальное число "важных" цветов */

/* Далее следуют поля, добавленные в версии Windows 4.x */

DWORD RedMask;  /* Маска, обозначающая биты красной составляющей */

DWORD GreenMask; /* Маска, обозначающая биты зеленой составляющей */ DWORD BlueMask;    /* Маска, обозначающая биты синей составляющей */ DWORD AlphaMask;   /* Маска, обозначающая биты альфа-составляющей */ DWORD CSType;   /* Тип цветового пространства */

LONG RedX;     /* Х-координата конечной точки красного */

LONG RedY;     /* У-координата конечной точки красного */

LONG RedZ;     /* Z-координата конечной точки красного */

LONG GreenX;   /* Х-координата конечной точки зеленого */

LONG GreenY;   /* Y-координата конечной точки зеленого */

LONG GreenZ;   /* Z-координата конечной точки зеленого */

LONG BlueX;    /* Х-координата конечной точки синего */

LONG BlueY;    /* Y-координата конечной точки синего */

LONG BlueZ;    /* Z-координата конечной точки синего */

DWORD GammaRed;/* Масштабирующее гамма-значение координаты красного */ DWORD GammaGreen;/* Масштабирующее гамма-значение координаты зеленого */ DWORD GammaBlue; /* Масштабирующее гамма-значение координаты синего */

} WIN4XBITMAPHEADER;

Поле Size содержит данные о размере заголовка в байтах. В случае BMP-файлов для Microsoft Windows 4.x значение этого поля всегда равно 108.

Поля Width и Height задают соответственно ширину и высоту изображения в пикселях. Если поле Height содержит положительное число, то изображение представляет собой "восходящий" растр с началом в левом нижнем углу. Если значение поля Height — число отрицательное, то изображение представляет собой "нисходящий" растр с началом в левом верхнем углу. Значение поля Width указывается без учета заполнителя строк развертки.

В поле Planes хранится информация о количестве цветовых плоскостей, используемых для представления растровых данных. Файлы BMP всегда содержат одну цветовую плоскость, поэтому значение этого поля всегда равно 1.

В поле BitsPerPixel задается количество битов на пиксель изображения. Значения этого поля находятся в диапазоне от 1 до 32. Для API Windows 4.x допустимы только значения 1, 4, 8, 16, 24 и 32.

Поле Compression определяет метод сжатия растровых данных. Значение 0 указывает на то, что данные не сжаты, 1 — что был использован 8-битовый алгоритм RLE, 2 — что был использован 4-битовый алгоритм RLE, 3 — что применялось кодирование битовых полей. Если битовая глубина растра равна 16 или 32 битам на пиксель, то поддерживается только значение 3.

В поле SizeOfBitmap задается размер растра в байтах. Если значение этого поля равно нулю, то данные либо вообще не сжаты, либо применено кодирование битовых полей в этом случае декодер вычисляет величину изображения по его размерам.

Поля HorzResolution и VertResolution содержат соответственно данные о разрешении в горизонтальном и вертикальном направлении, выраженном в пикселях на метр. Эти поля помогают программе чтения BMP выбирать корректное разрешение при печати и отображении BMP-файла.

В поле ColoisUsed хранится информация о количестве цветов в палитре изображения. Если значение этого поля равно 0,

но BMP-файл содержит палитру, то количество ее элементов равно максимально возможному размеру этой цветовой таблицы. Если пиксельная глубина растра — 16 и выше, то палитра всегда отсутствует, а значение этого поля равно 0.

Поле Colorslmportant определяет количество наиболее необходимых цветов в палитре, которое зависит от частоты их появления в растровых данных. Чем чаще цвет встречается в растре, тем он важнее. Более подробно этот вопрос рассмотрен в описании этого поля для заголовка растра версии Windows З.х.

В полях RedMask, GreenMask, BlueMask и AlphaMask указывается, какие биты в пиксельном значении соответствуют конкретному цвету и альфа-каналу в 16- и 32-битовых растрах. Биты в этих масках должны быть смежными и не перекрываться. Биты пикселя всегда располагаются в порядке от старшего к младшему. Для 16-битовых растров часто применяется формат RGB555, который определяет по 5 битов для представления красного, синего, зеленого и альфа:

AlphaMask = OxFSOOOOOO; /* 1111 1000 0000 0000 0000 0000 0000 0000 */ RedMask    = Ox07COOOOO; /* 0000 0111 1100 0000 0000 0000 0000 0000 */ GreenMask = ОхООЗЕОООО; /* 0000 0000 0011 1110 0000 0000 0000 0000 */ BlueMask   = OxOOOlFOOO; /* 0000 0000 0000 0001 1111 0000 0000 0000 */

Для 32-битовых растров применяется формат RGB888, который задает по 8 битов для представления красного, синего, зеленого и альфа:

AlphaMask = OxFFOOOOOO; /* 1111 1111 0000 0000 0000 0000 0000 0000 */ RedMask    = OxOOFFOOOO; /* 0000 0000 1111 1111 0000 0000 0000 0000 */ GreenMask = OxOOOOFFOO; /* 0000 0000 0000 0000 1111 1111 0000 0000 */ BlueMask   = OxOOOOOOFF; /* 0000 0000 0000 0000 0000 0000 1111 1111 */

Отметим, что Windows 95 поддерживает в случае 16-битовых BMP-растров маски исключительно в форматах RGB555 и RGB565, а в случае 32-битовых в формате RGB888.

Поле CSType устанавливает тип цветового пространства, используемого в растровых данных. Поле может иметь следующие значения: OOh (калиброванный RGB), Olh (аппаратно-зависимый RGB) и 02h (аппаратно-зависимый CMYK). По умолчанию принимается аппаратно-зависимый RGB. Калиброванный RGB определяется стандартом 1931 CIE XYZ.

Поля RedX, RedY и RedZ задают соответственно координаты X, Y и Z конечной точки красной составляющей указанного логического цветового пространства и используются только в том случае, если CSType = OOh (калиброванный RGB).

Поля GreenX, GreenY и GreenZ задают соответственно координаты X, Y и Z конечной точки зеленой составляющей указанного логического цветового пространства и используются только в том случае, если CSType = OOh (калиброванный RGB).

Поля BlueX, BlueY и BlueZ задают соответственно координаты X, Y и Z конечной точки синей составляющей указанного логического цветового пространства и используются только в том случае, если CSType = OOh (калиброванный RGB).

В полях GammaRed, GanunaGreen и GammaBlue хранятся масштабирующие гамма-значения координат соответственно красного, зеленого и синего.

Все дополнительные поля в заголовке растра версии для Windows 4.x используются для поддержки 16-и 32-битовых растров, согласования и спецификации цветов растровых данных. Обработка цветов может выполняться также и согласно информации ICM (Image Color Matching), записанной непосредственно в BMP-файле. Эти данные используются для согласования цветов при печати или отображении растра.

Цветовая палитра

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

1-, 4- и 8-битовые BMP-файлы всегда содержат палитру. А вот 16-, 24- и 32-битовые файлы BMP палитры никогда не имеют. Кроме того, 16- и 32-битовые BMP-файлы вместо палитры хранят значения масок битовых полей.

Чтобы определить, какие элементы палитры вы читаете — 3- или 4-байтовые, необходимо проверить значение поля Size заголовка растра. Значение 12 соответствует BMP-файлу для Windows 2.x (или, возможно, OS/2 1-х) с 3-байтовыми элементами. Большие значения (например, 40 или 108) указывают на последние версии BMP, в которых используются 4-байтовые элементы палитры.

Типы файлов BMP в Windows

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

Очевидно, что внутренний формат BMP-файла только по расширению его имени определить невозможно. К счастью, для этого существует довольно простой алгоритм.

Начинать чтение файла BMP следует с поля FileType заголовка файла. Если в нем записано значение 424Dh ("ВМ"), то у вас BMP-файл с одним изображением, созданный, вероятно, в операционной системе Windows или OS/2. Если значение FileType равно 4241h ("BA"), то у вас файл с растровым массивом OS/2 (кстати, остальные разновидности BMP версии OS/2 имеют расширения .ICO и .PTR).

Если тип файла ВМ, то для определения его версии нужно прочитать поле Size заголовка растра. Значение 12 соответствует версиям для Windows 2.x и OS/2 1.х, значение 40 — версиям .wiWindows З.х и Windows NT, значение из диапазона от 12 до 64 — для OS/2 2.x и, наконец, значение 108 соответствует Windows 4.x. BMP-файл Windows NT всегда имеет значение Compression, равное 3; в противном случае он читается как файл Windows З.х.

Единственное различие между BMP-файлами для Windows 2.x и OS/2 1 .х заключается в типе полей Width и Height. В Windows 2.x это SHORT со знаком, а в OS/2 l.x — SHORT без знака. Файлы BMP для Windows З.х, Windows NT и

OS/2 2.x различаются только количеством полей заголовка растра и интерпретацией поля Compression.

Данные изображения и сжатие

Несжатые данные это ряд значений, представляющих собой либо индексы в цветовой палитре, либо реальные RGB-значения. Пиксели упаковываются в байты и упорядочиваются по строкам развертки. Каждая строка развертки должна заканчиваться на границе двойного слова, поэтому строка данных может завершаться заполнителем — 1,2 или 3 байтами.

Если значение поля Height в заголовке растра является положительным, то строки развертки записываются в файле снизу вверх, в противном случае сверху вниз. Первый вариант записи встречается чаще, потому что строки развертки, записанные сверху вниз, нельзя сжать.

Монохромные растры содержат по 1 биту на пиксель, 8 пикселей в байте (при этом левый пиксель хранится в старшем бите) и имеют двухэлементную цветовую палитру. Если программа чтения BMP игнорирует палитру, то все "единичные" биты отображаются в цвете переднего плана дисплея, а все "нулевые" в цвете фона. 

4-битовые пиксели упаковываются по два в байт, при этом левый пиксель хранится в старшем полубайте; 8-битовые пиксели хранятся по одному в байте. И 4-, и 8-битовые пиксельные значения представляют собой индексы в цветовых палитрах, содержащих соответственно 16 и 256 элементов.

16-битовые пиксели в формате Windows NT хранятся в двух байтах и записываются в порядке "старший в младшем". Другими словами, на машинах с порядком "младший в младшем" эти байты необходимо перед использованием прочитать и преобразовать в порядок "младший в младшем". Порядок битовых полей в 16-битовых пикселях определяется значениями полей RedMask, GreenMask и BlueMask заголовка. Наиболее распространенными являются маски RGB555 и RGB565. Если в файле хранятся 16-битовые данные, то поле Compression всегда должно иметь значение 3 (кодирование битовых полей).

В формате BMP v4.x 16- и 32-битовые пиксели хранятся в виде 4-байтовых RGB-значений, записанных в порядке "младший в младшем". Для 32-битовых данных чаще всего применяются маски RGB888 и RGB101010. Такая битовая глубина также требует кодирования битовых полей и наличия полей маски в заголовке растра. 24-битовые растровые данные всегда хранятся в виде 3-байтовых RGB-значений.

Формат Windows BMP поддерживает простую схему группового кодирования (RLE), обеспечивающую сжатие 4-и 8-битовых растровых данных. Поскольку эта схема является схемой байтового уровня, то не имеет смысла сжимать с ее помощью 1-, 16-, 24- и 32-битовые растры, поскольку в данных этих типов длинные группы байтов обычно отсутствуют.

В формате BMP применяется RLE-схема с двумя переменными. Первая переменная содержит счетчик количества пикселей в группе (счетчик группы), а вторая пиксельное значение (значение группы). Группы размером до 255 идентичных пиксельных значений теоретически можно закодировать всего лишь в 2 байта данных. Конечно, на практике это выглядит несколько сложнее. Наряду с закодированными группами существуют группы незакодированные, дельта-маркеры, маркеры конца строки развертки и конца RLE-данных.

8-битовый алгоритм RLE (RLE8) записывает повторяющиеся пиксельные значения в виде закодированных групп. Значение первого байта (счетчика) закодированной группы может находиться в диапазоне от 1 до 255. Второй байт содержит значение, общее для всех 8-битовых пикселей в группе. Например, закодированная группа 05 18 декодируется в пять пикселей со значением 18, т.е. следующим образом: 18 18 18 18 18.

Если строка развертки не содержит достаточное для нормального уровня сжатия количество пиксельных групп, то смежные пиксельные значения можно записать буквально, т.е. в виде незакодированных групп. Незакодированная группа может содержать от 3 до 255 пиксельных значений. Первый байт незакодированной группы всегда равен нулю, что позволяет отличить ее от группы закодированной. Во втором байте записывается количество следующих за ним незакодированных пиксельных значений (счетчик литеральной группы). Если количество пикселей в такой группе является нечетной величиной, то добавляется заполнитель 00. Он не относится к исходным пиксельным данным и не должен записываться в декодированный поток выходных данных. Вот несколько примеров закодированных и декодированных потоков данных:

Закодированные байты     Декодированные байты

05 10    10 10 10 10 10

00 05 23 65 34 56 45 00        23 65 34 56 45

ОА ОА                    ОА ОА ОА ОА ОА ОА ОА ОА ОА ОА

00 04 46 57 68 79             46 57 68 79

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

К маркерам первого типа относится маркер конца строки развертки. Он состоит из двух байтовых значений 00 и 00 и указывает на то, что достигнут конец данных текущей строки развертки. Закодированные данные, следующие за этим маркером, декодируются с начала следующей строки развертки. Если маркера конца строки развертки в закодированных данных нет, пиксели автоматически переносятся (по концу строки развертки) в начало следующей.

Данный маркер используется только в том случае, если необходимо, чтобы декодирование строки развертки завершалось в определенном месте. Если он стоит, например, посреди строки развертки, то следующие за ним пиксели декодированного растра относятся уже к следующей строке. Такой метод "укороченных строк развертки" позволяет игнорировать ненужные фрагменты строк. Чаще всего он применяется в BMP-файлах, содержащих пиктограммы и указатели.

К следующему типу маркеров относятся маркеры конца RLE-данных. Каждый такой маркер обозначается двумя байтовыми значениями — 00 и 01. Располагаясь исключительно в двух последних байтах RLE-данных, он указывает на то, что программа чтения должна завершить декодирование данных.

И, наконец, рассмотрим маркер смещения группы, также именуемый дельта-кодом или векторным кодом. Размер этого маркера равен 4 байтам, причем первые 2 байта содержат значения 00 и 02, а последние 2 байта задают адрес следующего пикселя в виде смещения по осям Х и Y (беззнаковые целые) относительно текущей позиции курсора в растре. Величина, задающая смещение по оси X, представляет собой количество пикселей, пропускаемых в данной строке развертки в направлении слева направо, а величина, задающая смещение по оси Y, — количество пропускаемых строк растра. Направление смещения называется направлением "вперед", хотя фактически это движение сверху вниз или снизу вверх, что зависит от типа растра "нисходящего" или "восходящего".

Этот маркер позволяет задать точку в растре, в которую необходимо записать следующую декодированную группу пикселей. Например, маркер смещения группы 00 02 05 03 показывает, что курсор растра должен сместиться на пять пикселей вправо и на три строки развертки вперед относительно своего текущего положения, после чего записать там следующую группу. Затем запись декодированных данных продолжается в направлении вправо (до конца строки развертки) и вперед.

Маркеры смещения группы применяются в тех случаях, когда растры содержат большое количество "лишних" пикселей. Например, если в файле BMP записан растр, применяемый в качестве маски (такие растры используются, например, с пиктограммами и указателями), то многие пиксели в нем могут не использоваться. Чтобы не "захламлять" бесполезными пикселями BMP-файл, в него нужно записывать только значащие пиксели. При этом дельта-маркеры помогают организовать "переходы", пропуская те фрагменты растра, которые в маске не используются.

Ниже представлены образцы RLE-маркеров всех видов:

00 00              Конец строки развертки

00 01              Конец растровых данных

00 02 XX УУ       Маркер смещения группы

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

Закодированные байты   Описание     Декодированные байты

04 16                        Четыре байта со значением 16            16 16 16 16

08 45                       Восемь байтов со значением 45          45 45 45 45 45 45 45 45

00 00               Конец строки развертки                  Нет

00 02 04 02                  Передвинуть курсор на четыре пикселя    Нет

вправо и на две строки вперед

03 Е4                       Три байта со значением Е4               Е4 Е4 Е4

00 03 12 А4 46 00            Три байта незакодированных данных      12 А4 46

00 00                       Конец строки развертки                  Нет

00 01                       Конец RLE-данных                     Нет

4-битовый алгоритм RLE (RLE4) записывает повторяющиеся пиксельные значения почти так же, как это делает RLE8, и используя такие же маркеры. Единственное различие состоит в том, что в байт упаковываются два пиксельных значения, а при декодировании эти значения вновь разделяются. Например, поток данных 07 48, закодированный по схеме RLE4, декодируется в семь пикселей: 04 08 04 08 04 08 04.

Если это покажется странным, отметим, что в растрах глубиной 8 и более битов чередующиеся группы пиксельных значений встречаются очень редко. А вот в 4-битовых (16-цветных) растрах смешение цветов обычное явление. Многие алгоритмы смешения цветов производят относительно большие группы чередующихся пикселей. Для этих алгоритмов также характерны группы повторяющихся последовательностей из трех и четырех пикселей. Следует отметить, однако, что возможность эффективного кодирования таких групп пикселей по RLE-схеме форматом BMP не поддерживается.

Не следует думать, что группы идентичных пиксельных значений нельзя закодировать с использованием алгоритма RLE4. Например, группу из 12 пикселей со значением 9 можно закодировать как ОС 99 и декодировать в группу 09 09 09 09 09 09 09 09 09 09 09 09.

К незакодированным (литеральным) группам пикселей, состоящим из нечетного количества байтов (но не пикселей), добавляется заполнитель. Неиспользуемый последний полубайт в группах с нечетным количеством закодированных пикселей устанавливается в 0. Например, пиксельные значения 135790 (всего их шесть) записываются как незакодированная группа 00 06 13 57 90 00, а пиксельные значения 13579 (их пять) как незакодированная группа 00 05 13 57 90 00.

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

Закодированные байты    Описание                           Декодированные байты

04 16                       Четыре чередующихся значения 1 и б     1616

08 44                       Восемь чередующихся значений 4и4     44444444

00 00                        Конец строки развертки                  Нет

00 02 04 02                  Передвинуть курсор на четыре пикселя    Нет

вправо и на две строки вперед

03 Е4                       Три чередующихся значения Е и 4        Е 4 Е

00 06 12 А4 46 00             Шесть значений незакодированных дан-  1 2 А 4 4 6

ных

00 00                       Конец строки развертки                 Нет

00 01                       Конец RLE-данных                     Нет

Далее следует сводка характеристик данных в формате Windows BMP:

Пиксельная глубина  Размер пикселя  Сжатие   Палитра  Маски цветов

1 бит                  1 бит               0           Есть      Нет

4 бита                 4 бита              0,2          Есть        Нет

8 бит                  1 байт              0,1          Есть        Нет

16 бит                4 байта             3           Нет         Есть

24 бита               3 байта             0           Нет         Нет

32 бита                4 байта             3           Нет         Есть


Название:
  PCX

Известен также как:   PC Paintbrush File Format, DCX, PCC

Тип:   Растровый

Цвета:  Монохромный; 4-, 8- и 24-битовый

Сжатие:  RLE, без сжатия

Максимальный размер изображения:  64 К х 64 К пикселей

Больше одного изображения в файле:   Нет

Формат чисел:  "Младший в младшем" Разработчик:  ZSoft, Microsoft Inc.

Платформы:  MS-DOS, Windows, UNIX и другие

Применение:  PCX используется в Microsoft Windows и Windows-продуктах, но применяется и в других средах, в основном в MS-DOS. Формат служит для обмена данными и их хранения.

Комментарии:  Частично документированный формат широкого применения; быстро и легко читается и распаковывается. К сожалению, из-за отсутствия эффективной схемы сжатия он не пригоден для хранения изображений с большой пиксельной глубиной.

Обзор

PCX — один из наиболее широко используемых форматов. Первоначально он был разработан фирмой ZSoft для применения в PC Paintbrush в среде MS-DOS, поэтому его часто называют форматом PC Paintbrush. ZSoft заключила OEM-соглашение с фирмой Microsoft, что позволило последней использовать PC Paintbrush с различными продуктами, включая версию Microsoft Paintbrush для Windows (поставляется с каждой копией Microsoft Windows). В результате значение формата PCX возросло, причем не только при использовании на компьютерах, базирующихся на процессорах Intel, но и во всей компьютерной индустрии.

PCX широко применялся для хранения иллюстраций в настольных издательских системах и, кроме того, использовался производителями компьютерных факс-плат.

Первоначально (начиная с версии 2.5 PC Paintbrush) он предназначался для хранения графики и изображений, содержащих не более 1 б цветов. Это ограничение было обусловлено конструкцией дисплеев Enhanced Graphics Adapter (EGA) фирмы IBM. Когда IBM начала выпускать адаптер VGA, формат PCX был переработан для хранения графики и изображений, которые содержали до 256 цветов.

Последние версии PCX позволяют хранить 24-битовые цветные изображения, благодаря чему этот формат может использоваться в большинстве из применяемых на сегодняшний день программ создания изображений, графических приложений и видеотехнологий.

PCX — это аппаратно-зависимый формат, поскольку первоначально он был приспособлен к определенному типу аппаратного обеспечения. Данные могут храниться либо в виде плоскостей, либо в виде пикселей, т.е. в соответствии с особенностями плоскостно-ориентированного аппаратного обеспечения (IBM EGA) и пиксельно-ориентированного адаптера экрана IBM Virtual Graphics Array (VGA).

Данные изображения кодируются с применением одного из вариантов алгоритма RLE, который, несмотря на простоту и скорость работы, трудно назвать эффективным. Как и при работе с другими RLE-схемами, очень сложно предсказать, насколько эффективно удастся сжать данные изображения, поскольку степень сжатия в значительной мере зависит от его содержимого (насколько оно "загружено") и от того, какое количество цветов реально используется. В общем случае данные изображения, содержащего не более 16 цветов, уменьшаются на 40—70% по сравнению с исходным размером, в то время как 64- иди 256-цветныс изображения, полученные со сканера или с видеоисточника, могут уменьшиться только на 10—30%. Иногда изображения оказываются настолько сложными, что применение схемы сжатия приводит к увеличению размера PCX-файла.

Организация файла

Файлы PCX состоят из трех основных разделов: заголовка, данных изображения и цветовой палитры. Цветовая палитра обычно состоит из записей для каждого из 256 цветов и связана с адаптером VGA (это относится только к последней версии формата PCX).

Подробное описание файла

Ниже описаны структура формата PCX, а также методы чтения, сжатия, кодирования и декодирования PCX-файлов.

Заголовок

Первые 128 байтов каждого файла PCX — это заголовок, который имеет следующий формат:

typedef struct _PcxHeader{

BYTE Identifier;     /* Идентифицирующее PCX число (всегда OAh) */

BYTE Version;        /* Номер версии */

BYTE Encoding;       /* Формат кодирования */

BYTE BitsPerPixel;   /* Количество битов на пиксель */

WORD XStart;         /* Левая граница изображения */

WORD YStart;         /* Верхняя граница изображения */

WORD XEnd;           /* Правая граница изображения */

WORD YEnd;           /* Нижняя граница изображения */

WORD HorzRez;        /* Горизонтальное разрешение */

WORD VertRez;        /* Вертикальное разрешение */

BYTE Palette[48];    /* 16-цветная палитра EGA */

BYTE Reservedl;      /* Зарезервировано (всегда 0) */

BYTE NumBitPlanes;   /* Количество битовых плоскостей */

WORD BytesPerLine;   /* Количество байтов на строку развертки */

WORD PaletteType;    /* Тип палитры */

WORD HorzScreenSize; /* Размер экрана по горизонтали */

WORD VertScreenSize; /* Размер экрана по вертикали */

BYTE Reserved2[54]; /* Зарезервировано (всегда 0) */

} PCXHEAD;

Поле Identifier содержит идентифицирующее значение, которое, в соответствии со спецификацией PCX, всегда равно OAh. Это значение не имеет никакого специального смысла, а просто подтверждает, что данный файл действительно является ZSoft PCX. Приложения, читающие файлы PCX, должны проверять корректность значения этого поля, даже если файл имеет расширение PCX. Однако следует помнить, что встречаются файлы отличного от PCX формата, которые могут начинаться с этого значения. Поэтому приложение, прежде чем декодировать любые данные изображения, должно прочитать и проверить все поля заголовка. Иными словами, не спешите переходить сразу к байту со смещением 128 и декодировать то, что вы считаете данными изображения. Поле Version определяет номер версии программы Paintbrush, которая создала этот файл PCX. Фирма ZSoft выпустила модернизированную версию формата PCX, чтобы поддержать расширение функциональных возможностей PC Paintbrush и развитие технологии экранных адаптеров, выпускаемых для PC. Для каждой версии формата PCX характерны определенные требования к обработке и воспроизведению изображений. До версии 2.5 PC Paintbrush формат изображений PCX рассматривался как собственность ZSoft Corporation. Возможны следующие значения поля Version:

Значение Версия PC Paintbrush, ее описание

0         Версия 2.5 с фиксированной палитрой EGA

2         Версия 2.8 с модифицируемой палитрой EGA

3          Версия 2.8 без палитры

4          PC Paintbrush для Windows

5          Версия 3.0

Поле Encoding указывает схему кодирования данных изображения. В настоящее время спецификацией PCX поддерживается только байт-ориентированный алгоритм группового кодирования (RLE), которому соответствует значение 1 этого поля. Можно догадаться, что значение 0 предназначалось для незакодированных данных, но поскольку файлы PCX всегда содержат закодированную информацию, то в настоящее время единственным корректным значением поля Encoding является 1.

Поле BitsPerPixel содержит сведения о количестве битов на пиксель в одной цветовой плоскости. Допустимыми его значениями являются 1, 2, 4 и 8 для 2-, 4-, 16- и 256-цветных изображений. Данные строки развертки дополняются заполнителем для выравнивания по границе четного байта. Программы, рисующие и преобразующие изображения в формате PCX, по значению этого поля определяют конец реальных данных и начало заполнителя. Поля XStart, YStart, XEnd и YEnd задают размер изображения в пикселях, т.е. прямоугольник, ограничивающий видимую часть изображения PCX (иногда его называют Picture Dimension Window), и его положение на экране. Максимальный размер изображения, которое можно сохранить с использованием этих полей, равен 65535х65535 пикселей. Значения этих полей определяют координаты верхнего левого и нижнего правого углов изображения на экране. Верхним левым углом считается пиксель с координатами 0,0, и любое РСХ-изображение, в котором поля XStart и YStart равны 0, начнет отображаться с этой позиции. Если значения XStart и YStart больше 0, то программа начнет выводить изображение с соответствующим смещением. Однако эта возможность редко поддерживается приложениями, воспроизводящими РСХ-изображения.

Любое изображение PCX может содержать лишние байты, добавленные в конец каждой растровой строки, и лишние строки развертки, добавленные в конец изображения. Для того чтобы они не отображались, программа должна выводить на экран только те данные, которые находятся внутри Picture Dimension Window. Поля HorzRez и VertRez указывают разрешение изображения по горизонтали и вертикали в пикселях на строку или в точках на дюйм (dpi). Изображения, полученные в результате сканирования, имеют то же разрешение, что и создавшее их устройство (обычно 100х100 dpi или 300х300 dpi). Изображение, созданное факс-платой, может иметь разрешение 100х200 dpi или 200х200 dpi. Изображения, созданные программой рисования, и дампы экрана будут иметь разрешение, соответствующее разрешению дисплея, на котором они были получены. Например, типичные программы рисования на дисплее VGA сохраняют изображения с горизонтальным разрешением 320 пикселей и вертикальным разрешением 200 пикселей. Однако эти значения не используются при декодировании данных изображения. Поле Palette — это 48-байтовый массив 8-битовых величин, которые создают 16-цветную палитру EGA. Ранние версии PC Paintbrush не могли использовать модифицируемую палитру EGA, поэтому применялась стандартная палитра. Последующие версии поддерживали модифицируемую палитру EGA, что позволяло программам записи файлов изображений PCX выбирать 16 (или менее) цветов из 64-х, которые поддерживает EGA. Поле Reservedl в настоящее время не используется и всегда должно иметь значение OOh. В старых версиях PCX это поле предназначалось для идентификации файла или для хранения значения, соответствовавшего режиму дисплея, на котором было создано изображение. Но сейчас некоторые программы рисования и отображения могут объявить файл PCX некорректным, если значение этого поля будет отличаться от OOh. Поле NumBitPlanes задает количество цветовых плоскостей, которые содержатся в данных изображения. Значение этого поля обычно равно 1, 3 или 4 и используется в сочетании со значением поля BitsPerPixel для определения корректного видеорежима, в котором нужно воспроизводить изображение. Ниже перечислены видеорежимы, которые поддерживает PCX:

Цветовые   Битов на пиксель  Максимальное        Видеорежим

плоскости  в плоскости       количество цветов

1           1                 2                   Монохромный

1           2                 4                   CGA

3          1               8                 EGA

4          1                16                 EGA и VGA

1           8                  256                   Расширенный VGA

3           8                  16777216              Расширенный VGA и XGA

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

MaxNumberOfColors = (1L <<(BitsPerPixel * NumBitPlanes));

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

ScanLineLength = (BytesPerLine * NumBitPlanes);

Поле PaletteType определяет тип информации, записанной в цветовой палитре. Значение 1 соответствует цветной или монохромной информации, а значение 2 — информации о градациях серого. Причем возможность корректно отображать изображения в шкале серого цвета имеет только VGA; PC Paintbrush и большинство других программ, использующих PCX, игнорируют значение данного поля.

Поля HorzScreenSize и VertScreenSize были добавлены к формату PCX в версии PC Paintbrush 4.0 и 4.0 Plus и определяют горизонтальный и вертикальный размеры (разрешение) экрана, на котором было создано изображение. Это позволяет программам подобрать видеорежим, который способен адекватно отобразить изображение. Поскольку эти поля были добавлены уже после выхода PC Paintbrush 3.0, то практически невозможно определить, содержат ли они достоверную информацию или являются просто частью поля Reserved!. Поэтому, прежде чем использовать записанные здесь значения, следует проверить их достоверность.

Поле Reserved! является последним в заголовке и представляет собой группу байтов, каждый из которых равен OOh. Это поле предназначено для дополнения заголовка до 128 байтов и резервирования места под будущие поля, которые могут появиться в новых версиях формата. Размер этого поля — 54 или 58 байтов зависит от того, включены поля HorzScreenSize и VertScreenSize в заголовок или нет.

Палитра

Информация, содержащаяся в цветовой палитре, неодинакова в разных версиях формата PCX.

16-цветная палитра EGA

Первые версии формата PCX не поддерживали модифицируемую цветовую палитру и всегда использовали значения цветов стандартной палитры EGA. Последние версии PC Paintbrush могут работать как с модифицируемой палитрой, так и без нее, поэтому для каждой из таких версий программы существуют две версии формата: одна с палитрой (модифицируемая палитра), а другая без нее (стандартная палитра EGA).

Палитра EGA — это 48-байтовый массив из шестнадцати RGB-триплетов, каждый из которых состоит из величин красного, зеленого и синего цветов в диапазоне значений от 0 до 255. Палитра может содержать элементы для 2, 4, 8 и 16 цветовых триплетов, а остальные ее элементы устанавливаются в OOh. Адаптеры, использующие такой формат цветовых величин, не требуют какой-либо интерпретации. А вот в EGA существуют только четыре возможных величины для представления каждого цвета RGB (от 0 до 3), поэтому получить соответствующее значение можно смещением каждой RGB-величины на шесть битов вправо. Чтобы выделить значение, пригодное для загрузки в регистры палитры EGA, можно использовать, например, следующий код:

EgaColorORed  = EgaPalette[0] >> 6 EgaColorOGreen = EgaPalette[1] >> 6 EgaColorOBlue = EgaPalette[2] >> 6 EgaColorlRed   = EgaPalette[3] >> 6 EgaColorlGreen = EgaPalette[4] >> 6 EgaColorlBlue = EgaPalette[5]  >> 6 /* и так далее... */

4-цветная палитра CGA

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

Четыре старших бита первого байта цветовой палитры EGA содержат информацию о цвете фона из диапазона от О до 15.

Три старших бита четвертого байта цветовой палитры EGA хранят информацию о цвете переднего плана. Эти три бита соответствуют установкам CGA — Цветовой режим. Палитра и Интенсивность как показано ниже:

Цветовой режим  Палитра    Интенсивность

(бит7)   (бит 6)  (бит 5)

0 (цветной)          0 (желтый)     0 (нормальный)

1 (монохромный)     1 (белый)      1 (яркий)

256-цветная палитра VGA

Когда создавался формат PCX, EGA считался лучшим адаптером фирмы IBM для PC. Он позволял отображать только 16 цветов из 64-цветной палитры, поэтому PCX был вначале разработан с цветовой палитрой, пригодной для определения лишь 16-ти цветов.

Однако 16-цветная технология EGA 1984 года уступила дорогу 256-цветной технологии VGA 1987 года, и сейчас PCX поддерживает изображения VGA, которые могут содержать до 256 цветов из 262144-цветной палитры. Эту новую цветовую палитру нужно было добавить в файлы формата PCX для изображений VGA. Поскольку в заголовке для дополнительной палитры не было места, то разработчики формата добавили ее в конец PCX-файла.

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

Чтобы выяснить, подключена ли палитра VGA, следует переместиться к 769 байту от конца файла и проверить его значение. Если оно равно C0h, то 768 следующих байтов содержат цветовую палитру VGA. В спецификации PCX указано, что если номер версии в заголовке (байт 1) равен 5 (версия 3.0), то цветовая палитра VGA может быть подключена.

Обычно цветовая палитра VGA подключается к файлу PCX только в том случае, если в изображении содержится больше 16 цветов (в противном случае используется палитра EGA). Однако многие графические программы создают файлы изображений PCX версии 3.0 без цветовой палитры VGA, в то время как другие подключают цветовую палитру VGA даже к двухцветным изображениям. 24-битовые изображения PCX помечаются как версия 3.0, хотя никогда не сопровождаются цветовой палитрой. Это, конечно же, вносит определенную путаницу.

Может случиться, что изображение PCX версии 3.0 не будет иметь цветовой палитры, а значение байта со смещением 768 случайно окажется равным ОСЬ (как будто палитра есть). В этом случае приложение, читающее PCX, будет интерпретировать последние 768 байтов закодированных данных изображения как палитру VGA, что приведет к весьма экстравагантному виду отображенного изображения. Одно из решений этой проблемы заключается в предварительном чтении всех данных изображения и анализе позиции указателя: если он остановится на отметке 769 байтов от конца файла, то можно сделать вывод, что цветовая палитра VGA присутствует. Другим решением может быть проверка трех байтов, следующих за значением 0Сh. Это первый цвет цветовой палитры и он обычно черный, т.е. три байта, следующие за индикатором цветовой палитры VGA, должны быть установлены в 0.

Если в файле присутствует палитра VGA, то ее информация используется независимо от того, что содержится в цветовой .палитре EGA. При некорректном отображении цветов изображения можно попробовать запретить применение цветовой палитры, чтобы аппаратное обеспечение могло применить свою "родную" цветовую палитру. Для этого достаточно изменить номер версии в заголовке (байт 1) с 5 на 3. Отображающая программа поймет, что эта версия формата не имеет цветовой палитры, следовательно, нужно использовать собственную палитру, заданную по умолчанию.

Палитра VGA представляет собой массив из 768 байтов (256х3), содержащий величины красной, зеленой и синей составляющих для каждого из 256 цветов, допустимых в изображениях PCX VGA. Цветовые величины, подобно палитре EGA, организованы в триплеты. Байты 0, 1 и 2 — это величины для цвета 0, байты 3, 4 и 5 — для цвета 1 и так далее. Каждая RGB-величина выбирается из диапазона 0—255.

Фактически палитра VGA — это просто более длинная версия палитры EGA. Дисплеи VGA требуют, чтобы цветовые величины в палитре находились в диапазоне от 0 до 63, т.е. все RGB-величины нужно разделить на четыре (сдвигом на два бита вправо). Изображения VGA могут иметь палитры из 2, 4, 8, 16, 32, 64, 128 или 256 элементов.

Чтение заголовка PCX

В спецификации PCX явно не указано, что в формате применяется схема "младший в младшем", принятая для компьютеров, которые базируются на процессорах Intel 80х86. Но мы можем уверенно утверждать, что это так, поскольку формат PCX был разработан для использования именно на таких компьютерах.

Сжатие данных PCX

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

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

Закодированные данные читаются побайтово. Если два старших бита (MSB) установлены в 1, то этот байт является первым в 2-байтовой закодированной группе. Первый байт 2-байтовой закодированной группы всегда содержит в младших шести битах счетчик группы, который определяет ее длину. Следовательно, пиксельная группа может иметь длину от 1 до 63 пикселей.

Второй байт 2-байтовой закодированной группы имеет пиксельное значение из диапазона от 0 до 255, которое при выводе повторяется столько раз, сколько задано в счетчике группы.

Если в прочитанном байте счетчика группы оба старших бита установлены в 0, то этот байт содержит буквальное пиксельное значение, а длина группы считается равной 1. Такая однобайтовая группа позволяет не кодировать одиночные пиксели в 2-байтовые группы.

Однако схема RLE PCX имеет серьезный недостаток. 1-байтовые литеральные (незакодированные) группы могут содержать только значения из диапазона 0—63. Если значение одиночного пикселя находится в диапазоне от 64 до 255, то приходится использовать 2-байтовую группу. Размер данных изображения, содержащего много пикселей со значениями больше 63, в результате такого сжатия может даже увеличиться, правда, это происходит обычно только в результате обработки очень "зашумленных" или зернистых изображений.

Декодирование файла формата PCX

Для декодирования файла формата PCX нужно прочитать заголовок файла и вычислить следующие параметры:

* ширину изображения в пикселях;

* длину изображения в строках развертки;

* количество байтов, которые нужно зарезервировать для хранения декодированной строки развертки;

* количество байтов заполнителя в конце каждой строки развертки.

Ширину и высоту изображения можно вычислить по его координатам следующим образом:

ImageWidth = XEnd - XStart + 1; /* Ширина изображения в пикселях */

ImageHeight = YEnd - YStart + 1; /* Высота изображения в строках развертки */

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

ScanLineLength = NumBitPlanes * BytesPerLine;

Длина заполнителя в конце строки развертки представляет собой результат вычитания пиксельной ширины отображаемого изображения из количества пикселей в декодированной строке:

LanePaddingSize = ((BytesPerLine * NumBitPlanes) *

(8 / BitsPerPixel) ) - ((XEnd - XStart) +1).

Пошаговое описание процесса декодирования:

1. Прочитать байт.

2. Если два старших бита установлены в 1, выделить счетчик группы.

3. Прочитать следующий байт.

4. Записать этот байт столько раз, сколько указано в счетчике группы.

5. Иначе, если два старших бита установлены в 0, выделить значение группы.

6. Записать полученное значение один раз.

7. Повторять шаги 1—6 до тех пор, пока буфер не заполнится.

Спецификация PCX утверждает, что кодирование должно прерываться в конце каждой строки развертки. Это означает, что если при кодировании данных достигается конец растровой строки, то группа должна быть прервана во избежание перехода на следующую строку.

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

Кодирование данных изображения PCX

Схема кодирования строки развертки достаточно проста. Исходные данные читаются побайтово. Для этого достаточно знать количество байтов в строке развертки. Ниже приведено пошаговое описание процесса кодирования данных изображения с применением алгоритма сжатия PCX:

1. Прочитать один байт пиксельных данных и сохранить его значение.

2. Установить счетчик в 0.

3. Прочитать следующий байт и проверить, не совпадает ли он с сохраненным значением.

4. Если совпадает, увеличить значение счетчика на 1.

5. Если не совпадает, а счетчик больше 1 либо равен 63, или если просто достигнут конец строки развертки, установить два старших бита в 1 и вывести значение счетчика.

6. Вывести пиксельное значение.

7. Повтврять шаги 1—7 до тех пор, пока не будут прочитаны все строки развертки.

Формат данных изображения PCX

После декодирования строки развертки формат полученных данных зависит от значений полей BitsPerPixel и NumBitPlanes в заголовке. Знать формат данных строки развертки необходимо, так как только при этом условии из нее можно выделить пиксельные данные для отображения изображения или преобразования файла из одного формата в другой. Все растровые строки в файле PCX всегда имеют одинаковый формат.

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

Плоскостные данные хранятся попиксельно в виде одной плоскости, длина которой равна длине строки развертки. Строка развертки содержит не собственно данные изображения, а ряд индексных значений в цветовых палитрах EGA или VGA. Исключением является 1-битовое монохромное изображение, где каждый бит строки развертки непосредственно отображается как пиксельное значение.

Объем данных строки развертки, занимаемый пикселем, определяется значением поля BitsPerPixel. Например, если это поле определяет 1 бит на пиксель, то каждый байт строки развертки содержит 8 пикселей. При 8 битах на пиксель каждый байт строки развертки содержит одно пиксельное значение.

Строки развертки с тремя плоскостями встречаются редко. 24-битовые изображения PCX хранятся в виде 3 байтов на пиксель, которые распределены по трем плоскостям. Цветовые величины 24-битовых данных являются собственно данными изображения, поскольку палитра не применяется. Paintbrush for Windows 2.0 использует три плоскости 1-битовых данных для хранения 8-цветных изображений, причем каждое пиксельное значение является индексом в цветовой палитре EGA.

Изображения с четырьмя плоскостями обычно являются 16-цветными изображениями EGA. Кроме красной, зеленой и синей плоскостей существует еще одна плоскость интенсивность цвета, которая специфична для адаптеров EGA. Строки развертки в 4-плоскостных изображениях содержат значения индексов в палитре EGA.

Форматы, родственные PCX

От PCX произошло несколько других графических форматов. Как правило, это просто специализированные версии PCX.

Формат РСС

Ранние версии PC Paintbrush имели возможность отсекать области изображения PCX и с помощью команды Copy To... сохранять в файле формата PCX, но с расширением .РСС. Возможно, такое расширение использовалось для того, чтобы показать, что этот файл содержит часть другого изображения. В текущей версии PC Paintbrush вместо РСС применяется расширение .PCX.

Формат DCX

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

Одним из таких приложений является программное обеспечение факсимильных аппаратов, в котором каждая факсимильная страница хранится в виде отдельного файла. PCX приобрел большую популярность среди PC-ориентированного программного обеспечения для факс-аппаратов благодаря тому, что факсимильные страницы, сохраненные в этом формате, можно просмотреть при помощи многих популярных программ рисования и воспроизведения изображений. Однако хранение каждой страницы в отдельном файле весьма неудобно и может привести к ошибкам, особенно если имена файлов зашифрованы.

Чтобы решить эти проблемы, был создан формат DCX, который позволяет хранить до 1023 PCX-изображений в одном файле. Каждое изображение в файле DCX является полным файлом PCX, включающим заголовок и информацию о палитре. В приложениях файлы DCX могут содержать все страницы факсимильного сообщения, серию изображений одного содержания или все иллюстрации к документу. Ниже приведен заголовок DCX:

typdef struct _DcxHeader }

DWORD Id;              /* Число, идентифицирующее DCX */

DWORD PageTable[1024]; /* Смещения изображений */

}DCXHEAD;

Поле Id хранит 4-байтовое двойное слово, применяемое для идентификации файла. Значение этого слова всегда равно 3ADE68Blh (десятичное 987654321).

Поле PageTable содержит массив из 1024 4-байтовых слов, называемый таблицей страниц. Элементами этого массива являются смещения каждого изображения PCX, содержащегося в файле DCX, причем эти смещения задаются от начала файла (байт 0). Последним элементом в таблице страниц является признак конца, который всегда устанавливается в ноль.

Обычно файл DCX содержит полную 4096-байтовую таблицу страниц (1023 4-байтовых смещения, за которыми следует 4-байтовый признак конца), даже если значения большинства элементов таблицы равны нулю. Некоторые приложения, сохраняющие изображения в файлах DCX, могут попытаться сэкономить дисковое пространство, записывая таблицу, состоящую только из ненулевых элементов. Поэтому никогда нельзя быть уверенным в том, что таблица записана в полном объеме, т.е. равна 4096 байтам. Приложения, читающие файлы DCX, всегда должны читать по одному элементу до тех пор, пока не будет прочитано нулевое значение. Если первым значением смещения в таблице страниц будет 1004h (десятичное 4100), то в таком файле DCX содержится вся 4096-байтовая таблица.

Формат DCX очень удобен и прост в применении, однако имеет один серьезный недостаток. Когда множество файлов PCX объединяется в файл DCX, вся информация внутри файлов PCX сохраняется, но теряются их имена. В формате DCX (а тем более в PCX) нет возможности хранить принятые в MS-DOS имена файлов изображений. Следовательно, если для вашего приложения важно имя PCX-файла, то придется организовать своего рода список имен файлов, который будет храниться вне файла DCX. Возможно, в будущих версиях формата DCX этот недостаток будет устранен (скажем, путем добавления списка имен в конец файла DCX).


 

А также другие работы, которые могут Вас заинтересовать

12186. Мониторинг работоспособности материнской платы 41.91 KB
  Лабораторная работа № 17 Мониторинг работоспособности материнской платы 1. Цель работы Научиться диагностировать работоспособность системной платы 2. Теоретические сведения SpeedFan мощная утилита мониторинга Задача мониторинга критически важных параметров р
12187. СИРОВИННІ МАТЕРІАЛИ МАРТЕНІВСЬКОГО ВИРОБНИЦТВА 1.09 MB
  1 СИРОВИННІ МАТЕРІАЛИ МАРТЕНІВСЬКОГО ВИРОБНИЦТВА Шихтові матеріали поділяються на металеві і неметалічні. До металевої частини шихти відносяться: чавун брухт розкислювачі і легуючі добавки; до неметалічної – залізна і марганцева руда окалина агломерат вапняк і ва...
12188. ОСОБЛИВОСТІ ПОБУДОВИ ЗЛИВКІВ СПОКІЙНОЇ, КИПЛЯЧОЇ ТА НАПІВСПОКІЙНОЇ СТАЛЕЙ 797.5 KB
  ОСОБЛИВОСТІ ПОБУДОВИ ЗЛИВКІВ СПОКІЙНОЇ КИПЛЯЧОЇ ТА НАПІВСПОКІЙНОЇ СТАЛЕЙ Особливості побудови зливка спокійної сталі Звичайна структура зливка спокійної сталі рис. 7.1 характеризується наступними основними зонами. Зона 1. Тонкий поверхневий шар що утвор
12189. ВИЗНАЧЕННЯ ВМІСТУ ВУГЛЕЦЮ В СТАЛІ ЗА ДОПОМОГОЮ КАРБОМЕТРУ ALPHA 1.03 MB
  ВИЗНАЧЕННЯ ВМІСТУ ВУГЛЕЦЮ в СТАЛІ ЗА ДОПОМОГОЮ карбометру ALPHA Ціль роботи: вивчити методи контролю вмісту вуглецю в сталі; освоїти один з фізичних методів визначення вуглецю в сталі. Теоретичне введення Перед проведенням лабораторної роботи студент зобовя
12190. ХРОНОМЕТРАЖ ПЛАВКИ В СТАЛЕПЛАВИЛЬНОМУ АГРЕГАТІ 31.5 KB
  ХРОНОМЕТРАЖ ПЛАВКИ В СТАЛЕПЛАВИЛЬНОМУ АГРЕГАТІ Мета роботи: 1. Вивчити конструкцію сталеплавильного агрегату. 2. Ознайомитись з організацією робіт сталеплавильного агрегату. 3. Вивчити технологію плавки в сталеплавильному агрегаті. Перед проведенням ла...
12191. Определение порядка реакции по мурексиду и ката¬лизатору (кислоте) 282.69 KB
  Цель работы: определение порядка реакции по мурексиду и катализатору кислоте; определение константы диссоциации слабой кислоты путем кинетических измерений. Схема установки Рис. 1. Общий вид прибора где 1 – узел светофильтров 2 – узел кюветодержателя 3 – и
12192. Ознакомиться с оптическим методом изучения кинетики реакции; определить порядок реакции по сахару к катализатору 151 KB
  Цель работы: ознакомиться с оптическим методом изучения кинетики реакции; определить порядок реакции по сахару к катализатору; определить среднюю константу скорости. Схема установки Рис. 1. Схема поляриметра где 1 – источник света 2 – светофильтр 34 – поляр
12193. Определить частные и общий кинетический порядок реакции 31.15 KB
  Цель работы: определить частные и общий кинетический порядок реакции Fe3I→Fe2I Рабочие формулы где: n1 – частный порядок реакции по ионам железа n2 – частный порядок реакции по йодидионам где: n – общий порядок реакции. Таблица 1 Экспериментальны
12194. Установить зависимость удельной и эквивалентной электропроводности электролита от концентрации и температуры 29 KB
  Цель работы: установить зависимость удельной и эквивалентной электропроводности электролита от концентрации и температуры. Рабочие формулы где: k постоянная сосуда RKCl сопротивление раствора KCl ‒ удельная электропроводность раствора KCl ...