Современные форматы графических файлов

Размещено на http://www.allbest.ru/

Описание формата BMP для Windows 3.0 (DIB)

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

Файлы битовых образов нового формата начинаются со структуры FileHeader {

word bfType; //тип файла (для битового образа - BM)

dword bfSize; //размер файла в dword

word bfReserved1; //не используется

word bfReserved2; //не используется

dword bfOffbits; //смещение данных битового образа от заголовка в байтах }

Непосредственно за ней располагается структура Info, содержащая всю информацию о битовом образе. Она делится на две части: структуру InfoHeader, описывающей размеры и цветовой формат битового образа, и массив структур RGBquad, определяющей цветовую палитру:

MAPINFO {

InfoHeader bmiHeader;

RGBquad bmiColors[1]; }

1. Структура InfoHeader {

dword Size; //число байт, занимаемых структурой InfoHeader

dword Width; //ширина битового образа в пикселах

dword Height; //высота битового образа в пикселах

word Planes; //число битовых плоскостей устройства

word BitCount; //число битов на пиксел

dword Compression; //тип сжатия

dword SizeImage; //размер картинки в байтах

dword XPelsPerMeter;//горизонтальное разрешение устройства, пиксел/м

dword YPelPerMeter; //вертикальное разрешение устройства, пиксел/м

dword ClrUsed; //число используемых цветов

dword ClrImportant; //число "важных" цветов

}

Более подробно:

Size - обычно используется для облегчения доступа к таблице цветов.

Planes - определяет число битовых плоскостей; однако, поскольку цвет кодируется последовательными битами, это число всегда равно 1.

BitCount - этим полем определяется число цветов, используемых битовым образом. В зависимости от способа кодирования, может принимать значения:

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

4 - битовый образ имеет максимум 16 цветов, и массив bmiColors (таблица цветов) имеет до 16 элементов. Цвет каждого пиксела определяется по таблице цветов при помощи четырехбитного индекса. Например, если первый байт данных имеет значение 3Ah, то при отображении битового образа цвет первого пиксела определяет четвертый элемент таблицы цветов, а цвет второго - одиннадцатый.

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

24 - битовый образ имеет максимум 2 в 24-й степени цветов. Таблица цветов пуста, а цвет пикселов определяется пакетами из трех байтов, описывающими цветовые интенсивности красного, зеленого и голубого цветов.

biCompression - тип сжатия. Может принимать значения:

BI_RGB - сжатие отсутствует;

BI_RLE8 - сжатие для формата 8 бит на пиксел;

BI_RLE4 - сжатие для формата 4 бита на пиксел.

XPelsPerMeter и YPelsPerMeter - могут использоваться для выбора из списка ресурсов пиктограммы, наиболее подходящей для данного устройства.

ClrUsed - число цветов, используемых данными битовым образом. Если 0, то используются все цвета палитры (указанные в массиве bmiColors).

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

2. структура RGBquad {

byte rgbRed; //интенсивность красного

byte rgbGreen; //интенсивность зеленого

byte rgbBlue; //интенсивность голубого

byte rgbReserved; //не используется

}

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

Сканстроки выровнены по 32-битной границе - dword !!!

Описание формата PCX

Файлы изображений, которые используются в продуктах семейства PC Paintbrush и FRIEZE, были разработаны фирмой Zsoft. Расширение файла DOS - PCX, тип формата растровый. Открывать или импортировать файлы PCX могут почти все графические приложения для персональных компьютеров. Цветовые возможности 1, 2, 4, 8 или 24- битовый цвет, никаких оттенков серого. Всегда применяется сжатие ROB. У этого формата есть ряд недостатков: 1) не поддерживает изображения с оттенками серого или таблицы коррекции шкалы серого; 2) не поддерживает цвета CMYK или другие системы отличные от RGB; 3) многочисленные варианты, особенно при работе с цветами, могут делать работу с файлом невозможным; 4) неудобная схема сжатия в действительности может увеличивать размеры некоторых файлов.

