GIF - GIF


Из Википедии, свободной энциклопедии

GIF
Вращение Земли (большой) .gif
Имя файла расширения .gif
Интернет-тип носителя image/gif
Тип кода гифф
Равномерное идентификатор типа (ИМП) com.compuserve.gif
Магическое число GIF87a/GIF89a
Разработан CompuServe
Первый выпуск 1987 ; 32 лет назад ( Тысяча девятьсот восемьдесят семь )
Последний релиз
89а
(1989 ; 30 лет назад ) ( 1989 )
Тип формата без потерь растрового формата изображения
Веб-сайт WWW .w3 .org / Графика / GIF / спец-gif89a .txt

Формат Graphics Interchange ( GIF , / ɪ е / JIF или / ɡ ɪ е / ФВМС ), представляет собой растровый формат изображения , который был разработан группой в онлайн - услуг провайдера CompuServe во главе американского компьютера ученый Стив Уилайт 15 июня, 1987. с тех пор она вступит в широкое использование на World Wide Web в связи с ее широкой поддержки и портативности.

Формат поддерживает до 8 бит на пиксель для каждого изображения, что позволяет одно изображение , чтобы ссылаться на свою собственную палитру до 256 различных цветов , выбранных из 24-битного RGB цветового пространства. Он также поддерживает анимацию и позволяет отдельную палитру до 256 цветов для каждого кадра. Эти ограничения палитры делают GIF менее пригодны для воспроизведения цветных фотографий и других изображений с цветовыми градиентами, но хорошо подходит для более простых изображений , таких как графики и логотипы с твердой областью цвета.

GIF изображения сжимаются с использованием Лемпеля-Зив-Велч (LZW) сжатие данных без потерь техники , чтобы уменьшить размер файла без ухудшения качества изображения. Этот метод сжатия был запатентован в 1985 году полемики по поводу лицензионного соглашения между патентным программным обеспечением держателем, Unisys и CompuServe в 1994 году стимулировало развитие Portable Network Graphics (PNG) стандарта. К 2004 году все соответствующие патенты истекли.

история

CompuServe ввел GIF 15 июня 1987 года , чтобы обеспечить формат изображение цвета для их загрузки файла областей, заменив их ранее длины кодирования (RLE) формат, который был черно-белым только. GIF стал популярным , поскольку он используется сжатие данных LZW , который был более эффективен , чем кодирования длин серий , что форматы , такие как те , которые используются PCX и MacPaint , и , следовательно , могут быть загружены в достаточно короткое время довольно большие изображения, даже при очень медленных модемов ,

Оригинальная версия GIF называлась 87а . В 1989 году CompuServe выпустила улучшенную версию, называемую 89а , которая добавлена поддержка задержки анимации (несколько изображений в потоке уже были поддержаны в 87а), прозрачные цвета фона, и хранения метаданных конкретного приложения. Спецификация 89а также поддерживает включение текстовых меток в виде текста (не встраивая их в графических данных), но есть немного контроля над шрифтами дисплея, эта функция не используется широко. Обе версии можно отличить, посмотрев на первые шесть байт из файла ( « магическое число » или подписи), который, когда интерпретируется как ASCII , читать «GIF87a» и «GIF89a», соответственно.

CompuServe поощрять принятие GIF, предоставляя загружаемые утилиты преобразования для многих компьютеров. К декабрю 1987 года, например, Apple , IIGS пользователь может просматривать фотографии , созданные на Atari ST или Commodore 64 . GIF был один из первых двух форматов изображений , обычно используемых на веб - сайтах, другой черно-белый XBM .

В сентябре 1995 года Netscape Navigator 2.0 добавлена возможность для анимированных GIF - файлов в цикле .

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

В мае 2015 года Facebook добавлена поддержка GIF.

Лингвистические характеристики

Как существительное , слово GIF встречается в новых изданиях многих словарей. В 2012 году американское крыло Oxford University Press признал GIF в качестве глагола , а также, что означает «создать GIF - файл», как в «GIFing была идеальной средой для распространения сцены из летних Олимпийских играх ». Лексикографы пресса - голосовали это их слово года , заявив , что GI превратились в «инструмент с серьезными приложениями , включая исследование и журналистики».

Произношение GIF

Юмористическое изображение объявляет о запуске Белого дома Tumblr предлагает произнесение GIF с жестким звуком «G».

