Какие форматы файлов могут хранить анимированные изображения
GIF — формат хранения графических изображений (Graphics Interchange Format). Формат GIF способен хранить сжатые без потерь изображения в формате до 256 цветов с палитрой, и предназначен, в основном, для чертежей, графиков и прочих четких изображений от которых требуется маленький размер.
Краткие сведения:
Размер картинки — от 1×1 до 65535×65535 пикселов.
Число цветов палитры — от 2 до 256.
Каждый цвет палитры имеет глубину 24 бита/пиксел (выбор из 16 миллионов цветов) .
Карта прозрачности — 1-битная (полупрозрачных цветов нет) .
Число повторов анимации — от 1 до 65535, а также бесконечное.
Время показа одного кадра анимации — от 1/100 секунды до 655 секунд.
Число кадров анимации — неограниченно.
Число невидимых текстовых комментариев и размер каждого комментария — неограниченны.
Один из цветов в палитре может быть объявлен «прозрачным» . В этом случае, в програмах которые поддерживают прозрачность GIF (например, большинство современных браузеров) сквозь пиксели, окрашеные «прозрачным» цветом будет виден фон. «Полупрозрачность» пикселей (технология альфа-канала) не поддерживается.
Анимированные изображения
Формат GIF поддерживает анимационные изображения. Фрагменты представляют собой последовательности нескольких статичных кадров, а также информацию о том, сколько времени каждый кадр будет показан на экране. Анимация может быть закольцована, тогда после последнего кадра будет вновь показан первый и так далее.
Для создания анимированного GIF баннера нужны программы Adobe Photoshop CS3 – для подготовки кадров баннера и Ulead GIF Animator 5 – для создания из готовых кадров анимационного ролика в формате GIF. В принципе, можно обойтись одной из этих программ, но двумя программаи пользоваться удобнее, позволяет использовать сильные стороны каждой и сделать анимацию быстрее и проще. Как это сделать, подробно описывается в статье на этом блоге.
Т. е. по сути мы получим несколько неанимированных GIF файлов, которые соберем в один анимированный GIF баннер. Гиф может быть как анимированный, т. е. состоять из нескольких картинок ГИФ, так и статическим - состоять из одного GIF-изображения.
Чтобы создать эффект движения нужно повторить слегка измененную картинку с достаточно высокой скоростью. Например в кино эта скорость составляет 24 кадра в секунду. Чем она выше, тем движение выглядит плавнее.
Как создается анимация
Соседние кадры не должны сильно отличаться. Когда мы снимаем на видеокамеру, то это получается само собой, а вот если рисовать в редакторе, то можно об этом забыть, и Мальвина будет ходить, как Буратино.
Этот принцип используется в анимированных графических файлах. Они содержат не одно изображение, а серию картинок-кадров. Каждый кадр знает, сколько миллисекунд он должен отображаться.
Пример абстрактного алгоритма сжатия
Итак, есть файл. В нем только два цвета – черный и синий. Тогда цвет можно закодировать одним битом. Размер по горизонтали — 20, по вертикали — 1. Всего он занимает 20х1х1 = 20 бит.
В строке первые семь точек имеют первый цвет, затем шесть точек — второй, и оставшиеся в строке точки опять окрашены в первый цвет. Записать можно так: повторить цвет 1 — 7 раз, цвет 2 – 6 раз, цвет 1 – 7 раз (1х7 2х6 1х7).
Выгода кажется не очевидной, но если растянуть файл-строку в 1000 раз до 20 килобит, то запись увеличится совсем незначительно: 1х7000 2х6000 1х7000. С увеличением размера исходного файла выгода от сжатия будет только расти.
Сжатие применяется для каждого кадра анимации. Если в секунде 24 кадра, то оно сработает 24 раза. Без этого файлы анимации были бы очень большими.
Форматы с возможностью анимации
GIF формат
Формат хорошо сжимает изображение без потерь. Для маленьких картинок это важно.
APNG формат
Этот формат (Animated PNG) является расширением распространенного формата PNG. Однако разработчики последнего не включили это расширение в спецификацию. Получилось, что немногие программы могут его правильно отображать. Большинство браузеров покажет первый кадр статичной картинкой, а про анимацию забудет.
Маловероятно, что формат будет широко использоваться. Тем более, что появились новые мощные конкуренты.
WEBP формат
Этот формат появился в 2010 году. Разработчик, компания Google, позиционирует его как замену GIF и других форматов. WEBP имеет все возможности GIF, но только в улучшенном варианте:
- Эффективней с прозрачными слоями.
- При анимации последующий кадр хранит только изменения предыдущего. А раз так, то размер анимированного файла уменьшается.
- Изображение сжимается эффективнее.
BPG формат
BPG — самый новый. Он был предложен в конце 2014 года. Формат позиционируется как замена JPEG со значительными улучшениями. Сжатие изображения будет эффективнее, чем у предка. Появится поддержка анимации (JPEG не умеет этого делать). Но формат только начинает свое развитие, рекомендовать его для использования еще нельзя, а вот следить за ним можно.
Работа с GIF, APNG и WEBP в CLI
Есть два замечательных пакета ImageMagick и GraphicsMagic. С помощью ImageМagic создается анимация из *.jpg картинок:
Команда convert подхватывает все файлы *.jpg в директории, сортирует их по алфавиту и последовательно вставляет в новый файл animated.jpg.
Проверка (запустится маленький графический контейнер с мультиком):
Конвертация мультика в APNG формат:
Если использовать GraphicsMagic, то команды такие:
На этот раз выходной формат WEBP. Аналогично обрабатывается и BPG.
Также возможно вытащить анимацию в GIF из видеофайлов. Например, с использованием пакета libav-tools импортируется видео из MP4:
Посмотреть разницу между анимацией GIF, WebP и APNG в разных форматах можно тут. А вот пример.
Safari TP в корне изменили подход к ним. Теперь я обожаю анимированые “GIF”.
Анимированные GIF-файлы — это фича. Цитата из спецификации GIF89a:
Формат обмена графикой не предназначен как платформа для анимации, хотя ее можно организовать с ограничениями.
Но они стали крутым инструментом для синемаграфов, мемов и творческого выражения. Однако вся эта крутость стоит дорого. Анимированные GIF-файлы ужасны для веб-производительности. Они ОГРОМНЫЕ по размеру, влияют на сотовые данные, требуют большего количества памяти и производительности процессора, вызывают перерисовку и являются убийцами батареи. Как правило, GIF-файлы размером в 12 раз больше, чем видео H.264, и съедают в 2 раза больше энергии при загрузке и отображении в браузере. И мы тратим все эти ресурсы на то, что даже не выглядит очень хорошо — GIF ограничивается 256 цветами, что часто делает файлы GIF ужасными (хотя есть некоторые крутые пути обхода).
Моя дочь любит их, но она не понимает, почему ее батарея всегда мертва.
GIF имеют много преимуществ: они запрашиваются немедленно при помощи прелоадера браузера, они автоматически проигрываются и зацикливаются. Они короткие. Исследование рынка показало, что у пользователей более высокий уровень взаимодействия с ними и обычно предпочитают как короткие видео (
Итак, как я пришел от любви / ненависти к GIF к любви к «Gifs»?
В последнем Safari Tech Preview, благодаря тяжелой работе Джера Нобла, мы можем использовать файлы MP4 в тегах . Предлагаемый пример — это не длинноформатное видео, а микроформатное, циклическое видео без звука — как GIF. Взгляните сами:
Круто! Это будет полезно Во многих сферах — для бизнеса, для удобства использования и особенно для работы в Интернете.
… но у нас уже есть video-теги
Как уже отмечалось, использование тега video намного лучше для производительности, чем использование анимированных GIF. Именно поэтому в 2014 году Twitter заметно добавил анимированную поддержку GIF, не добавляя поддержку GIF. Twitter вместо этого перекодировал GIF в MP4 на лету и показывал их внутри тегов video . Поскольку все браузеры теперь поддерживают H.264, это был очень простой переход.
Перекодирование анимированных GIF-файлов в MP 4это довольно просто. Вам просто нужно запустить ffmpeg -i source.jpg output.mp4
Однако не все могут перестраивать свою CMS и конвертировать img в video . Даже если это возможно, есть три проблемы с этим методом доставки GIF-подобного (Gif), микроформатного видео:
1. Медленная производительность браузера с тегом «video»
В отличие от тегов img , браузеры не загружают контент video . Обычно preloaders только предварительно загружают ресурсы JavaScript, CSS и изображения, потому что они имеют решающее значение для макета страницы. Поскольку содержание video может быть любой длины — от микроформы до длинной формы — теги video пропускаются до тех пор, пока основной поток не будет готов проанализировать его содержимое. Это задерживает загрузку содержимого video на много сотен миллисекунд.
Например, видео в верхней части страницы Velocity требует всего 5 секунд при загрузке страницы. Это 27-й по запрашиваемости ресурс, и даже он не прогружается целиком до тех пор, пока не начнется рендеринг, после загрузки веб-шрифтов.
И что еще хуже, чем нативный элемент video ? Типичный JavaScript видеопроигрыватель. Часто самый простой способ встроить видео на сайт — использовать службу, такую как YouTube или Vimeo, и избегать сложностей кодирования видео, хостинга и UX. Это, как правило, отличная идея, но для микроформатного видео или тяжелого контента, такого как видео, это просто добавляет задержку из-за javascript плеера и поддержки ресурсов, которые вводят эти услуги хостинга (css / js / jpg / woff). В дополнение к разметке video вы вынуждаете браузер загружать, оценивать и исполнять javascript-плеер, и только после этого видео может начать загрузку.
Как известно многим, я люблю свою куртку Loki из-за ее встроенных рукавов, балаклавы и капюшона, который рассчитан на шлемы. Но взгляните на домашнюю страницу Loki USA, в которой используется великолепное видео, размещенное на Vimeo:
Если вы посмотрите внимательно, вы увидите, что JavaScript для плеера действительно запрашивается вскоре после завершения загрузки DOM. Но он загружается не полностью и готов к запуску видеопотока намного позже.
2. Вы не можете щелкнуть правой кнопкой мыши и сохранить видео
Самый длинный видеоконтент — влоги, TV, movies — предоставляется через плееры на основе JavaScript. Обычно эти плееры предоставляют пользователям удобную ссылку «Share now» или инструмент закладки, поэтому можно вернуться на YouTube (или куда угодно) и снова найти видео. Напротив, микроформатный контент — как мемы и синемаграфы — обычно не приходит через плееры, и пользователи ожидают, что смогут загружать GIF и отправлять их друзьям, как они могут сделать с любым изображением в Интернете. Этот мэм танцующего кота был смешным — я должен поделиться им со всеми моими друзьями!
Если вы используете теги video для показа видео в формате micro-form, пользователи не смогут щелкнуть правой кнопкой мыши, щелкнуть мышью и перетащить и сохранить. И их радость от кошки-танцора становится разочаровывающей неожиданностью UX.
3. Нарушение автовоспроизведения
Наконец, использование тегов video и MP4 вместо тегов img и GIF приводит вас к текущей ситуации игры в кошки-мышки между браузерами и недобросовестными продавцами объявлений, которые злоупотребляют атрибутом video autoplay , чтобы получить внимание пользователей. Исторически мобильные браузеры игнорировали атрибут автовоспроизведения и / или отказались от воспроизведения видеороликов, требуя, чтобы они вошли в полноэкранный режим. За последние пару лет Apple и Google смягчили свои ограничения на встроенные видеоролики с автовоспроизведением, что позволяет использовать Gif-подобные изображения с тегом video . Но опять же, рекламные сети злоупотребляют этим, вызывая дополнительные ограничения: если вы хотите автовоспроизвести теги video , вам нужно выключить звук ( muted ) у контента или удалить звуковую дорожку в нем.
… но у нас уже есть анимированный WebP. И анимированный PNG.
Формат GIF — это не единственный формат, поддерживающий анимацию. У WebP и PNG тоже есть поддержка анимации. Но, как и GIF, они не были предназначены для анимации и весили значительно больше по сравнению с выделенными видеокодеками, такими как H.264, H.265, VP9 и AV1.
Анимированный PNG теперь широко поддерживается во всех браузерах, и в то время как он тоже касается ограничения цветовой палитры как у GIF, это все еще неэффективный формат файла для сжатия видео.
Анимированный WebP лучше, но по сравнению с классическими видеоформатами он все еще проблематичен. Помимо того, что не имеет принятого стандарта, анимированный WebP испытывает недостаток в подвыборке и широкодиапазонной поддержке. Кроме того, экосистема поддержки фрагментирована. Даже не все версии Android, Chrome и Opera поддерживают анимированный WebP — даже если эти браузеры говорят о поддержке с помощью Accept: image / webp . Вам нужны Chrome 42, Opera 15+ или Android 5+.
Таким образом, хотя анимированное сжатие WebP намного лучше, чем анимированные GIF или PNG, хотя мы можем сделать лучше. (См. Сравнения размеров файлов ниже)
И рыбку съесть и .
Добавлением поддержки классических видеоформатов (таких как MP4), которые будут включены в теги img Safari Technology Preview исправил проблемы производительности и UX. Теперь наши видеоролики с микроформатами могут быть небольшими и производительными (например, MP4, переданные с помощью тега video ), и их можно легко подгрузить, автоматически запустить и поделится им (например, как с нашим старым другом, GIF).
Так насколько быстрее это будет? Откройте инструменты разработчика и посмотрите разницу между Safari Technology Preview и другими браузерами:
К сожалению, Safari не очень хорошо работает с WebPageTest, и создание надежных тестовых бенчмарков довольно затруднительно. Аналогично, использование Tech Preview довольно мало, поэтому сравнение производительности с инструментами RUM пока что не практично.
Однако мы можем сделать две вещи. Во-первых, сравнивать размеры необработанных байтов, а во-вторых, использовать правило Image.decode () для измерения воздействия различных ресурсов на устройство.
Экономия памяти
NB: Эти результаты следует рассматривать только как поверхностные. Каждый кодек может быть настроен гораздо лучше, так как вы можете видеть, что результат с vp9 хуже, чем с vp8. Необходимо провести более комплексное исследование, которое учитывает SSIM.
Ниже приведены медианные (p50) результаты преобразования:
Да, анимированный WebP имеет небольшой размер, но любой формат видео имеет размер намного меньше. Это никого не должно удивлять, поскольку современные видеокодеки очень оптимизированы для потоковой передачи онлайн-видео. Алгоритмы H.265 очень хороши, как я ожидал, AV1 тоже.
Преимущества здесь является не только скорость передачи, но и существенная экономия $$ для конечных пользователей.
Используя видео в тегах img , оно будет грузиться намного быстрее при сотовой связи.
Улучшение декодирования и визуальной производительности
Далее рассмотрим влияние эффектов декодирования и отображения на просмотр. H.264 (и H.265) имеет значительное преимущество в том, что они используют аппаратное декодирование вместо использования основного ядра.
Как мы можем это измерить? Поскольку браузеры еще не реализовали предложенный Hero image API , мы можем использовать стратегию Стива Соудера User Timing and Custom Metric как хорошее сравнение, когда изображение начинает отображаться пользователю. Он не измеряет частоту кадров, но говорит о том, когда отображается первый кадр. Мы также можем использовать недавно принятое соглашение об Image.decode () для измерения производительности декодирования. На тестовой странице ниже я добавляю уникальный GIF и MP4 в теге img 100 раз и сравниваю производительность декодирования и отрисовки.
let image = new Image;
t_startReq = new Date().getTime();
document.getElementById("testimg").appendChild(image);
image.onload = timeOnLoad;
image.src = src;
return image.decode().then(() => < resolve(image); >);
Результаты впечатляют. Даже на моем мощном MacBook Pro 2017, работающем локально, без подключения к сети, мы видим, что GIF-файлам нужно в 20 раз больше времени, чем MP4, чтобы нарисовать первый кадр (сигнализируется событием onload ), и в 7 раз больше для декодирования.
Удивлены? Скопируйте репозиторий и проверте у себя. Отмечу, что добавление сетевых условий передачи GIF и соответственно MP4 будет непропорционально искажать результаты теста. В частности, поскольку декодирование может начаться до окончания последнего байта, дельта между передачей, отображением и декодированием становится намного меньше. На самом деле это говорит о том, что только экономия памяти сама по себе значительно улучшит работу пользователя. Однако, если исключить подключение к сети, как я это делал при запуске localhost, вы можете видеть, что использование видео имеет существенные преимущества в производительности.
Как вы можете реализовать это?
Вариант 1: Использовать адаптивные изображения
В идеале самым простым способом является использование атрибута source type тега HTML5 picture .
Я хотел бы сказать, что мы можем остановиться на этом. Тем не менее, есть неприятная ошибка WebKit в Safari, которая заставляет preloader загружать первый source независимо от объявления mimetype. Основной DOM-loader распознает ошибку и выберет правильный источник. Однако ущерб уже будет нанесен. Preloader теряет возможность загрузить изображение раньше, и, более того, загружает неправильную версию, теряя байты. Хорошей новостью является то, что я исправил эту ошибку, и фикс должен появиться в Safari TP 45.
Короче говоря, использование picture и source type для выбора типа mime не рекомендуется, пока следующая версия Safari не будет установлена у 90%+ пользователей.
Вариант 2. Используйте MP4, анимированные WebP и Fallback для GIF
Это будет немного чище, если WebKit BUG 179178 будет решен, и вы можете добавить тест для заголовка Accept: video / * (например, вы можете проверить Accept: image / webp ). Но конечным результатом является то, что каждый браузер получает лучший формат для img видео на основе микроформата, которые он поддерживает:
В nginx это выглядело бы примерно так:
map $http_user_agent $mp4_suffix default "";
"~*Safari/605" ".mp4";
>
location ~* .(gif)$ add_header Vary Accept;
try_files $uri$mp4_suffix $uri =404;
>
Разумеется, не забывайте указывать Vary: Accept, User-Agent , чтобы указать прокси-провайдерам и CDN кэшировать каждый ответ по-разному. Фактически, вы должны отметить Cache-Control как частный и использовать TLS, чтобы гарантировать, что менее сложные Прокси-серверы повышения производительности ISP не кэшируют содержимое.
Вариант 3: используйте RESS и тег «video»
Если вы можете манипулировать своим HTML, вы можете применить технологию «Responsive-server-side» (RESS). Этот параметр переводит логику обнаружения браузера в ваш вывод HTML.
Например, вы можете сделать это с помощью PHP:
Бонус: не забудьте удалить звуковую дорожку
Теперь, поскольку вы не конвертируете GIF в MP4, а скорее конвертируете MP4 в GIF, мы также должны помнить о том, что нужно удалить звуковую дорожку для экономии памяти. (Скажите, пожалуйста, что вы не используете GIF в качестве исходника. Правильно.) Аудиодорожки занимают дополнительные байты в размере файла, которые мы можем просто освободить, так как знаем, что он будет воспроизводиться без звука в любом случае. Самый простой способ с ffmpeg:
ffmpeg -i cats.mp4 -vcodec copy -an cats.mp4
Существуют ли ограничения по размеру
Когда я пишу это, Safari будет слепо загружать все видео, которые вы указываете в теге img , независимо от того, сколько это займет времени. С одной стороны, это ожидаемо, потому что это помогает повысить производительность браузера. Тем не менее, это может быть глупо, если вы заставите пользователя грузить 120-минутное видео. Я тестировал видео разных размеров, и все они были загружены, пока пользователь листал сайт. Поэтому будьте любезны с пользователями. Если вы хотите добавить более длинное видео, используйте тег video для повышения производительности.
Что дальше. Адаптивные видео и фоновые видео
Теперь, когда мы можем размещать MP4 через теги img , открываются двери для многих новых вариантов использования. Два из которых приходят на ум: адаптивное видео и фоновые видео. Теперь, когда мы можем поместить MP4 в srcsets , измените запросы к ним с помощью Client Hints и Content-DPR, редактируйте их отображение с помощью image media , просто используйте все возможности.
Видео в CSS background-image: url (.mp4) тоже работает.
Заключение
Включив видеоконтент в тегах img , Safari Technology Preview прокладывает путь к удивительным GIF-подобным анимациям, без потери производительности и качества, присущих файлам GIF. Эта функциональность будет полезна для пользователей, разработчиков, дизайнеров и Интернета в целом. Кроме того, колоссально выигрывая в производительности, эта технология открывает множество новых вариантов использования, которые СМИ и Е-бизнес стремятся реализовать в течение многих лет. Мы надеемся, что другие браузеры скоро последуют этому примеру. Google? Microsoft? Mozilla? Samsung? Ваш ход.
Поисковый маркетинг или SEM (Search Engine Marketing) — это набор действий, направленных на увеличение потока клиентов на сайт через ул.
Как и для чего необходимо уменьшать вес страниц сайта?
Мы сейчас потребляем значительно больше информации, чем какое-либо поколение за всю историю человечества. Люди сидят в социальных сетях.
Обновление Google Page Experience и новый фактор ранжирования Core Web Vitals
В течение многих лет Google подчёркивал важность качества сайтов, их безопасности и удобства использования для пользователей. Занимая л.
Что может дать уменьшение загрузки сайта на 0,1 секунды на мобильных устройствах
Компании Akamai и SOASTA провели много исследований, в результате которых выявлено, что более половины посетителей покидают страницу, к.
Выбираем домен для сайта: на что следует обратить внимание
Выбор домена — одна из главных вещей, о которых необходимо подумать при создании сайта. Правильно подобранное доменное имя впечатляет п.
Юзабилити — удобство использования сайта: что это такое и рекомендации по его улучшению
Вы когда-нибудь закрывали сайт просто потому что загрузка занимала слишком много времени? Нет ничего утомительнее, чем ожидание пока эл.
Локальное SEO продвижение — как оптимизировать сайт под локальный поиск
В поисковой выдаче постоянно усовершенствуются алгоритмы, кроме того, она становится с каждым днём более персонализированной. Одним из .
Психология веб-дизайна: на что пользователи обращают внимание в первую очередь
Сайт для гаджетов. Или почему важно обращать внимание на руки пользователя
Персональные компьютеры и ноутбуки больше не являются основным инструментом, посредством которого люди получают информацию из интернета.
Вам когда-нибудь было интересно, как устроены gif-ки? В данной статье попробуем разобраться с внутренним строением GIF-формата и методом сжатия LZW.
Файл в формате GIF состоит из фиксированной области в начале файла, за которой располагается переменное число блоков, и заканчивается файл завершителем изображения.
Основные характеристики формата GIF:
- Изображение в формате GIF хранится построчно, поддерживается только формат с индексированной палитрой цветов;
- Поддерживается 256-цветовая палитра;
- Этот формат позволяет хранить несколько изображений в одном файле;
- GIF поддерживает анимационные изображения;
Рассмотрим разбор дампа анимированного GIF-изображения размера 4х4 пикселя, состоящего из двух кадров. А вот и сами кадры, увеличенные в десятки раз.
Заголовок
В начале каждого файла GIF находится заголовок. Состоит он из текста «GIF87a» или «GIF89a», в зависимости от версии. В формате GIF87a переменная область содержит исключительно описания изображения, а в формате GIF89a она может включать еще и блоки расширений.
Логический дескриптор экрана
[04 00] [04 00] – ширина и высота виртуального экрана в пикселях
[А2] –
     (1) — флаг M использования глобальной таблицы цветов. Если 1, то в файле присутствует глобальная таблица цветов.
     (010) = 2 — флаг CR. Число бит разрешения цвета = CR + 1.
     (0) – флаг S (флаг сортировки). Если 1, то цвета в глобальной карте цветов отсортированы в порядке убывающей важности.
     (010) = 2 — флаг PIXEL. Размер общей таблицы цветов. Число записей в глобальной таблице цветов: 2^(N+1).
[00] – Индекс цвета фона.
[00] – Соотношение сторон. По умолчанию — 1:1.
Глобальная таблица цветов
[0A B2 5D] —
[C8 A6 2D] —
[F3 ED 63] —  
[BA 60 A5] —
[00 80 C8] —  
[F1 60 22] —  
[00 00 00] —  
[FF FF FF] —   
После глобальной таблицы цветов располагается переменная часть GIF. Файл содержит последовательность блоков, которые иденцифицируются 1-байтовым кодом в начале блока.
Коды блоков:
    0x21 – Расширение
    0x2С – Блок изображения
    0x3B – Завершение файла GIF
Блок расширения
Коды расширения:
    0x1 – расширение простого текста
    0xF9 – расширение управления графикой
    0xFE – расширение комментария
    0xFF – расширение программы
[FF] — код расширения. В нашем случае имеем расширение программы.
[0B] — размер последующего блока в байтах.
[4E 45 54 53 43 41 50 45] — (NETSCAPE) идентификатор приложения, которому принадлежит это расширение.
[32 2E 30] — (2.0) код приложения. С его помощью приложение проверяет, действительно ли это расширение принадлежит ему.
[03] — размер последующего блока в байтах.
[01] — фиксированное значение.
[00 00] — значение 0..65535. Беззнаковое целое в формате little-endian. Определяет, сколько раз должен повторяться цикл.
            Для 0 – бесконечно.
[00] — конец блока.
[F9] — код расширения (расширение управления графикой).
[04] — размер последующего блока в байтах.
[04] —
    (000) – зарезервировано. Рекомендуется заполнять нулями.
    (001) — метод обработки. Определяет, что делать после отображения.
                0 – к картинке не будет применяться никакой обработки
                1 – картинка останется без изменений
                2 – картинка затрется фоном
                3 – восстановится изображение под картинкой
                4-7 – не определены
    (0) – флаг ввода пользователя. Если 1, то для продолжения обработки изображения требуется реакция пользователя.
    (0) – флаг цвета прозрачности. Указывает, будет ли какой-нибудь цвет использоваться как прозрачный.
[32 00] – время задержки в анимации. = 50/100 секунды = 0,5 с
[00] – индекс цвета прозрачности.
[00] — конец блока.
Блок изображения
[03] — минимальный размер кода в LZW.
[08] — размер последующего блока в байтах.
[08 0A D2 42 90 94 59 12] — блок данных, сжатых алгоритмом LZW. Представлены в виде последовательности кодов, имеющих длину [мин. размер кода] + 1
[00] — окончание потока данных.
Разбор алгоритма LZW
Кадр 1
Словарь/Code Table
Словарь инициализирован по количеству цветов и кодами и . Берем код с длиной текущего размера, получаем его значение из словаря. Если значение есть в словаре, то получаем готовый индекс цвета для текущего пикселя и добавляем в словарь следующее значение: полученное предыдущее + первое из текущего. Если в словаре еще нет такого значения, то добавляем по этому индексу полученное предыдущее + первое из предыдущего. Первый код должен соответствовать значению , последний — .
Решим обратную задачу. Возьмем исходные данные изображения и закодируем их с использованием алгоритма LZW. Под исходными данными понимаем последовательность индексов цветов из словаря, соответствующих каждому из пикселей. Пискели рассматриваем сверху вниз, слева направо.
[08 0A D2 42 90 94 59 12] — блок данных, сжатых алгоритмом LZW.
Аналогично поступаем со вторым кадром.
Кадр 2
Словарь/Code Table
Блок завершения файла GIF
Заключение
На этом всё. Надеемся, эта статья была полезна для вас (ну или хотя бы интересна).
Читайте также: