Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Для использования в других целях, см GIF (значения) .

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

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

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

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

История [ править ]

Дополнительная информация: Защита патентов Unisys и LZW

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

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

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

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

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

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

В мае 2015 года Facebook добавил поддержку GIF. [6] [7] В январе 2018 года Instagram также добавил стикеры в формате GIF в режим истории. [8]

Терминология [ править ]

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

Произношение GIF [ править ]

См. Также: Hard and soft g и Описание и рецепт.
Юмористическое изображение, объявляющее о запуске Tumblr в Белом доме, предлагает произносить GIF с жесткой буквой «G».

Создатели формата произносили слово как «jif» с мягким «G» / dʒ ɪ f /, как в «спортзал». Стив Уилхайт говорит, что предполагаемое произношение намеренно перекликается с американским брендом арахисового масла Jif , а сотрудники CompuServe часто говорили: «Разборчивые разработчики выбирают GIF», подделывая телевизионные рекламные ролики этого бренда. [11] Слово теперь также широко произносится с твердым «G» / ɡ ɪ f / как в «подарок». [12] В 2017 г. был проведен неофициальный опрос на веб-сайте программирования. Stack Overflow.продемонстрировали некоторое численное предпочтение жесткому произношению «G» [13], особенно среди респондентов в Восточной Европе, хотя как мягкое «G», так и индивидуальное произнесение каждой буквы оказались популярными в Азии и развивающихся странах. [14]

American Heritage Dictionary [15] цитирует и, указывая на «камеру jПри» в качестве основного произношения, а Кембриджский словарь американского английского языка [16] предлагает только жесткосферическое «G» произношение. Словарь Merriam-Webster [17] и Оксфордские словари цитируют оба произношения, но помещают «gif» в позицию по умолчанию: / gɪf, dʒɪf / . [18] [19] [20] [21] New Oxford American Dictionary дал только "камеры jПри" в своем 2 - м издании [22] , но обновил его "мкф, GIF" в 3 - м издании. [23]

Разногласия по поводу произношения привели к горячим спорам в Интернете. По случаю получения награды за пожизненные достижения на церемонии вручения премии Webby в 2013 году Уилхайт отказался от твердого произношения «G» [12] [24] [25], и его речь привела к 17 000 постов в Твиттере и 50 новостным статьям. [26] Белый дом [12] и телепрограмма Jeopardy! также участвовал в дебатах в 2013 году. [25]

