гифка
 Анимированный GIF глобуса вращающегося | |
| Расширение имени файла | .gif |
|---|---|
| Тип интернет-СМИ | image/gif |
| Введите код | GIFf |
| Единый идентификатор типа (UTI) | com.compuserve.gif |
| Магическое число | GIF87a/ GIF89a |
| Разработано | КомпуСерв |
| Первоначальный выпуск | 15 июня 1987 г [1] |
| Последний выпуск | 89а 1989 год [2] |
| Тип формата | изображения без потерь растрового формат |
| Веб-сайт | www |
Формат обмена графикой ( 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 / с твёрдым г , [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] Фейсбук и Твиттер . [32]
Формат файла [ править ]
Концептуально файл GIF описывает графическую область фиксированного размера («логический экран»), заполненную нулем или более «изображениями». Многие файлы GIF содержат одно изображение, занимающее весь логический экран. Другие делят логический экран на отдельные фрагменты изображений. Изображения также могут функционировать как кадры анимации в анимированном файле GIF, но, опять же, они не обязательно должны заполнять весь логический экран.
Файлы GIF начинаются с заголовка фиксированной длины («GIF87a» или «GIF89a»), указывающего версию, за которым следует дескриптор логического экрана фиксированной длины, указывающий размеры в пикселях и другие характеристики логического экрана. Дескриптор экрана также может указывать наличие и размер глобальной таблицы цветов (GCT), которая следует за ней, если она присутствует.
После этого файл делится на сегменты следующих типов, каждый из которых представлен 1-байтовым сигналом:
- Изображение (представленное 0x2C, запятой ASCII)
',') - Блок расширения (представленный 0x21, восклицательным знаком ASCII).
'!') - Конец (один байт значения 0x3B, точка с запятой ASCII).
';'), который должен быть последним байтом файла.
Изображение начинается с дескриптора изображения фиксированной длины, который может указывать наличие и размер локальной таблицы цветов (которая следует далее, если она присутствует). Далее следуют данные изображения: один байт, указывающий разрядность незакодированных символов (который должен быть не менее 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 от 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] [ нужен лучший источник ]
Пример GIF-файла [ править ]
| Microsoft Paint сохраняет небольшое черно-белое изображение в виде следующего файла GIF (показано в увеличенном виде). Paint не оптимально использует GIF; из-за неоправданно большой таблицы цветов (хранящей полные 256 цветов вместо используемых 2) и ширины символов этот GIF-файл не является эффективным представлением 15-пиксельного изображения. Хотя блок расширения графического управления объявляет индекс цвета 16 (шестнадцатеричный 10) прозрачным, этот индекс не используется в изображении. В данных изображения появляются только десятичные индексы цвета 40 и 255, которые в глобальной таблице цветов отображаются как черный и белый соответственно. |
 Пример изображения (увеличенный), реальный размер: 3 пикселя в ширину и 5 в высоту. |