Создатели формата произносили слово , как «мкф» с мягким «G» / ɪ е / , как и в «джин». Стив Уилайт говорит , что предполагаемое произношение намеренно повторяет американскую арахисовое масло марки мкф , и сотрудники CompuServe часто говорят , что «Разборчивые разработчики выбирают GIF», подмены телерекламы этого бренда. Слово в настоящее время также широко произносятся с жестким «G» / ɡ ɪ е / , как в «дар». В 2017 году, неформальный опрос на сайте программирования Stack Overflow показал некоторое численное предпочтение аппаратно произношение «G», особенно среди респондентов в Восточной Европе, хотя и программно «G» и выговаривая каждую букву по отдельности были найдены , чтобы быть популярным в Азии и развивающиеся страны.

Heritage Dictionary американского цитирует и, указывая на «камеру jПри» в качестве основного произношения, а Кембриджский словарь американского английского языка предлагает только жесткосферическое «G» произношение. Merriam-Webster Энциклопедический словарь и КДИ цитируют оба произношения, но место «GIF» в положение по умолчанию ( «\ GIF, Jif \»). New Oxford American Dictionary дал только «камеры jПри» в своем 2 - м издании , но был обновлен до «мкф, GIF» в 3 - м издании.

Разногласия по поводу произношения привело горячие дебаты в Интернете. По случаю получения награды за достижения в 2013 году Webby Award церемонии, Wilhite отверг жесткосферической «G» произношение, и его выступление привело к 17000 постов на Twitter и 50 новостных статей. Белый дом и телепрограмма Jeopardy! также вступила в дискуссию в течение 2013 года .

использование

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

Формат файла

Концептуально GIF файл описывает фиксированный размером графической области ( «логический экран») заполняется нуль или более «изображения». Многие GIF файлы имеют одно изображение, которое заполняет весь логический экран. Другие делят логический экран на отдельные суб-изображения. Изображения могут также функционировать в качестве кадров анимации в анимированный файл GIF, но опять-таки это не нужно заполнить весь логический экран.

GIF файлы начинаются с фиксированной длины заголовка ( «GIF87a» или «GIF89a») дает версию, а затем с помощью фиксированной длины логического дескрипторе экрана дает размеры пикселей и другие характеристики логического экрана. Дескриптор экрана может также указать наличие и размер глобальной таблицы цвета, который следует дальше, если присутствуют.

После этого файл разделен на сегменты, каждый введенного 1-байтовый часовой:

  • Изображения (введенный 0x2c, с ASCII запятой «» )
  • Блок расширения (введен 0x21, в ASCII восклицательным «!» )
  • Прицеп (один байт значение 0x3B, ASCII , точка с запятой «;» ), который должен быть последним байтом файла.

Изображения начинаются с фиксированной длиной дескриптором изображения, которые могут указывать на наличие и размер Color Table (Local, которое следует дальше, если он присутствует). Данные изображения следующим образом: один байт дает ширину бита некодированных символов (который должен быть по крайней мере 2 бита, даже для двухцветных изображений), а затем связанный список суб-блоков, содержащих данные LZW-кодированию.

Удлинительные блоки (блоки, которые «расширяют» определение 87a посредством механизма, уже определенного в спецификации 87a) состоят из Sentinel, дополнительный байта с указанием типа расширения, и связанным списка субблоков с данными расширения. Блоки расширения, которые изменяют изображение (например, расширение управления Graphic, который определяет дополнительное время задержки анимации и дополнительный прозрачный цвет фона) должны непосредственно предшествовать сегмент с изображением они относятся.

Связанные списки, используемые данные изображений и удлинительные блоки состоят из серии субблоков, каждый субблок, начиная с байтом, давая количество последующих байт данных в субблока (от 1 до 255). Серии субблоков завершаются пустым субблоком (а 0 байт).

Эта структура позволяет файл, который будет обработана, даже если не все части понимается. GIF отмечены 87a может содержать блоки расширения; намерение состоит в том, что декодер может считывать и отображать файл без особенностей, охватываемых расширений, не понимают.

Полная деталь формата файла описывается в спецификации GIF.

Палитры

Пример GIF изображения сохраняются с веб-безопасной палитры и редактируется с использованием Floyd-Steinberg метод. В связи с уменьшением количества цветов в изображении, есть проблемы с отображением.

GIF является палитрой на основе: цвет , используемый в изображении (кадр) в файле имеет свой RGB значение , определенное в таблице палитры , которая может содержать до 256 записей, а также данные для изображения относится к цветам их индексы ( 0-255) в таблице палитры. Определения цвета в палитре можно извлечь из цветового пространства миллионов оттенков (2 24 оттенков, 8 бит для каждого первичного), но максимальное число цветов кадра можно использовать 256. Это ограничение представляется разумным , когда GIF был разработан потому что немногие люди могут позволить себе оборудование для отображения большего количества цветов одновременно. Простая графика, штриховые рисунки, мультфильмы, и полутоновые фотографии обычно требуется меньше , чем 256 цветов.

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

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

