Формат обмена графикой ( GIF ; / ɡ ɪ f / GHIF или / dʒ ɪ f / JIF , ) — это формат растрового изображения , разработанный командой поставщика онлайн-услуг CompuServe под руководством американского ученого-компьютерщика Стива Уилхайта и выпущен 15 июня 1987 г. [1]
Формат может содержать до 8 бит на пиксель , что позволяет одному изображению ссылаться на собственную палитру , состоящую из до 256 различных цветов, выбранных из 24-битного цветового пространства RGB . Он также может представлять несколько изображений в файле, который можно использовать для анимации , и позволяет использовать отдельную палитру, содержащую до 256 цветов для каждого кадра. Эти ограничения палитры делают GIF менее подходящим для воспроизведения цветных фотографий и других изображений с цветовыми градиентами, но хорошо подходящим для более простых изображений, таких как графика или логотипы со сплошными цветными областями.
Изображения GIF сжимаются с использованием метода сжатия данных без потерь Лемпеля-Зива-Велча (LZW) , чтобы уменьшить размер файла без ухудшения визуального качества.
Несмотря на то, что этот формат когда-то широко использовался во Всемирной паутине из-за его широкой реализации и переносимости между приложениями и операционными системами, его использование сократилось по причинам, связанным с пространством и качеством, и его часто заменяют видеоформатами, такими как формат файла MP4 . Эти замены, в свою очередь, часто называют «GIF», несмотря на то, что они не имеют никакого отношения к исходному формату файла. [3]
CompuServe представила GIF 15 июня 1987 года, чтобы предоставить формат цветного изображения для своих областей загрузки файлов. Это заменило их более ранний формат кодирования серий , который был только черно-белым. GIF стал популярным, потому что в нем использовалось сжатие данных Лемпеля-Зива-Уэлча . Поскольку это было более эффективно, чем кодирование по длине, используемое PCX и MacPaint , довольно большие изображения можно было загружать достаточно быстро даже с помощью медленных модемов .
Оригинальная версия GIF называлась 87a. [1] Эта версия уже поддерживала несколько изображений в потоке.
В 1989 году CompuServe выпустила расширенную версию под названием 89a. [2] В эту версию добавлено:
Эти две версии можно отличить, посмотрев на первые шесть байтов файла (« магическое число » или подпись), которые при интерпретации как ASCII читаются как «GIF87a» или «GIF89a» соответственно.
CompuServe способствовала внедрению GIF, предоставляя загружаемые утилиты преобразования для многих компьютеров. К декабрю 1987 года, например, пользователь Apple IIGS мог просматривать изображения, созданные на Atari ST или Commodore 64 . [4] GIF был одним из первых двух форматов изображений, широко используемых на веб-сайтах, второй — черно-белый XBM . [5]
В сентябре 1995 года в Netscape Navigator 2.0 была добавлена возможность зацикливания анимированных GIF-файлов.
Хотя GIF был разработан CompuServe , в нем использовался алгоритм сжатия данных без потерь Лемпеля-Зива-Уэлча (LZW), запатентованный Unisys в 1985 году. Споры по поводу лицензионного соглашения между Unisys и CompuServe в 1994 году стимулировали развитие портативной сетевой графики (PNG). стандарт. В 2004 году истек срок действия всех патентов, касающихся патентованного сжатия GIF.
Функция хранения нескольких изображений в одном файле, сопровождаемых управляющими данными, широко используется в Интернете для создания простых анимаций .
Дополнительная функция чересстрочной развертки , которая сохраняет строки развертки изображения в произвольном порядке таким образом, что даже частично загруженное изображение было в некоторой степени узнаваемым, также способствовала популярности GIF, [6] поскольку пользователь мог прервать загрузку, если это было не то, что требовалось.
В мае 2015 года Facebook добавил поддержку GIF. [7] [8] В январе 2018 года Instagram также добавил стикеры GIF в режим истории. [9]
Как существительное слово GIF встречается в новых редакциях многих словарей. В 2012 году американское крыло Oxford University Press признало GIF глаголом , означающим «создать файл GIF», например: «GIF был идеальным средством для обмена сценами с летних Олимпийских игр ». Лексикографы прессы назвали его словом года , заявив, что GIF-файлы превратились в «инструмент с серьезными приложениями, включая исследования и журналистику». [10] [11]
Произношение первой буквы GIF является спорным с 1990-х годов. Наиболее распространенное произношение на английском языке: / dʒ ɪ f / ⓘ (смягкимg,как вджине) и / ɡ ɪ f / ⓘ (ствердымг,каквдаре), отличающиеся фонемой,представленнойбуквойГ. Создатели формата произносили аббревиатуруGIFкак / dʒ ɪ f / смягкойg, причем Уилхайт заявлял, что он хотел, чтобы произношение намеренно перекликалось с американскимбрендомарахисового маслаJif, а сотрудники CompuServe часто шутили: «Разборчивые разработчики выбирают GIF», пародия на телевизионную рекламу Джифа. [12]Однако это слово широко произносится как / ɡ ɪ f / ствердымg,[13]и опросы в целом показали, что это жесткоеgболее распространено. [14][15]
Dictionary.com [16] приводит оба варианта произношения, указывая / dʒ ɪ f / в качестве основного произношения, тогда как Кембриджский словарь американского английского [17] предлагает только жесткое произношение . В Университетском словаре Мерриам-Вебстера [18] и Оксфордском словаре приводятся оба варианта произношения, но сначаластавится твердый g : / ɡ ɪ f , dʒ ɪ f / . [19] [20] [21] [22] Новый Оксфордский американский словарь дал только / dʒ ɪ f / во втором издании [23] , но обновил его до / dʒ ɪ f , ɡ ɪ f / в третьем издании. [24]
Разногласия по поводу произношения привели к жарким спорам в Интернете. По случаю получения награды за заслуги перед жизнью на церемонии вручения наград Webby Awards 2013 Уилхайт публично отверг жесткое произношение ; [13] [25] [26] его речь привела к более чем 17 000 сообщений в Твиттере и десяткам новостных статей. [27] Белый дом [13] и телепрограмма Jeopardy! также вступила в дебаты в 2013 году. [26] В феврале 2020 года компания JM Smucker , владельцы бренда Jif, в партнерстве с базой данных анимированных изображений и поисковой системой Giphy выпустила ограниченную серию «Jif vs. GIF» ( с хэштегом) . как #JIFvsGIF) банка с арахисовым маслом, на которой была этикетка с юмором, в которой говорилось, что мягкое произношение g относится исключительно к арахисовому маслу, а GIF должно произноситься исключительно с жестким произношением . [28]
GIF-файлы подходят для создания резких линий с ограниченным количеством цветов, например логотипов. При этом используется сжатие без потерь формата, которое отдает предпочтение плоским областям однородного цвета с четко выраженными краями. [29] Их также можно использовать для хранения данных низкоцветных спрайтов для игр. [30] GIF-файлы можно использовать для небольших анимаций и видеоклипов с низким разрешением или в качестве реакций в онлайн-сообщениях, используемых для передачи эмоций и чувств вместо использования слов. Они популярны в социальных сетях, таких как Tumblr , [31] Facebook и Twitter . [32]
Концептуально файл GIF описывает графическую область фиксированного размера («логический экран»), заполненную нулем или более «изображениями». Многие файлы GIF содержат одно изображение, занимающее весь логический экран. Другие делят логический экран на отдельные фрагменты изображений. Изображения также могут функционировать как кадры анимации в анимированном файле GIF, но, опять же, они не обязательно должны заполнять весь логический экран.
Файлы GIF начинаются с заголовка фиксированной длины («GIF87a» или «GIF89a»), указывающего версию, за которым следует дескриптор логического экрана фиксированной длины, указывающий размеры в пикселях и другие характеристики логического экрана. Дескриптор экрана также может указывать наличие и размер глобальной таблицы цветов (GCT), которая следует за ней, если она присутствует.
После этого файл делится на сегменты следующих типов, каждый из которых представлен 1-байтовым сигналом:
',')'!')';'), который должен быть последним байтом файла.Изображение начинается с дескриптора изображения фиксированной длины, который может указывать наличие и размер локальной таблицы цветов (которая следует далее, если она присутствует). Далее следуют данные изображения: один байт, указывающий разрядность незакодированных символов (который должен быть не менее 2 битов, даже для двухцветных изображений), за которым следует серия субблоков, содержащих данные в кодировке LZW.
Блоки расширения (блоки, которые «расширяют» определение 87a с помощью механизма, уже определенного в спецификации 87a) состоят из дозорного, дополнительного байта, определяющего тип расширения, и серии подблоков с данными расширения. Блоки расширения, которые изменяют изображение (например, расширение графического управления, которое определяет необязательное время задержки анимации и необязательный прозрачный цвет фона), должны непосредственно предшествовать сегменту с изображением, на которое они ссылаются.
Каждый субблок начинается с байта, указывающего количество последующих байтов данных в субблоке (от 1 до 255). Последовательность субблоков завершается пустым субблоком (0 байтом).
Эта структура позволяет анализировать файл, даже если не все его части понятны. GIF-файл с пометкой 87a может содержать блоки расширения; цель состоит в том, чтобы декодер мог читать и отображать файл без функций, предусмотренных расширениями, которые он не понимает.
Полная информация о формате файла описана в спецификации GIF. [2]
GIF основан на палитре: цвета, используемые в изображении (кадре) в файле, имеют значения RGB, определенные в таблице палитр , которая может содержать до 256 записей, а данные изображения относятся к цветам по их индексам ( 0–255) в таблице палитр. Определения цветов в палитре могут быть взяты из цветового пространства, состоящего из миллионов оттенков (2 24 оттенка, 8 бит для каждого основного), но максимальное количество цветов, которые может использовать кадр, составляет 256. Это ограничение было разумным, когда был разработан GIF. потому что оборудование, способное отображать более 256 цветов одновременно, было редкостью. Для простой графики, штриховых рисунков, мультфильмов и фотографий в оттенках серого обычно требуется менее 256 цветов.
Каждый кадр может обозначать один индекс как «цвет прозрачного фона»: любой пиксель, которому присвоен этот индекс, принимает цвет пикселя в той же позиции фона, который мог быть определен предыдущим кадром анимации.
Многие методы, называемые под общим названием «дизеринг» , были разработаны для аппроксимации более широкого диапазона цветов с помощью небольшой цветовой палитры путем использования пикселей двух или более цветов для аппроксимации промежуточных цветов. Эти методы жертвуют пространственным разрешением ради более глубокого цветового разрешения. Хотя сглаживание не является частью спецификации GIF, его можно использовать в изображениях, которые впоследствии кодируются как изображения GIF. Часто это не идеальное решение для изображений GIF, поскольку из-за потери пространственного разрешения изображение обычно выглядит нечетким на экране, а также потому, что шаблоны размытия часто мешают сжимаемости данных изображения, что противоречит основной цели GIF.
На заре графических веб-браузеров [ когда? ] , видеокарты с 8-битными буферами (разрешающими только 256 цветов) были распространены, и было довольно распространено создание изображений GIF с использованием палитры веб-безопасности . [ по мнению кого? ] Это обеспечивало предсказуемое отображение, но сильно ограничивало выбор цветов. Когда 24-битный цвет стал нормой, вместо этого палитры можно было заполнить оптимальными цветами для отдельных изображений.
Небольшой таблицы цветов может быть достаточно для небольших изображений, а небольшой размер таблицы цветов позволяет быстрее загружать файл. Спецификации 87a и 89a допускают цветовые таблицы из 2 n цветов для любого n от 1 до 8. Большинство графических приложений читают и отображают изображения GIF с любым из этих размеров таблиц; но некоторые из них не поддерживают все размеры при создании изображений. Широко поддерживаются таблицы из 2, 16 и 256 цветов.
Хотя GIF почти никогда не используется для полноцветных изображений, это возможно. [33] [34] Изображение GIF может включать в себя несколько блоков изображений, каждый из которых может иметь свою собственную 256-цветную палитру, и блоки можно объединять в единое целое для создания целостного изображения. В качестве альтернативы спецификация GIF89a представила идею «прозрачного» цвета, при котором каждый блок изображения может включать свою собственную палитру из 255 видимых цветов плюс один прозрачный цвет. Полное изображение можно создать путем наложения блоков изображения так, чтобы видимая часть каждого слоя была видна сквозь прозрачные части слоев выше.
Чтобы визуализировать полноцветное изображение в формате GIF, исходное изображение необходимо разбить на более мелкие области, содержащие не более 255 или 256 различных цветов. Каждая из этих областей затем сохраняется как отдельный блок изображения со своей собственной локальной палитрой, и когда блоки изображения отображаются вместе (либо путем мозаики, либо путем наложения частично прозрачных блоков изображения), появляется полное полноцветное изображение. Например, разбиение изображения на плитки размером 16 на 16 пикселей (всего 256 пикселей) гарантирует, что ни одна плитка не будет иметь более локального предела палитры в 256 цветов, хотя можно использовать плитки большего размера и объединять похожие цвета, что приводит к некоторой потере цвета. информация. [33]
Поскольку каждый блок изображения может иметь свою собственную локальную таблицу цветов, файл GIF, содержащий множество блоков изображений, может быть очень большим, что ограничивает полезность полноцветных GIF-файлов. [34] Кроме того, не все программы рендеринга GIF правильно обрабатывают мозаичные или многослойные изображения. Многие программы рендеринга интерпретируют плитки или слои как кадры анимации и последовательно отображают их как анимацию [33] , причем большинство веб-браузеров автоматически отображают кадры с задержкой 0,1 секунды или более. [35] [36] [ нужен лучший источник ]
Шестнадцатеричные числа в следующих таблицах имеют порядок байтов с прямым порядком байтов, как предписывает спецификация формата.
Данные пикселей изображения, сканированные горизонтально сверху слева, преобразуются с помощью кодирования LZW в коды, которые затем преобразуются в байты для сохранения в файле. Коды пикселей обычно не соответствуют 8-битному размеру байтов, поэтому коды упаковываются в байты по схеме «little-endian»: младший бит первого кода сохраняется в младшем бите байта. первый байт, биты более высокого порядка кода в биты более высокого порядка байта, при необходимости перетекая в младшие биты следующего байта. Каждый последующий код сохраняется, начиная с младшего бита, который еще не используется.
Этот поток байтов хранится в файле как серия «субблоков». Каждый субблок имеет максимальную длину 255 байт и имеет префикс байта, указывающего количество байтов данных в субблоке. Серия субблоков завершается пустым субблоком (одиночный нулевой байт, обозначающий субблок с 0 байтами данных).
Для примера изображения выше обратимое сопоставление между 9-битными кодами и байтами показано ниже.
Небольшое сжатие очевидно: цвета пикселей, первоначально определенные 15 байтами, точно представлены 12 байтами кода, включая управляющие коды. Процесс кодирования, в результате которого создаются 9-битные коды, показан ниже. Локальная строка накапливает номера цветов пикселей из палитры без каких-либо действий по выводу, если локальную строку можно найти в таблице кодов. Существует специальная обработка первых двух пикселей, которые появляются до того, как таблица вырастет по сравнению с исходным размером, путем добавления строк. После каждого выходного кода локальная строка инициализируется последним цветом пикселя (который не удалось включить в выходной код).
Таблица 9-битная строка --> код Код Действие #0 | 000h Инициализация корневой таблицы 9-битных кодов. палитра | : цвета | : #255 | 0FFh клр | 100 часов конец | 101 час | 100 ч. ОчиститьПиксель Локальный |строка цветовой палитры |ЧЕРНЫЙ #40 28 | 028h Всегда выводится первый пиксельБЕЛЫЙ #255 ФФ | В таблице найдена строка 28 ФФ | 102h Всегда добавлять в таблицу первую строку ФФ | Инициализировать локальную строкуБЕЛЫЙ #255 FF FF | Строка не найдена в таблице | 0FFh — выходной код предыдущей строки ФФ ФФ | 103h — добавить в таблицу последнюю строку ФФ | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | В таблице найдена строкаЧЕРНЫЙ #40 FF FF 28 | Строка не найдена в таблице | 103h — выходной код предыдущей строки ФФ ФФ 28 | 104h — добавить в таблицу последнюю строку 28 | - инициализировать локальную строкуБЕЛЫЙ #255 28 FF | В таблице найдена строкаБЕЛЫЙ #255 28 FF FF | Строка не найдена в таблице | 102h — выходной код предыдущей строки 28 FF FF | 105h — добавить в таблицу последнюю строку ФФ | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | В таблице найдена строкаБЕЛЫЙ #255 FF FF FF | Строка не найдена в таблице | 103h — выходной код предыдущей строки ФФ ФФ ФФ | 106h — добавить в таблицу последнюю строку ФФ | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | В таблице найдена строкаБЕЛЫЙ #255 FF FF FF | В таблице найдена строкаБЕЛЫЙ #255 FF FF FF FF | Строка не найдена в таблице | 106h — выходной код предыдущей строки ФФ ФФ ФФ ФФ| 107h — добавить в таблицу последнюю строку ФФ | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | В таблице найдена строкаБЕЛЫЙ #255 FF FF FF | В таблице найдена строкаБЕЛЫЙ #255 FF FF FF FF | В таблице найдена строка Больше нет пикселей 107h — выходной код последней строки 101ч Конец
Для ясности таблица показана выше как составленная из строк увеличивающейся длины. Эта схема может работать, но таблица потребляет непредсказуемый объем памяти. На практике можно сэкономить память, если учесть, что каждая новая сохраняемая строка состоит из ранее сохраненной строки, дополненной одним символом. Экономично хранить по каждому адресу только два слова: существующий адрес и один символ.
Алгоритм LZW требует поиска по таблице для каждого пикселя. Линейный поиск по 4096 адресам замедлит кодирование. На практике коды могут храниться в порядке числовых значений; это позволяет выполнять каждый поиск с помощью SAR (регистра последовательного приближения, используемого в некоторых АЦП ) с 12 сравнениями величин. Для достижения этой эффективности необходима дополнительная таблица для преобразования кодов в фактические адреса памяти; дополнительное обслуживание таблицы необходимо только тогда, когда сохраняется новый код, что происходит со скоростью, намного меньшей, чем частота пикселей.
Декодирование начинается с преобразования сохраненных байтов обратно в 9-битные коды. Они декодируются для восстановления цветов пикселей, как показано ниже. Таблица, идентичная той, что используется в кодировщике, строится путем добавления строк по такому правилу:
сдвиг 9 бит ----> Код кода пикселя локальной таблицы --> строка Цвет палитры Действие100ч 000ч | #0 Инициализировать корневую таблицу 9-битных кодов : | палитра : | цвета 0FFh | #255 100ч | CLR 101 час | конец028ч | #40 ЧЕРНЫЙ Декодирование 1-го пикселя0FFч 028ч | Входящий код найден в таблице | #255 WHITE - вывод строки из таблицы 102ч | 28 FF - добавить в таблицу103ч 0ФФч | Входящий код не найден в таблице 103ч | FF FF - добавить в таблицу | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ102ч 103ч | Входящий код найден в таблице | - вывод строки из таблицы | #40 ЧЕРНЫЙ | #255 БЕЛЫЙ 104 часа | ФФ ФФ 28 - добавить в таблицу103ч 102ч | Входящий код найден в таблице | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ 105ч | 28 FF FF - добавить в таблицу106ч 103ч | Входящий код не найден в таблице 106ч | FF FF FF - добавить в таблицу | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ | #255 БЕЛЫЙ107ч 106ч | Входящий код не найден в таблице 107ч | FF FF FF FF - добавить в таблицу | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ | #255 БЕЛЫЙ | #255 БЕЛЫЙ101ч | Конец
Более короткую длину кода можно использовать для палитр, меньших, чем 256 цветов в примере. Если в палитре всего 64 цвета (то есть индексы цветов имеют ширину 6 бит), символы могут находиться в диапазоне от 0 до 63, а ширину символа можно принять равной 6 бит, а коды начинаются с 7 бит. Фактически, ширина символа не обязательно должна соответствовать размеру палитры: пока декодируемые значения всегда меньше количества цветов в палитре, символы могут иметь любую ширину от 2 до 8, а размер палитры — любую степень 2. от 2 до 256. Например, если используются только первые четыре цвета (значения от 0 до 3) палитры, символы можно принять шириной 2 бита с кодами, начинающимися с 3 битов.
И наоборот, ширину символа можно установить равной 8, даже если используются только значения 0 и 1; для этих данных потребуется только двухцветная таблица. Хотя нет смысла кодировать файл таким образом, нечто подобное обычно происходит и с двухцветными изображениями: минимальная ширина символа равна 2, даже если используются только значения 0 и 1.
Таблица кодов изначально содержит коды, длина которых на один бит превышает размер символа, чтобы вместить два специальных кода clr и end , а также коды для строк, которые добавляются во время процесса. Когда таблица заполнена, длина кода увеличивается, чтобы освободить место для большего количества строк, вплоть до максимального кода 4095 = FFF(шестнадцатеричный). По мере построения таблицы декодер отслеживает увеличение длины кода и может соответствующим образом распаковывать входящие байты.
Процесс кодирования GIF можно изменить для создания файла без сжатия LZW, который по-прежнему можно просматривать как изображение GIF. Первоначально этот метод был введен как способ избежать нарушения патентных прав. Несжатый GIF также может быть полезным промежуточным форматом для графического программиста, поскольку отдельные пиксели доступны для чтения или рисования. Несжатый файл GIF можно преобразовать в обычный файл GIF, просто пропустив его через редактор изображений.
Измененный метод кодирования игнорирует построение таблицы LZW и выдает только коды корневой палитры и коды CLEAR и STOP. Это дает более простое кодирование (соответствие 1 к 1 между значениями кода и кодами палитры), но при этом жертвуется всем сжатием: каждый пиксель изображения генерирует выходной код, указывающий его индекс цвета. При обработке несжатого GIF стандартному декодеру GIF не будет запрещено записывать строки в свою словарную таблицу, но ширина кода никогда не должна увеличиваться, поскольку это вызывает различную упаковку битов в байты.
Если ширина символа равна n , коды ширины n +1 естественным образом распадаются на два блока: нижний блок из 2 n кодов для кодирования одиночных символов и верхний блок из 2 n кодов, который будет использоваться декодером для последовательностей символов. длина больше единицы. Из этого верхнего блока уже взяты первые два кода: 2 n для CLEAR и 2 n + 1 для STOP. Также необходимо запретить декодеру использовать последний код в верхнем блоке, 2 n +1 − 1 , поскольку когда декодер заполняет этот слот, он увеличивает ширину кода. Таким образом, в верхнем блоке декодеру доступно 2 n - 3 кода, которые не вызовут увеличения ширины кода. Поскольку декодер всегда отстает на один шаг в обслуживании таблицы, он не создает запись таблицы при получении первого кода от кодера, а создает ее для каждого последующего кода. Таким образом, кодер может генерировать 2 n - 2 кодов, не вызывая увеличения ширины кода. Следовательно, кодер должен выдавать дополнительные коды CLEAR с интервалом 2 n - 2 кода или меньше, чтобы заставить декодер сбросить словарь кодирования. Стандарт GIF позволяет вставлять такие дополнительные коды CLEAR в данные изображения в любое время. Составной поток данных разбивается на подблоки, каждый из которых содержит от 1 до 255 байт.
Для приведенного выше примера изображения 3×5 следующие 9-битные коды представляют «чистоту» (100), за которой следуют пиксели изображения в порядке сканирования и «стоп» (101).
100 028 0ФФ 0ФФ 0ФФ 028 0ФФ 0ФФ 0ФФ 0ФФ 0ФФ 0ФФ 0ФФ 0ФФ 0ФФ 0ФФ 101
После того, как приведенные выше коды преобразуются в байты, несжатый файл отличается от сжатого следующим образом:
Тривиальный пример большого одноцветного изображения демонстрирует сжатие LZW переменной длины, используемое в файлах GIF.
Показанные значения кода упакованы в байты, которые затем упаковываются в блоки размером до 255 байт. Блок данных изображения начинается с байта, который определяет количество последующих байтов. Последний блок данных изображения помечен байтом нулевой длины блока.
Спецификация GIF позволяет каждому изображению на логическом экране файла GIF указывать, что оно чересстрочное; т.е. порядок строк растра в блоке данных не является последовательным. Это позволяет частично отобразить изображение, которое можно распознать до того, как будет нарисовано полное изображение.
Чересстрочное изображение разбивается сверху вниз на полоски высотой 8 пикселей, причем строки изображения располагаются в следующем порядке:
Пиксели внутри каждой строки не переплетены, а представлены последовательно слева направо. Как и в случае с нечересстрочными изображениями, между данными одной строки и данными следующей нет разрыва. Индикатор того, что изображение чересстрочное, устанавливается в соответствующем блоке дескриптора изображения.
Хотя GIF не был разработан как среда анимации, его способность хранить несколько изображений в одном файле естественным образом предполагала использование этого формата для хранения кадров анимационной последовательности. Для облегчения отображения анимации в спецификацию GIF89a добавлено расширение Graphic Control Extension (GCE), позволяющее отрисовывать изображения (кадры) в файле с задержками по времени, образуя видеоклип . Каждый кадр в GIF-анимации представлен собственным GCE, определяющим задержку ожидания после отрисовки кадра. Глобальная информация в начале файла по умолчанию применяется ко всем кадрам. Данные ориентированы на поток, поэтому смещение начала каждого GCE в файле зависит от длины предшествующих данных. Внутри каждого кадра данные изображения, закодированные LZW, располагаются в субблоках длиной до 255 байт; размер каждого субблока определяется предшествующим ему байтом.
По умолчанию анимация отображает последовательность кадров только один раз и останавливается, когда отображается последний кадр. Чтобы обеспечить зацикливание анимации, Netscape в 1990-х годах использовала блок Application Extension (предназначенный для того, чтобы позволить поставщикам добавлять информацию, специфичную для приложения, в файл GIF) для реализации Netscape Application Block (NAB). [37] Этот блок, расположенный непосредственно перед последовательностью кадров анимации, определяет количество раз, которое последовательность кадров должна воспроизводиться (от 1 до 65535 раз) или повторяться непрерывно (ноль означает бесконечный цикл). Поддержка этих повторяющихся анимаций впервые появилась в Netscape Navigator версии 2.0, а затем распространилась на другие браузеры. [38] Сейчас большинство браузеров распознают и поддерживают NAB, хотя это не является строго частью спецификации GIF89a.
В следующем примере показана структура анимационного файла Rotating Earth (large).gif, показанного (в виде миниатюры) в информационном окне статьи.
Задержка анимации для каждого кадра указывается в GCE в сотых долях секунды. Некоторая экономия данных возможна, когда кадру нужно перезаписать только часть пикселей дисплея, поскольку дескриптор изображения может определить меньший прямоугольник для повторного сканирования вместо всего изображения. Браузеры или другие дисплеи, не поддерживающие анимированные GIF-файлы, обычно отображают только первый кадр.
Размер и качество цвета анимированных файлов GIF могут существенно различаться в зависимости от приложения, использованного для их создания. Стратегии минимизации размера файла включают использование общей глобальной таблицы цветов для всех кадров (вместо полной локальной таблицы цветов для каждого кадра) и минимизацию количества пикселей, охватываемых последовательными кадрами (так что только те пиксели, которые изменяются от одного кадра к другому), следующие включены в последний кадр). Более продвинутые методы включают изменение последовательностей цветов для лучшего соответствия существующему словарю LZW, что является формой сжатия с потерями . Простая упаковка серии независимых изображений кадров в составную анимацию приводит к получению файлов большого размера. Доступны инструменты для минимизации размера файла с учетом существующего GIF.
Метаданные могут храниться в файлах GIF в виде блока комментариев, блока обычного текста или блока расширения приложения для конкретного приложения. Некоторые графические редакторы используют неофициальные блоки расширений приложений для включения данных, использованных для создания изображения, чтобы их можно было восстановить для дальнейшего редактирования.
Все эти методы технически требуют, чтобы метаданные были разбиты на подблоки, чтобы приложения могли перемещаться по блоку метаданных, не зная его внутренней структуры.
Стандарт метаданных Extensible Metadata Platform (XMP) представил неофициальный, но теперь широко распространенный блок расширения приложения «XMP Data» для включения данных XMP в файлы GIF. [39] Поскольку данные XMP кодируются с использованием UTF-8 без символов NUL, в данных нет нулевых байтов. Вместо того, чтобы разбивать данные на формальные субблоки, блок расширения завершается «магическим трейлером», который направляет любое приложение, обрабатывающее данные как субблоки, к последнему 0 байту, завершающему цепочку субблоков.
В 1977 и 1978 годах Джейкоб Зив и Авраам Лемпель опубликовали пару статей о новом классе алгоритмов сжатия данных без потерь, которые теперь называются LZ77 и LZ78 . В 1983 году Терри Уэлч разработал быстрый вариант LZ78, получивший название Лемпель-Зив-Велч (LZW). [40] [41]
Уэлч подал заявку на патент на метод LZW в июне 1983 года. Полученный в результате патент US4558302, [42] выданный в декабре 1985 года, был передан Sperry Corporation , которая впоследствии объединилась с Burroughs Corporation в 1986 году и образовала Unisys . [40] Дальнейшие патенты были получены в Великобритании, Франции, Германии, Италии, Японии и Канаде.
Помимо вышеупомянутых патентов, патент Уэлча 1983 года также включает ссылки на несколько других патентов, оказавших на него влияние, в том числе:
В июне 1984 года в журнале IEEE была опубликована статья Уэлча , в которой впервые публично описывалась техника LZW. [47] LZW стал популярным методом сжатия данных, и когда патент был выдан, Unisys заключила лицензионные соглашения с более чем сотней компаний. [40] [48]
Популярность LZW побудила CompuServe выбрать его в качестве метода сжатия для своей версии GIF, разработанной в 1987 году. В то время CompuServe не знала о патенте. [40] Unisys стало известно, что версия GIF использует метод сжатия LZW, и вступила в переговоры о лицензировании с CompuServe в январе 1993 года. О последующем соглашении было объявлено 24 декабря 1994 года. [41] Unisys заявила, что они ожидают, что все основные коммерческие файлы будут компании, предоставляющие линейные информационные услуги, использующие патент LZW для лицензирования технологии Unisys по разумной цене, но что они не будут требовать лицензирования или уплаты сборов за некоммерческие, некоммерческие приложения на основе GIF, в том числе за использование на онлайн-сервисах. [48]
После этого объявления CompuServe и Unisys подверглись широкому осуждению, и многие разработчики программного обеспечения пригрозили прекратить использование GIF. Формат PNG (см. ниже) был разработан в 1995 году как предполагаемая замена. [40] [41] [47] Однако получить поддержку формата PNG от производителей веб-браузеров и другого программного обеспечения оказалось сложно, и заменить GIF не удалось, хотя популярность PNG постепенно росла. [40] Поэтому были разработаны варианты GIF без сжатия LZW. Например, библиотека libungif, основанная на giflib Эрика С. Рэймонда , позволяет создавать GIF-файлы, соответствующие формату данных, но без функций сжатия, что позволяет избежать использования патента Unisys LZW. [49] В статье доктора Добба 2001 года описан способ достижения LZW-совместимого кодирования без нарушения его патентов. [50]
В августе 1999 года Unisys изменила детали своей практики лицензирования, объявив о возможности для владельцев некоторых некоммерческих и частных веб-сайтов получать лицензии при уплате единовременного лицензионного сбора в размере 5000 или 7500 долларов США. [51] Такие лицензии не требовались владельцам веб-сайтов или другим пользователям GIF, которые использовали лицензионное программное обеспечение для создания GIF-файлов. Тем не менее, Unisys подверглась тысячам онлайн-атак и оскорбительным электронным письмам от пользователей, которые полагали, что с них собираются заплатить 5000 долларов или подать в суд за использование GIF-файлов на своих веб-сайтах. [52] Несмотря на предоставление бесплатных лицензий сотням некоммерческих организаций, школ и правительств, Unisys была совершенно неспособна создать какую-либо хорошую рекламу и продолжала подвергаться осуждению со стороны отдельных лиц и организаций, таких как Лига за свободу программирования , которая начала кампанию «Сжечь все». Кампания GIF» в 1999 году. [53] [54]
Срок действия патента LZW в США истек 20 июня 2003 г. [55] Срок действия аналогичных патентов в Великобритании, Франции, Германии и Италии истек 18 июня 2004 г., срок действия японских патентов истек 20 июня 2004 г., а срок действия канадского патента истек 7 июля. 2004. [55] Следовательно, хотя Unisys имеет дополнительные патенты и заявки на патенты, касающиеся усовершенствований технологии LZW, [55] сам LZW (и, следовательно, GIF) можно использовать бесплатно с июля 2004 года. [56]
Портативная сетевая графика (PNG) была разработана как замена GIF, чтобы избежать нарушения патента Unisys на технику сжатия LZW. [40] PNG предлагает лучшее сжатие и больше возможностей, чем GIF, [57] анимация является единственным существенным исключением. PNG более подходит, чем GIF, в тех случаях, когда требуется полноцветное изображение и альфа-прозрачность .
Хотя поддержка формата PNG появлялась медленно, новые веб-браузеры поддерживают PNG. Старые версии Internet Explorer не поддерживают все функции PNG. Версии 6 и более ранние не поддерживают прозрачность альфа-канала без использования специфичных для Microsoft расширений HTML. [58] Гамма -коррекция изображений PNG не поддерживалась до версии 8, и отображение этих изображений в более ранних версиях могло иметь неправильный оттенок. [59]
Для идентичных 8-битных (или менее) данных изображения файлы PNG обычно меньше, чем эквивалентные файлы GIF, из-за более эффективных методов сжатия, используемых при кодировании PNG. [60] Полная поддержка GIF осложняется главным образом сложной структурой холста, которую он допускает, хотя именно это обеспечивает возможности компактной анимации.
Видео решают многие проблемы, с которыми сталкиваются GIF-файлы при обычном использовании в Интернете. Они включают в себя значительно меньшие размеры файлов , возможность обойти ограничение 8-битного цвета , а также лучшую обработку и сжатие кадров посредством межкадрового кодирования . Практически универсальная поддержка формата GIF в веб-браузерах и отсутствие официальной поддержки видео в стандарте HTML привели к тому, что GIF стал популярным для отображения коротких видеофайлов в Интернете.
<video>) в большинстве веб-браузеров некоторые веб-сайты используют зацикленную версию тега видео, созданную функциями JavaScript . Это создает вид GIF, но с преимуществами по размеру и скорости сжатого видео.В апреле 2014 года 4chan добавил поддержку немых видеороликов WebM размером менее 3 МБ и продолжительностью 2 минуты, [73] [74] , а в октябре 2014 года Imgur начал конвертировать любые файлы GIF, загруженные на сайт, в видео H.264 . и придание ссылке на HTML-плеер вида реального файла с расширением .gifv. [75] [76]
В январе 2016 года Telegram начал перекодировать все GIF-файлы в видео MPEG-4 , которым «требуется до 95% меньше дискового пространства для того же качества изображения». [77]
.gif,/File:Rotating_earth_(large).gif){kind=link}