Среди положительных сторон формата РСХ можно назвать то, что он хорош для изображений, которые: 1)создают ограниченную палитру цветов (лучше всего 16 или 256); 2) не являются изображениями отсканированными или фотографиями, которые плохо сжимаются; 3)должны быть читаемыми всеми приложениями персонального компьютера.

Файлы изображения PCX начинается с заголовка длиной 128 байт. Затем идут закодированные графические данные. При кодировании используется простой алгоритм, основанный на методе длинных серий. Если в файле запоминается несколько цветовых слоев, каждая строка изображения запоминается по цветовым слоям. Согласно документации Zsoft, это выполняется по приведенной ниже схеме (R - красный слой, G - зеленый слой, B - синий слой, I - слой интенсивности)

Строка изображения 0:

RRR...

GGG...

BBB...

III...

Строка изображения 1:

RRR...

GGG...

BBB...

III...

(и т.д.)

Замечание о некорректности документа. Запоминание по слоям проводится, как правило, для 16-цветных изображений EGA. При стандартной палитре EGA, которая устанавливается по умолчанию BIOS'ом, нулевой слой видео памяти содержит СИНЮЮ компоненту цвета, а не красную. Если же палитра отлична от стандартной, то говорить о том, что слои видео памяти, соотносятся с компонентами цвета вообще затруднительно.

Метод кодирования состоит в следующем:

ДЛЯ каждого байта X, прочитанного из файла. ЕСЛИ оба старших бита X равны 1, то <повторитель> = значению, хранящемуся в 6 младших битах X <данные> = находятся в следующем байте за X. ИНАЧЕ <повторитель> = 1 <данные> = X

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

Формат заголовка PCX

Смещение	Обозначение	Длина	Описание / комментарий
0	Manufacturer	1	Постоянный флаг 10 = ZSoft .PCX
1	Version	1	Информация о версии: 0 = Версия 2.5 2 = Версия 2.8 с информацией о палитре 3 = Версия 2.8 без информации о палитре 5 = Версия 3.0
2	Encoding	1	1 = PCX кодирование длинными сериями
3	Bits per pixel	1	Число бит на пиксел в слое
4	Window	8	Размеры изображения (Xmin, Ymin) - (Xmax, Ymax) в пикселах включительно
12	Hres	2	Горизонтальное разрешение создающего устройства
14	Vres	2	Вертикальное разрешение создающего устройства
16	Colormap	48	Набор цветовой палитры (см. далее текст)
64	Reserved	1
65	NPlanes	1	Число цветовых слоев
66	Bytes per Line	2	Число байт на строку в цветовом слое (для PCX-файлов всегда должно быть четным)
68	Palette Info	2	Как интерпретировать палитру: 1 = цветная/черно-белая, 2 = градации серого
70	Filler	58	Заполняется нулями до конца заголовка

Все переменные длины 2 являются целыми.

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

Сначала определяется размер изображения, для этого вычисляют

[XSIZE = Xmax - Xmin + 1] и [YSIZE = Ymax - Ymin + 1].

Затем вычисляют, сколько байтов требуется для сохранения одной несжатой строки развертки изображения:

TotalBytes = NPlanes * BytesPerLine

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

Далее выполняется собственно декодирование, читается первый байт данных из файла. Если два старших бита этого байта равны 1, оставшиеся шесть битов показывают, сколько раз следует повторить следующий байт из файла. Если это не так, то этот байт сам является данными с повторителем равным 1. Далее продолжается декодирование до конца строки, ведя подсчет количества байтов, переданных в буфер вывода. В конце ка-ждой строки развертки имеет место остановка алгоритма кодирования, но ее не существует при переходе от одного слоя к другому. Когда строка сформирована полностью, в конце каждого слоя внутри строки возможно наличие лишних данных. Для нахождения этого остатка используются значения XSIZE и YSIZE. Если данные являются многослойными, то BytesPerLine показывает, где заканчивается каждый слой внутри строки развертки.

Продолжается декодирование оставшихся строк. В файле возможно наличие лишних строк с округлением на 8 или 16 строк.

Замечание

В конце каждой строки развертки предусматривается остановка алгоритма кодирова-ния, т.е. предполагается, что каждая строка развертки кодируется независимо. Но это не всегда так (файлы в этом формате пишет не только ZSoft Corporation !). Конец каждой строки лучше все-таки фиксировать по заполнении ее буфера. Это, безусловно, чуть усложнит программу декодирования, но сделает ее более гибкой.

