©1987,1988,1989,1990
Copyright
CompuServe Incorporated
Columbus, Ohio
Перевод на русский язык выполнен
Радиком Усмановым
<radik@nsp.chg.ru>
по заказу Web-издательства ИнфоАрт
Приложения
|
Дополнения |
Представленная здесь информация может быть изменена без какого-либо уведомления. Ни при каких обстоятельствах фирма CompuServe Incorporated не будет нести ответственности за ущерб, такой как, какая-либо потеря дохода, потеря прибыли, либо любой другой непредвиденный или опосредованный ущерб, если он возник вследствие использования, либо наоборот невозможности использовать данную информацию. Фирма CompuServe Incorporated не ставит перед собой цель обеспечить полную корректность данного материала.
Данный документ определяет формат передачи графических изображений (Graphics Interchange Format). В нем дается спецификация версии 89a, являющейся расширением версии 87a.
Представленный в данном документе формат передачи графических данных должен рассматриваться как единое целое. Любое отклонение от него следует считать неправомерным, причем это подразумевает (и не только) использование зарезервированных или изначально не заявленных полей в блоках управления и данных, запись в блоках и между ними посторонних данных, применение методов и алгоритмов, не оговоренных в данном формате, и т.д. И вообще, любые отклонения, расширения, либо модификации, не оговоренные в данном документе, следует рассматривать как недопустимое нарушение формата.
Формат обмена графической информацией - Graphics Interchange Format(c) - является собственностью фирмы CompuServe Incorporated. Только CompuServe Incorporated имеет право формулировать данный формат, переопределять и дополнять его, изменять или заменять отдельные части в описании формата - и делать это она может любым образом.
Настоящим фирма CompuServe Incorporated обязуется предоставлять ограниченную, неэксклюзивную, бесплатную лицензию на использование Формата передачи графических данных (sm) в программном обеспечении. Для программ, использующих формат GIF (sm), в пользовательской и технической документации должно быть оговорено право собственности на Формат, а также должна присутствовать торговая марка фирмы CompuServe Incorporated. В программном обеспечении, которое использует формат GIF, но распространяется, либо может распространяться без сопроводительной пользовательской или технической документации, сообщение о праве собственности на Формат, а также торговая марка фирмы CompuServe Incorporated должны появляться в специальном сообщении на экране или принтере. В последнем случае, обязательные ссылки могут появляться в первой заставке при открытии экрана, либо в последней заставке при закрытии экрана. При этом достаточно воспользоваться сообщением следующего типа:
"The Graphics Interchange Format(c) is the Copyright property of CompuServe Incorporated. GIF(sm) is a Service Mark property of CompuServe Incorporated."
За получением дополнительной информации обращайтесь по адресу:
CompuServe Incorporated Graphics Technology Department 5000 Arlington Center Boulevard Columbus, Ohio 43220 U. S. A.
Фирма CompuServe Incorporated поддерживает специальный список почтовой рассылки для всех частных лиц и организаций, которые желают получать копии данного документа, когда в него будут вноситься исправления, либо осуществляться его полный пересмотр. Данная услуга предоставляется бесплатно - сообщите нам, пожалуйста, ваши почтовый адрес.
В данном документе дается подробное описание Формата передачи графических данных. Его целью является предоставление программистам необходимой справочной информации. Перед тем, как приступить к написанию программы, желательно тщательно прочесть весь документ, поскольку различные его части тесно увязаны друг с другом. Описанию каждого из блоков Формата отводится отдельная глава. В каждой главе имеется подраздел "Требуемая Версия", где записан номер версии, которым должен воспользоваться кодировщик, если возникает необходимость занести этот блок в общий поток данных. Кроме того, в каждом разделе представлена схема, показывающая расположение отдельных полей описываемого блока. (При этом поля байтов изображаются в виде колонки, где байты, находящиеся в верхней части схемы, первыми заносятся в общий поток данных). Если внутри какого-либо байта дается описание отдельных битовых полей, то старшие биты ставятся в схеме слева, а младшие - справа. В многобайтовых числовых полях первыми пишутся младшие байты, затем старшие. Числа в данной спецификации записываются в шестнадцатеричной нотации, начинающейся символами "0x". Описание битовых полей начинается с самого старшего бита и заканчается самым младшим.
В описываемом Формате передачи графических данных GIF(sm) сформулирован протокол, предназначенный для обмена и передачи в диалоговом режиме растровых графических изображений. Протокол независим от особенностей аппаратных средств, применяемых как для создания изображений, так и для их воспроизведения.
Формат передачи графических данных формулируется в терминах блоков и субблоков, в которые заносятся параметры и данные, необходимые для воспроизведения графических изображений. Поток данных в стандарте GIF представляет собой последовательность блоков и субблоков, несущих информацию о графических образах. Обычно предполагается, что в потоке данные графических изображений до некоторой степени взаимосвязаны друг с другом и имеют одни и те же контрольные параметры. Программа-кодировщик должна пытаться сгруппировать графические образы таким образом, чтобы в аппаратных средствах, осуществляющих конечную обработку изображений, уменьшить количество перенастроек в момент перехода от одного изображения к другому и чтобы вообще уменьшить объем передаваемой контрольной информации. По той же причине несвязанные друг с другом графические образы, либо графические изображения, для воспроизведения которых требуется перенастройка аппаратных средств, должны по возможности кодироваться раздельно.
Поток графических данных может создаваться локально (например, при чтении данных из некого файла), либо передаваться от удаленного источника (например, по коммуникационным линиям). Данный Формат строится на предположении, что на транспортном уровне для передачи данных используется такой протокол, который самостоятельно производит коррекцию ошибок, возникающих при работе с коммуникационными линиями. Поэтому в Формате не предусмотрено никаких проверок с целью обнаружения и коррекции ошибок.
Поток графических данных GIF должен интерпретироваться в соответствии с контекстом, иными словами, прикладная программа должна оперировать с информацией, более общей, чем конкретный поток данных - для декодирования ею она должна запускать отдельный процесс.
Номер версии, указываемый в заголовке потока данных, должен нести информацию о том, какой минимальный набор ресурсов необходим декодировщику для полной обработки предлагаемого потока данных. Со своей стороны, кодировщик должен использовать самый ранний номер версии, который вместе с тем не менее включал бы все блоки, используемые в формируемом потоке данных. В каждой главе описания имеется строка "Требуемая Версия", где указан номер самой ранней версии, в которой имелся бы описываемый блок. Соответственно, проектируемый кодировщик в каждом конкретном случае должен пытаться использовать самый ранний номер версии, в который были бы описаны все блоки, задействованные в текущем потоке данных. Неоправданное использование более поздних версий Формата будет бессмысленно препятствовать воспроизведению информации на некоторых из имеющихся в хождении декодировщиках.
Кодировщик - это программа, предназначенная для создания потока данных в формате GIF. Получая данные графического растра, а также другую информацию, кодировщик создает управляющие блоки и блоки данных, необходимые для воспроизведения первоначальных изображений.
Декодировщик - это программа, предназначенная для обработки потока данных в формате GIF. Обработка потока данных выполняется последовательно блок за блоком, проводится анализ различных блоков и субблоков, выделяется контрольная информация, управляющая аппаратными средствами и характеристиками всего процесса, и наконец обрабатываются данные, создающие собственно графическое изображение.
Кодировщик или декодировщик считаются соответствующими той или иной версии Формата передачи графических данных, если они способны распознавать все его конструкции и правильно их использовать. Кодировщик или декодировщик могут соответствовать текущему номеру версии, и при этом не отвечать требованиям более поздних реализаций Формата.
В каждой главе документа содержится запись "Рекомендация", в которой приводится перечень инструкций и методик применения для тех или иных блоков Формата. Подобные рекомендации относятся к проектированию более эффективных функций кодировщика и декодировщика, к организации более оптимального использования полосы пропускания в коммуникационных линиях. Указанные рекомендации желательно соблюдать.
В формате GIF для построения растровых графических изображений используются таблицы цветов. Таблица цветов может иметь глобальную, либо локальную область применения. Глобальная таблица цветов используется в потоке данных всеми теми графическими изображениями, которые не имеют собственной локальной таблицы цветов. Таким образом, областью действия глобальной таблицы цветов является весь поток данных. Локальная же таблица цветов всегда используется идующим сразу вслед за ней графическим изображением. Этим отдельным графическим элементом и ограничивается применение данной локальной таблицы цветов. Локальная таблица цветов подменяет собой глобальную таблицу, то есть если в потоке данных присутствует глобальная таблица цветов, но при этом конкретное изображение имеет свою локальную таблицу, то декодировщик должен будет записать глобальную таблицу цветов в буфер, воспользовавшись локальной таблицей, обрабатывать данное изображение, а затем вновь возвращаться к глобальной таблице цветов. Таблицы обоих типов относятся к разряду необязательных, так что возможен случай, когда в потоке данных содержится множество графических изображений, и одновременно вообще отсутствуют какие-либо таблицы цветов. По этой причине декодировщик до тех пор обязан сохранять в рабочем состоянии последнюю из использовавшихся глобальных цветовых таблиц, пока он не встретится со следующей глобальной таблицей цветов. В результате, поток данных, в котором не содержится ни глобальной, ни локальной таблицы цветов, может быть обработан с применением последней из сохраненных глобальных таблиц. Иными словами, если используется глобальная таблица цветов от предыдущего потока данных, то для текущего потока она фактически становится заменой собственной глобальной таблице. Смысл этой операции состоит в отказе от ненужного дублирования таблиц цвета. В частности, кодировщику рекомендуется использовать только одну глобальную таблицу цветов, если к ней можно свести все графические образы в представленных потоках данных. В случае, если вообще нет никакой доступной таблицы цветов, декодировщик может воспользоваться системной таблицей, либо своей собственной. В таком случае декодировщик может задействовать в новой таблице столько цветов, сколько их позволяют применить аппаратные средства. При этом желательно, чтобы в такой таблице первыми двумя цветами были черный и белый, поскольку это даст возможность декодировщику в любом случае правильным образом воспроизвести одноцветный графический образ.
В соответствии со спецификацией Формата GIF, можно создать специальный поток данных, в который будут входить лишь заголовок, дескриптор логического экрана, глобальная таблица цветов и блок-терминатор. Подобный урезанный поток данных может специально использоваться для загрузки в декодировщик глобальной таблицы цветов, которая в дальнейшем будет использоваться при работе с потокам данных, не имеющими собственных цветовых таблиц.
Описываемые в Формате блоки условно могут быть разбиты на три группы: управляющие,
графические и специальные. Управляющие блоки, такие как заголовок, дескриптор
логического экрана, дополнительный блок управления графикой и блок-терминатор, содержат
сведения, необходимые для управления процессом обработки потока данных, либо информацию,
необходимую для настройки аппаратной части. Блоки с графической информацией, такие
как дескрипторы изображений и дополнительные блоки с простым текстом, содержат
данные и информацию, непосредственно связанные с воспроизведением на дисплее
графических образов. Специальные блоки, такие как дополнительные блоки комментариев
и приложений, также используются для управления процессом обработки данных, однако
сами не содержат информации, напрямую связанной с выводом на экран графического
изображения. За исключением дескриптора логического экрана и глобальной таблицы цветов,
имеющих отношение ко всему потоку данных в целом, все остальные управляющие блоки имеют
ограниченную область действия, а точнее, относятся только к тому блоку графической
информации, который записан следом. Блоки специального назначения не могут ограничивать
область применения управляющих блоков. Специальные блоки игнорируются в процессе
декодирования. Область действия управляющих блоков и блоков расширений ограничивается
графическим блоком или другим блоком расширений. Метки, используемые для идентификации
блоков, можно также разбить на три группы:
0x00-0x7F (0-127) - блоки с графической информацией; исключение составляет
блок-терминатор (0x3B);
0x80-0xF9 (128-249) - блоки управления;
0xFA-0xFF (250-255) - специальные блоки.
Представленные диапазоны выбраны таким образом, чтобы декодировщик мог определить
область действия того или иного блока, имея лишь его метку, т.е. даже в том случае,
если нет возможности непосредственно выполнить обработку самого блока.
В поле "Размера Блока" указывается количество байт, занимаемых данным блоком (при этом не берется в расчет размер самого этого поля, а также размер субблока-терминатора, если таковой имеется). За исключением блоков с графическими данными, все остальные должны иметь фиксированную длину. При этом назначением поля "Размера Блока" является упрощение процедуры разбиения потока данных на отдельные блоки, а не провоцирование на произвольное изменение размера указанных блоков. Блоки же графических данных и субблоки имеют переменную длину соответственно реальному объему данных.
Формат GIF может использоваться в составе более общих протоколов прикладного уровня в качестве подчиненного протокола, выполняющего обработку графических изображений. Для этой цели в протоколе прикладного уровня может выделяться специальный блок, в котором и будет размещаться поток данных в формате GIF, соответствующий изображению. Прикладная программа, встречаясь с подобным блоком, может автоматически вызывать для его обработки необходимый GIF-декодировщик. Такой подход к обработке данных желательно реализовывать посредством дополнительных блоков приложений, поскольку во всяком случае они могут быть просто проигнорированы теми приложениями, которые не в состоянии их обработать. Поскольку в предложенном варианте поток данных в формате GIF должен обрабатываться в контексте, прикладная программа должна иметь возможность распознать этот поток по неким внешним признакам.
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Размер блока Байт
+---------------+
1 | |
+- -+
2 | |
+- -+
3 | |
+- -+
| | Данные Байт
+- -+
| |
+- . . . . -+
до | |
+- -+
| |
+- -+
255 | |
+---------------+
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Размер блока Байт
+---------------+
7 6 5 4 3 2 1 0 Название поля Тип +---------------+ 0 | | Идентификатор 3 байта +- -+ 1 | | +- -+ 2 | | +---------------+ 3 | | Версия 3 байта +- -+ 4 | | +- -+ 5 | | +---------------+
Номера версий, имевшихся на 10 июля 1990 года:
"87a" - май 1987 года "89a" - июль 1989 года
По замыслу разработчиков, номера версий будут идти в возрастающем порядке и записываться в виде комбинации из двух цифр (сперва 87, а затем 88, ...,99,00, ...,85,86) и одной буквы (от 'a' до 'z' в алфавитном порядке).
Кодировщик должен использовать самую раннюю версию, которая включала бы описание всех блоков, задействованных в создаваемом потоке данных. Если выполняется процедура объединения двух или более потоков данных, то в получившемся потоке должна использоваться самая последняя из представленных исходных версий.
Декодировщик должен стараться обработать поток данных наилучшим из возможных способов. Если программа сталкивается с номером версии, который она не сможет поддерживать в полном объеме, то она тем не менее обязана попытаться интерпретировать представленный поток данных, насколько это будет возможно. В некоторых реализациях прикладная программа перед началом обработки предупреждает пользователя о том, что сведения, извлеченные ею из представленного потока, могут оказаться неполными.
Представленный блок относится к разряду ОБЯЗАТЕЛЬНЫХ. Однако, вместе с тем в каждом потоке данных должен присутствовать только один дескриптор логического экрана.
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Ширина логического Беззнаковое
+- -+ экрана целое
1 | |
+---------------+
2 | | Высота логического Беззнаковое
+- -+ экрана целое
3 | |
+---------------+
4 | | | | | <Набор битовых полей> См. ниже
+---------------+
5 | | Индекс фонового цвета Байт
+---------------+
6 | | Соотношение сторон пиксела Байт
+---------------+
| <Битовые поля> = | Флаг глобальной таблицы цветов | 1 бит |
| Цветовое разрешение | 3 бита | |
| Флаг сортировки | 1 бит | |
| Размер глобальной таблицы цветов | 3 бита |
| Значения: | 0 - | Глобальная таблица цветов отсутствует. Значение, записанное в поле с индексом фонового цвета, игнорируется. |
| 1 - | Сразу за дескриптором следует глобальная таблица цветов. Кроме того, выполняется обработка поля с индексом фонового цвета. |
| Значения: | 0 - | Таблица неотсортирована. |
| 1 - | Таблица отсортирована в порядке уменьшения важности: наиболее важный цвет стоит первым. |
параметр соотношения = (соотношение сторон пиксела + 15)/64
Здесь параметр "соотношение сторон" - это отношение ширины пиксела к его высоте. Приведенный алгоритм позволяет программе дискретно менять соотношение сторон от 4:1 (самый широкий пиксел) до 1:4 (самый высокий пиксел) с шагом 1/64.
| Значения: | 0 - | Информация о соотношении сторон отсутствует. |
| 1..255 - | Указанное здесь значение используется для определения соотношения сторон пиксела. |
Описываемый блок относится к разряду НЕОБЯЗАТЕЛЬНЫХ, однако в потоке данных может присутствовать только одна глобальная таблица цветов.
7 6 5 4 3 2 1 0 Название поля Тип
+===============+
0 | | Красный 0 Байт
+- -+
1 | | Зеленый 0 Байт
+- -+
2 | | Синий 0 Байт
+- -+
3 | | Красный 1 Байт
+- -+
| | Зеленый 1 Байт
+- -+
до | |
+- . . . . -+ ...
| |
+- -+
| | Зеленый 255 Байт
+- -+
767 | | Синий 255 Байт
+===============+
В дескриптор изображения заносятся параметры, необходимые для работы с изображением, построенным по методу таблиц. Координаты, сообщаемые в этом блоке, измеряются в пикселах и привязаны к внутренней системе координат логического экрана. Описываемый блок контролирует процесс воспроизведения графического изображения, перед ним могут стоять один или несколько управляющих блоков, таких как дополнительный блок управления изображением. Вслед за дескриптором может стоять локальная таблица цветов. В конце всего этого обязательно следует блок графических данных.
Описываемый блок ДОЛЖЕН ставиться перед каждым графическим изображением. Вместе с тем каждому изображению в потоке данных должен соответствовать только один дескриптор. В потоке данных можно размещать любое количество графических образов.
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Идентификатор Байт
+---------------+
1 | | Положение левой границы Беззнаковое
+- -+ изображения целое
2 | |
+---------------+
3 | | Положение верхней границы Беззнаковое
+- -+ изображения целое
4 | |
+---------------+
5 | | Ширина изображения Беззнаковое
+- -+ целое
6 | |
+---------------+
7 | | Высота изображения Беззнаковое
+- -+ целое
8 | |
+---------------+
9 | | | | | | <Битовые поля> См. ниже
+---------------+
| <Битовые поля> = | Флаг локальной таблицы цветов | 1 бит |
| Флаг чересстрочной развертки | 1 бит | |
| Флаг сортировки | 1 бит | |
| Зарезервировано | 2 бита | |
| Размер локальной таблицы цветов | 3 бита |
| Значения: | 0 - | Локальная таблица цветов отсутствует. По возможности следует воспользоваться глобальной таблицей цветов. |
| 1 - | Локальная таблица цветов была записана сразу вслед за этим дескриптором. |
| Значение: | 0 - | Чересстрочная развертка отсутствует. |
| 1 - | Задействован режим чересстрочной развертки. |
| Значения: | 0 - | Таблица не отсортирована. |
| 1 - | Цвета отсортированы в порядке уменьшения важности, наиболее важный цвет стоит первым. |
7 6 5 4 3 2 1 0 Название поля Тип
+===============+
0 | | Красный 0 Байт
+- -+
1 | | Зеленый 0 Байт
+- -+
2 | | Синий 0 Байт
+- -+
3 | | Красный 1 Байт
+- -+
| | Зеленый 1 Байт
+- -+
| |
+- . . . . -+ ...
до | |
+- -+
| | Зеленый 255 Байт
+- -+
767 | | Синий 255 Байт
+===============+
7 6 5 4 3 2 1 0 Название поля Тип +---------------+ | | Минимальный размер Байт +---------------+ кода в LZW+===============+ | | / / Графические данные Субблоки | | данных +===============+
Хотя данный блок относится к разряду НЕОБЯЗАТЕЛЬНЫХ, перед графическим блоком может ставиться только один дополнительный блок управления. Это условие является единственным фактором, ограничивающим количество дополнительных блоков управления, встречающихся в потоке данных.
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Идентификатор Байт
+---------------+
1 | | маркер управляющего блока Байт
+---------------+
+---------------+
0 | | Размер блока Байт
+---------------+
1 | | | | | <Битовые поля> См. ниже
+---------------+
2 | | Время задержки Беззнаковое
+- -+ целое
3 | |
+---------------+
4 | | Индекс прозрачного цвета Байт
+---------------+
+---------------+
0 | | Терминатор блока Байт
+---------------+
| <Битовые поля> = | Зарезервировано | 3 бита |
| Способ размещения | 3 бита | |
| Флаг ручного ввода | 1 бит | |
| Флаг прозрачного цвета | 1 бит |
| Значения: | 0 - | Метод размещения не указан. Декодер не должен выполнять никаких специальных действий. |
| 1 - | Метод не указан. Изображение должно оставаться на месте. | |
| 2 - | Восстановить до фонового цвета - в область, занятую изображением, должен быть возвращен фоновый цвет. | |
| 3 - | Восстановить предыдущее. Декодировщик должен восстановить картинку, которая была до вывода на экран данного изображения. | |
| 4-7 - | Не определены. |
| Значения: | 0 - | пользователь не обязан вводить данные. |
| 1 - | пользователь должен ввести данные. |
Если в параметрах задано время задержки и одновременно установлен флаг ручного ввода, то обработка будет продолжена после того, как от пользователя будут получены данные, либо когда истечет оговоренное время задержки (в зависимости от того, что произойдет раньше).
| Значения: | 0 - | Индекс прозрачности не указан. |
| 1 - | Индекс прозрачности присутствует. |
Данный блок относится к разряду НЕОБЯЗАТЕЛЬНЫХ. В потоке данных может встречаться любое количество блоков с комментариями.
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Идентификатор расширения Байт
+---------------+
1 | | Заголовок комментария Байт
+---------------+
+===============+
| |
N | | Текст комментария Субблоки
| | с данными
+===============+
+---------------+
0 | | Терминатор блока Байт
+---------------+
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Идентификатор Байт
+---------------+
1 | | Заголовок простого Байт
+---------------+ текста
+---------------+
0 | | Размер блока Байт
+---------------+
1 | | Положение левой Беззнаковое
+- -+ границы сетки целое
2 | |
+---------------+
3 | | Положение верхней Беззнаковое
+- -+ границы сетки целое
4 | |
+---------------+
5 | | Ширина сетки Беззнаковое
+- -+ целое
6 | |
+---------------+
7 | | Высота сетки Беззнаковое
+- -+ целое
8 | |
+---------------+
9 | | Ширина ячейки с символом Байт
+---------------+
10 | | Высота ячейки с символом Байт
+---------------+
11 | | Индекс цвета Байт
+---------------+ основного текста
12 | | Индекс фонового цвета Байт
+---------------+
+===============+
| |
N | | Простой текст Субблоки
| | с данными
+===============+
+---------------+
0 | | Терминатор блока Байт
+---------------+
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Идентификатор расширения Байт
+---------------+
1 | | Заголовок блока Байт
+---------------+
+---------------+
0 | | Размер блока Байт
+---------------+
1 | |
+- -+
2 | |
+- -+
3 | | Идентификатор приложения 8 байт
+- -+
4 | |
+- -+
5 | |
+- -+
6 | |
+- -+
7 | |
+- -+
8 | |
+---------------+
9 | |
+- -+
10 | | Идентификационный 3 байта
+- -+ код приложения
11 | |
+---------------+
+===============+
| |
| | Данные для приложения Субблоки
| | с данными
| |
+===============+
+---------------+
0 | | Блок-терминатор Байт
+---------------+
7 6 5 4 3 2 1 0 Название поля Тип
+---------------+
0 | | Блок завершения GIF Байт
+---------------+
| Название блока | Обязательность | Заголовок | Расш. | Версия | |
|---|---|---|---|---|---|
| Дополнительный приложения | необяз. | (*) | 0xFF (255) | да | 89a |
| Дополнительный комментария | необяз. | (*) | 0xFE (254) | да | 89a |
| Глобальная таблица цветов | необяз. | (1) | отсутствует | нет | 87a |
| Дополнительный управления изображением | необяз. | (*) | 0xF9 (249) | да | 89a |
| Заголовок | обяз. | (1) | отсутствует | нет | N/A |
| Дескриптор изображения | необяз. | (*) | 0x2C (044) | нет | 87a (89a) |
| Локальная таблица цветов | необяз. | (*) | отсутствует | нет | 87a |
| Дескриптор логического экрана | обяз. | (1) | отсутствует | нет | 87a (89a) |
| Дополнительный с простым текстом | необяз. | (*) | 0x01 (001) | да | 89a |
| Завершающий | обяз. | (1) | 0x3B (059) | нет | 87a |
| Блоки без заголовков | |||||
| Заголовок | обяз. | (1) | отсутствует | нет | N/A |
| Дескриптор логического экрана | обяз. | (1) | отсутствует | нет | 87a (89a) |
| Глобальная таблица цветов | необяз. | (1) | отсутствует | нет | 87a |
| Локальная таблица цветов | необяз. | (*) | отсутствует | нет | 87a |
| Блоки управления графикой | |||||
| Дополнительный с простым текстом | необяз. | (*) | 0x01 (001) | да | 89a |
| Дескриптор изображения | необяз. | (*) | 0x2C (044) | нет | 87a (89a) |
| Управляющие блоки | |||||
| Дополнительный управления изображением | необяз. | (*) | 0xF9 (249) | да | 89a |
| Блоки специального назначения | |||||
| Завершающий | обяз. | (1) | 0x3B (059) | нет | 87a |
| Дополнительный комментария | необяз. | (*) | 0xFE (254) | да | 89a |
| Дополнительный приложения | необяз. | (*) | 0xFF (255) | да | 89a |
Замечания: Заголовок во всех версиях стандарта стается тем же самым. (89a) Синтаксис дескриптора логического экрана и дескриптора изображения остался тем же самым при переходе с версии 87a на версию 89a; однако некоторые из полей, зарезервированных в версии 87a, в 89a были использованы.
Грамматика - это форма записи последовательных данных, когда из определенных исходных объектов формируются более крупные образования. Грамматика позволяет также указывать, какие объекты могут стоять в том или ином месте потока данных. Представленная грамматика дает описание для набора блоков, из которых формируется поток данных в формате GIF. При этом сама грамматика сформулирована в виде некого набора правил. Каждое из этих правил имеет левую часть, за которой следует знак тождества и далее - правую часть. При этом правую половину правила занимает определение для его левой части. Как правило, правая половина правила представляет собой некую комбинацию из записей и специальных символов. Ниже приведится легенда, где дается определение специальных символов, Задействованных в грамматике формата GIF.
| <> | слово в грамматике |
|---|---|
| ::= | символ определения |
| * | отсутствует, либо появляется один или несколько раз |
| + | появляется один или несколько раз |
| | | альтернативный элемент |
| [] | необязательный элемент |
<Поток данных в формате GIF> ::= Заголовок <Логический экран> <Данные>* Завершающий блок
В этом правиле определен обобщенный объект <Поток данных GIF>. Поток начинается с Заголовка. За ним следует запись "Логический Экран", описываемая отдельным правилом. За логическим экраном следует запись "Данные" (также свое правило). И наконец, за объектом "Данные" идет "Завершающий блок". Поскольку нет правила, в котором давалось бы определение объектов "Заголовок" и "Завершающий блок", то, следовательно, они должны быть описаны в самой спецификации. Поскольку рядом с записью "Данные" стоит специальный символ (*), то в данном месте может быть записано любое количество объектов типа "Данные" (либо таковые вообще могут отсутствовать в потоке). Дальнейшие подробности см. в стандартных материалах по языкам программирования.
ЗАМЕЧАНИЕ: Из представленной грамматики следует, что поток данных в формате GIF, в частности, может представлять собой комбинацию "Заголовок", "Дескриптор логического экрана", "Глобальная таблица цветов" и "Завершающий блок". Столь специфичный вариант обычно используется для загрузки в GIF-декодировщик глобальной таблицы цветов и подготовки его тем самым к получению потоков данных, вообще лишенных собственных таблиц цвета.
Порядок записи пикселов в изображении, кодируемом в черезстрочном режиме:
| Группа 1: | каждый 8-ой ряд, начиная с 0-го ряда. | (проход 1) |
| Группа 2: | каждый 8-ой ряд, начиная с 4-го ряда. | (проход 2) |
| Группа 3: | каждый 4-ый ряд, начиная со 2-го ряда. | (проход 3) |
| Группа 4: | каждый 2-ой ряд, начиная с 1-го ряда. | (проход 4) |
Следующий пример иллюстрирует порядок записи в изображении в случае режима черезстрочной развертки.
Номер ряда Развертка Номер прохода0 ----------------------------------------- 1 1 ----------------------------------------- 4 2 ----------------------------------------- 3 3 ----------------------------------------- 4 4 ----------------------------------------- 2 5 ----------------------------------------- 4 6 ----------------------------------------- 3 7 ----------------------------------------- 4 8 ----------------------------------------- 1 9 ----------------------------------------- 4 10 ----------------------------------------- 3 11 ----------------------------------------- 4 12 ----------------------------------------- 2 13 ----------------------------------------- 4 14 ----------------------------------------- 3 15 ----------------------------------------- 4 16 ----------------------------------------- 1 17 ----------------------------------------- 4 18 ----------------------------------------- 3 19 ----------------------------------------- 4
Алгоритм компрессии с кодом переменной длины LZW является разновидностью алгоритма компрессии Lempel-Ziv, в котором коды переменной длиной используются для замены сочетаний, обнаруженных в исходных данных. В данном алгоритме используется код, либо переводная таблица, составленная из комбинаций, встретившихся в исходных данных. Каждая новая комбинация заносится в эту таблицу, и затем в потоке данных, подлежащем компрессии, замещается определенным индексом.
Программа компрессии получает входные данные и строит код или таблицу перевода из новых ключевых комбинаций по мере того, как они встречаются в потоке данных. Каждая новая комбинация заносится в таблицу кодов, а ее индекс записывается в исходящий поток данных. Если программа компрессии сталкиваются с комбинацией, которая уже встречалась, то вместо нее в исходящий поток данных она ставит соответствующий индекс из таблицы, таким образом достигается общая компрессия данных. Программа декомпрессии получает на вход сжатый поток данных и воссоздает по нему код, либо таблицу перевода. В процессе обработки потока сжатых данных эти коды используются в качестве индексов таблицы, а соответствующие им комбинации заносятся в поток восстаналиваемых данных. Таким образом получается декомпрессия данных. Подробности алгоритма обработки описаны ниже. Отличительная черта нашего алгоритма - код переменной длины - напрямую связана с исходным размером кода (см. параметр "размер кода LZW"), сообающим, сколько бит изначально было использовано в процессе компрессии для записи кода. Если количество комбинаций, обнаруженных программой компрессии в исходном потоке данных, превышает количество образцов, которое можно было бы записать в таблицу при данном размере кода в соответствии с алгоритмом LZW, то количество бит, предоставляемых для записи кода LZW, автоматически увеличивается на единицу.
Поток данных, которые получены при растровом сканировании и несут информацию собственно о графическом изображении, может быть сформирован следующим образом:
7 6 5 4 3 2 1 0 +---------------+ |размер кода LZW| +---------------++---------------+ ----+ | размер блока | | +---------------+ | | | +-- повторяется столько раз | байты данных | | сколько необходимо. | | | +---------------+ ----+
. . . . . . ------- Код, которым завершаются данные при LZW компрессии, должен стоять перед терминатором +---------------+ |0 0 0 0 0 0 0 0| Терминатор +---------------+
Преобразование изображения из набора пикселов в передаваемый, либо записываемый на диск поток данных включает в себя несколько шагов. Вкратце это:
В первом же байте упакованного потока данных указывается минимальное число бит, которые необходимы для передачи всего массива пикселов, реально используемых в данном изображении. Как правило, записываемое в этом месте значение равно числу бит в цветовой палитре изображения. Однако вледствие некоторых ограничений в алгоритме компрессии-декомпрессии, черно-белые изображения, фактически имеющие один бит цвета, тем не менее должны иметь размер кода, равный 2. Подразумевается, что в этом случае дополнительный бит должны иметь также и коды компрессии.
В алгоритме LZW массив графических данных преобразуется в набор кодов, каждый из которых соответствуют либо цвету отдельного пиксела, либо определенной комбинации цветов. Если взять в качестве аналогии строку символов, то каждый код на выходе кодировщика будет соответствовать либо одиночному символу, либо строке символов.
Алгоритм LZW, используемый в формате GIF, алгоритмически аналогичен стандартному алгоритму LZW со следующими отличиями:
Поскольку в результате LZW-компрессии, согласно формату GIF, генерируется массив кодов переменной длины - от 3 до 12 бит, то возникает необходимость в преобразовании этого массива в последовательную цепочку байтов, где все 8 бит были бы значащими, и эту последовательность можно было бы реально записать на диск или передать адресату. Попутно осуществляется также дополнительная компрессии графических данных. Для выполнения этой операции коды преобразуются в поток отдельных битов (порядок паковки - справа налево), а затем такой поток делится программой на одинаковые блоки по 8 бит каждый.
Так, если дан массив символов по 8 бит каждый, а для компрессии данных используются 5-битные коды, то схематически компоновка будет выглядеть следующим образом:
Заметим однако, что реально схема упаковки будет по ходу дела меняться при изменении числа бит в коде компрессии, однако основная заявленная концепция останется прежней.+---------------+ 0 | | bbbaaaaa +---------------+ 1 | | dcccccbb +---------------+ 2 | | eeeedddd +---------------+ 3 | | ggfffffe +---------------+ 4 | | hhhhhggg +---------------+ . . . +---------------+ N | | +---------------+
Как только байты с данными получены, они группируются программой в блоки. Каждому такому блоку предшествует счетчик с указанием его размера (от 0 до 255 байт). Поток данных с записью растра очередного изображения всегда завершает блок с нулевым счетчиком. Фактически этот нулевой блок инициируют процесс вывода на экран изображения, переданного в формате GIF. Дополнительная функция такого формата записи блоков заключается в том, что программа декодирования, если ей необходимо пропустить графические данные, имеющие отношение к конкретному изображению, может просто прочесть значение счетчика и затем пропустить соответствующее количество байтов с данными.
| [1] | Ziv, J. and Lempel, A. : "A Universal Algorithm for Sequential DataCompression", IEEE Transactions on Information Theory, May 1977. |
| [2] | Welch, T. : "A Technique for High-Performance Data Compression", Computer, June 1984. |
| [3] | Nelson, M.R. : "LZW Data Compression", Dr. Dobb's Journal, October 1989. |
ЗАМЕЧАНИЕ: В настоящее время - 10 июля 1990 года - данная глава находится в стадии разработки. Изложенные здесь указания должны использоваться в качестве основополагающих принципов. Программные коды, написанные на основании этой информации, должны быть разработаны таким образом, чтобы их легко можно было бы адаптировать к любым изменениям, которые возникнут во время последующих пересмотров представленного материала.
Описанные далее команды построены таким образом, чтобы их можно было применять для управления взаимодействием между программой, отправляющей поток данных в формате GIF по коммуникационной линии, и программой, их получающей. Указанные команды не являются частью файла данных в формате GIF, поскольку не нужны приложениям, использующим загрузку данных из статических файлов.
Команда запроса ресурсов GIF исходит от отправителя графических данных и в интерактивном режиме заставляет декодировщик GIF выслать ответное сообщение, в котором он сообает свои графические параметры. Последние содержат такую информацию, как возможный размер экрана, количество бит, используемых для кодировки цвета, количество поддерживаемых цветов. Escape-последовательность команды запроса ресурсов GIF определяется следующим образом:
ESC[>0g 0x1B 0x5B 0x3E 0x30 0x67
Сообщение о ресурсах GIF передается декодировщиком в диалоговым режиме и содержит информацию о возможностях дисплея того компьютера, на котором работает декодировщик, причем во всех графических режимах, поддерживаемых программой. Заметим, что это сообщение может относиться не только к характеристикам экрана монитора, но и к графическому принтеру. В общем случае сообщение имеет следующий формат:
#version;protocol{;dev, width, height, color-bits, color-res}...
Заметим, что все параметры, указанные в сообщении о ресурсах, записываются в виде чисел в десятичной системе счисления и в кодировке ASCII, а также что все сообщения о ресурсах заканчиваются символом возврата каретки.
Представленное далее сообщение о ресурсах GIF дает описание трех стандартных конфигураций видеоадаптера Enhanced Graphics Adapter на компьютере IBM PC без принтера. Поток данных, передаваемых в формате GIF, может быть обработан с применением протокола коррекции ошибок:
#87a;1;0,320,200,4,0;0,640,200,2,2;0,640,350,4,2
В данном параграфе дается определение двух команд, запускающих в
диалоговом режиме декодировщик GIF. Единственное различие между ними
состоит в том, что осуществляется выбор различных средств отображения
информации.
Заметим, что символ 'g', которым заканчивается каждая из представленных
последовательностей, записывается в нижнем регистре.
Предполагается, что внешнее окружение позволяет во время организации
взаимодействия программ и передачи графических данных в формате GIF
организовать полноценный 8-битный поток данных от источника к
получателю. Иными словами, всегда имеется возможность передать все 256
кодов ASCII. О создании коммуникаций в режиме передачи 8-битных данных,
как правило,обычно должна заботиться прикладная программа, запущенная со
стороны отправителя. Коммуникационная программа, отвечающая за
получение данных в формате GIF, также должна иметь возможность получать
и передавать программе декодирования GIF все 256 значений, возникающие
в случае, когда для кодировки данных используются все 8 бит.
Во время реализации данного протокола у разработчиков возникла путаница
с тем, в каком месте потока данных может располагаться код очистки. В
спецификации говорится о том, что код может появиться в любом месте.
Нет указания и на то, что код очистки можно посылать только в момент
заполнения таблицы.
Решение об очистке таблицы принимает кодировщик. Если текущая
таблица заполнена, то кодировщик может просто ее использовать как
есть, не внося более туда никаких изменений, и до тех пор, пока сам же
не решит ее очистить. В последнем случае кодировщик отправляет в поток
данных код, соответствующий максимальному размеру - код очистки.
Соответственно, если таблица декодировщика заполнена, то она не должна
затем подвергаться никаким изменениям до тех пор, пока
не будет получен код очистки. Код очистки соответствует максимально
допустимому размеру кода. Обработка же всех остальных кодов
осуществляется обычным порядком.
Поскольку имеется большое количество декодировщиков, которые не
осуществляют декомпрессию описанным образом, мы просим разработчиков
программ, выполняющих кодировку в формате GIF, НЕ ПРИМЕНЯТЬ
этот механизм, по крайней мере до января 1991 года и позже, если они
видят, что реально существующий рынок программ еще не готов к этому.
Тем самым разработчикам программ декодирования формата GIF отпускается
время на реализацию описанного механизма и передачу его в руки клиентов
до того момента, как применяемые декодировщики начнут "ломаться" на
новом формате GIF. С другой стороны, это совсем не обязывает
разработчиков менять текст своих кодировщиков с тем, чтобы непременно
воспользоваться преимуществом отложенного кода очистки, однако
разработчики декодировщиков это сделать обязаны.
На сервере фирмы CompuServe в документах форума PICS будет создан
файл Courtesy Directory. В этом справочнике будут содержаться
идентификаторы дополнительных блоков приложений, которыми должны
пользоваться разработчики приложений для формата GIF. Данный документ
предназначен для того, чтобы специалисты, независимо друг от друга
разрабатывающие дополнительные блоки приложений, не воспользовались
для их обозначения своих программ одним и тем же идентификатором.
Предложенный документ не является официальным реестром и создается
исключительно на добровольных началах, а стало быть не дает полной
гарантии того, что различные группы разработчиков все же не
воспользуются одним и тем же идентификатором.
Запуск графического режима GIF
0x1B 0x5B 0x3E 0x31 0x67
0x1B 0x5B 0x3E 0x32 0x67
Внешние условия взаимодействия программ
Дополнения
*1) Отложенный код очистки в алгоритме LZW компрессии
*2) Блок расширения для приложений - идентификатор приложения