Шестнадцатеричные числа в следующих таблицах расположены в порядке байтов с прямым порядком байтов, как предписывает спецификация формата.
| Байт № (шестнадцатеричный) | Шестнадцатеричный | Текст или значение | Значение | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | Заголовок | |||||||
| Дескриптор логического экрана | ||||||||||
| 6 | 03 00 | 3 | Логическая ширина экрана | |||||||
| 8 | 05 00 | 5 | Логическая высота экрана | |||||||
| А | F7 | Далее следует GCT для 256 цветов с разрешением 3 × 8 бит/основной, самые младшие 3 бита представляют битовую глубину минус 1, самый высокий истинный бит означает, что GCT присутствует. | ||||||||
| Б | 00 | 0 | Цвет фона: индекс #0; #000000 черный | |||||||
| С | 00 | 0 | Соотношение сторон пикселей по умолчанию, 0:0 | |||||||
| Глобальная таблица цветов | ||||||||||
| Д | 00 00 00 |
|
Глобальная таблица цветов, цвет № 0: #000000, черный |  | ||||||
| 10 | 80 00 00 |
|
Глобальная таблица цветов, цвет №1: прозрачный бит, не используется в изображении. | |||||||
| ... | ... | ... | Глобальная таблица цветов расширяется до 30 А | |||||||
| 30А | ФФ ФФ ФФ |
|
Глобальная таблица цветов, цвет № 255: #ffffff, белый. | |||||||
| Расширение графического управления | ||||||||||
| 30Д | 21 | '!' |
Блок расширения (представленный восклицательным знаком ASCII). '!')
| |||||||
| 30E | F9 | Расширение графического управления | ||||||||
| 30F | 04 | 4 | Объем данных GCE, 4 байта | |||||||
| 310 | 01 | Прозрачный цвет фона; это битовое поле, младший бит означает прозрачность | ||||||||
| 311 | 00 00 | Задержка анимации в сотых долях секунды; не используется | ||||||||
| 313 | 10 | 16 | Номер цвета прозрачного пикселя в GCT | |||||||
| 314 | 00 | Конец блока GCE | ||||||||
| Дескриптор изображения | ||||||||||
| 315 | 2С | ',' |
Дескриптор изображения (представленный 0x2C, запятой ASCII). ',')
| |||||||
| 316 | 00 00 00 00 | (0, 0) | Положение изображения в северо-западном углу логического экрана | |||||||
| 31А | 03 00 05 00 | (3, 5) | Ширина и высота изображения в пикселях | |||||||
| 31Е | 00 | 0 | Бит локальной таблицы цветов, 0 означает отсутствие | |||||||
| Данные изображения | ||||||||||
| 31F | 08 | 8 | Начало изображения, минимальный размер кода LZW | |||||||
| 320 | 0Б | 11 | Начало первого подблока данных, указывающее 11 байтов последующих закодированных данных. | |||||||
| 321 | 00 51 FC 1B 28 70 A0 C1 83 01 01 | <данные изображения> | 11 байт данных изображения, см. поле 320. | |||||||
| 32С | 00 | 0 | Конечный подблок данных, без указания следующих байтов данных (и конца изображения) | |||||||
| Трейлер | ||||||||||
| 32Д | 3Б | ';' |
Индикатор блока завершения файла (точка с запятой в формате ASCII). ';')
| |||||||
Кодирование изображений [ править ]
Данные пикселей изображения, сканированные горизонтально сверху слева, преобразуются с помощью кодирования LZW в коды, которые затем преобразуются в байты для сохранения в файле. Коды пикселей обычно не соответствуют 8-битному размеру байтов, поэтому коды упаковываются в байты по схеме «little-endian»: младший значащий бит первого кода сохраняется в младшем бите байта. первый байт, биты более высокого порядка кода в биты более высокого порядка байта, при необходимости перетекая в младшие биты следующего байта. Каждый последующий код сохраняется, начиная с младшего бита, который еще не используется.
Этот поток байтов хранится в файле как серия «субблоков». Каждый субблок имеет максимальную длину 255 байт и имеет префикс байта, указывающего количество байтов данных в субблоке. Серия субблоков завершается пустым субблоком (одиночный нулевой байт, обозначающий субблок с 0 байтами данных).
Для примера изображения выше обратимое сопоставление между 9-битными кодами и байтами показано ниже.
| 9-битный код | Байт | ||
|---|---|---|---|
| Шестнадцатеричный | Двоичный | Двоичный | Шестнадцатеричный |
| 100 | 1 00000000 | 00000000 | 00 |
| 028 | 00 0101000 | 0101000 1 | 51 |
| 0ФФ | 011 111111 | 111111 00 | ФК |
| 103 | 1000 00011 | 00011 011 | 1Б |
| 102 | 10000 0010 | 0010 1000 | 28 |
| 103 | 100000 011 | 011 10000 | 70 |
| 106 | 1000001 10 | 10 100000 | А0 |
| 107 | 10000011 1 | 1 1000001 | С1 |
| 10000011 | 83 | ||
| 101 | 1 00000001 | 00000001 | 01 |
| 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-битные коды. Они декодируются для восстановления цветов пикселей, как показано ниже. Таблица, идентичная той, что используется в кодировщике, строится путем добавления строк по такому правилу:
| Да | добавить строку для локального кода, за которой следует первый байт строки для входящего кода |
| Нет | добавить строку для локального кода, за которой следует копия собственного первого байта |
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, даже если используются только значения 0 и 1.
Таблица кодов изначально содержит коды, длина которых на один бит превышает размер символа, чтобы вместить два специальных кода clr и end, а также коды для строк, которые добавляются во время процесса. Когда таблица заполнена, длина кода увеличивается, чтобы освободить место для большего количества строк, вплоть до максимального кода 4095 = FFF(шестнадцатеричный). По мере того, как декодер строит свою таблицу, он отслеживает увеличение длины кода и может соответствующим образом распаковывать входящие байты.
Несжатый GIF [ править ]
 Несжатый GIF-файл размером 46×46 с 7-битными символами (128 цветов, 8-битные коды). |