В феврале 2020 года JM Смакер компания , владельцы арахисового масла марки мкфа, в партнерстве с анимационной базой данных изображений и поисковая Giphy выпустить ограниченный тираж «Jif против GIF» ( hashtagged в #JIFvsGIF) банка из Jif арахисового масла на этикетке с юмором объявляется, что мягкое произношение «G» относится исключительно к арахисовому маслу, а GIF - произносится исключительно с жестким произношением «G». [27]

Использование [ править ]

  • GIF-файлы подходят для штриховых рисунков с острыми краями и ограниченного количества цветов, например логотипов. Это позволяет использовать сжатие формата без потерь, которое позволяет использовать плоские области однородного цвета с четко очерченными краями. [28]
  • GIF-файлы можно использовать для хранения данных спрайтов с низким содержанием цвета для игр. [29]
  • GIF-файлы можно использовать для небольших анимаций и видеоклипов с низким разрешением. [29]
  • GIF-файлы можно использовать в качестве реакции при обмене сообщениями в Интернете, использовать для передачи эмоций и чувств вместо использования слов.
  • Популярно в социальных сетях, таких как Tumblr, Facebook и Twitter.

Формат файла [ править ]

Файл: Empty.gif в шестнадцатеричном редакторе

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

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

00000000  47  49  46  38  39  61  01  00  01  00  80  00  00  00  00  00  | GIF89a .......... | 00000010  ff  ff  ff  21  f9  04  01  00  00  00  00  2c  00  00  00  00  | ...! ......., .... | 00000020  01  00  01  00  00  02  01  44  00  3b  | ....... D .; |

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

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

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

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

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

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

Полная информация о формате файла описана в спецификации GIF. [2]

Палитры [ править ]

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

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

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

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

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

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

Истинный цвет [ править ]

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

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

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

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

Пример файла GIF [ править ]

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

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

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

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

Таблица с примерами значений изображений GIF
Байт # (шестнадцатеричный)ШестнадцатеричныйТекст или значениеСмысл
047 49 46 38 39 61GIF89aЗаголовок
603 003Логическая ширина экрана
805 005Логическая высота экрана
АF7GCT следует для 256 цветов с разрешением 3  ×  8 бит / первичный, младшие 3 бита представляют битовую глубину минус 1, самый высокий истинный бит означает, что GCT присутствует
B000Цвет фона: # 000000, черный
C000Соотношение сторон пикселя по умолчанию, 0: 0
D00 00 00
R (красный)G (зеленый)B (синий)
000
Глобальная таблица цветов, цвет # 0: # 000000, черный
1080 00 00
R (красный)G (зеленый)B (синий)
12800
Глобальная таблица цветов, цвет # 1: бит прозрачности, не используется в изображении
………Глобальная таблица цветов расширяется до 30А
30АFF FF FF
R (красный)G (зеленый)B (синий)
255255255
Глобальная таблица цветов, цвет # 255: #ffffff, белый
30D21 F9Расширение графического управления (в большинстве файлов этому предшествуют поля комментариев)
30F044Количество данных GCE, 4 байта
31001Прозрачный цвет фона; это битовое поле, самый низкий бит означает прозрачность
31100 00Задержка анимации в сотых долях секунды; не используется
3131016Количество цветов прозрачного пикселя в GCT
31400Конец блока GCE
3152CДескриптор изображения
31600 00 00 00(0, 0)Расположение изображения на логическом экране в северо-западном углу
31A03 00 05 00(3, 5)Ширина и высота изображения в пикселях
31E000Бит локальной таблицы цветов, 0 означает отсутствие
31F088Начало изображения, минимальный размер кода LZW
3200B11Количество последующего изображения в кодировке LZW, 11 байт
32100 51 FC 1B 28 70 A0 C1 83 01 01<данные изображения>11 байтов данных изображения, см. Поле 320
32C000Конец блока данных изображения
32D3BПрекращение действия файла

Кодирование изображения [ править ]

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

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

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

Обратимое отображение
9-битный кодДвоичныйБайты (шестнадцатеричные)
100| 00000000 |00
028| 0101000 | 151
0FF| 111111 | 00FC
103| 00011 | 0111B
102| 0010 | 100028 год
103| 011 | 1000070
106| 10 | 100000A0
107| 1 | 1000001C1
| 1000001183
101| 0000000101
| 0000000 | 101

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

 Таблица 9-битная  строка -> код код Действие # 0 | 000h Инициализировать корневую таблицу 9-битных кодов палитра | : цвета | : # 255 | 0FFh clr | 100ч конец | 101ч | 100h ClearPixel Local |цветовая палитра строка |ЧЕРНЫЙ # 40 28 | 028h 1-й пиксель всегда для выводаБЕЛЫЙ # 255 FF | Строка найдена в таблице 28 FF | 102h Всегда добавлять первую строку в таблицу FF | Инициализировать локальную строкуБЕЛЫЙ # 255 FF FF | Строка не найдена в таблице | 0FFh - код вывода предыдущей строки FF FF | 103h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ # 255 FF FF | Строка найдена в таблицеЧЕРНЫЙ # 40 FF FF 28 | Строка не найдена в таблице | 103h - код вывода предыдущей строки FF FF 28 | 104h - добавить последнюю строку в таблицу 28 | - инициализировать локальную строкуБЕЛЫЙ # 255 28 FF | Строка найдена в таблицеБЕЛЫЙ # 255 28 FF FF | Строка не найдена в таблице | 102h - код вывода предыдущей строки 28 FF FF | 105h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ # 255 FF FF | Строка найдена в таблицеБЕЛЫЙ # 255 FF FF FF | Строка не найдена в таблице | 103h - код вывода предыдущей строки FF FF FF | 106h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ # 255 FF FF | Строка найдена в таблицеБЕЛЫЙ # 255 FF FF FF | Строка найдена в таблицеБЕЛЫЙ # 255 FF FF FF FF | Строка не найдена в таблице | 106h - код вывода предыдущей строки FF FF FF FF | 107h - добавить последнюю строку в таблицу FF | - инициализировать локальную строкуБЕЛЫЙ # 255 FF FF | Строка найдена в таблицеБЕЛЫЙ # 255 FF FF FF | Строка найдена в таблицеБЕЛЫЙ # 255 FF FF FF FF | Строка найдена в таблице Больше никаких пикселей 107h - код вывода последней строки 101h Конец

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

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

Расшифровка изображения [ править ]

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

Входящий код находится в таблице?
дадобавить строку для локального кода, за которой следует первый байт строки для входящего кода
Нетдобавить строку для локального кода, за которой следует копия собственного первого байта
 сдвиг 9-битный ----> Код кода пикселя локальной таблицы -> Строка Цветовая палитра Действие100ч 000ч | # 0 Инициализировать корневую таблицу 9-битных кодов : | палитра : | цвета 0FFh | # 255 100ч | clr 101h | конец028h | # 40 ЧЕРНЫЙ Декодировать 1-й пиксель0FFh 028h | Входящий код найден в таблице | # 255 БЕЛЫЙ - вывод строки из таблицы 102h | 28 FF - в таблицу103h 0FFh | Входящий код не найден в таблице 103h | FF FF - добавить в таблицу | - строка вывода из таблицы | # 255 БЕЛЫЙ | # 255 БЕЛЫЙ102h 103h | Входящий код найден в таблице | - строка вывода из таблицы | # 40 ЧЕРНЫЙ | # 255 БЕЛЫЙ 104h | FF FF 28 - добавить в таблицу103h 102h | Входящий код найден в таблице | - строка вывода из таблицы | # 255 БЕЛЫЙ | # 255 БЕЛЫЙ 105h | 28 FF FF - добавить в таблицу106h 103h | Входящий код не найден в таблице 106h | FF FF FF - добавить в таблицу | - строка вывода из таблицы | # 255 БЕЛЫЙ | # 255 БЕЛЫЙ | # 255 БЕЛЫЙ107h 106h | Входящий код не найден в таблице 107h | FF FF FF FF - добавить в таблицу | - строка вывода из таблицы | # 255 БЕЛЫЙ | # 255 БЕЛЫЙ | # 255 БЕЛЫЙ | # 255 БЕЛЫЙ101h | Конец

Длина кода LZW [ править ]

Более короткие длины кода могут использоваться для палитр, меньших, чем 256 цветов в примере. Если палитра состоит только из 64 цветов (так что цветовые индексы имеют ширину 6 бит), символы могут находиться в диапазоне от 0 до 63, а ширину символа можно принять равной 6 битам с кодами, начинающимися с 7 бит. Фактически, ширина символа не обязательно должна соответствовать размеру палитры: до тех пор, пока декодированные значения всегда меньше количества цветов в палитре, символы могут иметь любую ширину от 2 до 8, а размер палитры - любую степень двойки. от 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 n кодов для кодирования одиночных символов и верхний блок из 2 n кодов, который будет использоваться декодером для последовательностей длина больше единицы. Из этого верхнего блока уже приняты первые два кода: 2 n для CLEAR и 2 n + 1 для STOP. Также необходимо запретить декодеру использовать последний код в верхнем блоке, 2 n +1 - 1 , потому что, когда декодер заполняет этот слот, он увеличивает ширину кода. Таким образом, в верхнем блоке есть2 n - 3 кода, доступных декодеру, которые не вызывают увеличения ширины кода. Поскольку декодер всегда на один шаг отстает в обслуживании таблицы, он не генерирует запись в таблице после получения первого кода от кодировщика, но будет генерировать запись для каждого последующего кода. Таким образом, кодер может сгенерировать 2 n - 2 кода, не вызывая увеличения ширины кода. Следовательно, кодер должен выдавать дополнительные коды CLEAR с интервалами 2 n - 2 кода или меньше, чтобы декодер сбросил словарь кодирования. Стандарт GIF позволяет вставлять такие дополнительные коды CLEAR в данные изображения в любое время. Поток составных данных разделен на подблоки, каждый из которых содержит от 1 до 255 байтов.

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

100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

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

Байт # (шестнадцатеричный)ШестнадцатеричныйТекст или значениеСмысл
3201420Далее следуют 20 байт несжатых данных изображения.
32100 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335000Конец данных изображения

Пример сжатия [ править ]

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

Пример сжатия файла GIF
КодПикселейПримечания
Нет
N i		Значение
N i + 256		Длина
(бит)		Этот код
N i		Накоплено
N i (N i + 1)/2		Отношения, использующие N i, применяются только к
пикселям одного цвета, пока таблица кодирования не будет заполнена.
0100ч9Очистить кодовую таблицу
1FFh11Цвет верхнего левого пикселя выбран как
наивысший индекс 256-цветной палитры
2102ч23
3
⋮
255		103ч
⋮
1FFh		3
⋮
255		6
⋮
32640

Последний 9-битный код
256
⋮
767		200h
⋮
3FFh		10256
⋮
767		32896
⋮
294528

Последний 10-битный код
768
⋮
1791		400 ч
⋮
7FF ч		11768
⋮
1791		295296
⋮
1604736

Последний 11-битный код
1792
⋮
3839		800 ч
⋮
FFFh		121792
⋮
3839		1606528
⋮
7370880

Таблица кодов заполнена
⋮FFFh3839Максимальный код может повторяться для большего количества пикселей одного цвета.
Общее сжатие данных асимптотически приближается к
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 можно использовать для отображения анимации, как на этом изображении Колыбели Ньютона .
GIF-анимация, состоящая из двух фотографий, одна из которых трансформируется в другую.

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

По умолчанию анимация отображает последовательность кадров только один раз, останавливаясь, когда отображается последний кадр. Чтобы включить зацикливание анимации, Netscape в 1990-х годах использовал блок Application Extension (предназначенный для того, чтобы позволить поставщикам добавлять информацию о приложении в файл GIF) для реализации блока Netscape Application Block (NAB). [34] Этот блок, расположенный непосредственно перед последовательностью кадров анимации, определяет, сколько раз последовательность кадров должна быть воспроизведена (от 1 до 65 535 раз) или что она должна повторяться непрерывно (ноль означает бесконечный цикл). Поддержка этих повторяющихся анимаций впервые появилась в Netscape Navigator версии 2.0, а затем распространилась на другие браузеры. [35] Большинство браузеров теперь распознают и поддерживают NAB, хотя это не является строго частью спецификации GIF89a.

В следующем примере показана структура файла анимации Rotating earth (large) .gif, показанного (в виде эскиза) в информационном окне статьи.

Структура GIF
Байт # (шестнадцатеричный)ШестнадцатеричныйТекст или значениеСмысл
047 49 46 38 39 61GIF89a Логический дескриптор экрана заголовка
690 01400Ширина в пикселях
890 01400Высота в пикселях
АF7GCT следует для 256 цветов с разрешением 3  ×  8 бит / первичный
B000Цвет фона: # 000000, черный
C000Соотношение сторон пикселя по умолчанию, 0: 0
D00Глобальная таблица цветов
⋮
30D21 FFГлобальная таблица цветов
30F4Э 45 54 53 43 41 50 45 32 2Э 30NETSCAPE2.0Имя приложения
31B0333 дополнительных байта
31C011Индекс текущего подблока данных (всегда 1 для блока NETSCAPE)
31DFF FF65535Беззнаковое количество повторов
31F00Конец блока расширения приложения
32021 F9Расширение графического управления для кадра №1
322044Количество байтов в текущем блоке, 4 байта
32304
000 ........ 001 ........ 0........ 0
(разбиты на разделы для облегчения чтения)		Зарезервировано, 5 младших битов являются битовым полем
Метод удаления 1: не удалять
Нет ввода данных пользователем
Прозрачный цвет, 0 означает, что не задано
32409 009Задержка кадра: задержка 0,09 секунды перед рисованием следующего кадра
326FFПрозрачный указатель цвета (в этом кадре не используется)
32700Конец блока Global Color Table
3282CДескриптор изображения кадра №1
32900 00 00 00(0, 0)Положение северо-западного угла изображения на логическом экране: (0, 0)
32D90 01 90 01(400, 400)Ширина и высота кадра: 400  ×  400 пикселей
331000Таблица локальных цветов, 0 означает отсутствие и отсутствие переплетения
332088Минимальный размер кода LZW Изображение Данные кадра №1
333FF255Количество последующих байтов данных изображения LZW, 255 байтов
334…<данные изображения>Данные изображения, 255 байтов
433FF255Количество последующих байтов данных изображения LZW, 255 байтов
434…<данные изображения>Данные изображения, 255 байтов
⋮Повторите для следующих блоков
92C000Конец данных LZW для этого кадра
92C121 F9Расширение графического управления для кадра №2
⋮Повторить для следующих кадров
ЭДАБД21 F9Расширение графического управления для кадра # 44
⋮Повторить для следующих кадров
F48F53BПрекращение действия файла

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

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

Метаданные [ править ]

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

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

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

Защита патентов Unisys и LZW [ править ]

В 1977 и 1978 годах Джейкоб Зив и Абрахам Лемпель опубликовали пару статей о новом классе алгоритмов сжатия данных без потерь, которые теперь собирательно называются LZ77 и LZ78 . В 1983 году Терри Велч разработал быстрый вариант LZ78, который получил название Lempel – Ziv – Welch (LZW). [37] [38]

Уэлч подал заявку на патент на метод LZW в июне 1983 года. Полученный в результате патент, US 4558302  , выданный в декабре 1985 года, был передан Sperry Corporation, которая впоследствии объединилась с Burroughs Corporation в 1986 году и сформировала Unisys . [37] Дополнительные патенты были получены в Великобритании, Франции, Германии, Италии, Японии и Канаде.

В дополнение к указанным выше патентам, 1983 патента Уэлча также включает в себя цитаты на несколько других патентов , которые повлияли на него, в том числе два 1980 японских патентов ( JP9343880A и JP17790880A ) от NEC «ы июня Kanatsu, патент США 4021782 (1974) от John S. Hoerning, Патент США 4366551 (1977) от Клауса Э. Хольца и голландский патент 1981 года ( DE 19813118676 ) от Карла Экхарта Хайнца. [39]

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

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

После этого объявления CompuServe и Unisys подверглись всеобщему осуждению, и многие разработчики программного обеспечения пригрозили прекратить использование GIF. Формат PNG (см. Ниже) был разработан в 1995 году как предполагаемая замена. [37] [38] [40] Однако получение поддержки от производителей веб-браузеров и другого программного обеспечения для формата PNG оказалось трудным, и заменить GIF было невозможно, хотя популярность PNG постепенно увеличивалась. [37] Поэтому были разработаны варианты GIF без сжатия LZW. Например, библиотека libungif, основанная на Эрике С. Реймонде.'s giflib, позволяет создавать GIF-файлы, соответствующие формату данных, но без использования функций сжатия, что позволяет избежать использования патента Unisys LZW. [42] В статье доктора Добба 2001 г. описана еще одна альтернатива сжатию LZW, основанная на квадратных корнях. [43]

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

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

Альтернативы [ править ]

PNG [ править ]

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

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

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

Форматы анимации [ править ]

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

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

В 2006 году Mozilla предложила расширение формата PNG под названием APNG («Анимированная переносимая сетевая графика») в качестве альтернативы формату MNG . APNG поддерживается большинством браузеров с 2019 года. [54] APNG предоставляет возможность анимировать файлы PNG, сохраняя при этом обратную совместимость в декодерах, которые не могут понять фрагмент анимации (в отличие от MNG). Старые декодеры просто визуализируют первый кадр анимации. Группа PNG официально отклонила APNG как официальное расширение 20 апреля 2007 года. [55] Было несколько последующих предложений для простого формата анимированной графики на основе PNG с использованием нескольких различных подходов. [56] Тем не менее, переносимая сетевая анимированная графикавсе еще находится в разработке Mozilla и поддерживается в Firefox 3 [57] [58], в то время как поддержка MNG была прекращена. [59] [60] APNG в настоящее время поддерживается всеми основными веб-браузерами, включая Chrome начиная с версии 59.0, а также Opera, Firefox и Edge.

Встроенные объекты Adobe Flash и MPEG используются на некоторых веб-сайтах для отображения простого видео, но для этого требуется дополнительный плагин браузера. WebM и WebP находятся в разработке и поддерживаются некоторыми веб-браузерами. [61] Другие варианты веб-анимации включают обслуживание отдельных кадров с использованием AJAX или анимацию изображений SVG с использованием JavaScript или SMIL («язык синхронизированной интеграции мультимедиа»). [ необходима цитата ]

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

Высокоэффективный формат файла изображения (HEIF) - это формат файла изображения, завершенный в 2015 году, в котором используется алгоритм сжатия с потерями с дискретным косинусным преобразованием (DCT) на основе видеоформата HEVC и связанный с форматом изображения JPEG . В отличие от JPEG, HEIF поддерживает анимацию. [63] По сравнению с форматом GIF, в котором отсутствует сжатие DCT, HEIF обеспечивает значительно более эффективное сжатие. HEIF хранит больше информации и производит анимированные изображения более высокого качества при небольшой части эквивалентного размера GIF. [64]

VP9 поддерживает только альфа-композитинг с субдискретизацией цветности 4: 2: 0 [65] в формате пикселей YUV A420, что может не подходить для GIF-файлов, сочетающих прозрачность с растровой векторной графикой с мелкими деталями цвета.

AV1 кодек также может быть использован либо в качестве видео или виртуализированного изображения.

Использует [ редактировать ]

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

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

См. Также [ править ]

  • Синемаграф , частично анимированная фотография, часто в формате GIF.
  • Сравнение форматов графических файлов
  • Сравнение движков верстки (графика)
  • GIF-арт , форма цифрового искусства, связанная с GIF.
  • GNU plotutils (поддерживает псевдо-GIF, который использует кодировку длин серий, а не LZW)
  • Microsoft GIF Animator , историческая программа для создания простых анимированных GIF-файлов.
  • Патент на программное обеспечение

Ссылки [ править ]

  1. ^ a b c «Формат обмена графикой, версия 87a» . W3C . 15 июня 1987 . Проверено 13 октября 2012 года .
  2. ^ a b c «Формат обмена графикой, версия 89a» . W3C . 31 июля 1990 . Проверено 6 марта 2009 года .
  3. ^ «Интернет-искусство» . Compute! Яблочные приложения . Декабрь 1987 г. с. 10 . Проверено 14 сентября 2016 года .
  4. ^ Holdener III, Энтони (2008). Ajax: полное руководство: интерактивные приложения для Интернета . O'Reilly Media. ISBN 978-0596528386.
  5. ^ Furht, Борко (2008). Энциклопедия мультимедиа . Springer. ISBN 978-0387747248.
  6. Рианна МакХью, Молли (29 мая 2015 г.). «Наконец-то вы действительно можете публиковать гифки на Facebook» . Проводной . wired.com . Дата обращения 29 мая 2015 .
  7. ↑ Перес, Сара (29 мая 2015 г.). «Facebook подтверждает, что будет официально поддерживать GIF» . techcrunch.com . Дата обращения 29 мая 2015 .
  8. ^ «Представляем стикеры GIF» . Instagram . 23 января 2018 . Проверено 19 сентября 2019 года .
  9. ^ "Оксфордские словари США Слово года 2012" . Блог OxfordWords . Оксфордские американские словари. 13 ноября 2012 . Проверено 1 мая 2013 года .
  10. ↑ Flood, Элисон (27 апреля 2013 г.). « Gif - это слово года Америки? Вот что я называю omnishambles» . Книжный блог. Хранитель . Лондон . Проверено 1 мая 2013 года .
  11. ^ Олсен, Стив. «Страница произношения в формате GIF» . Проверено 6 марта 2009 года .
  12. ^ a b c «Изобретатель Gif говорит, что игнорируйте словари и говорите« Jif » » . BBC News . 22 мая 2013 . Проверено 22 мая 2013 года .
  13. ^ «Опрос разработчиков Stack Overflow 2017» . 2017 . Проверено 19 августа 2018 .
  14. ^ "Как вы произносите" GIF "?" . Экономист . Проверено 4 января 2018 .
  15. ^ "GIF" . Словарь сокращений американского наследия, третье издание . Компания Houghton Mifflin. 2005 . Проверено 15 апреля 2007 года .
  16. ^ "GIF" . Кембриджский словарь американского английского . Издательство Кембриджского университета . Проверено 19 февраля 2014 .
  17. ^ «Gif - определение из словаря Мерриам-Вебстера» . Словарь Мерриама-Вебстера . Merriam-Webster, Incorporated . Проверено 6 июня 2013 года .
  18. ^ "GIF" . Оксфордские словари онлайн . Издательство Оксфордского университета . Проверено 7 октября 2014 года .
  19. ^ "gif noun - Определение, изображения, произношение и примечания по использованию | Oxford Advanced Learner's Dictionary" . Словари Oxford Learner's . Проверено 6 февраля 2021 года .
  20. ^ "GIF | Определение GIF в Оксфордском словаре" . Лексико . Проверено 6 февраля 2021 года .
  21. ^ Стивенсон, Ангус, изд. (2010). Оксфордский словарь английского языка (3-е изд.). Издательство Оксфордского университета. ISBN 9780199571123. OCLC  729551189 .
  22. ^ Новый Оксфордский американский словарь (2-е изд.). Издательство Оксфордского университета. 2005. с. 711.
  23. ^ Новый Оксфордский американский словарь (3-е изд.). 2012 г. (часть встроенных словарей Macintosh).
  24. ↑ О'Лири, Эми (21 мая 2013 г.). «Честь создателя GIF» . Нью-Йорк Таймс . Проверено 22 мая 2013 года .
  25. ^ a b Даниэль Ротберг (4 декабря 2013 г.). « „ Вброд Jeopardy“в„GIF“произношение бой» . Лос-Анджелес Таймс . Проверено 4 декабря 2013 года .
  26. ↑ О'Лири, Эми (23 мая 2013 г.). "Battle Over 'GIF' Произношение Erupts" . Нью-Йорк Таймс .
  27. ^ Валинские, Иордания (25 февраля 2020). «Джиф разрешает большой спор с помощью банки с арахисовым маслом GIF» . CNN . Проверено 25 февраля 2020 года .
  28. ^ Марур, DR; Бхаскар, В. (март 2012 г.). «Сравнение платформенно-независимых методов распространения электронных документов». Устройства, схемы и системы (ICDCS) . Международная конференция по устройствам, схемам и системам (ICDCS) . Университет Каруни; Коимбатур, Индия: IEEE. С. 297–301. DOI : 10.1109 / ICDCSyst.2012.6188724 . ISBN 9781457715457.
  29. ^ a b С. Чин; Д. Айверсон; О. Кампесато; П. Трани (2011). Pro Android Flash (PDF) . Нью-Йорк: Апресс. п. 350. ISBN  9781430232315. Проверено 11 марта 2015 года .
  30. ^ a b c Андреас Кляйнерт (2007). «24-битные (truecolor) расширения GIF» . Архивировано из оригинального 16 марта 2012 года . Проверено 23 марта 2012 года .
  31. ^ а б Филип Ховард. «Пример полноцветного GIF» . Архивировано из оригинального 22 февраля 2015 года . Проверено 23 марта 2012 года .
  32. ^ «Nullsleep - Джеремия Джонсон - Исследование совместимости с браузером с минимальной задержкой кадров анимированного GIF» . Дата обращения 26 мая 2015 .
  33. ^ «Они разные! Как согласовать скорость анимации файлов gif в [ sic ] браузерах» . Блог разработчика . 14 февраля 2012 года Архивировано из оригинала на 1 февраля 2017 года . Проверено 15 июня 2017 года .
  34. ↑ Роял Фрейзер. "Все о GIF89a" . Архивировано из оригинала 18 апреля 1999 года . Проверено 7 января 2013 года .
  35. ^ Скотт Вальтер (1996). Секретное оружие веб-скриптов . Que Publishing . ISBN 0-7897-0947-3.
  36. ^ «Спецификация XMP, часть 3: Хранение в файлах» (PDF) . Adobe. 2016. С. 11–12 . Проверено 16 августа 2018 .
  37. ^ a b c d e f g Грег Рулофс. «История формата переносимой сетевой графики (PNG)» . Проверено 23 марта 2012 года .
  38. ^ a b c Стюарт Кэй. «Печальный день ... Патент на гифку умер в 20 лет» . Проверено 23 марта 2012 года .
  39. ^ Патент США 4558302
  40. ^ a b «Противоречие GIF: точка зрения разработчика программного обеспечения» . Дата обращения 26 мая 2015 .
  41. ^ a b «Unisys разъясняет политику в отношении использования патентов в предложениях онлайн-услуг» . Архивировано из оригинала 7 февраля 2007 года.- Архивировано Лигой свободы программирования
  42. ^ «Либунгиф» . Дата обращения 26 мая 2015 .
  43. ↑ Каргилл, Том (1 октября 2001 г.). «Замена словаря квадратным корнем» . Журнал доктора Добба . Проверено 20 января 2017 года .
  44. ^ «Программное обеспечение LZW и патентная информация» . Архивировано из оригинала 8 июня 2009 года . Проверено 31 января 2007 года . - разъяснение от 2 сентября 1999 г.
  45. ^ Unisys не предъявляет иски (большинству) веб-мастеров за использование файлов GIF -расследование спора Slashdot
  46. ^ «День сжигания всех гифок» . Архивировано из оригинального 13 октября 1999 года.
  47. ^ Burn All GIFs - проект Лиги свободы программирования (последняя версия)
  48. ^ a b c «Информация о лицензии на GIF и другие технологии на основе LZW» . Архивировано из оригинала 2 июня 2009 года . Проверено 26 апреля 2005 года .
  49. ^ «Почему на веб-страницах GNU нет файлов GIF» . Фонд свободного программного обеспечения . Проверено 19 мая 2012 года .
  50. ^ «PNG против сжатия GIF» . Проверено 8 июня 2009 года .
  51. ^ "Фильтр AlphaImageLoader" . Microsoft . Дата обращения 26 мая 2015 .
  52. ^ «Что нового в Internet Explorer 7» . MSDN . Проверено 6 марта 2009 года .
  53. ^ "Формат файла изображения PNG" . Проверено 8 июня 2009 года .
  54. ^ «Могу я использовать ... Таблицы поддержки HTML5, CSS3 и т . Д.» . caniuse.com .
  55. ^ "ГОЛОСОВАНИЕ НЕ ВЫПОЛНЕНО: APNG 20070405a" . Список рассылки SourceForge . 20 апреля 2007 г.
  56. ^ "Обсуждение простого" анимированного "формата PNG" . Архивировано из оригинального 26 февраля 2009 года . Проверено 12 июля 2011 года .
  57. ^ «Спецификация APNG» . Дата обращения 26 мая 2015 .
  58. ^ Mozilla Labs »Архив блога» Улучшенная анимация в Firefox 3
  59. ^ "195280 - Удаление поддержки MNG / JNG" . Дата обращения 26 мая 2015 .
  60. ^ «18574 - (mng) восстановить поддержку формата анимации MNG и формата изображения JNG» . Дата обращения 26 мая 2015 .
  61. ^ «Блог Chromium: Chrome 32 Beta: Анимированные изображения WebP и более быстрый сенсорный ввод Chrome для Android» . Blog.chromium.org. 21 ноября 2013 . Проверено 1 февраля 2014 года .
  62. ^ «Представляем GIFV - блог Imgur» . imgur.com. 9 октября 2014 . Проверено 14 декабря 2014 .
  63. ^ Томсон, Гэвин; Шах, Атар (2017). «Знакомство с HEIF и HEVC» (PDF) . Apple , Inc. Проверено 5 августа 2 019 .
  64. ^ «Сравнение HEIF - высокоэффективный формат файла изображения» . Nokia Technologies . Дата обращения 5 августа 2019 .
  65. ^ "# 3271 (Разрешить использование дополнительных форматов пикселей с libvpx-vp9) - FFmpeg" . trac.ffmpeg.org .
  66. ^ Дьюи, Кейтлин. «Познакомьтесь с технологией, которая может сделать GIF-файлы устаревшими» . Вашингтон Пост . Проверено 4 февраля 2015 года .
  67. ^ "Поддержка WebM на 4chan" . Блог 4chan . Проверено 4 февраля 2015 года .
  68. ^ «Представляем GIFV» . Imgur. 9 августа 2014 . Проверено 21 июля +2016 .
  69. ^ Аллан, Патрик. «Imgur обновляет GIF-файлы для повышения скорости и качества с помощью GIFV» . Лайфхакер . Проверено 4 февраля 2015 года .
  70. ^ «Революция GIF» . Официальный блог Telegram . Проверено 4 января +2016 .

Внешние ссылки [ править ]

  • Проект GIFLIB
  • spec-gif89a.txt Спецификация GIF 89a на w3.org
  • Спецификация GIF 89a переформатирована в HTML
  • Объяснение LZW и GIF
  • Анимированные GIF : шестиминутный документальный фильм, созданный Off Book (веб-сериал)
  • GifCities (поисковая система анимированных GIF- файлов GeoCities)