Как правильно добавить GIF файл на WordPress сайт
Вступление
Здравствуйте! Это очень простой пост, на тему, как добавить GIF файл на WordPress сайт. Сделать это не сложно, однако при этом важно не занимать мегабайты места в каталоге сайта.
Что такое GIF файл
GIF файлы это файлы изображений имеющих блочную структуру. То есть, гифка это масса одиночных фотографий (блоков) не связанных друг с другом. Если программа, показывающая гифку, распознает этот формат, вы увидите следующие друг за другом картинки, образующие анимацию. Если программа не «видит» gif формат, вы увидите первую картинку этого набора.
Особенности GIF файлов
По умолчанию CMS WordPress прекрасно видит GIF файлы и никаких дополнительных настроек для их загрузки не нужно.
Однако серьёзные гифки много весят и постоянная загрузка 1-2 мегабайтных файлов, не принесёт пользы для скорости сайта. Тем более, GIF-файл нельзя сжать.
Решение этой проблемы простое. Используем сторонний сервис для хранения GIF-файлов, а на свой сайт WordPress внедряем гифку по стороннему URL.
Остается малое, выбрать сервис для хранения GIF файлов. Я рекомендую сервис giphy.com. На сервисе очень лёгкая регистрация и очень неплохие условия бесплатного хранения.
Сервис giphy.com
Покажу, как начать работать с сервисом.
Всё, после добавления файла можете забрать URL гифки, короткий URL гифки, ссылку для внедрения гифки, как Video HTML5.
Как добавить GIF файл на WordPress
Прямая вставка GIF файла
Если ваша гифка весит не много, можно вставить её напрямую, как простую картинку. Для этого:
Вставить GIF файл в сообщение по URL
Если GIF файл объемный у вас могут быть проблемы с его загрузкой на сайте. Также он сильно тормознёт загрузку страницы. Чтобы этого избежать, вставим GIF файл в сообщение по URL. Для этого:
Берём URL гифки из своего кабинета на сайте giphy.com или любом другом хранилище;
Добавляем в статью (страницу, виджет) через способ «Вставить с сайта». Для оптимизации даем гифке альтернативное имя (тег alt).
Всё. Гифка на сайте и будет на нём, пока у вас есть свой аккаунт в хранилище giphy.com.
Использовать плагин
Можно совсем упростить задачу добавления GIF файлов. Просто установите плагин. Например, такие:
Giphypress
Aparg HandyGIF
Это плагин добавляет, оптимизирует, ускоряет мобильную версию GIF файлов. Как работает плагин не знаю, не проверял.
Вывод
GIF файлы безусловно улучшают привлекательность сайта. Однако при прямой вставки файлов в каталог сайта они будут замедлять сайт. Поэтому нужно правильно добавить GIF файл на WordPress сайт через сторонние хранилища по URL. Я показал один из очень неплохих вариантов.
Эволюция «img»: Gif без формата GIF
Введение
Я как люблю так и ненавижу GIF анимации
Safari TP в корне изменили подход к ним. Теперь я обожаю анимированые “GIF”.
Анимированные GIF-файлы — это фича. Цитата из спецификации GIF89a:
Формат обмена графикой не предназначен как платформа для анимации, хотя ее можно организовать с ограничениями.
Но они стали крутым инструментом для синемаграфов, мемов и творческого выражения. Однако вся эта крутость стоит дорого. Анимированные GIF-файлы ужасны для веб-производительности. Они ОГРОМНЫЕ по размеру, влияют на сотовые данные, требуют большего количества памяти и производительности процессора, вызывают перерисовку и являются убийцами батареи. Как правило, GIF-файлы размером в 12 раз больше, чем видео H.264, и съедают в 2 раза больше энергии при загрузке и отображении в браузере. И мы тратим все эти ресурсы на то, что даже не выглядит очень хорошо — GIF ограничивается 256 цветами, что часто делает файлы GIF ужасными (хотя есть некоторые крутые пути обхода).
Моя дочь любит их, но она не понимает, почему ее батарея всегда мертва.
GIF имеют много преимуществ: они запрашиваются немедленно при помощи прелоадера браузера, они автоматически проигрываются и зацикливаются. Они короткие. Исследование рынка показало, что у пользователей более высокий уровень взаимодействия с ними и обычно предпочитают как короткие видео ( img src=»https://habr.com/ru/company/edison/blog/343958/rocky.mp4″
Круто! Это будет полезно Во многих сферах — для бизнеса, для удобства использования и особенно для работы в Интернете.
… но у нас уже есть video-теги
1. Медленная производительность браузера с тегом «video»
Как недавно указал Дуг Силларс в посте на HTTP Archive, в визуальной презентации при использовании тега video наблюдается огромная потеря в производительности.
Например, видео в верхней части страницы Velocity требует всего 5 секунд при загрузке страницы. Это 27-й по запрашиваемости ресурс, и даже он не прогружается целиком до тех пор, пока не начнется рендеринг, после загрузки веб-шрифтов.
Хуже того, многие браузеры предполагают, что теги video содержат длинноформатный контент. Вместо того, чтобы сразу загружать весь видеофайл, который будет тратить ваш интернет трафик даже в тех случаях, когда вы не просмотрите все видео, браузер сначала выполнит 1-байтовый запрос, чтобы проверить, поддерживает ли сервер HTTP-Range запросы. Затем он будет следовать нескольким range-запросам разных размерах блоков, чтобы гарантировать, что видео будет адекватно (но не слишком) буферизированным. Следствием является многократное передача его по TCP, прежде чем браузер даже начнет декодировать контент и значительная задержка, прежде чем пользователь что-нибудь увидит. При использовании сотовых данных с высокой задержкой эти круговые передачи могут загружать видео сотни или тысячи миллисекунд.
Как известно многим, я люблю свою куртку Loki из-за ее встроенных рукавов, балаклавы и капюшона, который рассчитан на шлемы. Но взгляните на домашнюю страницу Loki USA, в которой используется великолепное видео, размещенное на Vimeo:
Если вы посмотрите внимательно, вы увидите, что JavaScript для плеера действительно запрашивается вскоре после завершения загрузки DOM. Но он загружается не полностью и готов к запуску видеопотока намного позже.
2. Вы не можете щелкнуть правой кнопкой мыши и сохранить видео
Самый длинный видеоконтент — влоги, TV, movies — предоставляется через плееры на основе JavaScript. Обычно эти плееры предоставляют пользователям удобную ссылку «Share now» или инструмент закладки, поэтому можно вернуться на YouTube (или куда угодно) и снова найти видео. Напротив, микроформатный контент — как мемы и синемаграфы — обычно не приходит через плееры, и пользователи ожидают, что смогут загружать GIF и отправлять их друзьям, как они могут сделать с любым изображением в Интернете. Этот мэм танцующего кота был смешным — я должен поделиться им со всеми моими друзьями!
Если вы используете теги video для показа видео в формате micro-form, пользователи не смогут щелкнуть правой кнопкой мыши, щелкнуть мышью и перетащить и сохранить. И их радость от кошки-танцора становится разочаровывающей неожиданностью UX.
3. Нарушение автовоспроизведения
… но у нас уже есть анимированный WebP. И анимированный PNG.
Формат GIF — это не единственный формат, поддерживающий анимацию. У WebP и PNG тоже есть поддержка анимации. Но, как и GIF, они не были предназначены для анимации и весили значительно больше по сравнению с выделенными видеокодеками, такими как H.264, H.265, VP9 и AV1.
Анимированный PNG теперь широко поддерживается во всех браузерах, и в то время как он тоже касается ограничения цветовой палитры как у GIF, это все еще неэффективный формат файла для сжатия видео.
Таким образом, хотя анимированное сжатие WebP намного лучше, чем анимированные GIF или PNG, хотя мы можем сделать лучше. (См. Сравнения размеров файлов ниже)
Добавлением поддержки классических видеоформатов (таких как MP4), которые будут включены в теги img Safari Technology Preview исправил проблемы производительности и UX. Теперь наши видеоролики с микроформатами могут быть небольшими и производительными (например, MP4, переданные с помощью тега video ), и их можно легко подгрузить, автоматически запустить и поделится им (например, как с нашим старым другом, GIF).
Так насколько быстрее это будет? Откройте инструменты разработчика и посмотрите разницу между Safari Technology Preview и другими браузерами:
К сожалению, Safari не очень хорошо работает с WebPageTest, и создание надежных тестовых бенчмарков довольно затруднительно. Аналогично, использование Tech Preview довольно мало, поэтому сравнение производительности с инструментами RUM пока что не практично.
Однако мы можем сделать две вещи. Во-первых, сравнивать размеры необработанных байтов, а во-вторых, использовать правило Image.decode () для измерения воздействия различных ресурсов на устройство.
Экономия памяти
Первое-это экономия памяти. Для сравнения я перекодировал 100 популярных анимированных gif изображений с сайта giphy.com а затем конвертировал их в vp8 / vp9 / webp / h264 / h265.
NB: Эти результаты следует рассматривать только как поверхностные. Каждый кодек может быть настроен гораздо лучше, так как вы можете видеть, что результат с vp9 хуже, чем с vp8. Необходимо провести более комплексное исследование, которое учитывает SSIM.
Ниже приведены медианные (p50) результаты преобразования:
Да, анимированный WebP имеет небольшой размер, но любой формат видео имеет размер намного меньше. Это никого не должно удивлять, поскольку современные видеокодеки очень оптимизированы для потоковой передачи онлайн-видео. Алгоритмы H.265 очень хороши, как я ожидал, AV1 тоже.
Улучшение декодирования и визуальной производительности
Далее рассмотрим влияние эффектов декодирования и отображения на просмотр. H.264 (и H.265) имеет значительное преимущество в том, что они используют аппаратное декодирование вместо использования основного ядра.
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, вы можете видеть, что использование видео имеет существенные преимущества в производительности.
Как вы можете реализовать это?
Итак, теперь, когда Safari Technology Preview поддерживает этот шаблон дизайна, но как вы можете его использовать, не выводя поврежденные изображения на не поддерживаемые браузеры? Хорошие новости! Это относительно легко.
Вариант 1: Использовать адаптивные изображения
Я хотел бы сказать, что мы можем остановиться на этом. Тем не менее, есть неприятная ошибка 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 это выглядело бы примерно так:
Вариант 3: используйте RESS и тег «video»
Если вы можете манипулировать своим HTML, вы можете применить технологию «Responsive-server-side» (RESS). Этот параметр переводит логику обнаружения браузера в ваш вывод HTML.
Например, вы можете сделать это с помощью PHP:
Бонус: не забудьте удалить звуковую дорожку
Теперь, поскольку вы не конвертируете GIF в MP4, а скорее конвертируете MP4 в GIF, мы также должны помнить о том, что нужно удалить звуковую дорожку для экономии памяти. (Скажите, пожалуйста, что вы не используете GIF в качестве исходника. Правильно.) Аудиодорожки занимают дополнительные байты в размере файла, которые мы можем просто освободить, так как знаем, что он будет воспроизводиться без звука в любом случае. Самый простой способ с ffmpeg:
Существуют ли ограничения по размеру
Что дальше. Адаптивные видео и фоновые видео
Видео в CSS background-image: url (.mp4) тоже работает.
GIF изнутри
Вам когда-нибудь было интересно, как устроены gif-ки? В данной статье попробуем разобраться с внутренним строением GIF-формата и методом сжатия LZW.
Структура GIF
Файл в формате GIF состоит из фиксированной области в начале файла, за которой располагается переменное число блоков, и заканчивается файл завершителем изображения.
Основные характеристики формата 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] — конец блока.
Блок изображения
[00 00] [00 00] — номер строки и столбца. Определяет координаты верхнего левого угла логического экрана. (0, 0).
[04 00] [04 00] — ширина и высота изображения в пикселях.
[00] —
    (0) – флаг использования локальной таблицы цветов
    (0) – флаг чересстрочной развертки. Указывает, в каком порядке считываются пиксели изображения.
                0 – по строкам слева направо, сверху вниз
                1 – порядок:0-я. 8-я, 16-я…, 4-я, 12-я, 24-я…
    (0) – флаг сортировки локальной таблицы цветов. Если 1, то цвета в локальной карте цветов отсортированы в порядке убывающей важности.
    (00) – зарезервированы.
    (000) – флаг PIXEL. Размер локальной таблицы цветов, если есть.
