Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Последние темы форума

Показать новые сообщения »

Почтовая рассылка

Подписчиков: 11642
Последний выпуск: 19.06.2015

GIF

ПРИЛОЖЕНИЕ 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}... 
'#'          - 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

ВВОД ГРАФИЧЕСКОГО РЕЖИМА 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 - СЖАТИЕ И УПАКОВКА ИЗОБРАЖЕНИЯ

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

struct {
       char size;       // код размера
       ...              // Повторяется столько раз, сколько необходимо
       char counter;    // байт-счетчик блока
       char data[N];    // байт данных
       ...
       char end;        // '0' - заканчивает поток данных
}

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

  1. Установка кода размера - Определяет число битов, необходимое для представления действительных данных.
  2. Сжатие данных - Сжатие серии пикселов изображения в серию кодов сжатия.
  3. Построение серии байтов - берет серию кодов сжатия и преобразует их в строку 8-битных данных.
  4. Упаковка байтов - Упаковка набора байтов в блоки, которым предшествует символ-счетчик и вывод.

УСТАНОВКА КОДА РАЗМЕРА

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

СЖАТИЕ

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

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

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

Предыдущая | Оглавление

Оставить комментарий

Комментарий:
можно использовать BB-коды
Максимальная длина комментария - 4000 символов.
 
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог