Формат обмена графическими данными ( GIF ; / ɡ ɪ f / GHIF или / dʒ ɪ f / JIF , ) — формат растрового изображения , разработанный командой поставщика онлайн-услуг CompuServe под руководством американского учёного-компьютерщика Стива Уилхайта и выпущенный 15 июня 1987 года. [1]
Формат может содержать до 8 бит на пиксель , что позволяет одному изображению ссылаться на собственную палитру из до 256 различных цветов, выбранных из 24-битного цветового пространства RGB . Он также может представлять несколько изображений в файле, который может использоваться для анимации , и позволяет использовать отдельную палитру из до 256 цветов для каждого кадра. Эти ограничения палитры делают GIF менее подходящим для воспроизведения цветных фотографий и других изображений с цветовыми градиентами , но хорошо подходит для более простых изображений, таких как графика или логотипы со сплошными областями цвета.
Изображения GIF сжимаются с использованием метода сжатия данных без потерь Лемпела–Зива–Уэлча (LZW), что позволяет уменьшить размер файла без ухудшения визуального качества.
Хотя когда-то этот формат широко использовался в World Wide Web из-за его широкого внедрения и переносимости между приложениями и операционными системами, его использование сократилось по причинам нехватки места и качества, и его часто заменяют видеоформатами, такими как формат файла MP4 . Эти замены, в свою очередь, иногда называют «GIF», несмотря на то, что они не имеют никакого отношения к исходному формату файла. [3]
CompuServe представил GIF 15 июня 1987 года, чтобы предоставить цветной формат изображения для своих областей загрузки файлов. Он заменил их более ранний формат кодирования длины серии , который был только черно-белым. GIF стал популярным, потому что он использовал сжатие данных Lempel–Ziv–Welch . Поскольку это было более эффективно, чем кодирование длины серии, используемое 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 , он использовал алгоритм сжатия данных без потерь Lempel–Ziv–Welch (LZW), запатентованный Unisys в 1985 году. Разногласия по поводу лицензионного соглашения между Unisys и CompuServe в 1994 году подстегнули разработку стандарта Portable Network Graphics (PNG). В 2004 году все патенты, относящиеся к фирменному сжатию, используемому для GIF, истекли.
Возможность сохранения нескольких изображений в одном файле вместе с управляющими данными широко используется в Интернете для создания простых анимаций .
Дополнительная функция чересстрочной развертки , которая сохраняет строки сканирования изображения в неупорядоченном виде таким образом, что даже частично загруженное изображение было в некоторой степени узнаваемо, также способствовала популярности GIF, [6] поскольку пользователь мог прервать загрузку, если она была не той, что требовалась.
В мае 2015 года Facebook добавил поддержку GIF. [7] [8] В январе 2018 года Instagram также добавил GIF-стикеры в режим историй. [9]
Как существительное , слово GIF встречается в новых изданиях многих словарей. В 2012 году американское крыло Oxford University Press признало GIF также глаголом , означающим «создать GIF-файл», как в «GIFing был идеальным средством для обмена сценами с летних Олимпийских игр ». Лексикографы прессы проголосовали за него как за слово года , заявив, что GIF-файлы превратились в «инструмент с серьезными приложениями, включая исследования и журналистику». [10] [11]
Произношение первой буквы GIF является предметом споров с 1990-х годов. Наиболее распространенные произношения в английском языке: / dʒ ɪ f / (смягкимgкак вgin) и/ ɡ ɪ f / (ствёрдымg, как вgift), отличаясь фонемой,представленной буквойG.Создатели формата произносили аббревиатуруGIFкак/ dʒ ɪ f /, смягкимg, при этом Уилхайт заявлял, что он намеревался сделать произношение намеренно отсылающим к американскомубрендуарахисового маслаJif, а сотрудники CompuServe часто шутили: «разборчивые разработчики выбирают GIF», пародируя телевизионную рекламу Jif.[12]Однако это слово широко произносится как/ ɡ ɪ f /, ствёрдымg,[13]и опросы в целом показали, что это твёрдоеgболее распространено.[14][15]
Dictionary.com [16] приводит оба произношения, указывая / dʒ ɪ f / как основное произношение, в то время как Cambridge Dictionary of American English [17] предлагает только твердое произношение g . Merriam-Webster's Collegiate Dictionary [18] и Oxford Dictionaries приводят оба произношения, но ставят твердое g на первое место: / ɡ ɪ f , dʒ ɪ f / . [19] [20] [21] [22] New Oxford American Dictionary дал только / dʒ ɪ f / во втором издании [23], но обновил его до / dʒ ɪ f , ɡ ɪ f / в третьем издании. [24]
Разногласия по поводу произношения привели к жарким интернет-дебатам. По случаю получения награды за достижения всей жизни на церемонии вручения премии Webby Awards 2013 года Уилхайт публично отверг произношение с твёрдым g ; [13] [25] [26] его речь привела к более чем 17 000 сообщений в Twitter и десяткам новостных статей. [27] Белый дом [13] и телепрограмма Jeopardy! также вступили в дебаты в 2013 году. [26] В феврале 2020 года компания JM Smucker Company , владельцы бренда Jif, объединились с базой данных анимированных изображений и поисковой системой Giphy, чтобы выпустить ограниченную серию банок арахисового масла «Jif против GIF» ( с хэштегом #JIFvsGIF), на этикетке которой было юмористически заявлено, что мягкое g относится исключительно к арахисовому маслу, а GIF следует произносить исключительно с твёрдым g . [28]
GIF-файлы подходят для четких линий с ограниченным количеством цветов, таких как логотипы. Это использует преимущество сжатия без потерь формата, которое благоприятствует плоским областям однородного цвета с четко определенными краями. [29] Их также можно использовать для хранения низкоцветных спрайтовых данных для игр. [30] GIF-файлы можно использовать для небольших анимаций и видеоклипов с низким разрешением или в качестве реакций в онлайн-сообщениях, используемых для передачи эмоций и чувств вместо использования слов. Они популярны на платформах социальных сетей, таких как Tumblr , [31] Facebook и Twitter . [32]
Концептуально, GIF-файл описывает графическую область фиксированного размера («логический экран»), заполненную нулем или более «изображениями». Многие GIF-файлы имеют одно изображение, которое заполняет весь логический экран. Другие делят логический экран на отдельные подизображения. Изображения также могут функционировать как кадры анимации в анимированном GIF-файле, но, опять же, они не должны заполнять весь логический экран.
Файлы GIF начинаются с заголовка фиксированной длины ("GIF87a" или "GIF89a"), указывающего версию, за которым следует логический дескриптор экрана фиксированной длины, указывающий размеры пикселей и другие характеристики логического экрана. Дескриптор экрана может также указывать наличие и размер глобальной таблицы цветов (GCT), которая следует далее, если присутствует.
После этого файл делится на сегменты следующих типов, каждый из которых начинается с 1-байтового сигнального символа:
','
)'!'
)';'
), который должен быть последним байтом файла.Изображение начинается с дескриптора изображения фиксированной длины, который может указывать на наличие и размер локальной таблицы цветов (которая следует далее, если присутствует). Далее следуют данные изображения: один байт, задающий битовую ширину незакодированных символов (которая должна быть не менее 2 бит, даже для двухцветных изображений), за которым следует ряд подблоков, содержащих данные, закодированные LZW.
Блоки расширения (блоки, которые «расширяют» определение 87a с помощью механизма, уже определенного в спецификации 87a) состоят из контрольной точки, дополнительного байта, определяющего тип расширения, и ряда подблоков с данными расширения. Блоки расширения, которые изменяют изображение (например, расширение графического управления, которое определяет необязательное время задержки анимации и необязательное прозрачное цвет фона), должны непосредственно предшествовать сегменту с изображением, на которое они ссылаются.
Каждый подблок начинается с байта, указывающего количество последующих байтов данных в подблоке (от 1 до 255). Серия подблоков завершается пустым подблоком (нулевым байтом).
Эта структура позволяет анализировать файл, даже если не все части понятны. GIF-файл с меткой 87a может содержать блоки расширения; это делается для того, чтобы декодер мог читать и отображать файл без функций, которые содержатся в расширениях, которые он не понимает.
Полная информация о формате файла содержится в спецификации GIF. [2]
GIF основан на палитре: цвета, используемые в изображении (кадре) в файле, имеют свои значения RGB, определенные в таблице палитры , которая может содержать до 256 записей, а данные для изображения ссылаются на цвета по их индексам (0–255) в таблице палитры. Определения цветов в палитре могут быть получены из цветового пространства миллионов оттенков (2 24 оттенка, 8 бит для каждого основного цвета), но максимальное количество цветов, которое может использовать кадр, составляет 256. Это ограничение было разумным, когда разрабатывался GIF, поскольку оборудование, которое могло отображать более 256 цветов одновременно, было редким. Простая графика, линейные рисунки, мультфильмы и фотографии в оттенках серого обычно требуют менее 256 цветов.
Каждый кадр может назначить один индекс в качестве «прозрачного фонового цвета»: любой пиксель, которому назначен этот индекс, принимает цвет пикселя в той же позиции на фоне, который мог быть определен предыдущим кадром анимации.
Многие методы, в совокупности называемые дизерингом , были разработаны для аппроксимации более широкого диапазона цветов с небольшой цветовой палитрой путем использования пикселей двух или более цветов для аппроксимации промежуточных цветов. Эти методы жертвуют пространственным разрешением ради аппроксимации более глубокого цветового разрешения. Хотя это и не является частью спецификации GIF, дизеринг может использоваться в изображениях, впоследствии кодируемых как изображения GIF. Это часто не идеальное решение для изображений GIF, как потому, что потеря пространственного разрешения обычно делает изображение нечетким на экране, так и потому, что шаблоны дизеринга часто мешают сжимаемости данных изображения, работая против основного назначения GIF.
В ранние дни графических веб-браузеров [ когда? ] были распространены графические карты с 8-битными буферами (позволяющими только 256 цветов), и было довольно распространено создание изображений GIF с использованием палитры websafe . [ по мнению кого? ] Это гарантировало предсказуемое отображение, но серьезно ограничивало выбор цветов. Когда 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 байт, указывающий на подблок с 0 байтами данных).
Для приведенного выше примера изображения ниже показано обратимое отображение между 9-битными кодами и байтами.
Небольшое сжатие очевидно: цвета пикселей, изначально определенные 15 байтами, точно представлены 12 байтами кода, включая управляющие коды. Процесс кодирования, который создает 9-битные коды, показан ниже. Локальная строка накапливает номера цветов пикселей из палитры, без выходных действий, пока локальная строка может быть найдена в таблице кодов. Существует специальная обработка первых двух пикселей, которые поступают до того, как таблица вырастет из своего начального размера путем добавления строк. После каждого выходного кода локальная строка инициализируется последним цветом пикселя (который не может быть включен в выходной код).
Таблица 9-битная строка --> код код Действие #0 | 000h Инициализация корневой таблицы 9-битных кодов палитра | : цвета | : #255 | 0FFh клр | 100ч конец | 101h | 100ч ОчиститьПиксель Локальный |Цветовая палитра строка |ЧЕРНЫЙ #40 28 | 028h 1-й пиксель всегда выводитсяБЕЛЫЙ #255 FF | Строка найдена в таблице 28 FF | 102h Всегда добавлять 1-ю строку в таблицу FF | Инициализация локальной строкиБЕЛЫЙ #255 FF FF | Строка не найдена в таблице | 0FFh - выходной код для предыдущей строки FF FF | 103h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | Строка найдена в таблицеBLACK #40 FF FF 28 | Строка не найдена в таблице | 103h - выходной код для предыдущей строки FF FF 28 | 104h - добавить последнюю строку в таблицу 28 | - инициализировать локальную строкуБЕЛЫЙ #255 28 FF | Строка найдена в таблицеБЕЛЫЙ #255 28 FF FF | Строка не найдена в таблице | 102h - выходной код для предыдущей строки 28 FF FF | 105h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | Строка найдена в таблицеБЕЛЫЙ #255 FF FF FF | Строка не найдена в таблице | 103h - выходной код для предыдущей строки FF FF FF | 106h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | Строка найдена в таблицеБЕЛЫЙ #255 FF FF FF | Строка найдена в таблицеБЕЛЫЙ #255 FF FF FF FF | Строка не найдена в таблице | 106h - выходной код для предыдущей строки FF FF FF FF| 107h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ #255 FF FF | Строка найдена в таблицеБЕЛЫЙ #255 FF FF FF | Строка найдена в таблицеБЕЛЫЙ #255 FF FF FF FF | Строка найдена в таблице Больше никаких пикселей. 107h - выходной код для последней строки 101h Конец
Для ясности таблица показана выше как построенная из строк увеличивающейся длины. Такая схема может работать, но таблица потребляет непредсказуемый объем памяти. Память можно сэкономить на практике, заметив, что каждая новая строка для сохранения состоит из ранее сохраненной строки, увеличенной на один символ. Экономично хранить по каждому адресу только два слова: существующий адрес и один символ.
Алгоритм LZW требует поиска в таблице для каждого пикселя. Линейный поиск по 4096 адресам замедлит кодирование. На практике коды могут храниться в порядке числового значения; это позволяет выполнять каждый поиск с помощью SAR (регистр последовательного приближения, используемый в некоторых АЦП ) всего с 12 сравнениями величин. Для этой эффективности требуется дополнительная таблица для преобразования между кодами и фактическими адресами памяти; дополнительное ведение таблицы необходимо только при сохранении нового кода, что происходит со скоростью, намного меньшей, чем скорость пикселей.
Декодирование начинается с преобразования сохраненных байтов обратно в 9-битные коды. Они декодируются для восстановления цветов пикселей, как показано ниже. Таблица, идентичная той, что используется в кодере, создается путем добавления строк по этому правилу:
сдвиг 9 бит ----> Локальная таблица Код пикселя Код кода --> строка Палитра Цвет Действие100h 000h | #0 Инициализация корневой таблицы 9-битных кодов : | палитра : | цвета 0FFh | #255 100ч | клр 101h | конец028h | #40 ЧЕРНЫЙ Декодировать 1-й пиксель0FFh 028h | Входящий код найден в таблице | #255 WHITE - вывод строки из таблицы 102h | 28 FF - добавить в таблицу103h 0FFh | Входящий код не найден в таблице 103h | FF FF - добавить в таблицу | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ102h 103h | Входящий код найден в таблице | - вывод строки из таблицы | #40 ЧЁРНЫЙ | #255 БЕЛЫЙ 104h | FF FF 28 - добавить в таблицу103h 102h | Входящий код найден в таблице | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ 105h | 28 FF FF - добавить в таблицу106h 103h | Входящий код не найден в таблице 106h | FF FF FF - добавить в таблицу | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ | #255 БЕЛЫЙ107h 106h | Входящий код не найден в таблице 107h | FF FF FF FF - добавить в таблицу | - вывод строки из таблицы | #255 БЕЛЫЙ | #255 БЕЛЫЙ | #255 БЕЛЫЙ | #255 БЕЛЫЙ101h | Конец
Для палитр, меньших, чем 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(hex). По мере того, как декодер строит свою таблицу, он отслеживает эти увеличения длины кода и может распаковывать входящие байты соответствующим образом.
Процесс кодирования 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 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 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.
В следующем примере показана структура файла анимации Вращающаяся Земля (большая).gif, показанного (в виде миниатюры) в информационном поле статьи.
Задержка анимации для каждого кадра указывается в GCE в сотых долях секунды. Некоторая экономия данных возможна, когда кадру нужно перезаписать только часть пикселей дисплея, поскольку дескриптор изображения может определить меньший прямоугольник для повторного сканирования вместо всего изображения. Браузеры или другие дисплеи, не поддерживающие анимированные GIF-файлы, обычно показывают только первый кадр.
Размер и качество цвета анимированных файлов GIF могут значительно различаться в зависимости от приложения, используемого для их создания. Стратегии минимизации размера файла включают использование общей глобальной таблицы цветов для всех кадров (вместо полной локальной таблицы цветов для каждого кадра) и минимизацию количества пикселей, охватываемых последовательными кадрами (так, чтобы только пиксели, которые изменяются от одного кадра к другому, включались в последний кадр). Более продвинутые методы включают изменение цветовых последовательностей для лучшего соответствия существующему словарю LZW, форме сжатия с потерями . Простая упаковка серии независимых кадровых изображений в составную анимацию, как правило, дает большие размеры файлов. Существуют инструменты для минимизации размера файла с учетом существующего GIF.
Метаданные могут храниться в файлах GIF как блок комментариев, блок простого текста или блок расширения приложения, специфичный для приложения. Некоторые графические редакторы используют неофициальные блоки расширения приложения для включения данных, используемых для генерации изображения, чтобы его можно было восстановить для дальнейшего редактирования.
Все эти методы технически требуют, чтобы метаданные были разбиты на подблоки, чтобы приложения могли перемещаться по блоку метаданных, не зная его внутренней структуры.
Стандарт метаданных Extensible Metadata Platform ( XMP) представил неофициальный, но теперь широко распространенный блок расширения приложения "XMP Data" для включения данных XMP в файлы GIF. [39] Поскольку данные XMP кодируются с использованием UTF-8 без символов NUL, в данных нет нулевых байтов. Вместо того, чтобы разбивать данные на формальные подблоки, блок расширения завершается "волшебным трейлером", который направляет любое приложение, обрабатывающее данные как подблоки, к конечному нулевому байту, который завершает цепочку подблоков.
В 1977 и 1978 годах Якоб Зив и Авраам Лемпель опубликовали пару статей о новом классе алгоритмов сжатия данных без потерь, которые теперь совместно называются LZ77 и LZ78 . В 1983 году Терри Уэлч разработал быстрый вариант LZ78, который был назван Lempel–Ziv–Welch (LZW). [40] [41]
Уэлч подал заявку на патент на метод LZW в июне 1983 года. Полученный патент US4558302, [42] выданный в декабре 1985 года, был передан корпорации Sperry Corporation , которая впоследствии объединилась с корпорацией Burroughs в 1986 году и образовала Unisys . [40] Дальнейшие патенты были получены в Великобритании, Франции, Германии, Италии, Японии и Канаде.
Помимо вышеуказанных патентов, патент Уэлча 1983 года также включает ссылки на несколько других патентов, которые на него повлияли, в том числе:
В июне 1984 года в журнале IEEE была опубликована статья Уэлча , в которой впервые публично описывалась технология LZW. [47] LZW стала популярной технологией сжатия данных, и после выдачи патента Unisys заключила лицензионные соглашения с более чем сотней компаний. [40] [48]
Популярность LZW привела к тому, что CompuServe выбрала его в качестве метода сжатия для своей версии GIF, разработанной в 1987 году. В то время CompuServe не знала о патенте. [40] Unisys узнала, что версия GIF использует метод сжатия LZW, и в январе 1993 года вступила в переговоры о лицензировании с CompuServe. О последующем соглашении было объявлено 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]
Формат Portable Network Graphics (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>
) в большинстве веб-браузеров некоторые веб-сайты используют зацикленную версию тега video, сгенерированную функциями JavaScript . Это дает вид GIF, но с преимуществами размера и скорости сжатого видео.В апреле 2014 года 4chan добавил поддержку тихих видеороликов WebM размером менее 3 МБ и продолжительностью 2 минуты, [74] [75] а в октябре 2014 года Imgur начал конвертировать все загруженные на сайт GIF-файлы в видео H.264 и придавать ссылке на HTML-плеер вид реального файла с .gifv
расширением. [76] [77]
В январе 2016 года Telegram начал перекодировать все GIF-файлы в видео MPEG-4 , которые «требуют на 95% меньше места на диске для того же качества изображения». [78]