[03] — минимальный размер кода в LZW.
[08] — размер последующего блока в байтах.
[08 0A D2 42 90 94 59 12] — блок данных, сжатых алгоритмом LZW. Представлены в виде последовательности кодов, имеющих длину [мин. размер кода] + 1
[00] — окончание потока данных.
Разбор алгоритма LZW
Кадр 1
Словарь инициализирован по количеству цветов и кодами
Решим обратную задачу. Возьмем исходные данные изображения и закодируем их с использованием алгоритма LZW. Под исходными данными понимаем последовательность индексов цветов из словаря, соответствующих каждому из пикселей. Пискели рассматриваем сверху вниз, слева направо.
| Step | Action | Index Stream | New Code Table Row | Code Stream |
|---|---|---|---|---|
| 1 | Init | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 | |
| 2 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 | |
| 3 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #10 – 0 0 | #8 #0 |
| 4 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 | |
| 5 | Found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 | |
| 6 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 | |
| 7 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #11 – 0 0 0 | #8 #0 #10 |
| 8 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 | |
| 9 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #12 – 0 2 | #8 #0 #10 #0 |
| 10 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 | |
| 11 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #13 – 2 2 | #8 #0 #10 #0 #2 |
| 12 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 | |
| 13 | Found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 | |
| 14 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 | |
| 15 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #14 – 2 2 2 | #8 #0 #10 #0 #2 #13 |
| 16 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 | |
| 17 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #15 – 2 4 | #8 #0 #10 #0 #2 #13 #2 |
| 18 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 | |
| 19 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #16 – 4 4 | #8 #0 #10 #0 #2 #13 #2 #4 |
| 20 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 | |
| 21 | Found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 | |
| 22 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 | |
| 23 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #17 – 4 4 4 | #8 #0 #10 #0 #2 #13 #2 #4 #16 |
| 24 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 | |
| 25 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #18 – 4 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 |
| 26 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 | |
| 27 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #19 – 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 #5 |
| 28 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 #5 | |
| 29 | Found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 #5 | |
| 30 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 #5 | |
| 31 | Not found | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #20 –5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 #5 #19 |
| 32 | Read | 0 0 0 0 2 2 2 2 4 4 4 4 5 5 5 5 | #8 #0 #10 #0 #2 #13 #2 #4 #16 #4 #5 #19 #5 #9 |
Теперь сравним результат кодирования со сжатыми данными, хранящимися в дампе. Формат GIF в данном блоке хранит многобайтовые целые числа с младшим байтом на первом месте (прямой порядок байтов).
[08 0A D2 42 90 94 59 12] — блок данных, сжатых алгоритмом LZW.
Аналогично поступаем со вторым кадром.
Кадр 2
| Step | Action | Index Stream | New Code Table Row | Code Stream |
|---|---|---|---|---|
| 1 | Init | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 | |
| 2 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 | |
| 3 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #10 – 3 6 | #8 #3 |
| 4 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 | |
| 5 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #11 – 6 1 | #8 #3 #6 |
| 6 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 | |
| 7 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #12 – 1 7 | #8 #3 #6 #1 |
| 8 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 | |
| 9 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #13 – 7 3 | #8 #3 #6 #1 #7 |
| 10 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 | |
| 11 | Found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1#7 | |
| 12 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1#7 | |
| 13 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #14 – 3 6 1 | #8 #3 #6 #1 #7 #10 |
| 14 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 | |
| 15 | Found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 | |
| 16 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 | |
| 17 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #15 – 1 7 3 | #8 #3 #6 #1 #7 #10 #12 |
| 18 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 | |
| 19 | Found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 | |
| 20 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 | |
| 21 | Found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 | |
| 22 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 | |
| 23 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #16 – 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 |
| 24 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 | |
| 25 | Found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 | |
| 26 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 | |
| 27 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #17 – 7 3 6 | #8 #3 #6 #1 #7 #10 #12 #14 #13 |
| 28 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 #13 | |
| 29 | Found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 #13 | |
| 30 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 #13 | |
| 31 | Not found | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #18 – 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 #13 #11 |
| 32 | Read | 3 6 1 7 3 6 1 7 3 6 1 7 3 6 1 7 | #8 #3 #6 #1 #7 #10 #12 #14 #13 #11 #7 #9 |
[38 16 A7 EC 6D 9D 04] — блок данных, сжатых алгоритмом LZW.
Блок завершения файла GIF
Заключение
На этом всё. Надеемся, эта статья была полезна для вас (ну или хотя бы интересна).