В первые дни графических веб - браузеров, графические карты с 8-битовых буферов ( с учетом только 256 цветов) были широко распространены , и это было довольно распространенным , чтобы сделать GIF изображения с помощью палитры websafe . Это обеспечило прогнозируемый дисплей, но серьезно ограничивает выбор цветов. Когда 24-битный цвет стал норма палитры вместо могли быть заселены с оптимальными цветами для отдельных изображений.

Небольшая таблица цветов может быть достаточна для небольших изображений, и держать таблицу цветов маленькой позволяет файл для загрузки быстрее. Оба 87a и 89a характеристики позволяют цветовые таблицы 2 п цветов для любого п от 1 до 8. Большинство графических приложений будет считывать и отображать GIF изображения с любой из этих размеров таблиц; но некоторые не поддерживают все размеры при создании изображений. Таблицы 2, 16 и 256 цветов широко поддерживается.

Истинный цвет

Анимированный GIF, иллюстрирующий методику для отображения более чем типичный предел 256 цветов

Хотя GIF почти никогда не используется для полноцветных изображений, то можно сделать так. GIF изображение может включать в себя несколько блоков изображения, каждый из которых может иметь свой собственный 256-цветовую палитру, и блоки могут быть выложены плиткой , чтобы создать полный образ. В качестве альтернативы, спецификация GIF89a ввела идею «прозрачного» цвета , где каждый блок изображения может включать в себя свою собственную палитре 255 видимых цветов плюс один прозрачного цвета. Полное изображение может быть создано путем наслаивания блоков изображения с видимой частью каждого слоя , показывая через прозрачные части указанных выше слои.

Оказывать полноцветное изображение в формате GIF, исходное изображение должно быть разбиты на более мелкие участки, не имеющие не более 255 или 256 различных цветов. Каждый из этих регионов затем сохраняется в виде отдельного блока изображения с его собственной локальной палитры и, когда блоки изображения отображаются вместе (либо черепицей или отводками частично прозрачные блоки изображения) появляется полная, полноцветное изображение. Например, нарушая изображение в плитки 16 на 16 пикселей (256 пикселей в общей сложности) гарантирует, что ни одна плитка не имеет больше, чем локальный предел палитры 256 цветов, хотя более крупные плитки могут быть использованы и другие подобные цвета слиты в результате к некоторой потере цвета Информация.

Поскольку каждый блок изображения требует своей локальную таблицы цветов, является файл формат, имеющий множество блоков изображения может быть очень большим, что ограничивает полезность полноцветных GIFs. Кроме того, не все GIF рендеринга программы обрабатывать кафельные или многослойные изображения правильно. Многие программы рендеринга интерпретировать плитки или слои, как кадры анимации и отображать их в последовательности в виде бесконечной анимации с большинством веб-браузеров автоматически отображать кадры с временем задержки 0,1 секунды или более.

Пример GIF-файл

Пример изображения (увеличенный), фактический размер 3 пикселя в ширину и 5 высоким
Байты D ч до 30оС ч в примере определения палитры 256 цветов.

Microsoft Paint сохраняет небольшой черно-белое изображение , как следующий файл GIF. Краска не оптимально использовать GIF; из - за излишне большой таблицу цветов (хранение целых 256 цветов вместо использованных 2) и ширины символа, этот GIF - файл не является эффективным представление 15-пиксельного изображения (показано в увеличенном масштабе выше).

Хотя блок управления Графика Расширение объявляет цветовой индекс 16 (шестнадцатеричное 10), чтобы быть прозрачным, что индекс не используется в изображении. Единственные цветовые индексы, появляющиеся в данных изображения десятичные 40 и 255, которые Глобальный Color Table сопоставляется черный и белый соответственно.

Обратите внимание , что шестнадцатеричные числа в следующих таблицах в прямой порядок байтов порядка байтов, как спецификация формата предписывает.

byte#  hexadecimal  text or
(hex)               value       Meaning
0:     47 49 46
       38 39 61     GIF89a      Header
                                Logical Screen Descriptor
6:     03 00        3            - logical screen width in pixels
8:     05 00        5            - logical screen height in pixels
A:     F7                        - GCT follows for 256 colors with resolution 3 x 8 bits/primary; the lowest 3 bits represent the bit depth minus 1, the highest true bit means that the GCT is present
B:     00           0            - background color #0
C:     00                        - default pixel aspect ratio
                   R    G    B  Global Color Table
D:     00 00 00    0    0    0   - color #0 black
10:    80 00 00  128    0    0   - color #1
 :                                       :
