Описание формата BMP для Window 3.0 (DIB)
=========================================
Основным отличием файлов нового формата (DIB) - Device
Independent Bitmap (аппаратно-независимый битовый образ) является
то, что в них используется кодировка цветов с одной битовой плос-
костью.
Файлы битовых образов нового формата начинаются со структуры
BITMAPFILEHEADER:
typedef struct tagBITMAPFILEHEADER {
word bfType; //тип файла (для битового образа - BM)
dword bfSize; //размер файла в dword
word bfReserved1; //не используется
word bfReserved2; //не используется
dword bfOffbits; //смещение данных битового образа от
//заголовка в байтах
}
Непосредственно за ней располагается структура BITMAPINFO, со-
держащая всю информацию о битовом образе. Она делится на две час-
ти: структуру BITMAPINFOHEADER, описывающей размеры и цветовой
формат битового образа, и массив структур RGBQUAD, определяющей
цветовую палитру:
typedef struct tagBITMAPINFO {
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
}
typedef struct tagBITMAPINFOHEADER {
dword biSize; //число байт, занимаемых структурой
//BITMAPINFOHEADER
dword biWidth; //ширина битового образа в пикселах
dword biHeight; //высота битового образа в пикселах
word biPlanes; //число битовых плоскостей устройства
word biBitCount; //число битов на пиксель
dword biCompression; //тип сжатия
dword biSizeImage; //размер картинки в байтах
dword biXPelsPerMeter;//горизонтальное разрешение устройства,
//пиксел/м
dword biYPelPerMeter; //вертикальное разрешение устройства,
//пиксел/м
dword biClrUsed; //число используемых цветов
dword biClrImportant; //число "важных" цветов
} BITMAPINFOHEADER;
Более подробно:
biSize - обычно используется для облегчения доступа к таблице
цветов.
biPlanes - определяет число битовых плоскостей; однако, по-
скольку цвет кодируется последовательными битами, это число всег-
да равно 1.
biBitCount - этим полем определяется число цветов, используе-
мых битовым образом. В зависимости от способа кодирования, может
принимать значения:
1 - битовый образ монохромный, и таблица цветов должна содер-
жать два элемента. Каждый бит в массиве данных кодирует один пик-
сел. Если значение бита - 0, то пиксел становится первым цветом
таблицы; если - 1, пиксел становится вторым цветом таблицы.
4 - битовый образ имеет максимум 16 цветов, и массив bmiColors
(таблица цветов) имеет до 16 элементов. Цвет каждого пиксела оп-
ределяется по таблице цветов при помощи четырехбитного индекса.
Например, если первый байт данных имеет значение 3Ah, то при
отображении битового образа цвет первого пиксела определяет чет-
вертый элемент таблицы цветов, а цвет второго - одиннадцатый.
8 - битовый образ имеет максимум 256 цветов, и таблица цветов
имеет до 256 элементов. Каждый байт массива данных определяет
цвет одного пиксела.
24 - битовый образ имеет максимум 2 в 24-й степени цветов.
Таблица цветов пуста, а цвет пикселов определяется пакетами из
трех байтов, описывающими цветовые интенсивности красного, зеле-
ного и голубого цветов.
biCompression - тип сжатия. Может принимать значения:
BI_RGB - сжатие отсутствует;
BI_RLE8 - сжатие для формата 8 бит на пиксел;
BI_RLE4 - сжатие для формата 4 бита на пиксел.
biXPelsPerMeter и biYPelsPerMeter - могут использоваться для
выбора из списка ресурсов пиктограммы, наиболее подходящей для
данного устройства.
biClrUsed - число цветов, используемых данныи битовым образом.
Если 0, то используются все цвета палитры (указанные в массиве
bmiColors).
biClrImportant - используется для управления алгоритмом отоб-
ражения цветов. Так, если четыре различных приложения отображают
на экране по одному битовому образу с 75 цветами каждый, то адап-
тер, выводящий 256 цветов одновременно, не сможет полностью ау-
тентично отобразить на экране все 4 картинки. В этом случае ис-
пользуется механизм замены цветов - ищется битовый образ с наи-
меньшим приоритетом и его "лишние" цвета заменяются наиболее под-
ходящими.
typedef struct tagRGBQUAD {
byte rgbRed; //интенсивность красного
byte rgbGreen; //интенсивность зеленого
byte rgbBlue; //интенсивность голубого
byte rgbRserved; //не используется
} RGBQUAD;
После того, как все параметры битового образа определены, в
файле идут сами скан-строки битовой плоскости, причем первой
скан-строкой в формате DIB считается нижняя скан-строка (т.е. на-
чало координат находится в левом нижнем углу изображения).
Скан-строки выровнены по 32-битной границе - dword !!!
ОПИСАНИЕ ФОРМАТА PCX И НЕКОТОРЫХ УТИЛИТ PC PAINTBRUSH
Перевод с английского языка и форматирование выполнены
сотрудником Института прикладной математики АН СССР
А.Самотохиным
От переводчика
ДДДДДДДДДДДДДД
Исходный документ был получен мною из JVDialuge 1st BBS
10.09.1991, переведен на русский язык и отформатирован.
Некоторые части документа, не относящиеся к технической
информации при переводе были опущены. Там, где я считал это
необходимым, я снабдил перевод своими комментариями.
Техническое описание включает информацию о следующих
программах:
Publisher's Paintbrush~
PC Paintbrush~ Plus
PC Paintbrush
FRIEZE Graphics~
ZSoft Corporation
450 Franklin Rd. Suite 100
Marietta, GA 30067
(404) 428-0008
Copyright 1988 ZSoft Corporation
СОДЕРЖАНИЕ
Введение.......................................... 4
Формат файла изображения (.PCX)................... 5
Декодирование файлов в формате .PCX............... 7
Описание информации о палитре..................... 8
Формат матричного шрифта PC Paintbrush............ 9
Примеры программ на C.............................10
Техническая информация об утилите FRIEZE..........12
Спецификация FRIEZE для версий ранее 7.00.........12
Вызов функций FRIEZE для версий ранее 7.00........13
Коды ошибок FRIEZE для версий ранее 7.00..........14
Спецификация FRIEZE для версий начиная с 7.00.....14
Вызов функций FRIEZE для версий начиная с 7.00....15
Коды ошибок FRIEZE для версий начиная с 7.00......17
.PCX Programmer's Toolkit.........................18
Введение
Цель создания данного буклета состоит в том, чтобы
помочь пользователям и разработчикам программ разобраться в
технических аспектах формата .PCX и использования утилиты
FRIEZE. Все комментарии, вопросы и предложения по буклету
направляйте по адресу:
ZSoft Corporation
Technical Support Department
ATTN: Technical Reference Manual
450 Franklin Rd. Suite 100
Marietta, GA 30067
Формат файла изображений (.PCX)
Информация данного раздела будет полезна для вас, если
вы хотите написать программу для чтения или записи PCX
файлов. Если вы хотите написать программу для изображений
строго определенного формата, вы должны быть в состоянии
создать нечто такое, что будет работать вдвое быстрее, чем
"Load from..." в PC Paintbrush. Файлы изображений, которые
используются в продуктах семейства PC Paintbrush и FRIEZE (с
расширениями .PCX) начинаются с заголовка длиной 128 байт.
Обычно вы можете игнорировать этот заголовок, если все ваши
изображения будут иметь одинаковое разрешение. Если же вы
хотите обрабатывать изображения с различным разрешением и
разным количеством цветов, вам следует корректно
интерпретировать информацию, находящуюся в данном заголовке.
Оставшаяся часть файла с изображением состоит из
закодированных графических данных. При кодировании
используется простой алгоритм, основанный на методе длинных
серий. Мы оставляем за собой право изменять этот алгоритм с
целью повышения эффективности упаковки данных. Если в файле
запоминается несколько цветовых слоев, каждая строка
изображения запоминается по цветовым слоям (в общем случае
красному-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, безусловно, не лучший. В
частности, такое насыщение достаточно часто имеет место для
цветных реалистичных изображений, особенно, если при их
создании применялись методы полутонирования.
Формат заголовка 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 являются целыми.
Замечание переводчика
ДДДДДДДДДДДДДДДДДДДДД
Во избежание недоразумений: в поле Window после-
довательно располагаются 4 целых числа, которые
соответствуют угловым координатам изображения Xmin, Ymin,
Xmax, Ymax. Как правило, Xmin и Ymin = 0.
Декодирование файлов в формате PCX
Сначала определите размер изображения, вычислив
[XSIZE = Xmax - Xmin + 1] и
[YSIZE = Ymax - Ymin + 1].
Затем вычислите, сколько байтов требуется для сохранения
одной несжатой строки развертки изображения:
TotalBytes = NPlanes * BytesPerLine
Отметим, что поскольку всегда используется целое число
байтов, возможно существование неиспользуемых данных в конце
каждой строки развертки. TotalBytes показывает сколько
памяти должно быть доступно для декодирования каждой строки
развертки, включая неиспользуемую информацию на правом конце
каждой строки.
Теперь вы можете начать декодирование первой строки
развертки - прочитайте первый байт данных из файла. Если два
старших бита этого байта равны 1, оставшиеся шесть битов
показывают сколько раз следует повторить СЛЕДУЮЩИЙ байт из
файла. Если это не так, то этот байт сам является данными с
повторителем равным 1. Продолжайте декодирование до конца
строки, ведя подсчет количества байтов, переданных в буфер
вывода. В конце каждой строки развертки имеет место
остановка алгоритма кодирования, но ее не существует при
переходе от одного слоя к другому. Когда строка сформирована
полностью, в конце каждого слоя внутри строки возможно
наличие лишних данных. Для нахождения этого остатка
используйте значения XSIZE и YSIZE. Если данные являются
многослойными, то BytesPerLine показывает, где заканчивается
каждый слой внутри строки развертки.
Продолжайте декодирование оставшихся строк. В файле
возможно наличие лишних строк с округлением на 8 или 16
строк.
Замечание переводчика
ДДДДДДДДДДДДДДДДДДДДД
Как следует из приведенного описания, в конце каждой
строки развертки предусматривается остановка алгоритма
кодирования, т.е предполагается, что каждая строка развертки
кодируется независимо. Однако мое знакомство с файлами в
формате PCX показывает, что это не всегда так (файлы в этом
формате пишет не только ZSoft Corpration !). Поэтому я бы
советовал пользователям не рассчитывать на то, что такая
остановка обязательно будет иметь место. Конец каждой строки
лучше все-таки фиксировать по заполнении ее буфера. Это,
безусловно, чуть усложнит программу декодирования, но
сделает ее более гибкой. (Кстати говоря, графический
редактор PC Paintbrush прекрасно понимает PCX файлы,
записанные без остановки алгоритма кодирования в конце
каждой строки, хотя при порождении собственных файлов такую
остановку делает).
Описание информации о палитре
Информация о 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
В настоящее время ZSoft добавил возможность хранения в
файле изображения PCX палитры, превышающей 16 цветов.
256-цветная палитра форматируется и интерпретируется точно
также, как 16-цветная, естественно, за исключением того, что
она длиннее. Палитра (число цветов x 3 байта длины)
добавляется в конец PCX файла и ей предшествует байт с
десятичным значением 12. Для определения палитры VGA BIOS
вам достаточно разделить прочитанные значения цветов на 4.
Для доступа к 256-цветной палитре следует:
1. Прочитать в заголовке поле Version. Если оно равно 5,
палитра должна быть.
2. Прочитать конец файла и отсчитать назад 769 байт.
Найденное вами значение должно равняться 12, что
указывает на присутствие 256-цветной палитры.
Замечание переводчика
ДДДДДДДДДДДДДДДДДДДДД
Два замечания по поводу 256-цветной палитры.
Во-первых, между пунктами 1 и 2 приведенной инструкции
я добавил бы следующий: "Прочитать в заголовке поле Bits per
pixel. Если оно равно 8, 256-цветная палитра должна быть.".
Смысл очевиден.
Во-вторых, в настоящее время довольно широкое распро-
странение получил пакет программ .PCX Programmer's Toolkit
фирмы Genus Microprogramming. В этом пакете (по крайней мере
в известных мне версиях) принят способ хранения 256-цветной
палитры несколько отличный от того, что был описан выше.
Отличие состоит в том, что палитре предшествует байт с
десятичным значением 10 (вместо 12), а значения цветовых
компонент занимают младшие 6 битов в каждом из байтов
цветовой тройки (т.е. изменяются от 0 до 63, как это принято
в VGA BIOS).
Информация о цветовой палитре CGA
Для стандартной платы IBM CGA битовый набор для
определения палитры более сложен. Используется только первый
байт тройки. Первая тройка содержит только первый байт с
осмысленным значением, который определяет цвет фона. Чтобы
определить цвет фона, нужно значение этого байта
(беззнаковое) разделить на 16. В результате будет получено
значение в диапазоне 0-15, которое и определяет цвет фона.
Вторая тройка содержит осмысленное значение первого байта,
которое определяет значение палитры для трех оставшихся
цветов. PC Paintbrush поддерживает для этих цветов 8
возможных палитр CGA, и, поскольку значение байта может быть
от 0 до 255, его следует разделить на 32 (см. схему,
приведенную ниже).
Taблица цветов для CGA
Байт #16 в заголовке
Цвет фона определяется 4 старшими битами.
Байт #19 в заголовке
Используются только 3 старших бита, остальные 5
игнорируются. Первые три бита обозначаются как C, P, I.
Их интерпретация:
C: разрешение color burst - 0 = color; 1 = monochrome
P: палитра - 0 = желтая; 1 = белая
I: яркость - 0 = малая; 1 = повышенная.
Замечание переводчика
ДДДДДДДДДДДДДДДДДДДДД
Как видите, исходный документ умалчивает о том, в каких
случаях информацию в заголовке файла следует трактовать как
палитру CGA. Не исключено, что ветвление следует вести по
полю Version заголовка.
Формат матричного шрифта PC Paintbrush
Матричный символьный шрифт запоминается в очень простом
формате. Формат этих символов следующий:
Заголовок (2 байта)
ширина шрифта db 0a0h + ширина символов (в точках)
высота шрифта db высота символов (в точках)
Ширина символов (256 байтов)
ширина символов db 256 dup(ширина каждого символа + 1)
Изображения символов
(остаток файла)
Символы запоминаются в порядке кодов ASCII и их может
быть до 256. Каждый символ выравнивается слева на границу
символьный блок и содержит одинаковое число байтов.
Байты организованы как N цепочек, где каждая цепочка
соответствует одной строке символа.
Например, каждый символ в шрифте размером 5x7 требует 7
байтов. Шрифт размера 9x14 использует 28 байтов на символ
(два байта на строку по 14 наборов). Допускается создание
шрифтов любого размера, при условии, что размер файла не
превышает 10K.
Примеры программ на C
Приведенный ниже набор программ на C предназначен для
чтения из PCX файла.
/* Данная процедура читает из файла один блок закодированных
данных из файла и запоминает повторитель count и байт
данных data. Результат:
0 = данные прочитаны
EOF = данных нет (вышли за пределы файла) */
encget(pbyt, pcnt, fid)
int *pbyt; /* сюда писать байт данных */
int *pcnt; /* сюда писать повторитель */
FILE *fid; /* ссылка на файл изображения */
{
int i;
*pcnt = 1;
if(EOF == (i = getc(fid))) return(EOF);
if(0xc0 == (0xc0 & i)) {
*pcnt = 0x3f&i;
if(EOF == (i=getc(fid))) return(EOF);
}
*pbyt = i;
return(0);
}
/* Это фрагмент программы, использующей encget. Она читает
файл целиком и запоминает результат декодирования в
(большом) буфере, на который ссылается переменная "bufr".
"fp" - это ссылка на файл с изображением */
while (EOF != encget(&chr, &cnt, fp))
for (i = 0; i < cnt; i++, *bufr++ = chr)
Приведенный ниже набор программ предназначен для записи
в .PCX файл.
/* Эта программа кодирует содержимое одной строки
изображения и записывает его в файл */
encLine(inBuff, inLen, fp)
unsigned char *inBuff; /* указатель на строку данных */
int inLen; /* длина строки в байтах */
FILE *fp; /* указатель на запис. файл */
{ /* возвращает число байтов, запис. в файл, или 0, если
имела место ошибка */
unsigned char this, last;
int srcIndex, i;
register int total;
register unsigned char runCount; /* макс. значение равно
63 */
total = 0;
last = *(inBuff); runCount = 1;
for (srcIndex = 1; srcIndex < inLen; srcIndex++) {
this = *(++inBuff);
if (this == last) {
runCount++; /* он кодируется */
if (runCount == 63) {
if (!(i=encput(last, runCount, fp))) return(0);
total += i;
runCount = 0;
}
}
else { /* this != last */
if (runCount) {
if (!(i=encput(last, runCount, fp))) return(0);
total += i;
}
last = this;
runCount = 1;
}
} /* конец цикла */
if (runCount) { /* завершение */
if (!(i=encput(last, runCount, fp))) return(0);
return(total + i);
}
return(total);
}
/* программа для записи закодированной пары байтов (или
одиночного байта, если он не кодируется) в файл */
encput(byt, cnt, fid) /* возвращает число записанных байтов
или 0, если имела место ошибка */
unsigned char byt, cnt;
FILE *fid;
{
if(cnt) {
if( (cnt==1) && (0xc0 != (0xc0&byt)) ) {
if(EOF == putc((int)byt, fid))
return(0); /* ошибка при записи на диск */
return(1);
}
else {
if(EOF == putc((int)0xC0 | cnt, fid))
return(0); /* ошибка при записи на диск */
if(EOF == putc((int)byt, fid))
return(0); /* ошибка при записи на диск */
return(2);
}
}
return(0);
}
Техническая информация об утилите FRIEZE
FRIEZE является резидентной утилитой, которая позволяет
вам перехватывать и сохранять графические изображения других
программ. Вы можете потом переместить это изображение в PC
Paintbrush для редактирования и улучшения.
FRIEZE был переписан для использования в PC Paintbrush
Plus, и поэтому техническая документация по нему коренным
образом изменилась. Для облегчения понимания технической
информации по FRIEZE, мы разбили этот раздел на две части:
один о версиях FRIEZE, предшествующих 7.00, и второй о
текущей версии (начиная с 7.00).
Начиная с версии FRIEZE 7.10, он может быть позднее
удален из памяти (это возвращает вам почти 85K DOS RAM, в
зависимости от вашей конфигурации). Чтобы сделать это, вы
можете выбрать освобождение FRIEZE из памяти в меню
PCINSTAL, либо изменить в некоторый момент рабочую
директорию PC PAINTBRUSH и набрать слово "FRIEZE."
Спецификация для версий FRIEZE ранее 7.00
Набор опций печати FRIEZE
FRIEZE может легко адаптироваться к неполным принтерным
кабелям (в которых отсутствует линия статуса, указанная IBM)
и управляет как последовательным, так и параллельным
интерфейсами. Отметим также, что FRIEZE всегда использует
стандартные вызовы BIOS'а, вследствие чего неответившие
устройства будут находиться в режиме тайм-аута, однако можно
потребовать, чтобы случаи типа отсутствия бумаги при этом
игнорировались.
Синтаксис команды FRIEZE:
FRIEZE Xnaarr
Где:
X = параллельное (P) или последовательное (S)
устройство,
n = номер порта,
aa = две шестнадцатиричные цифры кода, для
которого возвращаемые биты вызывают аварийное
завершение,
rr = две шестнадцатиричные цифры кода, для
которого возвращаемые биты вызывают повтор.
Примеры:
FRIEZE P1 - использовать стандартный набор параллельного
вывода, номер порта 1, маска аварийного
завершения 28h, и маска повтора 01h
FRIEZE P2 - использовать принтерный порт #2
FRIEZE S1 - использовать последовательный порт #1 и протокол
Xon/Xoff
FRIEZE P10028 - использовать принтерный порт #1, маску
аварийного завершения 00 (ничто не воспри-
нимается как ошибка) и маску повтора 28h
Интерпретация кодов:
Коды, возвращаемые параллельным принтером при вызове
общеизвестны:
20h - отсутствие бумаги,
10h - выбран,
08h - ошибка ввода/вывода,
04h - не используется,
02h - не используется,
01h - тайм-аут.
Вызов функций FRIEZE
FRIEZE работает, используя программное прерывание номер
10h (вызов видео прерывания).
Для вызова функции FRIEZE, загрузите значение 75
(десятичное) на регистр AH, номер вызываемой функции на
регистр CL и затем либо загрузите на AL аргумент функции,
либо на регистры ES и BX сегмент и смещение того места, где
располагаются эти аргументы, после чего вызовите прерывание
10h.
FRIEZE возвращает на AX число, которое означает код
ответа: нулевое значение соответствует успешному завершению,
все другие - номер ошибки. Значения других регистров не
изменяются.
# Определение Аргументы
0 Печать окна AL = режим:
0 - символьный,
1 - обычный,
2 - sideways
1 Чтение окна ES:BX - строка
(имя читаемого файла)
2 Запись окна ES:BX - строка
(имя записываемого файла)
3 Ширина печати AL = ширине в 1/4 дюйма
4 Высота печати AL = высота в 1/4 дюйма
5 Резерв.
6 Уст. левой границы AL = левое поле в 1/4 дюйма
7 Уст. размера окна ES:BX - 4 слова в которых записаны
угловые координаты окна:
Xmin, Ymin, Xmax, Ymax
8 Резерв.
9 Уст. образцов ES:BX - 16-элементный вектор байтов,
содержащий цветовое
соответствие между принтером
и экраном.
10 Получ. образцов ES:BX - вектор из 16 байт, описанный
выше
11 Уст. режима AL = номер режима
12 Резерв.
13 Резерв.
14 Резерв.
15 Получ. окна ES:BX - пространство для 4, опред.
текущее окно
16 Уст. опций печати ES:BX - строка символов с опциями
печати. Имеет такой же
формат, что и команда
FRIEZE.
17 Инициализация ES:BX - массив из 3 слов,
содержащий данные из
файла CARDS.DAT Диска 1
PC Paintbrush (Hres, Vres,
и необяз. номер кода)
Все символьные строки заканчиваются нулевым байтом (формат
ASCIIZ).
Коды ошибок FRIEZE для версий ранее 7.00
Когда FRIEZE вызывается с использованием прерывания 10h,
он возвращает на регистре AX код ошибки. Нулевое значение
этого регистра означает отсутствие ошибки; ненулевое - что
имела место ошибка. Значения кодов ошибок объясняются ниже.
0 Нет ошибки
1 Вывод остановлен пользователем с помощью клавиши ESC.
2 Резерв.
3 Ошибка при чтении файла
4 Ошибка при записи файла
5 Файл не найден
6 Неправильный указатель или неудача при создании файла
(нет картинки или ошибочный режим экрана)
7 Ошибка при закрытии файла
8 Ошибка диска - обычно при открытой шторке дисковода
9 Не используется
10 Неверная команда - при вызове CL имеет значение
несуществующей функции FRIEZE
11 Не используется
12 Не используется
Версии FRIEZE, начиная с 7.00
Новые версии FRIEZE имеют другое число параметров в
командной строке. Новый формат команды FRIEZE:
FRIEZE {PD} {Xnaarr} {flags} {video} {hres} {vres} {vnum}
Где:
{PD} - имя файла драйвера принтера (без расширения .PDV)
{Xnaarr}
X = S для последовательного принтера
P для параллельного принтера
n = номер порта
aa = две шестнадцатиричные цифры кода, для которого
возвращаемые биты вызывают аварийное завершение,
rr = две шестнадцатиричные цифры кода, для которого
возвращаемые биты вызывают повтор.
{flags} Шестнадцатиричный код из четырех цифр
Первая управляет флагом длины
Вторая управляет флагом ширины
Третья управляет флагом режима
Четвертая управляет флагом BIOS'а
ЗАМЕЧАНИЕ: Флаги длины ширины и режима специфичны для
драйвера принтера. См. файл PRINTERS.DAT на диске 1 для
правильного использования. В общем случае флаг длины 1
означает широкую каретку, а 0 - стандартную ширину.
Нулевые флаги длины и режима означают использование
стандартного набора для принтера.
{video} Комбинация видео драйвера, в которой первый знак
отвечает за видео драйвер верхнего уровня, а оставшиеся за
драйвер нижнего.
Пример = 1EGA - использовать DRIVE1 и EGA.DEV
{hres} Горизонтальное разрешение нужного графического режима
{vres} Вертикальное разрешение нужного графического режима
{vnum} Аппаратно-зависимый параметр (обычно число цветовых
плоскостей)
Замечание: Последние четыре параметра могут быть получены из
файла CARDS.DAT на диске 1 вашего PC Paintbrush.
Коды возврата параллельного принтера:
80h - Сигнал занятости (0=занят)
40h - Acknowledge
20h - Отсутствие бумаги
10h - Выбран
08h - Ошибка ввода/вывода
04h - Не исп.
02h - Не исп.
01h - Тайм-аут
Вызов функций FRIEZE для версий начиная с 7.00
FRIEZE работает, используя программное прерывание номер
10h (вызов видео прерывания).
Для вызова функции FRIEZE, загрузите значение 75
(десятичное) на регистр AH, номер вызываемой функции на
регистр CL и затем либо загрузите на AL аргумент функции,
либо на регистры ES и BX сегмент и смещение того места, где
располагаются эти аргументы, после чего вызовите прерывание
10h.
FRIEZE возвращает на AX число, которое означает код
ответа: нулевое значение соответствует успешному завершению,
все другие - номер ошибки. Значения других регистров не
изменяются.
# Определение Аргументы
0 Резерв.
1 Чтение окна ES:BX - строка
(имя читаемого файла)
2 Запись окна ES:BX - строка
(имя записываемого файла)
3 Резерв.
4 Резерв.
5 Резерв.
6 Резерв.
7 Уст. размера окна ES:BX - 4 слова в которых записаны
угловые координаты окна:
Xmin, Ymin, Xmax, Ymax
8 Резерв.
9 Уст. образцов ES:BX - 16-элементный вектор байтов,
содержащий цветовое
соответствие между принтером
и экраном.
10 Получ. образцов ES:BX - вектор из 16 байт, описанный
выше
11 Уст. режима AL = номер режима
12 Резерв.
13 Резерв.
14 Резерв.
15 Получ. окна ES:BX - пространство для 4, опред.
текущее окно
16 Уст. опций печати ES:BX - строка символов с опциями
печати. Имеет такой же
формат, что и команда
FRIEZE.
17 Резерв.
18 Резерв.
19 Резерв. FRIEZE
20 Получение версии AH равен целой части номера версии,
FRIEZE а AL - десятичной. Если AH=0, то
можно считать, что установлена
версия FRIEZE ранее 7.00.
21 Уст. параметров ES:BX указывает на 8-словную (16
байтов) таблицу параметров:
TopMargin - верхнее поле,
LeftMargin - левое поле,
HSize - вертикальный размер,
VSize - горизонтальный размер,
Quality/Draft Mode - режим,
PrintHres - гор. разрешение,
PrintVres - верт. разрешение,
Reserved - резерв.
Поля и размеры задаются в сотых
долях дюйма. Параметр режима может
принимать след. значение:
0 - черновой режим (draft),
1 - режим качеств. печати,
2 - печатать с разрешение, указ. в
Hres и Vres.
Разрешение печати задается в DPI
(число точек на дюйм). Любой
параметр, который следует оставить
неизменным, должен равняться -1
(0FFFFh). Резервное поле следует
заполнить -1.
22 Получ. параметров ES:BX указывает на 8-словную (16
байтов) таблицу параметров.
23 Получ. разрешения ES:BX указывает на 12-словную
таблицу (24 байта), где содержатся
пары разрешения принтера (6 пар).
ЗАМЕЧАНИЕ: Все символьные строки заканчиваются нулевым
байтом (формат ASCIIZ).
Коды ошибок FRIEZE для версий начиная с 7.00
Когда FRIEZE вызывается с использованием прерывания 10h,
он возвращает на регистре AX код ошибки. Нулевое значение
этого регистра означает отсутствие ошибки; ненулевое - что
имела место ошибка. Значения кодов ошибок объясняются ниже.
0 Нет ошибки
1 Вывод остановлен пользователем с помощью клавиши ESC.
2 Резерв.
3 Ошибка при чтении файла
4 Ошибка при записи файла
5 Файл не найден
6 Неправильный указатель или неудача при создании файла
(нет картинки или ошибочный режим экрана)
7 Ошибка при закрытии файла
8 Ошибка диска - обычно при открытой шторке дисковода
9 Ошибка принтера - он выключен или отсутствует бумага.
10 Неверная команда - при вызове CL имеет значение
несуществующей функции FRIEZE
11 Ошибка при создании файла - диск защищен от записи или
переполнен
12 Неверный видео режим - FRIEZE не может захватить
текстовой экран.
.PCX Programmer's Toolkit
PCX Programmer's Toolkit, созданный фирмой Genus
Microprogramming, позволяет разработчикам создавать
прикладные программы с возможностью высвечивания,
сохранения, захвата и манипулирования изображениями в
формате PCX. Поскольку данный пакет поддерживает большинство
широко используемых адаптеров и компиляторов, он может
использоваться во многих областях. Хотя основным интерфейсом
пакета является библиотечный, к нему прилагается много
утилит для высвечивания и перехвата экрана, создания окон,
просмотра заголовка и позиционирования изображений.
Пакет также содержит 35 программ для высвечивания и
записи изображений из буфера и файлов, установки палитр,
доступа к заголовкам изображений и много другого.
Пакет написан на ассемблере для достижения
максимального быстродействия. Он также позволяет экономить
дисковое пространство (группа из нескольких PCX изображений
может помещаться в библиотечный файл) и облегчает достижение
мобильности программ. В нем также предусмотрена возможность
высвечивания изображений при работе с базами данных.
Пакет поддерживает следующие дисплеи:
Все режимы Hercules и графических адаптеров CGA, EGA, и
VGA.
Пакет совместим со следующими компиляторами:
Пакет содержит библиотеки, совместимые с Microsoft C,
Turbo C, QuickC, Lattice C, QuickBasic, Turbo Pascal, и
Clipper. Имеется также quick-библиотека для интегрированных
компиляторов Microsoft и unit для Turbo Pascal. Имеются
библиотеки для моделей памяти Small, Medium, Large всех
компиляторов, которые поддерживают такие модели.
Совместимое программное обеспечение:
Пакеты Paint, такие как ZSoft's PC Paintbrush и
Microsoft Paintbrush полностью совместимы. Поддерживаются
настольные издательства, включая Xerox Ventura Publisher и
Aldus PC PageMaker.
Что требуется для пакета:
Компьютер IBM PC/XT/AT и совместимый с ним на 100%,
дисковод, IBM CGA/EGA/VGA или Hercules адаптер (или
совместимый с ними на 100%) и DOS версии, начиная с 2.0.
Только 89.95$!!!
Заказы направлять по адресу:
ZSoft Corporation
450 Franklin Rd., Suite 100
Marietta, GA. 30057
(404) 428-0008
Microsoft, Microsoft C, QuickC, QuickBasic, and Microsoft
Paintbrush являются торговыми знаками Microsoft Corporation.
Turbo C, Turbo Basic, and Turbo Pascal - торговый знак
Borland International. Clipper - торговый знак Nantucket
Software. Lattice C - торговый знак Lattice Corporation.
Hercules - торговый знак Hercules Corporation. Другие
программные пакеты являются торговыми знаками производящих
их компаний.
Структура GIF-файла
Общая структура Блок данных Блок описания
ЪДДДДДДДДДДДДДДДДДДДДї графического образа
і Заголовок і ЪДДДДДДДДДДДДДДДДДДДДї ЪДДДДДДДДДДДДДДДДДДДДДДДДДї
і і і длина пикселя і 1 і разделитель образов і
ГДДДДДДДДДДДДДДДДДДДДґ ГДДДДДДДДДДДДДДДДДДДДґ і (ASCII 21h '!') і
і блок описания і іразмер блока данных і ГДДДДДДДДДДДДДДДДДДДДДДДДДґ
і логического экрана і ГДДДДДДДДДДДДДДДДДДДДґ 2 і левая координата і
ГДДДДДДДДДДДДДДДДДДДДґ і і 3 ГДДДДДДДДДДДДДДДДДДДДДДДДДґ
і глобальная і і данные і 4 і верхняя координата і
і цветовая карта і і і 5 ГДДДДДДДДДДДДДДДДДДДДДДДДДґ
і (необязательно) і ГДДДДДДДДДДДДДДДДДДДДґ 6 і ширина образа і
ГДДДДДДДДДДДДДДДДДДДДґ і маркер конца і 7 ГДДДДДДДДДДДДДДДДДДДДДДДДДґ
і блок расширения і і блока данных і 8 і высота образа і
і (необязательно) і АДДДДДДДДДДДДДДДДДДДДЩ 9 ГДДДВДДДВДДДВДДВДДВДДДДДДДґ
ГДДДДДДДДДДДДДДДДДДДДґ і і і і і і і
і блок описания і іMapіItiіSRTіR1іR2і длина і
і графического образаі Блок расширения і і і і і іпикселяі
і і ЪДДДДДДДДДДДДДДДДДДДДї АДВДБДВДБДВДБДДЕДДБДДДДДДДЩ
ГДДДДДДДДДДДДДДДДДДДДґ і разделитель блоков і . . . ... резерв
і локальная і і (ASCII 21h '!') і . . ..лок/карта сортирована
і цветовая карта і ГДДДДДДДДДДДДДДДДДДДДґ . ..флаг
і (необязательно) і і код функции і ..флаг наличия лок/карты
ГДДДДДДДДДДДДДДДДДДДДґ ГДДДДДДДДДДДДДДДДДДДДґ
іблок описания данныхі іразмер блока данных і
і (необязательно) і ГДДДДДДДДДДДДДДДДДДДДґ Блок описания
ГДДДДДДДДДДДДДДДДДДДДґ і і логического экрана
і блок расширения і і данные і ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї
і (необязательно) і ГДДДДДДДДДДДДДДДДДДДДґ 1 і ширина экрана і
ГДДДДДДДДДДДДДДДДДДДДґ і маркер конца блока і 2 ГДДДДДДДДДДДДДДДДДДДДДДДДДДДґ
і маркер конца і і 00h і 3 і высота экрана і
і заголовка і АДДДДДДДДДДДДДДДДДДДДЩ 4 ГДДДДДДДДДДВДДДДДДВДВДДДДДДДґ
АДДДДДДДДДДДДДДДДДДДДЩ іглобальнаяі К-во і і і
і карта іцветові0і длина і
і есть ? і (бит)і іпикселяі
Заголовок ГДДДДДДДДДДБДДДДДДБДБДДДДДДДґ
ЪДДДДДДДДї і цвет фона і
1 і і ГДДДДДДДДДДДДВДДДДДДДДДДДДДДґ
2 і GIF і і глобальная і разрешающая і
3 ГДДДДДДДДґ і карта і способность і
4 і версия і ісортирована?і (в пикселах) і
5 і 87a і АДДДДДДДДДДДДБДДДДДДДДДДДДДДЩ
6 АДДДДДДДДЩ
G I F (tm)
Graphics Interchange Format (tm)
(Формат графического обмена)
Стандартное определение механизма
для запоминания и передачи
растровой графической информации
June 15, 1987
(c) CompuServe Incorporated, 1987
All rights reserved
При копировании данного документа
содержащаяся в нем информация становится
доступна для пользователей компьютеров без
лицензионных ограничений
GIF и 'Graphics Interchange Format'
являются торговой маркой CompuServe, Incorporated.
an H&R Block Company 5000 Arlington Centre Blvd.
Columbus, Ohio 43220
(614) 457-8600
Перевод с английского языка выполнен А.С.Самотохиным
Институт прикладной математики АН СССР
Москва, ноябрь 1990 г.
Описание формата графического обмена (GIF)
Оглавление
ВВЕДЕНИЕ . . . . . . . . . . . . . . . . . . . 3
ОБЩИЙ ФОРМАТ ФАЙЛА . . . . . . . . . . . . . . 3
ИДЕНТИФИКАТОР GIF. . . . . . . . . . . . . . . 4
ДЕСКРИПТОР ЭКРАНА. . . . . . . . . . . . . . . 4
ГЛОБАЛЬНАЯ ТАБЛИЦА ЦВЕТОВ. . . . . . . . . . . 5
ДЕСКРИПТОР ИЗОБРАЖЕНИЯ . . . . . . . . . . . . 6
ЛОКАЛЬНАЯ ТАБЛИЦА ЦВЕТОВ . . . . . . . . . . . 7
РАСТРОВЫЕ ДАННЫЕ . . . . . . . . . . . . . . . 7
ТЕРМИНАТОР GIF . . . . . . . . . . . . . . . . 8
РАСШИРЕННЫЙ БЛОК GIF . . . . . . . . . . . . . 8
ПРИЛОЖЕНИЕ A - ГЛОССАРИЙ . . . . . . . . . . . 9
ПРИЛОЖЕНИЕ B - ВЗАИМОДЕЙСТВУЮЩИЕ
ПОСЛЕДОВАТЕЛЬНОСТИ. . . . . . . 10
ПРИЛОЖЕНИЕ C - УПАКОВКА И СЖАТИЕ ИЗОБРАЖЕНИЯ . 12
ПРИЛОЖЕНИЕ D - ОБРАБОТКА НЕСКОЛЬКИХ
ИЗОБРАЖЕНИЙ . . . . . . . . . . 15
ВВЕДЕНИЕ
'GIF' (tm) - это стандарт фирмы CompuServe для определения
растровых цветных изображений. Этот формат позволяет высвечивать
на различном оборудовании графические высококачественные
изображения с большим разрешением и подразумевает механизм обмена
и высвечивания изображений. Описанный в настоящем документе формат
изображений был разработан для поддержки настоящей и будущей
технологии обработки изображений и будет в дальнейшем служить
основой для будущих графических продуктов CompuServe.
Главная задача настоящего документа состоит в том, чтобы
снабдить программистов необходимой технической информацией для
написания декодеров и кодировщиков GIF. Поэтому в документе
используется терминология связанная с общими вопросами графики и
программирования.
Первый раздел настоящего документа описывает формат данных
GIF и его компоненты в приложении к декодерам GIF, вне зависимости
от того являются ли они отдельной программой или частью пакета
связи. Приложение B относится к декодерам являющимися частью
пакетов связи и описывает протокол, необходимый для входа и
существования режима GIF и отвечает на ряд специфических вопросов.
Глоссарий в приложении A определяет некоторые термины,
использованные в документе. Приложение C дает подробное объяснение
того, как сами графические изображения пакуются в виде
последовательности байтов.
Определение формата данных GIF
ОБЩИЙ ФОРМАТ ФАЙЛА
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї
і ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї і
і і Идентификатор GIF і і
і АДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ і
і ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї і
і і Дескриптор экрана і і
і АДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ і
і ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї і
і і Глобальная таблица цветов і і
і АДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ і
. . . . . .
і ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї і ДДДї
і і Дескирптор изображения і і і
і АДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ і і
і ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї і і
і і Локальная таблица цветов і і ГДД Повторяется
і АДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ і і от 1 до n раз
і ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї і і
і і Растровые данные і і і
і АДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ і ДДДЩ
. . . . . .
ГД Терминатор GIF Дґ
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ
ИДЕНТИФИКАТОР GIF
Наличие в начале файла специальной "подписи" указывает, что
последующие данные являются действительно потоком данных
изображения в формате GIF. Эта "подпись" состоит из следующих
шести символов:
G I F 8 7 a
Три последних символа '87a' могут рассматриваться как номер версии
для данного конкретного определения GIF и будут использоваться в
дальнейшем в качестве ссылки на документ с описанием GIF в
зависимости от номера версии.
ДЕСКРИПТОР ЭКРАНА
Дескриптор экрана описывает общие параметры для всех
последующих изображений в формате GIF. Он определяет размеры
пространства изображения или требуемого логического экрана,
существование информации о таблице цветов и "глубине" экрана. Эта
информация запоминается в виде серии 8-битовых байтов, как
показано ниже.
биты
7 6 5 4 3 2 1 0 Номер байта
ЪДДДДДДДДДДДДДДДї
і і 1
ГДШирина экранаДґ Ширина растра в пикселах (сначала LSB)
і і 2
ГДДДДДДДДДДДДДДДґ
і і 3
ГДВысота экранаДґ Высота растра в пикселах (сначала LSB)
і і 4
ГДВДДДДДВДВДДДДДґ M = 1, За дескриптором следует глобальная
і і і і і таблица цветов
іMі cr і0іpixelі 5 cr+1 = число битов цветового разрешения
ГДБДДДДДБДБДДДДДґ pixel+1 = число бит/пиксел в изображении
і background і 6 фон = цветовой индекс фона экрана
ГДДДДДДДДДДДДДДДґ (цвет определяется из глобальной таблицы
і0 0 0 0 0 0 0 0і 7 цветов или из таблицы по умолчанию)
АДДДДДДДДДДДДДДДЩ
Ширина и высота логического экрана могут быть больше размеров
физического экрана. Способ высвечивания изображений больших, чем
размеры физического экрана зависит от реализации и может
использовать преимущества конкретного оборудования (например, окна
скроллинга в Macintosh scrolling windows). В противном случае
изображение будет усечено по краям экрана.
Значение 'pixel' также определяет число цветов в изображении.
Диапазон значений 'pixel' составляет от 0 до 7, что соответствует
от 1 до 8 битам. Это транслируется в диапазон от 2 (черно-белые
изображения) до 256 цветов. Бит 3 в байте 5 зарезервирован для
будущих определений и должен быть нулевым.
ГЛОБАЛЬНАЯ ТАБЛИЦА ЦВЕТОВ
Глобальная таблица цветов является необязательной и
рекомендуется для изображений, где требуется точная передача
цветов. На существование этой таблицы указывает поле 'M' в байте 5
дескриптора экрана. Цветовая таблица может быть также связана с
каждым изображением в GIF-файле, что будет описано позже. Однако
обычно эта глобальная таблица будет использоваться, из-за
ограничений, существующих в настоящее время в доступном
оборудовании. Флаг 'M' в дескрипторе конкретного изображения
обычно равен 0. Если глобальная таблица цветов присутствует, ее
определение следует непосредственно за дескриптором экрана. Число
элементов цветовой таблицы, следующей за описателем экрана равно
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 Начало изображения в пикселах относи-
ГД Левый край Дґ тельно левого края экрана (сначала LSB)
і і 3
ГДДДДДДДДДДДДДДДґ
і і 4
ГД Верхний крайДґ Начало изображения в пикселах относительно
і і 5 верхнего края экрана (сначала LSB)
ГДДДДДДДДДДДДДДДґ
і і 6
ГД Ширина Дґ Ширина изображения в пикселах
і і 7 (сначала LSB)
ГДДДДДДДДДДДДДДДґ
і і 8
ГД Высота Дґ Высота изображения в пикселах
і і 9 (сначала LSB)
ГДВДВДВДВДВДДДДДґ M=0 - Использовать глобальную таблицу цве-
іMіIі0і0і0іpixelі 10 тов, игнорировать 'pixel'
АДБДБДБДБДБДДДДДЩ M=1 - Далее следует локальная таблица цве-
тов, использовать 'pixel'
I=0 - Изображение отформатировано в после-
довательном порядке
I=1 - Изображение отформатировано в поряд-
ке переплетения
pixel+1 - число бит на пиксел в данном
изображении
Описание положения и размеров экрана должно быть находиться
внутри матрицы, определенной в дескрипторе экрана. С другой
стороны, нет необходимости, чтобы изображение полностью заполняло
весь экран.
ЛОКАЛЬНАЯ ТАБЛИЦА ЦВЕТОВ
Локальная таблица цветов необязательна и определена здесь для
будущего использования. Если установлен бит 'M' байта 10 в
дескрипторе изображения, то вслед за дескриптором изображения
следует локальная таблица цветов, которая относится только к
последующему изображению. После обработки изображения цветовую
таблицу следует привести к той, которая была определена после
дескриптора экрана. Заметим, что поле 'pixel' байта 10 в
дескрипторе изображения используется только в том случае, если
указана локальная таблица цветов. Она определяет не только размер
пиксела (число битов в нем), но число элементов последующей
цветовой таблицы. Число битов на пиксел также следует
восстановить к тому значению, которое было определено в
дескрипторе экрана, после того, как закончится обработка
изображения.
РАСТРОВЫЕ ДАННЫЕ
Формат самого изображения определен как серия значений
номеров пикселов, которые образуют изображение. Пикселы
запоминаются слева направо последовательно по строкам изображения.
По умолчанию строки записываются последовательно, сверху вниз. В
том случае, если установлен бит 'I' в байте 10 дескриптора
изображения, то порядок строк при записи изображения соответствует
четырех проходному процессу. При первом проходе записывается
каждая 8-ая строка, начиная с верхней строки окна изображения. При
втором проходе записывается каждая 8-ая строка, начиная с пятой
строки сверху. На третьем проходе записывается каждая 4-ая строка,
начиная с третьей строки окна. Четвертый проход завершает
изображение, записывая каждую вторую строку, начиная со второй
строки с сверху. Ниже приведено графическое описание этого
процесса.
Изображение
Стр. Прох.1 Прох.2 Прох.3 Прох.4 Результат
ДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД
0 **1a** **1a**
1 **4a** **4a**
2 **3a** **3a**
3 **4b** **4b**
4 **2a** **2a**
5 **4c** **4c**
6 **3b** **3b**
7 **4d** **4d**
8 **1b** **1b**
9 **4e** **4e**
10 **3c** **3c**
11 **4f** **4f**
12 **2b** **2b**
. . .
Значения пикселов изображения обрабатываются как цветовые
индексы, указывающие на существующую таблицу цветов. В результате
получается цветовое значение из таблицы, которое реально
воспроизводится на экране. Эти серии цветовых индексов, число
которых равно ширине_изображения*высоту_изображения, пропускаются
через поток данных изображения GIF по одному значению на пиксел,
сжимаются и упаковываются в соответствии с версией алгоритма
сжатия LZW, как это определено в Приложении C.
ТЕРМИНАТОР 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 в будущем, хотя
и без дополнительных функциональных возможностей.
ПРИЛОЖЕНИЕ A
ГЛОССАРИЙ
Пиксел - Наименьший элемент графического изображения. Обычно
соответствует отдельной точке на графическом экране. Разрешение
изображения обычно задается в пикселах. Например, одним из
довольно стандартных экранных графических форматов является 320
пикселов по горизонтали на 200 по вертикали. Каждый пиксел
может быть окрашен одним из нескольких цветов в зависимости от
возможностей графического оборудования.
Растр - горизонтальные уровни пикселов, представляющие одну строку
изображения. Типичный метод порождения изображения, поскольку
большинство образцов видеоборудования ориентировано на наиболее
эффективную работу именно таким образом.
LSB - Сокращение от Least Significant Byte ( младший по значению
байт). Ссылается на соглашение для двух байтов числового
значения, согласно которому младший по значению байт
предшествует более старшему. Такое соглашение типично для
микрокомпьютеров.
Таблица цветов - Список определений для каждого цвета,
используемый в изображениях GIF. Желаемые цвета конвертируются
в доступные цвета с помощью таблицы, причем по входным цветовым
индексам изображения образуются выходные цветовые индексы
оборудования. Если для изображения GIF указана таблица цветов,
то цвета выходных пикселов будут изменены на основе
используемого оборудования и его способности соответствовать
заданным цветам.
Переплетение - Метод высвечивания изображений GIF, при котором
совершаются несколько проходов с выводом разнесенных строк
растра, что дает возможность визуализации общего содержания
всего изображения до того, как обработаны все данные.
B Протокол - Свободно распространяемый протокол передачи файлов с
исправлением ошибок, разработанный CompuServe и реализованный в
продукте VIDTEX фирмы CompuServe. Такой механизм обнаружения
ошибок будет использован при передаче изображений GIF для
интерактивных приложений.
LZW - Совершенный алгоритм сжатия данных, основанный на работе,
сделанной Lempel-Ziv и Welch, который обеспечивает возможность
высокоэффективного однопроходного кодирования и декодирования.
Это позволяет одновременно раскрывать и высвечивать
изображения. Исходная статья, в которой был описан указанный
метод:
Terry A. Welch, "A Technique for High
Performance Data Compression", IEEE Computer, vol 17
no 6 (June 1984)
Этот базовый алгоритм также используется в свободно
распространяемых утилитах ARC для сжатия файлов. Адаптация
алгоритма LZW, выполненная CompuServe для GIF описана в
приложении C.
ПРИЛОЖЕНИЕ B
ПОСЛЕДОВАТЕЛЬНОСТЬ ОБМЕНОВ GIF ДЛЯ ИНТЕРАКТИВНОЙ СРЕДЫ
Для управления на интерактивной линии связи между
отправителем и получателем GIF определена следующая
последовательность действий. Эта последовательность не применяется
в приложениях, включающих загрузку статических GIF-файлов и не
является частью GIF-файлов.
ЗАПРОС ВОЗМОЖНОСТЕЙ GIF - GIF CAPABILITIES ENQUIRY
Последовательность GCE идет из головного процесса и требует,
чтобы интерактивный декодер GIF вернул ответное сообщение, которое
определяет графические параметры для декодирования. Оно включает
возвращаемую информацию о доступных размерах экрана, числе битов
на цвет и поддерживаемом количестве цветов. Esc-последовательность
для GCE определена следующим образом:
ESC [ > 0 g (g в нижнем регистре, пробелы вставлены для
ясности)
(0x1B 0x5B 0x3E 0x30 0x67)
СООБЩЕНИЕ ВОЗМОЖНОСТЕЙ GIF - GIF CAPABILITIES RESPONSE
Ответное сообщение о возможностях GIF возвращается
интерактивным декодером и определяет возможности дисплея декодера
для всех графических режимов, поддерживаемых математическим
обеспечением. Заметьте, что оно может также включать графический
принтер, а не только экран монитора. Общий формат этого сообщения:
#version;protocol{;dev,width,height,color-bits,color-res}... <CR>
'#' - GCR символ-идентификатор (Знак номера)
version - номер версии формата GIF; начально '87a'
protocol='0' - Протокол end-to-end не поддерживается декодером.
Передача данных ведется непосредственным 8-битным
потоком.
protocol='1' - Может поддерживать протокол коррекции ошибок при
передаче данных от прямого хозяина на дисплей.
dev = '0' - Далее следуют параметры экрана
dev = '1' - Далее следуют параметры принтера
width - Максимальная ширина дисплея в пикселах
height - Максимальная высота дисплея в пикселах
color-bits - Поддерживаемое число битов на пиксел.
Следовательно, поддерживаемое число цветов
2**color-bits.
color-res - Число битов на компоненту цвета, поддерживаемое
аппаратной цветовой палитрой. Если color-res равен
'0', таблица аппаратной палитры недоступна.
Заметьте, что все значения в GCR возвращаются в десятичных
числах ASCII и сообщение заканчивается символом "Возврат каретки".
Следующее GCR-сообщение описывает три стандартных режима
EGA с конфигурацией без принтера, поток данных GIF может
обрабатываться в рамках протокола с коррекцией ошибок:
#87a;1 ;0,320,200,4,0 ;0,640,200,2,2 ;0,640,350,4,2<CR>
ВВОД ГРАФИЧЕСКОГО РЕЖИМА GIF
Две последовательности, определенные ниже вызывают для работы
интерактивный декодер GIF. Между ними существует только
единственное отличие. Оно заключается в выборе различной среды
вывода. Эти последовательности:
ESC [ > 1 g Высветить изображение GIF на экране
(0x1B 0x5B 0x3E 0x31 0x67)
ESC [ > 2 g Выдать изображение непосредственно на
присоединенный графический принтер. Допускается
также необязательный вывод на экран.
(0x1B 0x5B 0x3E 0x32 0x67)
Заметьте, что символ 'g', заканчивающий каждую
последовательность находится в нижнем регистре.
ИНТЕРАКТИВНАЯ СРЕДА
Подразумеваемой средой при пересылке данных об изображении
GIF в интерактивных приложения является полностью 8-битный поток
данных от "хозяина" к получателю. Об установке 8-битного способа
пересылки данных при связи обычно должна заботиться головная
прикладная программа. Однако программа-получатель, поддерживающая
декодер GIF в линии связи, должна быть способна принимать и
передавать декодеру GIF все 256 возможных кодов 8-битных данных.
ПРИЛОЖЕНИЕ C
СЖАТИЕ И УПАКОВКА ИЗОБРАЖЕНИЯ
Поток растровых данных, которые описывают действительное
выходное изображение может быть представлен в следующем виде:
7 6 5 4 3 2 1 0
ЪДДДДДДДДДДДДДДДї
і код размера і
ГДДДДДДДДДДДДДДДґ ДДДї
і байт-счетчик і і
і блока і і
ГДДДДДДДДДДДДДДДґ і
і і ГДД Повторяется столько раз, сколько
і байт данных і і необходимо
і і і
ГДДДДДДДДДДДДДДДґ ДДДЩ
. . . . . .
ГДДДДДДДДДДДДДДДґ
і0 0 0 0 0 0 0 0і нулевой байт-счетчик
АДДДДДДДДДДДДДДДЩ (заканчивает поток данных)
Преобразование изображения из серии значений пикселов к
передаваемому или запоминаемому потоку символов включает несколько
шагов. Вкратце эти шаги состоят в следующем:
1. Установка кода размера - Определяет число битов, необходимое
для представления действительных данных.
2. Сжатие данных - Сжатие серии пикселов изображения в серию
кодов сжатия.
3. Построение серии байтов - берет серию кодов сжатия и
преобразует их в строку 8-битных данных.
4. Упаковка байтов - Упаковка набора байтов в блоки, которым
предшествует символ-счетчик и вывод.
УСТАНОВКА КОДА РАЗМЕРА
Первый байт в потоке растровых данных GIF имеет значение,
указывающее минимальное число битов, необходимое для представления
для представления действительных значений пикселов. Как правило
оно будет таким же, что и число битов цвета. Однако из-за
некоторых ограничений алгоритма черно-белые изображения, которые
имеют один бит цвета, должны иметь код размера, равный 2. Такое
значение кода размера подразумевает также, что коды сжатия должны
быть на один бит длиннее.
СЖАТИЕ
Алгоритм LZW преобразует серию значений данных в серию кодов,
которые могут быть самими значениями или кодами, описывающими
серию значений. Если использовать аналогию с текстовыми символами,
то выходные коды состоят из символов и кодов, которые описывают
цепочки символов.
LZW-алгоритм, использованный в GIF алгоритмически
соответствует стандартному алгоритму LZW со следующими отличиями:
1. Определен специальный код очистки, который сбрасывает все
параметры сжатия/раскрытия и таблицы в исходное состояние.
Значение этого кода равно 2**<код размера>. Например, если код
размера равен 4 (изображение имеет 4 бита на пиксел), код
очистки равен 16 (двоичное 10000). Код очистки может
появляться в любом месте потока данных и, следовательно,
требуется, чтобы LZW-алгоритм обрабатывал последующие коды
так, как будто бы начался новый поток данных. Кодировщик
должен выводить код очистки в качестве первого кода в каждом
потоке данных изображения.
2. Определен код конца информации, который явно указывает на
конец потока данных изображения. Если встретится такой код,
LZW-обработка прекращается. Этот код должен быть последним
кодом, формируемым кодировщиком для изображения. Значение
этого кода равно <Код_очистки>+1.
3. Значение первого доступного кода сжатия равно <Код_очистки>+2.
4. Выходные коды имеют переменную длину, начиная от
<код_размера>+1 битов на код, до 12 битов на код. Тем самым
максимальное значение кода определяется равным 4095
(шестнадцатиричное FFF). Как только значение LZW-кода может
превысить текущую длину кода, длина кода увеличивается на
единицу. Паковщик и распаковщик этих кодов должны изменяться,
чтобы соответствовать новой длине кода.
ПОСТРОЕНИЕ 8-БИТНЫХ БАЙТОВ
Поскольку LZW-сжатие, используемое для GIF, создает серию
кодов переменной длины от 3 до 12 символов каждый, эти коды должны
быть переформированы в серию 8-битный байтов так, чтобы на самом
деле происходило запоминание или передача символов. Это
обеспечивает дополнительное сжатие изображения. Коды формируются в
поток битов так, как если бы они паковались справа налево, и затем
выбираются по 8 битов для вывода. Рассматриваемый массив 8-битных
символов при упаковке кодов длиной по 5 битов должен быть похож на
следующий пример:
байт n байт 5 байт 4 байт 3 байт 2 байт 1
ЪД.....ДДДДД+ДДДДДДДД+ДДДДДДДД+ДДДДДДДД+ДДДДДДДД+ДДДДДДДДї
і and so on іhhhhhgggіggfffffeіeeeeddddіdcccccbbіbbbaaaaaі
АД.....ДДДДД+ДДДДДДДД+ДДДДДДДД+ДДДДДДДД+ДДДДДДДД+ДДДДДДДДЩ
Заметьте, что механизм физической упаковки будет изменяться
по мере того, как изменяется число битов в коде сжатия, но
концептуально он остается тем же самым.
УПАКОВКА БАЙТОВ
Как только байты созданы, они группируются в блоки для
вывода, причем каждому блоку предшествует байт-счетчик со
значением от 0 до 255. Блок с нулевым байтом-счетчиком заканчивает
поток данных для данного изображения. Эти блоки являются тем, что
выводится на самом деле в формате GIF. Такой формат блока
обеспечивает дополнительную эффективность за счет того, что
позволяет декодировщику считывать данные по мере необходимости,
читая сначала байт-счетчик, а затем пропуская сами данные об
изображении.
ПРИЛОЖЕНИЕ D
ОБРАБОТКА НЕСКОЛЬКИХ ИЗОБРАЖЕНИЙ
Поскольку поток данных GIF может содержать несколько
изображений, необходимо описать обработку и высвечивание таких
файлов. Поскольку дескриптор изображения допускает размещение
изображения в пределах логического экрана, можно определить
последовательность изображений, каждое из которых занимает часть
экрана, но их совокупность заполняет экран целиком. В подобных
ситуациях линии поведения при обработке изображений состоит в
следующем:
1. Не делать пауз между изображениями. Каждое обрабатывается
сразу же, как только будет распознано декодировщиком.
2. Каждое изображение переписывает любое другое изображение уже
находящееся внутри его окна. Экран очищается только в начале и
в конце обработки GIF-изображений. См. обсуждение терминатора
GIF.
ЫЫЫЫЫ ЫЫЫЫЫ ЫЫЫЫЫ ЫЫЫЫЫ
Ы Ы Ы Ы
Ы Ы ЫЫЫ ЫЫЫ
Ы Ы Ы Ы
Ы ЫЫЫЫЫ Ы Ы
REVISION 5.0
Перевод с английского
- 2 -
Оглавление
ДДДДДДДДДД
От переводчика............................................. 4
Введение................................................... 8
Замечания по редакции ..................................... 9
Аннотация .................................................10
1. Структура ..............................................11
Заголовок файла (Image File Header - IFD) ..........11
Директории файла (Image File Directory) ............12
2. Определения ............................................14
3. Поля ...................................................15
Базовые поля .......................................15
Информационные поля ................................27
Факсимильные поля ..................................29
Поля запоминания и восстановления документов .......31
Поля, не рекомендуемые для дальнейшего
использования ......................................32
4. Частные поля ...........................................37
5. Обзор форматов файлов для изображений ..................38
6. Дополнительная информация ..............................39
Приложение A: Разумность теговой структуры ...............40
Приложение B: Сжатие данных по схеме 2 ...................42
Приложение C: Схема сжатия данных 32773 (PackBits) .......48
Приложение D: .............................................50
Приложение E: Упорядоченный список тегов TIFF ............51
Приложение F: Схема сжатия данных 5 (LZW-сжатие) .........57
Аннотация ..........................................57
Литература .........................................57
Требования .........................................57
Алгоритм ...........................................58
Декодирование LZW ..................................62
Что делать, если SamplesPerPixel больше 1 ..........63
Реализация .........................................64
Быстродействие .....................................64
Будущие расширения LZW .............................66
Благодарности ......................................66
Приложение G: Классы TIFF .................................67
Разумность .........................................67
Обзор ..............................................67
Ядро требований ....................................68
Класс TIFF B - двухуровневые изображения ...........71
Класс TIFF G - серые изображения ...................73
Класс TIFF P - цветные палитровые изображения ......73
Класс TIFF R - полностью цветные RGB-изображения ...74
Подтверждения и интерфейс для пользователя .........74
Приложение H: Цветометрическая информация изображений .....75
I. Введение .....................................75
II. Стандарты цветометрии ........................75
III. Мотивация ....................................76
IV. Цветометрическое воспроизведение .............77
V. Белая точка ..................................77
VI. Главные цвета ................................77
VII. ColorResponseCurves ..........................78
- 3 -
VIII. Новые теги и изменения .......................80
IX. Умолчания ....................................81
X. Ограничения и следствия ......................81
XI. Литература ...................................82
Приложение I: Схема предварительного горизонтального
дифференцирования ...........................84
Алгоритм ...........................................84
Результаты и следствия .............................86
Приложение J: Цветные палитровые изображения ..............87
Предложение.........................................87
Возражения..........................................87
Преимущества........................................88
Новые теги..........................................88
- 4 -
От переводчика
ДДДДДДДДДДДДДД
Перед вами перевод спецификации 5.0 стандарта TIFF (Tag Image File
Format). Этот документ содержит всю необходимую информацию для
написания собственных программ поддержки в файлов в этом формате.
Думаю, он будет полезен всем, кто интересуется машинной графикой и
в частности таким ее аспектом, как работа с растровыми
изображениями.
TIFF является сравнительно "старым" форматом и де-факто давно уже
стал стандартом для представления изображений, получаемых со
сканеров. Однако он не получил достаточно широкого
распространения, как стандарт обмена графической информацией на
IBM PC. На мог взгляд, это объясняется двумя причинами. Во-первых,
в нем долгое время отсутствовала эффективная схема для сжатия
изображений, которые не являются черно-белыми. Во-вторых, не было
поддержки цветных изображений на основе палитры (по сути дела
таковыми являются все изображения, которые можно высвечивать на
современных графических адаптерах и мониторах IBM PC).
Введение в спецификации 5.0 схемы сжатия LZW и тегов для описания
палитровых изображений во многом устраняет эти причины. По всей
видимости можно ожидать, что область его использования будет
постепенно расширяться.
Когда я переводил этот документ, у меня уже было общее
представление об организации данного формата и не возникало
сложностей с пониманием изложенного в нем материала. Однако, когда
я стал его перечитывать с целью устранения опечаток, у меня
сложилось впечатление, что он написан несколько тяжеловесно для
человека, который знакомится с эти форматом впервые. Поэтому я
рискну кратко изложить основные концепции организации TIFF-файла.
Мне кажется, это должно помочь тем, кто совсем не знаком с эти
форматом.
1. В одном TIFF-файле может находиться несколько изображений.
2. Каждое изображение описывается с помощью набора полей или
тегов, которые определяют это изображение. В рамках исходного
документа, как и в переводе, термины тег (tag) и поле (field)
абсолютно идентичны (хотя я отдаю себе отчет, что в общем
случае это не так).
3. Каждый тег имеет строго определенное назначение и описывает
конкретные характеристики изображения (размеры, характеристики
цветов и т.д.). Иногда наполнение тега можно рассматривать как
отдельное число, но в общем случае - это массив чисел
одинакового типа.
- 5 -
4. Каждому тегу соответствует определенный номер, который
позволяет определить при чтении файла какую информацию
описывает данный тег. При описании тегов в спецификации
приводятся десятичные значения этого номера, а в скобках -
шестнадцатиричные.
5. В спецификации для каждого тега введены названия, которые
состоят из одного или нескольких английских слов, например,
ImageWidth, ColorMap и т.д. Эти названия чисто условны и
никогда не появляются в самом TIFF-файле. При переводе
документа все они сохранены в своем первоначальном виде
(переводить их на русский - это то же самое, что переводить
for, while, return и т.д. в программах на C или Паскале).
Текст типа "если ImageWidth=320" расшифровывается как "если
значение тега, имеющего название ImageWidth, равно 320"
(естественно, используется только для тегов, значения которых
состоят из одного числа).
6. Все теги, относящиеся к одному изображению объединяются в
рамках одного элемента внутри файла, который называется
директорией (Image File Directory - IFD). Соблюдается принцип
"одно изображение - одна директория".
7. Единственный элемент, место которого определено в файле жестко
- это заголовок из 8 байтов, с которого начинается TIFF-файл.
Все остальные элементы (директории, теги и значения тегов)
могут располагаться практически в любом месте файла.
Взаимосвязь между ними осуществляется с помощью аппарата
указателей.
Для начала этого должно быть достаточно. Всю остальное вы узнаете,
прочитав основной документ.
Несколько слов следует сказать о терминологии. Очень часто при
переводе на русский язык англоязычных текстов по вычислительной
технике приходится сталкиваться с тем, что многие термины не имеют
достаточно лаконичных эквивалентов. В результате наш богатый и
могучий обогащается еще больше словами типа свопинг, дамп,
скроллинг и т.д. Настоящий документ не является в этом смысле
исключением. Во избежание недоразумений ниже приводится перечень
терминов, перевод которых в документе может вызвать нарекания.
Bilevel image. По непонятным мне причинам авторы документа
старательно избегают термина black and white image (черно-белое
изображение) и обозначают такие изображения как bilevel image
(двухуровневое изображение). Хотя второй вариант лаконичнее, он не
совсем точен. На самом деле, все изображения, которые названы в
документе bilevel, являются именно черно-белыми, а не
произвольными двухуровневыми изображениями. Каюсь, в данном случае
я пошел на поводу у авторов документа и переводил этот термин
дословно, т.е. как двухуровневые изображения.
- 6 -
Grayscale image. Английское слово grayscale образовано из двух
корневых слов gray (серый) и scale (масштаб). Имеются в виду
изображения, которые передаются тонами серого цвета разной
интенсивности (классический пример - черно-белые фотографии). При
переводе использовались термины "изображение в серых тонах" или
просто "серое изображение".
Palette color image. При переводе использовался термин "цветное
палитровое изображение". Имеются в виду изображения, которые
обладают тем свойством, что число цветов в них строго ограничено
таблицей фиксированного размера (палитрой). Каждый элемент этой
таблицы задает каким либо образом цвет пиксела (как правило, в
цветовой системе RGB), который может появляться на экране.
Значения пикселов являются одно компонентными и используются как
индексы для входа в палитру. Все изображения, которые могут
высвечиваться на стандартных мониторах IBM PC обладают указанным
свойством.
Full color RGB image. Этот термин переводился как "полностью
цветное RGB-изображение" или "RGB-изображение". Здесь имеются в
виду изображения каждый пиксел которых может задаваться с помощью
трех независимых компонент (samples) интенсивностей основных
цветов в системе RGB. Перевод термина sample как "компонента"
лексически не очень точен, но на мой взгляд наиболее точно
отражает существо дела в данном конкретном случае.
Bit depth. Использовался дословный перевод "битовая глубина".
Здесь имеется ввиду число бит отводимое для определения
интенсивностей серого тона или компонент интенсивности в системе
RGB. Говорят, что компонента или само изображение тем "глубже",
чем больше это число. Иногда используются обороты типа "8-битное
серое изображение" (смысл в свете сказанного очевиден).
Differing, differ matrix. В обработке изображений существует ряд
методов, которые предназначены для передачи изображений с
использованием меньшего количества цветов или оттенков, чем
имеется в исходном изображении (например, когда требуется
напечатать образ черно-белой фотографии на матричном принтере).
Общее название этих методов в англоязычной литературе - differing.
Многие из этих методов основаны на использовании специальных
матриц, имеющих фиксированные размеры (differ matrix). Более
подробную информацию об этих методах можно, например, почерпнуть
из книги Д.Роджерса "Алгоритмические основы машинной графики" (M.,
Мир, 1989 г., стр. 131-138). Я долго пытался найти для этих
терминов приемлемые русские эквиваленты, но в конце концов
остановился на банальном "дифферинг" и "матрица дифферинга" (Да
простят меня наши лингвисты...).
Могу честно признаться, что наибольшие трудности возникли у меня
при переводе Приложения H, посвященного проблемам цветопередачи.
Во-первых, это достаточно специфическая область. Во-вторых, сам
стиль изложения в оригинале, на мой взгляд оставляет желать
лучшего (хотя это мое личное мнение). Второе обстоятельство я как
мог пытался сгладить при переводе, но не думаю, что это мне
- 7 -
удалось. Относительно первого должен заметить, что материал этого
Приложения может оказаться совершенно несъедобным, если не иметь
хотя бы общего представления о стандартах определения цвета. Могу
порекомендовать уже упоминавшуюся книгу Д.Роджерса (стр. 458-487).
Отдельного обсуждения заслуживает Приложение F (алгоритм
LZW-сжатия). В принципе, изложенного в нем материала
достаточно для написания собственных программ, реализующих данный
алгоритм. Однако, на мой взгляд авторы документа опустили ряд
подробностей, которые не очевидны на первый взгляд, но крайне
важны именно с точки зрения программной реализации. Если вы
собираетесь писать такие программы, то я настоятельно рекомендую
вам сначала "прокрутить" вручную случай сжатия и распаковки
потока, состояжего из N одинаковых байтов. Уверяю, что несмотря
на тривиальность этого случая, при распаковке "вылезет" весьма
нетривиальная подробность, о которой авторы документа просто
умалчивают.
В заключение должен сказать, что материал данного документа,
несмотря на явную его полезность, местами оставляет достаточное
странное впечатление. Я не обнаружил в нем явных смысловых ошибок,
но мне кажется, что иногда он носит откровенно рекламный характер,
что наносит ущерб точности изложения, а некоторые размышления его
авторов по меньшей мере спорны. Но я счел за благо воздержаться от
комментариев по ходу документа: он и так достаточно велик, а
опытные программисты и без меня поймут что к чему. Кроме того, не
дай Бог Microsoft обидится...
А.Самотохин
Институт прикладной математики AH CCCР
Москва, 1991 г.
- 8 -
Введение
ДДДДДДДД
Этот меморандум был подготовлен фирмами Aldus и Microsoft
совместно с главными распространителями сканеров и другими
заинтересованными сторонами. Этот документ не является частью
обязательства Microsoft или Aldus обеспечивать поддержку этого
формата во всех приложениях. Если вам понадобится ответ на
специальные вопросы, затронутые в этом документе, или потребуются
дополнительные теги или модификации отдельных полей, обращайтесь
по любому из адресов:
Developers Desk Windows Marketing Group
Aldus Corporation Microsoft Corporation
411 First Ave. South 16011 NE 36th Way
Suite 200 Box 97017
Seattle, WA 98104 Redmond, WA 98073-9717
(206) 622-5500 (206) 882-8080
- 9 -
Замечания по редакции
ДДДДДДДДДДДДДДДДДДДДД
Эта редакция заменяет редакцию TIFF Revision 4. Разделы, набранные
курсивом являются новыми или значительно измененными по сравнению
с указанной версией. Новыми также являются приложения F, G и H,
хотя они и не набраны курсивом.
Главными улучшениями в TIFF 5.0 являются:
1. Сжатие серых и цветных изображений для лучшего использования
дискового пространства. См. Приложение F.
2. Классы TIFF ограничивают набор объектов TIFF, что упрощает
работу с инструментами TIFF. Возможно вы захотите просмотреть
Приложение G перед чтением оставшейся части документа. Фактически
вы можете использовать Приложение G как основной путеводитель,
возвращаясь к основному телу документа по мере необходимости для
получения подробных справок о структурах TIFF и описаний полей.
3. Поддержка цветных палитровых изображений. См. TIFF>