Описание информации о палитре

Информация о 16-цветной палитре (EGA/VGA). Информация о палитре запоминается в одном из двух различных форматов. В стандартном формате RGB (IBM EGA, IBM VGA) данные запоминаются в 16 тройках. Каждая тройка состоит из 3 байтов со значениями красного (Red), зеленого (Green) и синего (Blue) цветов. Значения могут находиться в диапазоне 0-255, и поэтому необходима их интерпретация в формат используемого оборудования. Например, на IBM EGA существуют 4 возможных уровня RGB для каждого цвета. Поскольку 256/4 = 64, то ниже приведен список соответствия цветовых значений и уровней:

Значение Уровень

0-63 0

64-127 1

128-192 2

193-254 3

Информация о 256-цветной палитре VGA. 256-цветная палитра форматируется и интерпретируется точно так же, как 16-цветная. Палитра (число цветов * 3 байта длины) добавляется в конец PCX файла и ей предшествует байт с десятичным значением 12. Для определения палитры VGA BIOS достаточно разделить прочитанные значения цветов на 4.

Для доступа к 256-цветной палитре следует:

1. Прочитать в заголовке поле Version. Если оно равно 5, палитра должна быть. Или прочитать в заголовке поле Bits per pixel. Если оно равно 8, 256-цветная палитра должна быть.

2. Прочитать конец файла и отсчитать назад 769 байт. Найденное вами значение должно равняться 12, что указывает на присутствие 256-цветной палитры.

В пакете программ PCX Programmer's Toolkit фирмы Genus Microprogramming принят другой способ хранения 256-цветной палитры. Отличие состоит в том, что палитре предшествует байт с десятичным значением 10 (вместо 12), а значения цветовых компонент занимают младшие 6 битов в каждом из байтов цветовой тройки (т.е. изменяются от 0 до 63, как это принято в VGA BIOS).

Глобальная таблица цветов

Глобальная таблица цветов является необязательной и рекомендуется для изображений, где требуется точная передача цветов. На существование этой таблицы указывает поле 'M' в байте 5 дескриптора экрана. Цветовая таблица может быть также связана с ка-ждым изображением в GIF-файле. Число элементов цветовой таблицы, следующей за описателем экрана равно 2**(число бит/пиксел), причем каждый элемент состоит из трех байтов, значения которых описывают соответственно относительную интенсивность красного, зеленого и синего цветов.

Структура блока цветовой таблицы

биты 7 6 5 4 3 2 1 0	№ Байта
Интен. красного	1	Значение красного для цвета 0
Интен. зеленого	2	Значение зеленого для цвета 0
Интен. синего	3	Значение синего для цвета 0
Интен. красного	4	Значение красного для цвета 1
Интен. зеленого	5	Значение зеленого для цвета 1
Интен. синего	6	Значение синего для цвета 1
		(Продолжение для остальных цветов)

Получаемое значение каждого пиксела при высвечивании изображения будет соответствовать ближайшему доступному цвету из цветовой таблицы дисплея. Цветовые компоненты представляют собой значение относительной интенсивности от нулевой (0) до полной (255). Белый цвет может быть представлен как (255,255,255), черный как (0,0,0) и желтый как (180,180,0). При высвечивании на дисплеях, которые поддерживают менее 8 бит на цветовую компоненту, используются старшие биты. При создании элементов цветовой таблицы GIF на аппаратуре, поддерживающей менее 8 бит на компоненту, значение аппаратной компоненты должно быть конвертировано в 8-битный формат по следующей формуле: <значение_в_таблице> = <компонента>*255/(2**<число_бит> -1)

Это обеспечивает точный перевод цветов для всех дисплеев. В случае создания изображения GIF на аппаратуре без возможности цветовой палитры, должна быть создана фиксированная палитра на основе доступных для данного оборудования цветов. Если указано отсутствие глобальной таблицы цветов, цветовая таблица по умолчанию генерируется внутренним образом так, что каждый цветовой индекс равен аппаратному цветовому индексу modulo <n>, где <n> - число доступных цветов на оборудовании.

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