85:    00 00 00    0    0    0   - color #40 black
 :                                       :
30A:   FF FF FF  255  255  255   - color #255 white
30D:   21 F9                    Graphic Control Extension (comment fields precede this in most files)
30F:   04           4            - 4 bytes of GCE data follow
310:   01                        - there is a transparent background color (bit field; the lowest bit signifies transparency)
311:   00 00                     - delay for animation in hundredths of a second: not used
313:   10          16            - color #16 is transparent
314:   00                        - end of GCE block
315:   2C                       Image Descriptor
316:   00 00 00 00 (0,0)         - NW corner position of image in logical screen
31A:   03 00 05 00 (3,5)         - image width and height in pixels
31E:   00                        - no local color table
31F:   08           8           Start of image - LZW minimum code size
320:   0B          11            - 11 bytes of LZW encoded image data follow
321:   00 51 FC 1B 28 70 A0 C1 83 01 01
32C:   00                        - end of image data
32D:   3B                       GIF file terminator

кодирование изображения

Пиксель изображения данные, сканируется в горизонтальном направлении от верхнего левого, преобразуется кодированием LZW кодов , которые затем преобразуются в байты для хранения в файле. Коды пикселов , как правило , не совпадают с 8-битный размер байтов, так что эти коды упакованы в байты с помощью «маленькой-Endian» схеме: наименее значимого бита первого кода хранится в наименее значащий бит первый байт, старшие биты порядка кода в старшие биты порядка байта, выплескивания в биты низкого порядка следующего байта по мере необходимости. Каждый последующий код сохраняется , начиная с наименьшего значащего бита уже не используется.

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

Для получения изображения образца выше обратимого отображения между 9-битовых кодов и байтов, показан ниже.

9-битовый код
(HEX)
двоичный Б
(шестнадцатеричный)
| 00000000 00
100
0101000 | 1 51
028
111111 | 00 FC
0FF
00011 | 011
103
0010 | 1000 28
102
011 | 10000 70
103
10 | 100000 A0
106
1 | 1000001 С1
107
10000011 | 83
| 00000001 01
101
0000000 | 1 01

Небольшое сжатие очевидно: цвета пикселей, определенные первоначально 15 байт точно представлены 12 кодовых байт, включая управляющие коды. Процесс кодирования, который производит 9-битовые коды приведен ниже. Локальная строка накапливает номер цвета пикселя из палитры, без вывода действия до тех пор, как локальная строка может быть найдена в таблице кодов. Существует специальная обработка первых два пикселей, которые прибывают перед таблицей растет от его первоначального размера путем добавления строк. После каждого выходного кода, локальная строка инициализация до последнего цвета пикселя (которые не могут быть включены в выходном коде).

                          Table           9-bit
                     string --> code      code    Action
                          #0 | 000h               Initialize root table of 9-bit codes
                    palette  |  :
                     colors  |  :
                        #255 | 0FFh
                         clr | 100h
                         end | 101h
                             |            100h     Clear
Pixel          Local         |
color Palette  string        |
BLACK  #40     28            |            028h     1st pixel always to output
WHITE  #255    FF            |                     String found in table
                  28 FF      | 102h                Always add 1st string to table
               FF            |                     Initialize local string
WHITE  #255    FF FF         |                     String not found in table
                             |            0FFh     - output code for previous string
                  FF FF      | 103h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
BLACK  #40     FF FF 28      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF 28   | 104h                - add latest string to table
               28            |                     - initialize local string
WHITE  #255    28 FF         |                     String found in table
WHITE  #255    28 FF FF      |                     String not found in table
                             |            102h     - output code for previous string
                  28 FF FF   | 105h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF FF   | 106h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String not found in table
                             |            106h     - output code for previous string
                  FF FF FF FF| 107h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String found in table
                                                   No more pixels
                                          107h     - output code for last string
                                          101h     End

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

Алгоритм LZW требует поиска таблицы для каждого пикселя. Линейный поиск через до 4096 адресов сделает кодирование медленно. На практике эти коды могут быть сохранены в порядке числового значения; это позволяет каждому поиск сделать с помощью SAR ( с регистром последовательного приближения, используемые в некоторых АЦП ), только с 12 магнитуд сравнений. Для этой эффективности дополнительная таблица необходима для преобразования между кодами и фактическими адресами памяти; дополнительный стол и содержание в порядке требуется только тогда , когда новый код будет сохранен , который происходит при значительно меньше скорости пикселей.

декодирования изображения

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

Is incoming code found in table?
 YES: add string for local code followed by first byte of string for incoming code
 NO: add string for local code followed by copy of its own first byte
      shift