Процесс кодирования GIF можно изменить для создания файла без сжатия LZW, который по-прежнему можно просматривать как изображение GIF. Первоначально этот метод был введен как способ избежать нарушения патентных прав. Несжатый GIF также может быть полезным промежуточным форматом для графического программиста, поскольку отдельные пиксели доступны для чтения или рисования. Несжатый файл GIF можно преобразовать в обычный файл GIF, просто пропустив его через редактор изображений.
Измененный метод кодирования игнорирует построение таблицы LZW и выдает только коды корневой палитры и коды CLEAR и STOP. Это дает более простое кодирование (соответствие 1 к 1 между значениями кода и кодами палитры), но при этом жертвуется всем сжатием: каждый пиксель изображения генерирует выходной код, указывающий его индекс цвета. При обработке несжатого GIF стандартному декодеру GIF не будет запрещено записывать строки в свою словарную таблицу, но ширина кода никогда не должна увеличиваться, поскольку это вызывает различную упаковку битов в байты.
Если ширина символа равна n , коды ширины n +1 естественным образом распадаются на два блока: нижний блок из 2 н коды для кодирования одиночных символов и верхний блок из 2 н коды, которые будут использоваться декодером для последовательностей длиной больше единицы. Из этого верхнего блока уже взяты первые два кода: 2 н для CLEAR и 2 н + 1 для СТОП. Декодеру также необходимо запретить использовать последний код в верхнем блоке, 2 п +1 − 1 , потому что когда декодер заполняет этот слот, ширина кода увеличивается. Таким образом, в верхнем блоке имеется 2 н − 3 кода, доступных декодеру, которые не вызывают увеличения ширины кода. Поскольку декодер всегда отстает на один шаг в обслуживании таблицы, он не создает запись таблицы при получении первого кода от кодера, а создает ее для каждого последующего кода. Таким образом, кодер может генерировать 2 н − 2 кода без увеличения ширины кода. Следовательно, кодер должен выдавать дополнительные коды CLEAR с интервалом 2 н − 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
После того, как приведенные выше коды преобразуются в байты, несжатый файл отличается от сжатого следующим образом:
| Байт № (шестнадцатеричный) | Шестнадцатеричный | Текст или значение | Значение |
|---|---|---|---|
| 320 | 14 | 20 | Далее следуют 20 байт несжатых данных изображения. |
| 321 | 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01 | ||
| 335 | 00 | 0 | Конец данных изображения |
Пример сжатия [ править ]
Тривиальный пример большого одноцветного изображения демонстрирует сжатие LZW переменной длины, используемое в файлах GIF.
| Код | Пиксели | Примечания | |||
|---|---|---|---|---|---|
| Нет. Н я | Ценить Н я + 256 | Длина (биты) | Этот код Н я | Накоплено Н я (Н я + 1) / 2 | Отношения с использованием N i применяются только к пикселям одного цвета до тех пор, пока таблица кодирования не заполнится. |
| 0 | 100 часов | 9 | Очистить таблицу кодов | ||
| 1 | ФФч | 1 | 1 | Цвет верхнего левого пикселя выбран как наивысший индекс палитры из 256 цветов. | |
| 2 | 102ч | 2 | 3 | ||
| 3 ⋮ 255 | 103ч. ⋮ 1FFч | 3 ⋮ 255 | 6 ⋮ 32640 | Последний 9-битный код | |
| 256 ⋮ 767 | 200 часов ⋮ 3FFh | 10 | 256 ⋮ 767 | 32896 ⋮ 294528 | Последний 10-битный код |
| 768 ⋮ 1791 | 400 часов ⋮ 7FFh | 11 | 768 ⋮ 1791 | 295296 ⋮ 1604736 | Последний 11-битный код |
| 1792 ⋮ 3839 | 800 часов ⋮ ФФФч | 12 | 1792 ⋮ 3839 | 1606528 ⋮ 7370880 | Кодовая таблица заполнена |
| ⋮ | ФФФч | 3839 | Максимальный код может повторяться для большего количества пикселей одного цвета. Общее сжатие данных асимптотически приближается к 3839 × 8 / 12 = 2559 + 1 / 3 | ||
| 101ч | Конец данных изображения | ||||
Показанные значения кода упакованы в байты, которые затем упаковываются в блоки размером до 255 байт. Блок данных изображения начинается с байта, который определяет количество последующих байтов. Последний блок данных изображения помечен байтом нулевой длины блока.
Чересстрочная развертка [ править ]
Спецификация GIF позволяет каждому изображению на логическом экране файла GIF указывать, что оно чересстрочное; т.е. порядок строк растра в блоке данных не является последовательным. Это позволяет частично отобразить изображение, которое можно распознать до того, как будет нарисовано полное изображение.
Чересстрочное изображение разбивается сверху вниз на полоски высотой 8 пикселей, причем строки изображения располагаются в следующем порядке:
- Проход 1: линия 0 (самая верхняя строка) с каждой полосы.
- Проход 2: линия 4 с каждой полосы.
- Проход 3: линии 2 и 6 с каждой полосы.
- Проход 4: линии 1, 3, 5 и 7 с каждой полосы.
Пиксели внутри каждой строки не переплетены, а представлены последовательно слева направо. Как и в случае с нечересстрочными изображениями, между данными одной строки и данными следующей нет разрыва. Индикатор того, что изображение чересстрочное, устанавливается в соответствующем блоке дескриптора изображения.
Анимированный GIF [ править ]
Хотя 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, показанного (в виде миниатюры) в информационном окне статьи.
| Байт № (шестнадцатеричный) | Шестнадцатеричный | Текст или значение | Значение |
|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | Дескриптор логического экрана |
| 6 | 90 01 | 400 | Ширина в пикселях |
| 8 | 90 01 | 400 | Высота в пикселях |
| А | F7 | Далее следует GCT для 256 цветов с разрешением 3 × 8 бит/основной. | |
| Б | 00 | 0 | Цвет фона: #000000, черный. |
| С | 00 | 0 | Соотношение сторон пикселей по умолчанию, 0:0 |
| Д | 00 | Глобальная таблица цветов | |
| ⋮ | |||
| 30Д | 21 | '!'
|
Блок расширения (представленный восклицательным знаком ASCII). '!')
|
| 30E | ФФ | Расширение приложения | |
| 30F | 0Б | 11 | Размер блока, включая имя приложения и проверочные байты (всегда 11) |
| 310 | 4Е 45 54 53 43 41 50 45 32 2Е 30 | NETSCAPE2.0 | 8-байтовое имя приложения плюс 3 байта проверки. |
| 31Б | 03 | 3 | Количество байтов в следующем подблоке |
| 31С | 01 | 1 | Индекс текущего подблока данных (всегда 1 для блока NETSCAPE) |
| 31Д | ФФ ФФ | 65535 | Беззнаковое количество повторений |
| 31F | 00 | Конец цепочки субблоков для блока расширения приложения. | |
| 320 | 21 | '!'
|
Блок расширения (представленный восклицательным знаком ASCII). '!')
|
| 321 | F9 | Расширение графического управления для кадра №1 | |
| 322 | 04 | 4 | Количество байтов (4) в текущем субблоке |
| 323 | 04 | 000.....
...001..
......0.
.......0
|
Зарезервировано, 5 младших битов — битовое поле. Способ утилизации 1: не выбрасывать. Нет пользовательского ввода Прозрачный цвет, 0 означает, что не задано |
| 324 | 09 00 | 9 | Задержка кадра: задержка 0,09 секунды перед прорисовкой следующего кадра. |
| 326 | ФФ | Прозрачный индекс цвета (не используется в этом кадре) | |
| 327 | 00 | Конец цепочки субблоков для блока расширения графического управления. | |
| 328 | 2С | ',' |
Дескриптор изображения (представленный 0x2C, запятой ASCII). ',')
|
| 329 | 00 00 00 00 | (0, 0) | Положение северо-западного угла изображения на логическом экране: (0, 0) |
| 32Д | 90 01 90 01 | (400, 400) | Ширина и высота рамки: 400 × 400 пикселей. |
| 331 | 00 | 0 | Локальная таблица цветов: 0 означает отсутствие и отсутствие чересстрочной развертки. |
| 332 | 08 | 8 | Минимальный размер кода LZW для данных изображения кадра №1. |
| 333 | ФФ | 255 | Количество байт данных изображения LZW в следующем субблоке: 255 байт. |
| 334 | ... | <данные изображения> | Данные изображения, 255 байт |
| 433 | ФФ | 255 | Количество байт данных изображения LZW в следующем субблоке, 255 байт. |
| 434 | ... | <данные изображения> | Данные изображения, 255 байт |
| ⋮ | Повторите для следующих блоков | ||
| 92C0 | 00 | Конец цепочки субблоков для этого кадра | |
| 92С1 | 21 | '!'
|
Блок расширения (представленный восклицательным знаком ASCII). '!')
|
| 92С2 | F9 | Расширение графического управления для кадра №2 | |
| ⋮ | Повторите для следующих кадров | ||
| ЕДАБД | 21 | '!'
|
Блок расширения (представленный восклицательным знаком ASCII). '!')
|
| НАПИТОК | F9 | Расширение графического управления для кадра № 44 | |
| ⋮ | Информация об изображении и данные для кадра № 44. | ||
| F48F5 | 3Б | Трейлер: последний байт в файле, сигнализирующий об окончании EOF. |
Задержка анимации для каждого кадра указывается в GCE в сотых долях секунды. Некоторая экономия данных возможна, когда кадру нужно перезаписать только часть пикселей дисплея, поскольку дескриптор изображения может определить меньший прямоугольник для повторного сканирования вместо всего изображения. Браузеры или другие дисплеи, не поддерживающие анимированные GIF-файлы, обычно отображают только первый кадр.
Размер и качество цвета анимированных файлов GIF могут существенно различаться в зависимости от приложения, использованного для их создания. Стратегии минимизации размера файла включают использование общей глобальной таблицы цветов для всех кадров (а не полной локальной таблицы цветов для каждого кадра) и минимизацию количества пикселей, охватываемых последовательными кадрами (так что только те пиксели, которые изменяются от одного кадра к другому), следующие включены в последний кадр). Более продвинутые методы включают изменение последовательностей цветов для лучшего соответствия существующему словарю LZW, что является формой сжатия с потерями . Простая упаковка серии независимых изображений кадров в составную анимацию приводит к получению файлов большого размера. Доступны инструменты для минимизации размера файла с учетом существующего GIF.
Метаданные [ править ]
Метаданные могут храниться в файлах GIF в виде блока комментариев, блока обычного текста или блока расширения приложения для конкретного приложения. Некоторые графические редакторы используют неофициальные блоки расширений приложений для включения данных, использованных для создания изображения, чтобы их можно было восстановить для дальнейшего редактирования.
Все эти методы технически требуют, чтобы метаданные были разбиты на подблоки, чтобы приложения могли перемещаться по блоку метаданных, не зная его внутренней структуры.
Стандарт метаданных Extensible Metadata Platform (XMP) представил неофициальный, но теперь широко распространенный блок расширения приложения «XMP Data» для включения данных XMP в файлы GIF. [39] Поскольку данные XMP кодируются с использованием UTF-8 без символов NUL, в данных нет нулевых байтов. Вместо того, чтобы разбивать данные на формальные субблоки, блок расширения завершается «магическим трейлером», который направляет любое приложение, обрабатывающее данные как субблоки, к последнему 0 байту, завершающему цепочку субблоков.
патентов Unisys Защита и LZW
В 1977 и 1978 годах Джейкоб Зив и Авраам Лемпель опубликовали пару статей о новом классе алгоритмов сжатия данных без потерь, которые теперь называются LZ77 и LZ78 . В 1983 году Терри Уэлч разработал быстрый вариант LZ78, получивший название Лемпель-Зив-Велч (LZW). [40] [41]
Уэлч подал заявку на патент на метод LZW в июне 1983 года. Полученный в результате патент US4558302 [42] предоставленный в декабре 1985 года, был передан Sperry Corporation , которая впоследствии объединилась с Burroughs Corporation в 1986 году и образовала Unisys . [40] Дальнейшие патенты были получены в Великобритании, Франции, Германии, Италии, Японии и Канаде.
Помимо вышеупомянутых патентов, патент Уэлча 1983 года также включает ссылки на несколько других патентов, оказавших на него влияние, в том числе:
- два японских патента 1980 года от из NEC , Джуна Канацу [43] [44]
- Патент США 4021782 (1974 г.), выданный Джоном С. Хернингом,
- патент США 4366551 (1977 г.), выданный Клаусом Э. Хольцем, и
- немецкий патент 1981 года от Карла Экхарта Хайнца. [45] [46]
была опубликована статья Уэлча В июне 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]
Альтернативы [ править ]
PNG [ править ]
Портативная сетевая графика (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 стал популярным для отображения коротких видеофайлов в Интернете.
- MNG («Сетевая графика с несколькими изображениями») изначально разрабатывался как решение для анимации на основе PNG. MNG достигла версии 1.0 в 2001 году, но ее поддерживают лишь немногие приложения.
- APNG («Анимированная переносимая сетевая графика») была предложена Mozilla в 2006 году. APNG — это расширение формата PNG в качестве альтернативы формату MNG. По состоянию на 2019 год APNG поддерживается большинством браузеров. [61] APNG предоставляет возможность анимировать файлы PNG, сохраняя при этом обратную совместимость с декодерами, которые не могут понять фрагмент анимации (в отличие от MNG). Старые декодеры просто визуализируют первый кадр анимации.
- Группа PNG официально отклонила APNG как официальное расширение 20 апреля 2007 года. [62]
- В дальнейшем было несколько предложений по созданию простого формата анимированной графики на основе PNG с использованием нескольких различных подходов. [63] Тем не менее, APNG все еще находится в разработке Mozilla и поддерживается в Firefox 3.0. [64] [65] в то время как поддержка MNG была прекращена. [66] [67] APNG в настоящее время поддерживается всеми основными веб-браузерами, включая Chrome (начиная с версии 59.0), Opera, Firefox и Edge.
- Встроенные объекты Adobe Flash и
- Файлы MPEG использовались на некоторых веб-сайтах для отображения простого видео, но требовали использования дополнительного плагина для браузера.
- Другие варианты веб-анимации включают предоставление отдельных кадров с помощью AJAX или
- анимация изображений SVG («Масштабируемая векторная графика») с использованием JavaScript или SMIL («Язык синхронизированной интеграции мультимедиа»). [69]
- С введением широкой поддержки HTML -видео (
<video>) в большинстве веб-браузеров, некоторые веб-сайты используют зацикленную версию тега видео, созданную функциями JavaScript . Это создает вид GIF, но с преимуществами по размеру и скорости сжатого видео.
- Яркими примерами являются Gfycat и Imgur и их метаформат GIFV, который на самом деле представляет собой видеотег, воспроизводящий зацикленное сжатое видео MP4 или WebM . [70]
- HEIF («Высокоэффективный формат файла изображения») — это формат файла изображения, доработанный в 2015 году, в котором используется дискретного косинусного преобразования (DCT) алгоритм сжатия с потерями , основанный на видеоформате HEVC и связанный с форматом изображения JPEG . В отличие от JPEG, HEIF поддерживает анимацию. [71]
- По сравнению с форматом GIF, в котором отсутствует сжатие DCT, HEIF обеспечивает значительно более эффективное сжатие. HEIF хранит больше информации и создает анимированные изображения более высокого качества, размер которых составляет небольшую часть эквивалентного размера GIF. [72]
- VP9 поддерживает только альфа-композицию 4:2:0 с субдискретизацией цветности . [73] что может быть неподходящим для GIF-файлов, сочетающих прозрачность с растровой векторной графикой с мелкими цветовыми деталями.
Использует [ править ]
В апреле 2014 года 4chan добавил поддержку немых видеороликов WebM размером менее 3 МБ и продолжительностью 2 минуты. [74] [75] а в октябре 2014 года Imgur начал конвертировать любые файлы GIF, загруженные на сайт, в видео H.264 и придавать ссылке на HTML-плеер вид реального файла с .gifv расширение. [76] [77]
В январе 2016 года Telegram начал перекодировать все GIF-файлы в видео MPEG-4 , которым «требуется до 95% меньше дискового пространства для того же качества изображения». [78]
См. также [ править ]
- АВИФ
- Cinemagraph — частично анимированная фотография, часто в формате GIF.
- Clear GIF — метод, используемый для проверки доступа к контенту.
- Сравнение форматов графических файлов
- GIF-арт — форма цифрового искусства , связанная с GIF.
- GIFBuilder — ранняя анимированных GIF-файлов . программа создания
- GNUploutils (поддерживает псевдо-GIF, который использует кодирование по длине, а не LZW)
- Microsoft GIF Animator — историческая программа для создания простых анимированных GIF-файлов.
- Патент на программное обеспечение
Ссылки [ править ]
- ↑ Перейти обратно: Перейти обратно: а б с «Формат графического обмена, версия 87a» . W3C . 15 июня 1987 года. Архивировано из оригинала 22 декабря 2018 года . Проверено 13 октября 2012 г.
- ↑ Перейти обратно: Перейти обратно: а б с «Формат графического обмена, версия 89a» . W3C . 31 июля 1990 года. Архивировано из оригинала 22 декабря 2018 года . Проверено 6 марта 2009 г.
- ^ Тиффани, Кейтлин (7 октября 2022 г.). «Гифка находится на смертном одре» . Атлантика . Проверено 21 октября 2023 г.
- ^ «Онлайн-искусство» . Приложения Apple от Compute ! Декабрь 1987. с. 10 . Проверено 14 сентября 2016 г.
- ^ Холденер III, Энтони (2008). Ajax: Полное руководство: Интерактивные приложения для Интернета . О'Рейли Медиа. ISBN 978-0596528386 .
- ^ Фурт, Борко (2008). Энциклопедия мультимедиа Спрингер. ISBN 978-0387747248 .
- ^ МакХью, Молли (29 мая 2015 г.). «Наконец-то вы действительно можете публиковать GIF-изображения на Facebook» . Проводной . Архивировано из оригинала 30 мая 2015 года . Проверено 29 мая 2015 г.
- ^ Перес, Сара (29 мая 2015 г.). «Facebook подтверждает, что будет официально поддерживать GIF» . ТехКранч . Архивировано из оригинала 30 мая 2015 года . Проверено 29 мая 2015 г.
- ^ «Представляем GIF-стикеры» . Инстаграм . 23 января 2018 года. Архивировано из оригинала 12 декабря 2019 года . Проверено 19 сентября 2019 г.
- ^ «Слово года 2012 по версии Оксфордского словаря США» . Блог OxfordWords . Оксфордские американские словари. 13 ноября 2012 года. Архивировано из оригинала 3 августа 2014 года . Проверено 1 мая 2013 г.
- ^ Флуд, Элисон (27 апреля 2013 г.). « Гифка — слово года в Америке? Вот это я называю омнишамблс» . Книжный блог. Хранитель . Лондон. Архивировано из оригинала 1 декабря 2016 года . Проверено 1 мая 2013 г.
- ^ Олсен, Стив. «Страница произношения GIF» . Архивировано из оригинала 25 февраля 2009 года . Проверено 6 марта 2009 г.
- ↑ Перейти обратно: Перейти обратно: а б с «Изобретатель Gif советует игнорировать словари и говорить «Jif» » . Новости Би-би-си . 22 мая 2013 г. Архивировано из оригинала 27 июня 2018 г. . Проверено 22 мая 2013 г.
- ^ Бак, Стефани (21 октября 2014 г.). «70 процентов людей во всем мире произносят GIF с твердой буквой «г » . Машаемый . Архивировано из оригинала 23 декабря 2021 года . Проверено 24 декабря 2021 г.
- ^ ван дер Мейлен, Мартен (22 мая 2019 г.). «Обама, подводное плавание или подарок?: Авторитет и аргументация в онлайн-дискуссии по поводу произношения GIF » . Английский сегодня . 36 (1): 45–50. Архивировано из оригинала 24 мая 2022 года . Проверено 22 мая 2022 г.
- ^ «ГИФ» . Словарь сокращений американского наследия, третье издание . Компания Хоутон Миффлин. 2005. Архивировано из оригинала 3 сентября 2011 года . Проверено 15 апреля 2007 г.
- ^ «ГИФ» . Кембриджский словарь американского английского . Издательство Кембриджского университета. Архивировано из оригинала 27 февраля 2014 года . Проверено 19 февраля 2014 г.
- ^ «Gif — определение из словаря Merriam-Webster» . Словарь Мерриам-Вебстера . Мерриам-Вебстер, Инкорпорейтед. Архивировано из оригинала 22 октября 2013 года . Проверено 6 июня 2013 г.
- ^ «ГИФ» . Оксфордские словари онлайн . Издательство Оксфордского университета. Архивировано из оригинала 12 октября 2014 года . Проверено 7 октября 2014 г.
- ^ «gif существительное — определение, изображения, произношение и примечания по использованию | Оксфордский словарь для продвинутых учащихся» . Оксфордские словари для учащихся . Архивировано из оригинала 24 ноября 2020 года . Проверено 6 февраля 2021 г.
- ^ «GIF | Определение GIF в Оксфордском словаре» . Лексико . Архивировано из оригинала 13 февраля 2021 года . Проверено 6 февраля 2021 г.
- ^ Стивенсон, Ангус, изд. (2010). Оксфордский словарь английского языка (3-е изд.). Издательство Оксфордского университета. ISBN 9780199571123 . OCLC 729551189 . Архивировано из оригинала 23 августа 2022 года . Проверено 6 февраля 2021 г.
- ^ Новый Оксфордский американский словарь (2-е изд.). Издательство Оксфордского университета. 2005. с. 711.
- ^ Новый Оксфордский американский словарь (3-е изд.). 2012 г. (часть встроенных словарей Macintosh).
- ^ О'Лири, Эми (21 мая 2013 г.). «Честь создателю GIF» . Нью-Йорк Таймс . Архивировано из оригинала 22 мая 2013 года . Проверено 22 мая 2013 г.
- ↑ Перейти обратно: Перейти обратно: а б Ротберг, Дэниел (4 декабря 2013 г.). « Jeopardy» вступает в битву за произношение «GIF»» . Лос-Анджелес Таймс . Архивировано из оригинала 6 декабря 2013 года . Проверено 4 декабря 2013 г.
- ^ О'Лири, Эми (23 мая 2013 г.). «Разгорается битва из-за произношения GIF» . Нью-Йорк Таймс . Архивировано из оригинала 16 декабря 2013 года . Проверено 5 декабря 2013 г.
- ^ Валинский, Иордания (25 февраля 2020 г.). «Джиф разрешает великие дебаты с помощью банки арахисового масла GIF» . CNN . Архивировано из оригинала 25 февраля 2020 года . Проверено 25 февраля 2020 г.
- ^ Марур, ДР; Бхаскар, В. (март 2012 г.). «Международная конференция по устройствам, схемам и системам (ICDCS) 2012» . Устройства, схемы и системы (ICDCS) . Международная конференция по устройствам, схемам и системам (ICDCS) . Университет Карунья; Коимбатур, Индия: IEEE. стр. 297–301. дои : 10.1109/ICDCSyst.2012.6188724 . ISBN 9781457715457 . Архивировано из оригинала 2 июля 2017 года . Проверено 11 марта 2015 г.
- ^ С. Чин; Д. Айверсон; О. Кампесато; П. Трани (2011). Про Android Flash (PDF ) Нью-Йорк: Апресс. п. 350. ИСБН 9781430232315 . Архивировано (PDF) из оригинала 2 апреля 2015 г. Проверено 11 марта 2015 г.
- ^ Бахши, Сайде; Шамма, Дэвид А.; Кеннеди, Линдон; Сонг, Йельский университет; де Хуан, Палома; Кэй, Джозеф «Джофиш» (7 мая 2016 г.). «Быстро, дешево и хорошо: почему нас привлекают анимированные GIF-файлы» . Материалы конференции CHI 2016 г. по человеческому фактору в вычислительных системах . стр. 575–586. дои : 10.1145/2858036.2858532 . ISBN 9781450333627 . S2CID 7417853 . Проверено 17 августа 2022 г.
- ^ Хайфилд, Тим; Ливер, Тама (2016). «Инстаграмматика и цифровые методы: изучаем визуальные социальные сети, от селфи и гифок до мемов и эмодзи» . Коммуникационные исследования и практика . 2 (1): 47–62. дои : 10.1080/22041451.2016.1155332 . hdl : 20.500.11937/36939 . S2CID 148538216 . Проверено 17 августа 2022 г.
- ↑ Перейти обратно: Перейти обратно: а б с Андреас Кляйнерт (2007). «Расширения GIF 24 бит (truecolor)» . Архивировано из оригинала 16 марта 2012 года . Проверено 23 марта 2012 г.
- ↑ Перейти обратно: Перейти обратно: а б Филип Ховард. «Пример GIF-изображения в полноцветном формате» . Архивировано из оригинала 22 февраля 2015 года . Проверено 23 марта 2012 г.
- ^ «Nullsleep — Джеремайя Джонсон — Исследование совместимости браузера с анимированным GIF-изображением с минимальной задержкой кадра» . Архивировано из оригинала 10 октября 2014 года . Проверено 26 мая 2015 г.
- ^ «Они разные! Как согласовать скорость анимации GIF-файлов в [ sic ] браузерах» . Блог разработчика . 14 февраля 2012 года. Архивировано из оригинала 1 февраля 2017 года . Проверено 15 июня 2017 г.
- ^ Роял Фрейзер. «Все о GIF89a» . Архивировано из оригинала 18 апреля 1999 года . Проверено 7 января 2013 г.
- ^ Скотт Уолтер (1996). Секретное оружие веб-сценариев . Издательство Que . ISBN 0-7897-0947-3 .
- ^ «Спецификация XMP, часть 3: Хранение в файлах» (PDF) . Adobe. 2016. С. 11–12. Архивировано (PDF) из оригинала 25 февраля 2018 года . Проверено 16 августа 2018 г.
- ↑ Перейти обратно: Перейти обратно: а б с д и ж г Грег Рулофс. «История формата переносимой сетевой графики (PNG)» . Архивировано из оригинала 7 марта 2012 года . Проверено 23 марта 2012 г.
- ↑ Перейти обратно: Перейти обратно: а б с Стюарт Кэй. «Печальный день… Патент на GIF умер в 20 лет» . Архивировано из оригинала 10 февраля 2012 года . Проверено 23 марта 2012 г.
- ^ US 4558302 , Welch, Terry A. , опубликован 10 декабря 1985 г., передан Sperry Corp.
- ^ Патент JP S5719857A , Канацу, Джиюнь, «Устройство хранения данных со сжатием данных», опубликован 2 февраля 1982 г., передан Nippon Electric Corp.
- ^ Патент JP S57101937A , Канацу, Джиюнь, «Устройство хранения данных», опубликован 24 декабря 1986 г., передан Nippon Electric Corp.
- ^ Патент DE 3118676 , Экхарт, Хайнц Карл, «Метод сжатия избыточных последовательностей последовательных элементов данных]», опубликован 2 декабря 1982 г.
- ^ Патент США 4 558 302.
- ↑ Перейти обратно: Перейти обратно: а б «Спор о GIF: взгляд разработчика программного обеспечения» . 27 января 1995 года. Архивировано из оригинала 23 августа 2016 года . Проверено 26 мая 2015 г.
- ↑ Перейти обратно: Перейти обратно: а б «Unisys разъясняет политику использования патентов в онлайн-сервисах» . Архивировано из оригинала 7 февраля 2007 г. - заархивировано Лигой свободы программирования.
- ^ «Либунгиф» . Архивировано из оригинала 13 апреля 2015 года . Проверено 26 мая 2015 г.
- ^ Каргилл, Том (1 октября 2001 г.). «Замена словаря квадратным корнем» . Журнал доктора Добба . Архивировано из оригинала 28 июня 2017 года . Проверено 20 января 2017 г.
- ^ «Программное обеспечение LZW и патентная информация» . Архивировано из оригинала 8 июня 2009 года . Проверено 31 января 2007 г. – разъяснение от 2 сентября 1999 г.
- ^ Unisys не подает в суд на (большинство) веб-мастеров за использование GIF-файлов. Архивировано 10 мая 2017 г. на Wayback Machine - расследование Slashdot противоречия.
- ^ «День сожжения всех GIF-файлов» . Архивировано из оригинала 13 октября 1999 года.
- ^ Записать все GIF-файлы. Архивировано 3 февраля 2007 г. в Wayback Machine - проект Лиги свободы программирования (последняя версия).
- ↑ Перейти обратно: Перейти обратно: а б с «Информация о лицензии на GIF и другие технологии на основе LZW» . Архивировано из оригинала 2 июня 2009 года . Проверено 26 апреля 2005 г.
- ^ «Почему на веб-страницах GNU нет файлов GIF» . Фонд свободного программного обеспечения. Архивировано из оригинала 19 мая 2012 года . Проверено 19 мая 2012 г.
- ^ «Сжатие PNG и GIF» . 31 марта 2007 г. Архивировано из оригинала 15 июля 2009 г. Проверено 8 июня 2009 г.
- ^ «Фильтр AlphaImageLoader» . Майкрософт. 4 сентября 2012 года. Архивировано из оригинала 3 октября 2014 года . Проверено 26 мая 2015 г.
- ^ «Что нового в Internet Explorer 7» . MSDN . Архивировано из оригинала 1 марта 2009 года . Проверено 6 марта 2009 г.
- ^ «Формат файла изображения PNG» . Архивировано из оригинала 14 июня 2009 года . Проверено 8 июня 2009 г.
- ^ «Могу ли я использовать... Таблицы поддержки HTML5, CSS3 и т. д.» . caniuse.com . Архивировано из оригинала 19 февраля 2018 года . Проверено 10 апреля 2020 г.
- ^ «ГОЛОСОВАНИЕ НЕ ПРОЙДЕНО: APNG 20070405a» . SourceForge Список рассылки . 20 апреля 2007 г. Архивировано из оригинала 13 февраля 2013 г. . Проверено 14 июля 2013 г.
- ^ «Обсуждение простого «анимированного» формата PNG» . Архивировано из оригинала 26 февраля 2009 года . Проверено 12 июля 2011 г.
- ^ «Спецификация APNG» . Архивировано из оригинала 5 июля 2010 года . Проверено 26 мая 2015 г.
- ^ «Лаборатория Mozilla » Архив блога » Улучшенная анимация в Firefox 3» . 13 августа 2007 года. Архивировано из оригинала 7 марта 2016 года . Проверено 3 февраля 2016 г.
- ^ «195280 – Удаление поддержки MNG/JNG» . Архивировано из оригинала 25 февраля 2021 года . Проверено 26 мая 2015 г.
- ^ «18574 – (mng) восстановить поддержку формата анимации MNG и формата изображений JNG» . Архивировано из оригинала 17 марта 2021 года . Проверено 26 мая 2015 г.
- ^ «Блог Chromium: Chrome 32 Beta: анимированные изображения WebP и более быстрый сенсорный ввод Chrome для Android» . Блог.chromium.org. 21 ноября 2013 г. Архивировано из оригинала 17 июля 2018 г. Проверено 1 февраля 2014 г.
- ^ Калу, Хуан. «SVG-анимация — руководство» . Топталь . Проверено 15 марта 2024 г.
- ^ «Представляем GIFV — блог Imgur» . imgur.com. 9 октября 2014 года. Архивировано из оригинала 14 декабря 2014 года . Проверено 14 декабря 2014 г.
- ^ Томсон, Гэвин; Шах, Атар (2017). «Представляем HEIF и HEVC» (PDF) . Apple Inc. Архивировано (PDF) из оригинала 19 января 2020 г. . Проверено 5 августа 2019 г.
- ^ «Сравнение HEIF — высокоэффективный формат файла изображения» . Нокиа Технологии . Архивировано из оригинала 25 июля 2019 года . Проверено 5 августа 2019 г.
- ^ «#3271 (Разрешить использование дополнительных форматов пикселей с помощью libvpx-vp9) – FFmpeg» . trac.ffmpeg.org . Архивировано из оригинала 16 июня 2020 года . Проверено 10 апреля 2020 г.
- ^ Дьюи, Кейтлин. «Познакомьтесь с технологией, которая может сделать GIF-файлы устаревшими» . Вашингтон Пост . Архивировано из оригинала 11 мая 2015 года . Проверено 4 февраля 2015 г.
- ^ «Поддержка WebM на 4chan» . Блог 4chan . Архивировано из оригинала 6 апреля 2014 года . Проверено 4 февраля 2015 г.
- ^ «Представляем GIFV» . Имгур. 9 августа 2014 г. Архивировано из оригинала 5 мая 2020 г. . Проверено 21 июля 2016 г.
- ^ Аллан, Патрик (9 октября 2014 г.). «Imgur обновляет GIF-файлы для повышения скорости и качества с помощью GIFV» . Лайфхакер . Архивировано из оригинала 3 февраля 2015 года . Проверено 4 февраля 2015 г.
- ^ «ГИФ-революция» . Официальный блог Telegram . 4 января 2016 г. Архивировано из оригинала 10 января 2016 г. . Проверено 4 января 2016 г.
Внешние ссылки [ править ]
- Проект GIFLIB
- spec-gif89a.txt Спецификация GIF 89a на w3.org
- Спецификация GIF 89a переформатирована в HTML
- Объяснение LZW и GIF
- Анимированные GIF-файлы : шестиминутный документальный фильм, созданный Off Book (веб-сериал).
- GifCities (поисковая система анимированных GIF-изображений GeoCities)