Дескриптор изображения определяет действительное расположение и размеры последующего изображения внутри пространства, определенного в дескрипторе экрана. Также определяются флаги, указывающие на присутствие локальной таблицы для поиска цветов и определения последовательности высвечивания пикселов. Каждый дескриптор изображения начинается с символа-разделителя изображений. Роль разделителя изображений состоит просто в синхронизации при входе в дескриптор изображения. Это желательно, если GIF-файл состоит более чем из одного изображения. Этот символ определен как шестнадцатеричное 0x2C или ',' (запятая). Как только этот символ встречается между изображениями, непосредственно за ним следует дескриптор изображения.

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

Структура дескриптора изображения

биты	Номер байта	Описание
7	6	5	4	3	2	1	0
0	0	1	0	1	1	0	0	1	',' - Символ-разделитель изображения
Левый край	2 3	Начало изображения в пикселах относительно левого края экрана (сначала LSB)
Верхний край	4 5	Начало изображения в пикселах относительно верхнего края экрана (сначала LSB)
Ширина	6 7	Ширина изображения в пикселах (сначала LSB)
Высота	8 9	Высота изображения в пикселах (сначала LSB)
M	I	0	0	0	Pixel	10	M=0 - Использовать глобальную таблицу цветов, игнорировать 'pixel'
		M=1 - Далее следует локальная таблица цветов, использовать 'pixel' I=0 - Изображение отформатировано в последовательном порядке I=1 - Изображение отформатировано в порядке переплетения pixel+1 - число бит на пиксел в данном изображении

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

Локальная таблица цветов

Локальная таблица цветов необязательна. Если установлен бит 'M' байта 10 в дескрипторе изображения, то далее следует локальная таблица цветов, которая относится только к последующему изображению. После обработки изображения цветовую таблицу следует привести к той, которая была определена после дескриптора экрана. Число битов на пиксел также следует восстановить к тому значению, которое было определено в дескрипторе экрана, после того, как закончится обработка изображения.

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

Формат самого изображения определен как серия значений номеров пикселов, которые образуют изображение. Пикселы запоминаются слева направо последовательно по строкам изображения. По умолчанию строки записываются последовательно, сверху вниз. В том случае, если установлен бит 'I' в байте 10 дескриптора изображения, то порядок строк при записи изображения соответствует четырех проходному процессу. При первом проходе записывается каждая 8-ая строка, начиная с верхней строки окна изображения. При втором проходе записывается каждая 8-ая строка, начиная с пятой строки сверху. На третьем проходе записывается каждая 4-ая строка, начиная с третьей строки окна. Четвертый проход завершает изображение, записывая каждую вторую строку, начиная со второй строки сверху.

Значения пикселов изображения обрабатываются как цветовые индексы, указывающие на существующую таблицу цветов. В результате получается цветовое значение из таблицы, которое реально воспроизводится на экране. Эти серии цветовых индексов, число которых равно ширине изображения * высоту изображения, пропускаются через поток данных изображения GIF по одному значению на пиксел, сжимаются и упаковываются в соответствии с версией алгоритма сжатия LZW.

Терминатор GIF

Для того чтобы обеспечить синхронизацию с окончанием файла изображения GIF, декодер GIF должен обрабатывать окончание режима GIF по символу шестнадцатеричное 0x3B или ';', найденному после окончания обработки изображения. По соглашению декодирующие программы должны делать паузу и ждать действий, указывающих, что пользователь готов к продолжению. Это может быть возврат каретки, введенный с клавиатуры или щелчок кнопкой мыши. Для интерактивных приложений эти действия пользователя должны быть переданы в ядро программы как перевод каретки, для того, чтобы вычислительный процесс мог продолжаться.

Расширенный блок GIF

Для того чтобы обеспечить аккуратное расширение определения GIF, необходим механизм для определения упаковки внутри потока данных GIF. Указанное расширение было определено и документировано CompuServe для того, чтобы предусмотреть управляемый способ усовершенствований.

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

Основная структура блока