9-bit ----> Local      Table                 Pixel
code        code   code --> string   Palette color  Action
100h               000h  | #0                       Initialize root table of 9-bit codes
                    :    | palette
                    :    | colors
                   0FFh  | #255
                   100h  | clr
                   101h  | end
028h                     |             #40    BLACK Decode 1st pixel
0FFh        028h         |                           Incoming code found in table
                         |             #255   WHITE  - output string from table
                   102h  | 28 FF                     - add to table
103h        0FFh         |                           Incoming code not found in table
                   103h  | FF FF                     - add to table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
102h        103h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #40    BLACK
                         |             #255   WHITE
                   104h  | FF FF 28                  - add to table
103h        102h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
                   105h  | 28 FF FF                  - add to table
106h        103h         |                           Incoming code not found in table
                   106h  | FF FF FF                  - add to table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
                         |             #255   WHITE
107h        106h         |                           Incoming code not found in table
                   107h  | FF FF FF FF               - add to table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
                         |             #255   WHITE
                         |             #255   WHITE
101h                     |                           End

Длина кода LZW

Более короткие длины кода могут быть использованы для палитр меньших, чем 256 цветов в примере. Если палитра только 64 цветов (так цветовые индексы 6 бит в ширине), символы могут варьироваться от 0 до 63, а ширина символа может быть принята 6 бит, с кодами, начиная с 7 бит. В самом деле, ширина символа не обязательно соответствует размеру палитры: до тех пор, как значения декодированных всегда меньше, чем количество цветов в палитре, символы могут быть любой шириной от 2 до 8, и размера палитры любой степени 2 от 2 до 256. Например, если только первые четыре цвета (значения от 0 до 3) из палитры используются, символы могут быть приняты, чтобы быть 2 бита с кодами, начиная с 3 битами.

С другой стороны, ширина символа может быть установлена ​​на уровне 8, даже если только значения 0 и 1 используются; эти данные будут требовать только таблицы 2-цветной. Несмотря на то, что не было бы никакого смысла при кодировании файла, который так, что-то подобное, как правило, происходит из-за двухцветных изображений: минимальная ширина символ 2, даже если только значения 0 и 1 используются.

Кодовая таблица изначально содержит коды, которые на один бит длиннее , чем размер символа для того , чтобы учесть два специальных коды CLR и конец и коды для строк, которые добавляются в ходе процесса. Когда таблица заполнена увеличивается длина коды , чтобы освободить место для более строк, вплоть до максимального кода 4095 = FFF (шест). По мере того как декодер строит свою таблицу он отслеживает эти увеличения длины коды и она способна распаковать входящие байты соответственно.

несжатый GIF

A 46 х 46 несжатый GIF с 7-битовых символов (128 цветов, 8-битные коды). Нажмите на изображение для объяснения кода.

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

Модифицированный метод кодирования игнорирует построения таблицы LZW и излучает только корневую коду палитры и коды для ясного и STOP. Это дает более простое кодирование (соответствие 1-к-1 между кодовыми значениями и палитрой кодами), но жертвами все сжатия: каждый пиксел в изображении генерирует выходной код, указывающий его индекс цвета. При обработке несжатых GIF, стандартный GIF декодер не будет предотвращено писать строки в его словарную таблицу, но ширина кода никогда не должна увеличиваться, так что вызывает различную упаковку бит в байты.

Если ширина символов равно п, коды ширины п + 1 падения , естественно , в два блока: нижний блок из 2 - н - кодов для кодирования отдельных символов, а также верхний блок из 2 - н - кодов , которые будут использоваться декодером для последовательностей длина больше , чем один. Из этого верхнего блока, первые два кода уже приняты: 2 п для ясного и 2 п + 1 для STOP. Декодер также должен быть предотвращен с использованием последнего кода в верхнем блоке, 2 N + 1 - 1, потому что , когда декодер заполняет этот слот, он будет увеличивать ширину коды. Таким образом , в верхнем блоке есть 2 п - 3 коды , доступные для декодера , который не будет вызывать увеличение ширины кода. Поскольку декодер всегда один шаг позади в поддержании таблицы, это не создает запись в таблице после получения первого кода из кодера, но будет генерировать один для каждого последующего кода. Таким образом , кодер может генерировать 2 п - 2 кодов , не вызывая увеличение ширины коды. Поэтому кодер должен излучать дополнительные Очистить коды с интервалом в 2 н - 2 или меньше кодов , чтобы декодер сброса словаря кодирования. Стандарт GIF позволяет таким дополнительные Очистить коды , которые будут вставлены в данных изображения в любое время. Поток композитного данных разбивается на подблоки , что каждый несут от 1 до 255 байт.

