✖


Jump to content

гифка

(Перенаправлено с GIF )
Чтобы узнать о других значениях, см. GIF (значения) .

гифка
Анимированный GIF глобуса вращающегося
Расширение имени файла
.gif
Тип интернет-СМИ
image/gif
Введите код GIFf
Единый идентификатор типа (UTI) com.compuserve.gif
Магическое число GIF87a/ GIF89a
Разработано КомпуСерв
Первоначальный выпуск 15 июня 1987 г .; 37 лет назад ( 15.06.1987 ) [1]
Последний выпуск
89а
1989 год ; 35 лет назад ( 1989 ) [2]
Тип формата изображения без потерь растрового формат
Веб-сайт www .w3 .org /Графика /ГИФ /spec-gif89a .текст

Формат обмена графикой ( GIF ; / ɡ ɪ f / GHIF или / dʒ ɪ f / JIF , см. § Произношение ) — формат растрового изображения , разработанный командой поставщика онлайн-услуг CompuServe под руководством американского ученого-компьютерщика Стива Уилхайта и выпущенный 15 июня 1987 года. [1]

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

Изображения GIF сжимаются с использованием Лемпеля-Зива-Велча (LZW), метода сжатия данных без потерь чтобы уменьшить размер файла без ухудшения визуального качества.

Несмотря на то, что этот формат когда-то широко использовался во Всемирной паутине из-за его широкой реализации и переносимости между приложениями и операционными системами, его использование сократилось по причинам, связанным с пространством и качеством, и его часто заменяют видеоформатами, такими как формат файла MP4 . Эти замены, в свою очередь, часто называют «GIF», несмотря на то, что они не имеют никакого отношения к исходному формату файла. [3]

История

[ редактировать ]
Дополнительная информация: § Защита патентов Unisys и LZW.

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
Юмористическое изображение, объявляющее о запуске в Tumblr аккаунта Белого дома , предполагает произнесение GIF с твердой буквой g .

Произношение первой буквы 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, сохраненного с использованием безопасной для Интернета палитры и подвергнутого сглаживанию с использованием метода Флойда-Стейнберга ; изображения из-за относительно небольшого количества цветов, разрешенных в таком изображении, контрастность и красочность заметно плохие.

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-файл, иллюстрирующий способ отображения цветов, превышающих типичный лимит в 256 цветов.

Чтобы визуализировать полноцветное изображение в формате 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 в высоту.

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

Таблица примеров значений изображений GIF
Байт № (шестнадцатеричный) Шестнадцатеричный Текст или значение Значение
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 0 0
Глобальная таблица цветов, цвет № 0: #000000, черный
Байты от D h до 30C h в этом примере определяют палитру из 256 цветов. Индексы, используемые в образце изображения для черно-белого изображения, — 28 h и FF h .
10 80 00 00
Р (красный) Г (зеленый) Б (синий)
128 0 0
Глобальная таблица цветов, цвет №1: прозрачный бит, не используется в изображении.
... ... ... Глобальная таблица цветов расширяется до 30 А
30А ФФ ФФ ФФ
Р (красный) Г (зеленый) Б (синий)
255 255 255
Глобальная таблица цветов, цвет № 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-файл размером 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.