7	6	5	4	3	2	1	0	№ байта
0	0	1	0	0	0	0	1	1	'!' - Идентификатор расширенного блока
Функциональный код	2	Расширенный функциональный код (0-255)
Байт-счетчик
Функциональные байты данных		Повторяется столько раз, сколько необходимо
… … …
0	0	0	0	0	0	0	0		нулевой байт-счетчик (терминатор блока)

Расширенный блок GIF может непосредственно предшествовать дескриптору изображения или находиться перед терминатором GIF.

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

Алгоритм сжатия LZW

формат графический файл

Когда для уменьшения размеров памяти, занимаемой файлами, применяются программы или математические алгоритмы, то говорят, что файлы подвергаются сжатию. Для уменьшения размеров памяти необходимой для хранения данных применяют различные организационные подходы. Методы можно разделить на две категории: сжатие всего файла и сжатие включенное в структуру файла. При сжатии всего файла программа упаковки (сжатия) считывает все его данные, применяет к ним некий сжимающий алгоритм и создаёт новый файл. Выигрыш в размере файла может быть значительным, но есть и один недостаток: файл нельзя использовать ни одной программой пока он не будет восстановлен до исходного состояния.

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

Алгоритм Lempel-Ziv и Welch (LZW) преобразует серию значений данных в серию кодов, которые могут быть самими значениями или кодами, описывающими серию значений. Если использовать аналогию с текстовыми символами, то выходные коды состоят из символов и кодов, которые описывают цепочки символов.

LZW-алгоритм, использованный в GIF,алгоритмически соответствует стандартному алгоритмуLZW со следующими отличиями:

1. Определен специальный код очистки, который сбрасывает все параметры сжатия/раскрытия и таблицы в исходное состояние. Значение этого кода равно 2**<код размера>. Например, если код размера равен 4 (изображение имеет 4 бита на пиксел), код очистки равен 16 (двоичное 10000). Код очистки может появляться в любом месте потока данных и, следовательно, требуется, чтобы LZW-алгоритм обрабатывал последующие коды так, как будто бы начался новый поток данных. Кодировщик должен выводить код очистки в качестве первого кода в каждом потоке данных изображения.

2. Определен код конца информации, который явно указывает на конец потока данных изображения. Если встретится такой код, LZW-обработка прекращается. Этот код должен быть последним кодом, формируемым кодировщиком для изображения. Значение этого кода равно <Код_очистки>+1.

3. Значение первого доступного кода сжатия равно <Код_очистки>+2.

4. Выходные коды имеют переменную длину, начиная от <код_размера>+1 битов на код, до 12 битов на код. Тем самым максимальное значение кода определяется равным 4095 (шестнадцатеричное FFF). Как только значение LZW-кода может превысить текущую длину кода, длина кода увеличивается на единицу. Паковщик и распаковщик этих кодов должны изменяться, чтобы соответствовать новой длине кода.

1. Построение 8-битных байтов

Поскольку LZW-сжатие, используемое для GIF, создает серию кодов переменной длины от 3 до 12 символов каждый, эти коды должны быть переформированы в серию 8-битный байтов. Это обеспечивает дополнительное сжатие изображения. Коды формируются в поток битов так, как если бы они паковались справа налево, и затем выбираются по 8 битов для вывода. Рассматриваемый массив 8-битных символов при упаковке кодов длиной по 5 битов должен быть похож на следующий пример:

байт n	байт 5	байт 4	байт 3	байт 2	байт 1
and so on	hhhhhggg	ggfffffe	eeeedddd	dcccccbb	bbbaaaaa

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

2. Упаковка байтов

Как только байты созданы, они группируются в блоки для вывода, причем каждому блоку предшествует байт-счетчик со значением от 0 до 255. Блок с нулевым байтом-счетчиком заканчивает поток данных для данного изображения. Эти блоки являются тем, что выводится на самом деле в формате GIF. Такой формат блока обеспечивает дополнительную эффективность за счет того, что позволяет декодировщику считывать данные по мере необходимости, читая сначала байт-счетчик, а затем пропуская сами данные об изображении.

3. Обработка нескольких изображений

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