Для образца 3x5 изображений выше, следующие 9-битные коды представляют собой «чистый» (100), а затем пиксели изображения в порядке сканирования и «стоп» (101).

9-bit codes: 100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

После того, как вышеуказанные коды отображаются в байты, несжатый файл отличается от сжатого файла, таким образом:

 :
320: 14            20            20 bytes uncompressed image data follow
321: 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335: 00                          - end
 :

пример сжатия

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

Код Пиксели Заметки
Количество
Н я
Значение
N я + 256
Длина
(биты)
Этот код
N я
Накопленная
Н яя + 1) / 2
Отношения с использованием N я применять только кампанией с такими же
цветами пикселей до кодирования таблицы не заполнится.
0 100h 9 Очистить таблицу кодов
1 FFh 1 1 Верхний левый пиксель цвет выбран в качестве самого
высокого показателя 256-цветовой палитры
2 102h 2 3
3

255
103H

1FFh
3

255
6

32640


Последний 9-битный код
256

767
200h

3FFh
10 256

767
32896

294528


Последний 10-битный код
768

1791
400h

7FFh
11 768

1791
295296

1604736


Последний 11-битный код
1792

3839
800h

FFFH
12 1792

3839
1606528

7370880


Кодовая таблица полная
FFFH 3839 Максимальный код может повторяться для более одного цвета пикселей.
В целом сжатие данных асимптотически приближается к
3839 × 8/12 = 2559 1/3
101h Конец данных изображения

Эти кодовые значения, показанные упакованы в байты, которые затем упакованы в блоки до 255 байт. Блок данных изображения начинается с байта, который объявляет число байтов, чтобы следовать. Последний блок данных для изображения отмечен нулевой блок-байт длины.

Переплетение

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

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

  • Шаг 1: линия 0 (самый верхний линия) от каждой полосы.
  • Pass 2: Линия 4 от каждой полосы.
  • Pass 3: Линии 2 и 6 из каждой полосы.
  • Проход 4: Линии 1, 3, 5 и 7 из каждой полосы.

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

Анимированные GIF

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

Основная анимация была добавлена в GIF89a спецификации с помощью расширения Graphics Control (GCE), что позволяет различные изображения (кадры) в файле должны быть окрашены с временными задержками, образуя видеоклип . Анимированный файл GIF содержит некоторое количество кадров, которые отображаются последовательно, каждый представил свой собственный GCE, что дает задержку по времени ожидания после того , как кадр рисуются. Глобальная информация в начале файла применяется по умолчанию для всех кадров. Данные потоки-ориентированные, поэтому файл-смещение начала каждого GCE зависит от длины предшествующих данных. В пределах каждого кадра данные изображени LZW закодированный расположено в подблоках до 255 байт; размер каждого субблока объявлен байт , который предшествует ему.

По умолчанию, однако, анимация показывает последовательность кадров только один раз, останавливаясь , когда отображается последний кадр. Поскольку GIF разработан , чтобы позволить пользователям определять новые блоки, Netscape в 1990 - х годах используется блок расширения приложений (предназначенный , чтобы позволить поставщикам , чтобы добавить информацию конкретного приложения в файл GIF) для реализации блока Netscape Application (NAB). Этот блок, расположенный непосредственно перед всеми кадрами анимации, определяет, сколько раз должна быть воспроизведена последовательность кадров. (Значение 0 означает непрерывное отображение.) Поддержка этих повторяющихся анимация первой появилась в Netscape Navigator версии 2.0, а затем распространилась на другие браузеры. Большинство браузеров теперь признают и поддерживают NAB, хотя это не является строго частью спецификации GIF89a.

Следующий пример показывает структуру файла анимации вращающейся Земли (большой) .gif показано (как эскиз) в верхней части статьи.

byte#  hexadecimal  text or
(hex)               value     Meaning
0:     47 49 46
       38 39 61     GIF89a    Header
                              Logical Screen Descriptor
6:     90 01        400        - width in pixels
8:     90 01        400        - height in pixels
A:     F7                      - GCT follows for 256 colors with resolution 3 x 8bits/primary
B:     00           0          - background color #0
C:     00                      - default pixel aspect ratio
D:                            Global Color Table
:
30D:   21 FF                  Application Extension block
30F:   0B           11         - eleven bytes of data follow
310:   4E 45 54
       53 43 41
       50 45        NETSCAPE   - 8-character application name
       32 2E 30     2.0        - application "authentication code"
