Odyssey Magazine
#00
11 декабря 1996 |
|
Система - IBM:GIF - FORMAT: описание графического формата (GIF).
Сейчас многие занимаются тем, что качают графику с IBM, те же кто этого не умеет,пытаются научиться, но как всегда информации не густо. Мы решили предложить вашему вниманию описание графического формата GIF. И в будующем этой теме мы также пос- тараемся уделять внимание. █████████████████████████████████████ 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) ВВЕДЕНИЕ '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 ├─Ширина экрана─┤Ширина растра в пикс. │ │ 2 (сначало LSB) ├───────────────┤ │ │ 3 ├─Высота экрана─┤Высота растра в пикс. │ │ 4 (сначалo LSB) ├─┬─────┬─┬─────┤ M = 1, За │ │ │ │ │ дескриптором │M│ cr │0│pixel│ 5 следует гло- ├─┴─────┴─┴─────┤ бальная таблица │ background │ 6 цветов cr+1 = ├───────────────┤ число битов │0 0 0 0 0 0 0 0│ 7 цветового раз- └───────────────┘ решения pixel+1 = число бит/пиксел в изображении фон = цветовой индекс фона экрана (цвет опре- деляется из глобальной таблицы цветов или из таблицы по умолчанию) Ширина и высота логического экрана могут быть больше размеров физического экрана. Способ высвечивания изображений больших, чем размеры физического экрана зависит от реализации и может использо- вать преимущества конкретного оборудо- вания (например, окна скроллинга в Ma- cintosh 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 Начало изображения ├─ Левый край ─┤ в пикселах относи- │ │ 3 тельно левого края ├───────────────┤ экрана(сначала LSB) │ │ 4 ├─ Верхний край─┤ Начало изображения │ │ 5в пикс.относительно ├───────────────┤ верх.края экрана │ │ 6 (сначала LSB) ├─ Ширина ─┤ Ширина изображения │ │ 7 в пикселях ├───────────────┤ (снаало LSB) │ │ 8 ├─ Высота ─┤ Высота изобр.в пикс │ │ 9 (сначала LSB) ├─┬─┬─┬─┬─┬─────┤ │M│I│0│0│0│pixel│ 10 └─┴─┴─┴─┴─┴─────┘ M=0 - Использовать глобальную таблицу цветов, игнорировать 'pixel' M=1 - Далее следует локальная таблица цветов, использовать 'pixel' I=0 - Изображение отформатировано в последовательном порядке I=1 - Изображение отформатировано в порядке переплетения pixel+1 - число бит на пиксел в данном изображении Описание положения и размеров эк- рана должно быть находиться внутри мат- рицы, определенной в дескрипторе экра- на. С другой стороны, нет необходимос- ти, чтобы изображение полностью запол- няло весь экран. ЛОКАЛЬНАЯ ТАБЛИЦА ЦВЕТОВ Локальная таблица цветов необяза- тельна и определена здесь для будущего использования. Если установлен бит 'M' байта 10 в дескрипторе изображения, то вслед за дескриптором изображения сле- дует локальная таблица цветов, которая относится только к последующему изобра- жению. После обработки изображения цве- товую таблицу следует привести к той, которая была определена после дескрип- тора экрана. Заметим, что поле 'pixel' байта 10 в дескрипторе изображения ис- пользуется только в том случае, если указана локальная таблица цветов. Она определяет не только размер пиксела (число битов в нем), но число элементов последующей цветовой таблицы. Число би- тов на пиксел также следует восстано- вить к тому значению, которое было оп- ределено в дескрипторе экрана, после того, как закончится обработка изобра- жения. РАСТРОВЫЕ ДАННЫЕ Формат самого изображения опреде- лен как серия значений номеров пиксе- лов, которые образуют изображение. Пик- селы запоминаются слева направо после- довательно по строкам изображения. По умолчанию строки записываются последо- вательно, сверху вниз. В том случае, если установлен бит 'I' в байте 10 дескриптора изображения, то порядок строк при записи изображения соот- ветствует четырех проходному процессу. При первом проходе записывается каждая 8-ая строка, начиная с верхней строки окна изображения. При втором проходе записывается каждая 8-ая строка, начи- ная с пятой строки сверху. На третьем проходе записывается каждая 4-ая стро- ка, начиная с третьей строки окна. Чет- вертый проход завершает изображение, записывая каждую вторую строку, начиная со второй строки с сверху. Ниже приве- дено графическое описание этого процес- са. Изображение Стр. Прох.1 Прох.2 Прох.3 Прох.4 ─────────────────────────────────── 0 **1a** 1 **4a** 2 **3a** 3 **4b** 4 **2a** 5 **4c** 6 **3b** 7 **4d** 8 **1b** 9 **4e** 10 **3c** 11 **4f** 12 **2b** . . . Результат ───────────────── **1a** **4a** **3a** **4b** **2a** **4c** **3b** **4d** **1b** **4e** **3c** **4f** **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 в будущем, хотя и без дополнительных функциональных возмож- ностей. Приложение А ГЛОССАРИЙ Пиксел - Наименьший элемент графи- ческого изображения. Обычно соот- ветствует отдельной точке на графичес- ком экране. Разрешение изображения обычно задается в пикселах. Например, одним из довольно стандартных экранных графических форматов является 320 пик- селов по горизонтали на 200 по вертика- ли. Каждый пиксел может быть окрашен одним из нескольких цветов в зависимос- ти от возможностей графического обору- дования. Растр - горизонтальные уровни пиксе- лов, представляющие одну строку изобра- жения. Типичный метод порождения изоб- ражения, поскольку большинство образцов видеоборудования ориентировано на наи- более эффективную работу именно таким образом. LSB - Сокращение от Least Signifi- cant 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, выполненная Compu- Serve для GIF описана в приложении w. НПРИЛОЖЕНИЕ w СЖАТИЕ И УПАКОВКА ИЗОБРАЖЕНИЯ Поток растровых данных, которые описывают действительное выходное изоб- ражение может быть представлен в следу- ющем виде: 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, создает серию кодов переменной длиныию 8-битный байтов так, чтобы на самом деле происходило запоминание или передача символов. Это обеспечивает до- полнительное сжатие изображения. Коды формируются в поток битов качестве ов сжатия. 3. Построив изображения в вен 16 (дво- ичное в так, как если бы они паковались справа налево, и затем выбираются по 8 битов для вывода. Рассматриваемый мас- сив 8-битных символов при упаковке ко- дов длиной по 5 битов должен быть похож на следующий пример: байт n байт 5 байт 4 ┌─.....─────+────────+────────+.. │ and so on │hhhhhggg│ggfffffe│.. └─.....─────+────────+────────+.. байт 3 байт 2 байт 1 .. +────────+────────+────────┐ .. │eeeedddd│dcccccbb│bbbaaaaa│ .. +────────+────────+────────┘ Заметьте, что механизм физической упаковки будет изменяться по мере того, как изменяется число битов в коде сжа- тия, но концептуально он остается тем же самым. УПАКОВКА БАЙТОВ Как только байты созданы, они группируются в блоки для вывода, причем каждому блоку предшествует байт-счетчик со значением от 0 до 255. Блок с нуле- вым байтом-счетчиком заканчивает поток данных для данного изображения. Эти блоки являются тем, что выводится на самом деле в формате GIF. Такой формат блока обеспечивает дополнительную эф- фективность за счет того, что позволяет декодировщику считывать данные по мере необходимости, читая сначала байт-счет- чик, а затем пропуская сами данные об изображении.
Другие статьи номера:
Похожие статьи:
В этот день... 2 декабря