Пример сжатия файла GIF
Код Пиксели Примечания
Нет.
Н я 		Ценить
Н я + 256 		Длина
(биты) 		Этот код
Н я 		Накоплено
⁠ N я (N я + 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 позволяет каждому изображению на логическом экране файла GIF указывать, что оно чересстрочное; т.е. порядок строк растра в блоке данных не является последовательным. Это позволяет частично отобразить изображение, которое можно распознать до того, как будет нарисовано полное изображение.

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

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

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

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

[ редактировать ]
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, показанного (в виде миниатюры) в информационном окне статьи.

Структура 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 года также включает ссылки на несколько других патентов, оказавших на него влияние, в том числе:

была опубликована статья Уэлча В июне 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 использовались на некоторых веб-сайтах для отображения простого видео, но требовали использования дополнительного плагина для браузера.
  • WebM и WebP находятся в разработке и поддерживаются некоторыми веб-браузерами. [68]
  • Другие варианты веб-анимации включают предоставление отдельных кадров с использованием AJAX или анимацию изображений SVG («Масштабируемая векторная графика») с использованием JavaScript или SMIL («Язык синхронизированной интеграции мультимедиа»). [69]
  • С введением широкой поддержки HTML -видео ( <video>) в большинстве веб-браузеров, некоторые веб-сайты используют зацикленную версию тега видео, созданную функциями JavaScript . Это создает вид GIF, но с преимуществами по размеру и скорости сжатого видео.
Яркими примерами являются Gfycat и Imgur и их метаформат GIFV, который на самом деле представляет собой видеотег, воспроизводящий зацикленное сжатое видео MP4 или WebM . [70]
По сравнению с форматом GIF, в котором отсутствует сжатие DCT, HEIF обеспечивает значительно более эффективное сжатие. HEIF хранит больше информации и создает анимированные изображения более высокого качества, размер которых составляет небольшую часть эквивалентного размера GIF. [72]
  • AV1 Видеокодек или AVIF также можно использовать как видео, так и секвенсированное изображение.

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

[ редактировать ]

В апреле 2014 года 4chan добавил поддержку немых видеороликов WebM размером менее 3 МБ и продолжительностью 2 минуты. [74] [75] а в октябре 2014 года Imgur начал конвертировать любые файлы GIF, загруженные на сайт, в видео H.264 и придавать ссылке на HTML-плеер вид реального файла с .gifv расширение. [76] [77]

В январе 2016 года Telegram начал перекодировать все GIF-файлы в видео MPEG-4 , которым «требуется до 95% меньше дискового пространства для того же качества изображения». [78]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Jump up to: а б с «Формат графического обмена, версия 87a» . W3C . 15 июня 1987 года. Архивировано из оригинала 22 декабря 2018 года . Проверено 13 октября 2012 г.
  2. ^ Jump up to: а б с «Формат графического обмена, версия 89a» . W3C . 31 июля 1990 года. Архивировано из оригинала 22 декабря 2018 года . Проверено 6 марта 2009 г.
  3. ^ Тиффани, Кейтлин (7 октября 2022 г.). «Гифка находится на смертном одре» . Атлантика . Проверено 21 октября 2023 г.
  4. ^ «Онлайн-искусство» . Приложения Apple от Compute ! Декабрь 1987. с. 10 . Проверено 14 сентября 2016 г.
  5. ^ Холденер III, Энтони (2008). Ajax: Полное руководство: Интерактивные приложения для Интернета . О'Рейли Медиа. ISBN  978-0596528386 .
  6. ^ Фурт, Борко (2008). Энциклопедия мультимедиа Спрингер. ISBN  978-0387747248 .
  7. ^ МакХью, Молли (29 мая 2015 г.). «Наконец-то вы действительно можете публиковать GIF-изображения на Facebook» . Проводной . Архивировано из оригинала 30 мая 2015 года . Проверено 29 мая 2015 г.
  8. ^ Перес, Сара (29 мая 2015 г.). «Facebook подтверждает, что будет официально поддерживать GIF» . ТехКранч . Архивировано из оригинала 30 мая 2015 года . Проверено 29 мая 2015 г.
  9. ^ «Представляем GIF-стикеры» . Инстаграм . 23 января 2018 года. Архивировано из оригинала 12 декабря 2019 года . Проверено 19 сентября 2019 г.
  10. ^ «Слово года 2012 по версии Оксфордского словаря США» . Блог OxfordWords . Оксфордские американские словари. 13 ноября 2012 года. Архивировано из оригинала 3 августа 2014 года . Проверено 1 мая 2013 г.
  11. ^ Флуд, Элисон (27 апреля 2013 г.). « Гифка — слово года в Америке? Вот это я называю омнишамблс» . Книжный блог. Хранитель . Лондон. Архивировано из оригинала 1 декабря 2016 года . Проверено 1 мая 2013 г.
  12. ^ Олсен, Стив. «Страница произношения GIF» . Архивировано из оригинала 25 февраля 2009 года . Проверено 6 марта 2009 г.
  13. ^ Jump up to: а б с «Изобретатель Gif советует игнорировать словари и говорить «Jif» » . Новости Би-би-си . 22 мая 2013 г. Архивировано из оригинала 27 июня 2018 г. . Проверено 22 мая 2013 г.
  14. ^ Бак, Стефани (21 октября 2014 г.). «70 процентов людей во всем мире произносят GIF с твердой буквой «г » . Машаемый . Архивировано из оригинала 23 декабря 2021 года . Проверено 24 декабря 2021 г.
  15. ^ ван дер Мейлен, Мартен (22 мая 2019 г.). «Обама, подводное плавание или подарок?: Авторитет и аргументация в онлайн-дискуссии по поводу произношения GIF » . Английский сегодня . 36 (1): 45–50. Архивировано из оригинала 24 мая 2022 года . Проверено 22 мая 2022 г.
  16. ^ «ГИФ» . Словарь сокращений американского наследия, третье издание . Компания Хоутон Миффлин. 2005. Архивировано из оригинала 3 сентября 2011 года . Проверено 15 апреля 2007 г.
  17. ^ «ГИФ» . Кембриджский словарь американского английского . Издательство Кембриджского университета. Архивировано из оригинала 27 февраля 2014 года . Проверено 19 февраля 2014 г.
  18. ^ «Gif — определение из словаря Merriam-Webster» . Словарь Мерриам-Вебстера . Мерриам-Вебстер, Инкорпорейтед. Архивировано из оригинала 22 октября 2013 года . Проверено 6 июня 2013 г.
  19. ^ «ГИФ» . Оксфордские словари онлайн . Издательство Оксфордского университета. Архивировано из оригинала 12 октября 2014 года . Проверено 7 октября 2014 г.
  20. ^ «gif существительное — определение, изображения, произношение и примечания по использованию | Оксфордский словарь для продвинутых учащихся» . Оксфордские словари для учащихся . Архивировано из оригинала 24 ноября 2020 года . Проверено 6 февраля 2021 г.
  21. ^ «GIF | Определение GIF в Оксфордском словаре» . Лексико . Архивировано из оригинала 13 февраля 2021 года . Проверено 6 февраля 2021 г.
  22. ^ Стивенсон, Ангус, изд. (2010). Оксфордский словарь английского языка (3-е изд.). Издательство Оксфордского университета. ISBN  9780199571123 . OCLC   729551189 . Архивировано из оригинала 23 августа 2022 года . Проверено 6 февраля 2021 г.
  23. ^ Новый Оксфордский американский словарь (2-е изд.). Издательство Оксфордского университета. 2005. с. 711.
  24. ^ Новый Оксфордский американский словарь (3-е изд.). 2012 г. (часть встроенных словарей Macintosh).
  25. ^ О'Лири, Эми (21 мая 2013 г.). «Честь создателю GIF» . Нью-Йорк Таймс . Архивировано из оригинала 22 мая 2013 года . Проверено 22 мая 2013 г.
  26. ^ Jump up to: а б Ротберг, Дэниел (4 декабря 2013 г.). « Jeopardy» вступает в битву за произношение «GIF»» . Лос-Анджелес Таймс . Архивировано из оригинала 6 декабря 2013 года . Проверено 4 декабря 2013 г.
  27. ^ О'Лири, Эми (23 мая 2013 г.). «Разгорается битва из-за произношения GIF» . Нью-Йорк Таймс . Архивировано из оригинала 16 декабря 2013 года . Проверено 5 декабря 2013 г.
  28. ^ Валинский, Иордания (25 февраля 2020 г.). «Джиф разрешает великие дебаты с помощью банки арахисового масла GIF» . CNN . Архивировано из оригинала 25 февраля 2020 года . Проверено 25 февраля 2020 г.
  29. ^ Марур, ДР; Бхаскар, В. (март 2012 г.). «Международная конференция по устройствам, схемам и системам (ICDCS) 2012» . Устройства, схемы и системы (ICDCS) . Международная конференция по устройствам, схемам и системам (ICDCS) . Университет Карунья; Коимбатур, Индия: IEEE. стр. 297–301. дои : 10.1109/ICDCSyst.2012.6188724 . ISBN  9781457715457 . Архивировано из оригинала 2 июля 2017 года . Проверено 11 марта 2015 г.
  30. ^ С. Чин; Д. Айверсон; О. Кампесато; П. Трани (2011). Про Android Flash (PDF ) Нью-Йорк: Апресс. п. 350. ИСБН  9781430232315 . Архивировано (PDF) из оригинала 2 апреля 2015 г. Проверено 11 марта 2015 г.
  31. ^ Бахши, Сайде; Шамма, Дэвид А.; Кеннеди, Линдон; Сонг, Йельский университет; де Хуан, Палома; Кэй, Джозеф «Джофиш» (7 мая 2016 г.). «Быстро, дешево и хорошо: почему нас привлекают анимированные GIF-файлы» . Материалы конференции CHI 2016 г. по человеческому фактору в вычислительных системах . стр. 575–586. дои : 10.1145/2858036.2858532 . ISBN  9781450333627 . S2CID   7417853 . Проверено 17 августа 2022 г.
  32. ^ Хайфилд, Тим; Ливер, Тама (2016). «Инстаграмматика и цифровые методы: изучаем визуальные социальные сети, от селфи и гифок до мемов и эмодзи» . Коммуникационные исследования и практика . 2 (1): 47–62. дои : 10.1080/22041451.2016.1155332 . hdl : 20.500.11937/36939 . S2CID   148538216 . Проверено 17 августа 2022 г.
  33. ^ Jump up to: а б с Андреас Кляйнерт (2007). «Расширения GIF 24 бит (truecolor)» . Архивировано из оригинала 16 марта 2012 года . Проверено 23 марта 2012 г.
  34. ^ Jump up to: а б Филип Ховард. «Пример GIF-изображения в полноцветном формате» . Архивировано из оригинала 22 февраля 2015 года . Проверено 23 марта 2012 г.
  35. ^ «Nullsleep — Джеремайя Джонсон — Исследование совместимости браузера с анимированным GIF-изображением с минимальной задержкой кадра» . Архивировано из оригинала 10 октября 2014 года . Проверено 26 мая 2015 г.
  36. ^ «Они разные! Как согласовать скорость анимации GIF-файлов в [ sic ] браузерах» . Блог разработчика . 14 февраля 2012 года. Архивировано из оригинала 1 февраля 2017 года . Проверено 15 июня 2017 г.
  37. ^ Роял Фрейзер. «Все о GIF89a» . Архивировано из оригинала 18 апреля 1999 года . Проверено 7 января 2013 г.
  38. ^ Скотт Уолтер (1996). Секретное оружие веб-сценариев . Издательство Que . ISBN  0-7897-0947-3 .
  39. ^ «Спецификация XMP, часть 3: Хранение в файлах» (PDF) . Adobe. 2016. С. 11–12. Архивировано (PDF) из оригинала 25 февраля 2018 года . Проверено 16 августа 2018 г.
  40. ^ Jump up to: а б с д и ж г Грег Рулофс. «История формата переносимой сетевой графики (PNG)» . Архивировано из оригинала 7 марта 2012 года . Проверено 23 марта 2012 г.
  41. ^ Jump up to: а б с Стюарт Кэй. «Печальный день… Патент на GIF умер в 20 лет» . Архивировано из оригинала 10 февраля 2012 года . Проверено 23 марта 2012 г.
  42. ^ US 4558302 , Welch, Terry A. , опубликован 10 декабря 1985 г., передан Sperry Corp.  
  43. ^ Патент JP S5719857A , Канацу, Джиюнь, «Устройство хранения данных со сжатием данных», опубликован 2 февраля 1982 г., передан Nippon Electric Corp.  
  44. ^ Патент JP S57101937A , Канацу, Джиюнь, «Устройство хранения данных», опубликован 24 декабря 1986 г., передан Nippon Electric Corp.  
  45. ^ Патент DE 3118676 , Экхарт, Хайнц Карл, «Метод сжатия избыточных последовательностей последовательных элементов данных]», опубликован 2 декабря 1982 г.  
  46. ^ Патент США 4 558 302.
  47. ^ Jump up to: а б «Спор о GIF: взгляд разработчика программного обеспечения» . 27 января 1995 года. Архивировано из оригинала 23 августа 2016 года . Проверено 26 мая 2015 г.
  48. ^ Jump up to: а б «Unisys разъясняет политику использования патентов в онлайн-сервисах» . Архивировано из оригинала 7 февраля 2007 г. - заархивировано Лигой свободы программирования.
  49. ^ «Либунгиф» . Архивировано из оригинала 13 апреля 2015 года . Проверено 26 мая 2015 г.
  50. ^ Каргилл, Том (1 октября 2001 г.). «Замена словаря квадратным корнем» . Журнал доктора Добба . Архивировано из оригинала 28 июня 2017 года . Проверено 20 января 2017 г.
  51. ^ «Программное обеспечение LZW и патентная информация» . Архивировано из оригинала 8 июня 2009 года . Проверено 31 января 2007 г. – разъяснение от 2 сентября 1999 г.
  52. ^ Unisys не подает в суд на (большинство) веб-мастеров за использование GIF-файлов. Архивировано 10 мая 2017 г. на Wayback Machine - расследование Slashdot противоречия.
  53. ^ «День сожжения всех GIF-файлов» . Архивировано из оригинала 13 октября 1999 года.
  54. ^ Записать все GIF-файлы. Архивировано 3 февраля 2007 г. в Wayback Machine - проект Лиги свободы программирования (последняя версия).
  55. ^ Jump up to: а б с «Информация о лицензии на GIF и другие технологии на основе LZW» . Архивировано из оригинала 2 июня 2009 года . Проверено 26 апреля 2005 г.
  56. ^ «Почему на веб-страницах GNU нет файлов GIF» . Фонд свободного программного обеспечения. Архивировано из оригинала 19 мая 2012 года . Проверено 19 мая 2012 г.
  57. ^ «Сжатие PNG и GIF» . 31 марта 2007 г. Архивировано из оригинала 15 июля 2009 г. Проверено 8 июня 2009 г.
  58. ^ «Фильтр AlphaImageLoader» . Майкрософт. 4 сентября 2012 года. Архивировано из оригинала 3 октября 2014 года . Проверено 26 мая 2015 г.
  59. ^ «Что нового в Internet Explorer 7» . MSDN . Архивировано из оригинала 1 марта 2009 года . Проверено 6 марта 2009 г.
  60. ^ «Формат файла изображения PNG» . Архивировано из оригинала 14 июня 2009 года . Проверено 8 июня 2009 г.
  61. ^ «Могу ли я использовать... Таблицы поддержки HTML5, CSS3 и т. д.» . caniuse.com . Архивировано из оригинала 19 февраля 2018 года . Проверено 10 апреля 2020 г.
  62. ^ «ГОЛОСОВАНИЕ НЕ ПРОЙДЕНО: APNG 20070405a» . SourceForge Список рассылки . 20 апреля 2007 г. Архивировано из оригинала 13 февраля 2013 г. . Проверено 14 июля 2013 г.
  63. ^ «Обсуждение простого «анимированного» формата PNG» . Архивировано из оригинала 26 февраля 2009 года . Проверено 12 июля 2011 г.
  64. ^ «Спецификация APNG» . Архивировано из оригинала 5 июля 2010 года . Проверено 26 мая 2015 г.
  65. ^ «Лаборатория Mozilla » Архив блога » Улучшенная анимация в Firefox 3» . 13 августа 2007 года. Архивировано из оригинала 7 марта 2016 года . Проверено 3 февраля 2016 г.
  66. ^ «195280 – Удаление поддержки MNG/JNG» . Архивировано из оригинала 25 февраля 2021 года . Проверено 26 мая 2015 г.
  67. ^ «18574 – (mng) восстановить поддержку формата анимации MNG и формата изображений JNG» . Архивировано из оригинала 17 марта 2021 года . Проверено 26 мая 2015 г.
  68. ^ «Блог Chromium: Chrome 32 Beta: анимированные изображения WebP и более быстрый сенсорный ввод Chrome для Android» . Блог.chromium.org. 21 ноября 2013 г. Архивировано из оригинала 17 июля 2018 г. . Проверено 1 февраля 2014 г.
  69. ^ Калу, Хуан. «SVG-анимация — руководство» . Топталь . Проверено 15 марта 2024 г.
  70. ^ «Представляем GIFV — блог Imgur» . imgur.com. 9 октября 2014 года. Архивировано из оригинала 14 декабря 2014 года . Проверено 14 декабря 2014 г.
  71. ^ Томсон, Гэвин; Шах, Атар (2017). «Представляем HEIF и HEVC» (PDF) . Apple Inc. Архивировано (PDF) из оригинала 19 января 2020 г. . Проверено 5 августа 2019 г.
  72. ^ «Сравнение HEIF — высокоэффективный формат файла изображения» . Нокиа Технологии . Архивировано из оригинала 25 июля 2019 года . Проверено 5 августа 2019 г.
  73. ^ «#3271 (Разрешить использование дополнительных форматов пикселей с помощью libvpx-vp9) – FFmpeg» . trac.ffmpeg.org . Архивировано из оригинала 16 июня 2020 года . Проверено 10 апреля 2020 г.
  74. ^ Дьюи, Кейтлин. «Познакомьтесь с технологией, которая может сделать GIF-файлы устаревшими» . Вашингтон Пост . Архивировано из оригинала 11 мая 2015 года . Проверено 4 февраля 2015 г.
  75. ^ «Поддержка WebM на 4chan» . Блог 4chan . Архивировано из оригинала 6 апреля 2014 года . Проверено 4 февраля 2015 г.
  76. ^ «Представляем GIFV» . Имгур. 9 августа 2014 г. Архивировано из оригинала 5 мая 2020 г. . Проверено 21 июля 2016 г.
  77. ^ Аллан, Патрик (9 октября 2014 г.). «Imgur обновляет GIF-файлы для повышения скорости и качества с помощью GIFV» . Лайфхакер . Архивировано из оригинала 3 февраля 2015 года . Проверено 4 февраля 2015 г.
  78. ^ «ГИФ-революция» . Официальный блог Telegram . 4 января 2016 г. Архивировано из оригинала 10 января 2016 г. . Проверено 4 января 2016 г.
[ редактировать ]
Викискладе есть медиафайлы, связанные с форматом файлов GIF .
Retrieved from "https://en.wikipedia.org/w/index.php?title=GIF&oldid=1237709364"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 78f57a9763f75afc99eaca1173ec99fc__1722386460
URL1:https://arc.ask3.ru/arc/aa/78/fc/78f57a9763f75afc99eaca1173ec99fc.html
Заголовок, (Title) документа по адресу, URL1:
GIF - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)