31B:   03           3          - three more bytes of data
31C:   01           1          - data sub-block index (always 1)
31D:   FF FF        65535      - unsigned number of repetitions
31F:   00                      - end of App Extension block
320:   21 F9                  Graphic Control Extension for frame #1
322:   04           4          - four bytes of data follow
323:   08                      - bit-fields 3x:3:1:1, 000|010|0|0 -> Restore to bg color
324:   09 00                   - 0.09 sec delay before painting next frame
326:   00                      - no transparent color
327:   00                      - end of GCE block
328:   2C                     Image Descriptor
329:   00 00 00 00  (0,0)      - NW corner of frame at 0, 0
32D:   90 01 90 01  (400,400)  - Frame width and height: 400 x 400
331:   00                      - no local color table; no interlace
332:   08           8         LZW min code size
333:   FF           255       - 255 bytes of LZW encoded image data follow
334:                data
433:   FF           255       - 255 bytes of LZW encoded image data follow
                    data
                     :
92BA:  00                    - end of LZW data for this frame
92BB:  21 F9                 Graphic Control Extension for frame #2
 :                                                            :
153B7B:21 F9                 Graphic Control Extension for frame #44
 :
15CF35:3B                    File terminator

Задержка анимации для каждого кадра задаются в БКА в сотых долей секунды. Некоторые экономики данных можно где кадр нужно только переписать часть пикселей дисплея, так как дескриптор изображения может определить меньший прямоугольник будет перепроверен вместо всего изображения. Браузеры или другие дисплеи, которые не поддерживают анимированные GIF-файлы, как правило, показывают только первый кадр.

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

Internet Explorer замедляет GIFs , если частота кадров составляет 20 кадров в секунду или выше и Microsoft сообщает , что Google Chrome и Safari также замедлить некоторые GIF анимацию.

С начала 1995 года Университет Ульма используется анимированный GIF в формате потокового видео в реальном времени показывать управляемую модель железной дороги.

Метаданные

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

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

Extensible Metadata Platform (XMP) стандарт метаданных введен негласный , но теперь широко распространенное расширение приложений блок «Data XMP» для включения данных XMP в GIF - файлов .. Так как данные XMP кодируется с использованием UTF-8 без символов NUL, нет 0 байт в данных. Вместо того , чтобы разбить данные в формальные подблоки, блок расширения завершается с прицепом «волшебным» , который направляет любое приложение обработки данных в виде субблоков до конечных 0 байт , что завершает субблоку цепь.

Unisys и LZW патентных прав

В 1977 и 1978 годах, Иаков Зив и Авраам Лемпель опубликовал пару статей о новом классе алгоритмов сжатия данных без потерь, в настоящее время совместно именуемые LZ77 и LZ78 . В 1983 году Терри Уэлч разработал быстрый вариант LZ78 , который был назван Лемпела-Зива-Уэлча (LZW).

Welch подал заявку на патент для метода LZW в июне 1983 года в результате патента, США 4558302  , выданный в декабре 1985 года был назначен Sperry Corporation , который впоследствии слился с Burroughs Corporation в 1986 году и формируется Unisys . Другие патенты были получены в Великобритании, Франции, Германии, Италии, Японии и Канаде.

В июне 1984 года, статья Уэлч была опубликована в IEEE журнала , который публично описал метод LZW впервые. LZW стал популярным методом сжатия данных и, когда патент был выдан, Unisys заключила лицензионные соглашения с более чем ста компаний.

Популярность LZW привело CompuServe , чтобы выбрать его в качестве метода сжатия для их версии GIF, разработанной в 1987 году В то время, CompuServe не было известно о патенте. Unisys стало известно , что версия GIF используется метод сжатия LZW и вступили в переговоры о лицензировании с CompuServe в январе 1993 года последующее соглашение было объявлено 24 декабря 1994 года Unisys заявили , что они ожидали , что все крупные коммерческие онлайновые информационные услуги компании , использующей патент LZW лицензировать технологию от Unisys по разумной ставке, но они не требуют лицензирования, или сборы , которые будут оплачены, в некоммерческих, некоммерческих GIF-приложений, в том числе для использования на он-лайн услуг ,

После этого заявления, было широко распространено осуждение CompuServe и Unisys, и многие разработчики программного обеспечения пригрозили прекратить использование GIF. Формат PNG (см ниже) был разработан в 1995 году в качестве предполагаемой замены. Однако получение поддержки от создателей веб - браузеров и других программ для формата PNG оказалось трудным и не было возможности заменить GIF, PNG , хотя постепенно увеличивается в популярности. Таким образом, были разработаны варианты GIF без сжатия LZW. Например , библиотека libungif, основанный на Eric S. Raymond giflib «с, позволяет создавать GIFs , которые следовали за формат данных , но избежать возможности сжатия, что позволяет избежать использования патента Unisys LZW. В 2001 году д - ра Dobb в статье описана другая альтернатива для сжатия LZW, на основе квадратных корней.