1. Не делать пауз между изображениями. Каждое обрабатывается сразу же, как только будет распознано декодировщиком.

2. Каждое изображение переписывает любое другое изображение уже находящееся внутри его окна. Экран очищается только в начале и в конце обработки GIF-изображений.

Обзор других графических форматов

Расширение файлов DOS IFF или LBM. Тип формата IFF - разные данные, LBM - растровый формат. Программы, которые могут открывать или импортировать эти файлы - это программы преобразования растровых форматов для персональных компьютеров. Цветовые возможности: чёрно-белые, серые, 256-цветные или 24-битные цвета RGB.

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

Для растровых изображений необходимо 3 типа блоков.

1) Блок BMHB - заголовок рисунка. В этом блоке содержится вся важная информация о растровом изображении: размеры рисунка, глубина цвета, метод сжатия и коэффициент прямоугольности пикселов.

2)Блок CMAP - это карта цветов растрового изображения.

3)Блок BODY - растровые данные, они могут быть сжаты или нет.

2. Формат IMG

Расширение файла DOS - IMG, тип формата - растровый. Цветовые возможности 2, 16, 256 или 16 миллионов цветов. Простое сжатие ROE. Структура файла IMG очень проста. Сначала идёт заголовок файла, а следом растровые данные. В заголовке находится информация о растровом изображении в целом: глубина цвета изображения, ширина и высота в пикселах, исходная ширина и высота в пикселах. Последние сведения полезны, когда растровые изображения переносятся с других компьютеров, где коэффициент прямоугольности может быть другим.

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

3. Растровый формат программы Macpaint

Расширение файла DOS - МАС, тип формата растровый. Программы, которые могут открывать или импортировать файлы МАС - большинство приложений Макинтош, некоторые растровые редакторы и издательские системы. Цветовые возможности - монохромный. Сжатие - RLE.

Macpaint - первый формат растровой графики для компьютеров Macintosh. Файл содержит ветви ресурсов и данных. Ветвь ресурсов содержит два элемента: элементы ресурсов идентифицируются четырехбуквенным кодом и следом за ним идут данные, которые интерпретируются программами в соответствии с кодом. Ресурсы могут быть 2-х видов: 1) PREF; 2) PREC. PREF ресурс для отображения на экране, второй для печати. Ветвь данных содержит действительные растровые данные и изображения. Вначале идут узоры, используемые для запоминания областей в растровом рисунке, следом за растровыми узорами идут растровые данные. Максимальный размер изображения ограничен: 576 на 720 пикселов, максимальный размер несжатого файла 51840 байтов. Когда файлы Macintosh передаются на РС ветви ресурсов и данных чаще всего разделяются на два различных файла. Иногда их могут комбинировать в одном файле или отбросить одну из ветвей. Чтобы вернуть файл обратно на Macintosh программа создаёт добавку к файлу - заголовок Macbinary - он занимает первые 128 байт файла Macpaint и содержит следующие данные: 1)оригинальное имя файла, как оно выглядит на Macintosh длиной до 63 символов; 2) код файла Macintosh; 3) код создателя на Macintosh; 4) длина ветви данных; 5) длина ветви ресурсов; 6) дата создания файла; 7) дата модификации файла.

4. Формат программы Microsoft Paint

Расширение файла DOS - MSP, тип формата растровый. Программы, которые могут открывать или импортировать файлы MSP: Microsoft Paint Brush, большинство программ преобразования графических файлов. Цветовые возможности - монохромный. Используется простое сжатие RLE. Первые 32 байта MSP файла заняты заголовком изображения, в котором записаны ширина и высота растрового рисунка в пикселах и коэффициенты прямоугольности отдельных пикселов. Следом за заголовком идут действительные данные растрового изображения. Пикселы могут быть только однобитовыми и пиксельные данные кодируются с помощью простой схемы сжатия RLE.

5. Графический язык фирмы Hewlett Packard

Расширение файла DOS - PGL, тип формата - язык управления принтером для перьевых графопостроителей. Программы, которые могут открывать или импортировать файлы PGL - большинство программ для РС, некоторые векторные редакторы и настольные издательские системы.

Размещено на Allbest.ru

...