В августе 1999 года Unisys изменил детали их лицензирования практики, объявляя возможность для владельцев определенных некоммерческих и частных веб - сайтов для получения лицензии на оплату лицензионного сбора на одноразовое $ 5000 или $ 7500. Такие лицензии не требуются для владельцев веб - сайтов или других пользователей GIF , которые использовали лицензионное программное обеспечение для создания GIF - файлов. Тем не менее, Unisys был подвергнут тысячи интернет - атак и оскорбительных писем от пользователей , полагая , что они собираются платить $ 5000 или подали в суд за использование GIFs на своих сайтах. Несмотря на предоставление бесплатных лицензий на сотни некоммерческих организаций, школ и правительств, Unisys была совершенно не в состоянии генерировать любую хорошую рекламу и продолжает быть осуждены лицами и организациями , такие как Лига для программирования свободы , которые начали «Сжечь все GIFs» кампанию в 1999.

Патент США LZW истек 20 июня 2003 года Патенты аналогов в Великобритании, Франции, Германии и Италии истек 18 июня 2004 года, японские патенты истек 20 июня 2004 года, а также канадский патент истек 7 июля 2004 г. Следовательно, , в то время как Unisys имеет дополнительные патенты и заявки на патенты, относящиеся к совершенствованию техники LZW, GIF теперь может свободно использоваться.

альтернативы

PNG

Portable Network Graphics (PNG) был разработан в качестве замены GIF, чтобы избежать нарушения патента Unisys' на технологии сжатия LZW. PNG обеспечивает лучшее сжатие и больше возможностей , чем GIF, анимацию будучи единственным существенным исключением. PNG является более подходящим , чем GIF в тех случаях , когда в истинном цвете изображения и альфа - прозрачность требуются.

Хотя поддержка формата PNG пришли медленно, новые веб - браузеры обычно поддерживают PNG. Более старые версии Internet Explorer не поддерживает все функции , PNG. Версии 6 и более ранние версии не поддерживают альфа - канал прозрачности без использования Microsoft-специфических расширений HTML. Гамма - коррекция PNG изображений не поддерживается до версии 8, и отображение этих изображений в более ранних версиях может иметь неправильный оттенок.

Для идентичных 8-бит (или ниже) данных изображения, PNG файлы, как правило, меньше, чем эквивалентные GIFs, за счет более эффективных методов сжатия, используемых при кодировании PNG. Полная поддержка GIF усложняется главным образом сложной структуры холста он позволяет, хотя это то, что позволяет компактные функции анимации.

форматы анимации

MNG первоначально был разработан в качестве PNG на основе решения для анимации. MNG достигла версии 1.0 в 2001 году, но лишь немногие приложения поддерживают его.

В 2006 году , расширение в формате PNG под названием APNG был предложен в качестве альтернативы формату MNG по Mozilla . APNG дают возможность анимировать PNG файлов, сохраняя при этом обратную совместимость в декодеров , которые не могут понять анимации кусок ( в отличие от MNG). Более старые декодеры будут просто визуализировать первый кадр анимации. Группа PNG официально отвергнута APNG в качестве официального расширения на 20 апреля 2007 г. Там было несколько последующих предложений по простому анимированным графическому формату на основе PNG , используя несколько различных подходов. Тем не менее, анимированные Portable Network Graphics еще в стадии разработки Mozilla и поддерживается в Firefox 3 в то время как поддержка MNG была сброшена .. APNG в настоящее время поддерживается большинством основных веб - браузеров , включая Chrome , начиная с версии 59.0 и Opera и Firefox.

Встроенный Adobe Flash объектов и MPEGs используется на некоторых веб - сайтах , чтобы отобразить простое видео, но требует использования дополнительного модуля браузера. WebM и WebP находятся в стадии разработки и поддерживаются некоторыми браузерами. Другие варианты для веб - анимации включают в себя обслуживание отдельных кадров с помощью AJAX , или оживляющий SVG изображений с помощью JavaScript или SMIL .

С появлением широко распространенной поддержкой HTML5 <video> тега в большинстве веб - браузеров, некоторые веб - сайты используют петельчатую версию видеотега генерируемой JavaScript функций. Это дает появление GIF, но с размером и скоростью преимущества сжатого видео. Характерные примеры являются Gfycat и Imgur и их GIFV metaformat, который действительно тег видео воспроизведения зацикленной MP4 или WebM сжатого видео.

Смотрите также

Рекомендации

внешняя ссылка