Хабрахабр

Безумный конвертер GIF’ок в анимированные стикеры для Telegram

Вместо тысячи слов...

xZibit тоже рад, ведь здесь GIF вставлены в стикеры, чтобы быть вставлеными в GIF для КДПВ!

А теперь о подробностях реализации.
Всё началось с дискуссии в чатике Telegram-разработчиков о грядущей фиче:

07. Bohdan Horbeshko, [04.  | Vitaly, [04. 19 20:21] Мда, а бот наверняка будет принимать только gif, и потом конвертить... 19 20:22] с гифа в джейсон? 07. 07.  я бы посмотрел :))) | Bohdan Horbeshko, [04.  Вон PlayCanvas'овский редактор модельки в JSON конвертит. 19 20:22] А почему нет? 07.  | Vitaly, [04.  попиксельно экспортировать? 19 20:23] а гиф как? 07.  :) | Bohdan Horbeshko, [04. 19 20:24] Конечно, мир IT и не такие извращения видал, стерпит.

Первый прототип на Pillow и svgwrite, разбирающий GIF'ку на пиксели и преобразующий их в векторные квадратики с предпросмотром в SVG, был написан за один выходной. Мужик сказал — мужик сделал!

Веселье началось дальше…

JSON — открытый формат, говорили они...

Доселе с форматами в Telegram то и дело хитрили. Сделали поддержку GIF-анимаций — на самом деле они конвертируются в MP4-видео. Сделали поддержку стикеров — выгружаются они в PNG, но преобразуются в WebP. В этот раз всё честнее: что на входе, то и на выходе.

В нём задействован новомодный формат, вышедший из-под крыла Airbnb — Lottie. Для анимированных стикеров в Telegram используется не GIF, не видео, и даже не какой-нибудь устоявшийся формат векторной графики типа SVG или — упаси Ктулху! — Flash. Доселе он имел некоторую известность в среде мобильных разработчиков, но благодаря Telegram, возможно, обретёт бо́льшую популярность.

С отображением, увы, всё не так радужно. По сути своей, файлы Lottie являются сериализованными в JSON проектами Adobe After Effects, по максимуму реализующими все возможности этой программы. В Telegram пошли ещё дальше и ограничили перечень поддерживаемых возможностей, а также «придумали» свой формат, который отличается от обычного Lottie всего лишь упаковкой в GZip и параметром "tgs": 1. Хотя готовых «официальных» реализаций библиотеки для рендеринга Lottie и много, как раз под покрываемые Telegram платформы: Android, iOS, Qt и Web — лишь часть из возможностей формата реализована во всех из них. 🙂 Кажется, я знаю, где сейчас работает Денис Попов!

Пришлось попутно ковыряться в существующих анимациях, дабы понять общие концепции формата. И если с документацией на библиотеки для разных платформ всё довольно неплохо, то найти хоть какое-то описание устройства формата, увы, не удалось — только JSON-схему в исходниках lottie-web. Также обнаружились расхождения реальных файлов со схемой: в частности, в слоях типа 4, согласно схеме, вложенные объекты хранятся в свойстве "it" — однако в реальных файлах ключ называется "shapes", а "it" не работает.

Выясненные нюансы формата:

  • Файл состоит из слоёв. В отличие от GIF, здесь у каждого слоя может быть произвольное время начала и конца отображения. К слою можно (точнее, нужно) применять различные трансформации: масштабирование, повороты, изменение прозрачности и т.д. Слои могут быть даже трёхмерными (запрещено для Telegram).
  • Слой состоит из «фигур» (shapes). Типов у них много, некоторе нельзя использовать в Telegram. На практике, чтобы слой отобразился, он должен включать три фигуры: контур (в готовых анимациях это обычно тип "sh" — кривые Безье; конвертер пока использует только тип "rc" — прямоугольники), заливка (тип "fl") и трансформация (тип "tr").
  • Можно даже включать растровые элементы, создавать текстовые слои, устанавливать взаимосвязи параметров слоёв и фигур через выражения. Вся эта вкуснотища также запрещена в Telegram.

Отсюда прямо следует первая проблема: избыточность. Хотя в JSON-схему недавно добавлены значения по умолчанию для параметров трансформаций — в библиотеках они не реализованы. Так что задавать их в явном виде всё равно нужно.

Даже простенький GZip неплохо справляется со сжатием вопиюще повторяющихся данных, и 1 МБ сырого JSON магическим образом превращается в пару десятков килобайт, которые спокойно пролезают в заявленное ограничение в 64 кБ. Казалось бы, это и не проблема вовсе? Не тут-то было!

Загружаю я, значит, пухленькую анимацию, которая спокойно отображается lottie-web, в Telegram — и тут вместо условно красивого пиксель-арта на меня смотрит статическое размазанное вот это:

А оказалось, на разжатые данные тоже есть явно не указанное ограничение в 1 МБ. Что такое?! Представитель команды Telegram оперативно подтвердил его и сообщил о грядущем поднятии лимита до 2 МБ.

Так что придётся, видимо, соблюдать ограничения и впредь. Даже если эти проблемы решат — стикеры, выходящие за пределы 1 МБ несжатых данных и не содержащие трансформаций, окажутся недоступными для пользователей старых версий Telegram.

Прозрачность — это важно

Pillow, наряду с OpenCV, можно назвать индустриальным стандартом для обработки изображений в Python. Мало того, он неплохо заточен и под особенности GIF: поддерживает индексированные цвета, даёт доступ к палитре. Поддерживает преобразование пиксельной карты в NumPy-массив, что важно для продуктивной обработки. Даже статистику по цветам собирает! Но обнаружились и минусы:

  1. Не нашлось задокументированного способа получить индекс прозрачного цвета. Пришлось в качестве временного решения подразумевать, что прозрачный цвет — самый распространённый, но в реальных GIF'ках это не всегда так.
  2. То же самое с задержкой между кадрами: Pillow отдаёт только сами кадры как последовательность изображений, без информации о задержках.
  3. Иногда некорректно накладываются частичные кадры.

Посему пришлось искать замену. В качестве неё выступил модуль gif2numpy. Он «заточен» под особенности GIF и предоставляет доступ ко всем техническим свойствам как изображения, так и отдельных кадров, в том числе GCE. Таким образом, проблему считывания задержек он решает.

Благо, модуль состоит из одного файла, так что не составило труда включить его в проект и доработать, зарезервировав под прозрачность цвет #FE00FE. Прозрачность, как оказалось, gif2numpy не поддерживает вообще: цвета сразу преобразуются в три канала с разрядностью в байт, без учёта разрядности и сохранения индексов цветов.

gif2numpy пытается накладывать такие кадры на предыдущий, однако не проверяет параметры наложения, из-за чего также не всегда выходит правильный результат. Проблему с частичными кадрами решить оказалось нетривиально. А заодно приводит их к использованию глобальной палитры, что устранило необходимость отдельным образом обрабатывать прозрачный цвет при использовании собственной палитры кадра. Дабы не возиться с флагами, добавлена предварительная обработка изображений с помощью gifsicle с ключом --unoptimize — он преобразует частичные кадры в полные.

Сожми меня сильнее

Квадратики — это хорошо, но с такими ограничениями нужно проявить больше фантазии, иначе в Telegram не «пролезают» даже миниатюрные GIF'ки.

Первым в ход пошло нечто похоже на RLE: соседние по горизонтали квадратики одного цвета объединяются в один прямоугольник.

Поскольку каждый слой имеет произвольное время начала и конца — можно применить технику, которая давным-давно используется видеокодеками, и отчасти в самом GIF: квадратики, которые остаются на одном месте в течение нескольких кадров, можно слить в один слой, во время отображения которого сменяется несколько других. Далее — черёд эксплуатации особенностей Lottie. Что и реализовано, пока только для пар соседних слоёв.

Планы по развитию

Идей, которые здесь можно применить, навалом:

Ссылки

  • Исходники. Местами страшные.
  • Канал, на котором я выкладываю паки успешно сконвертированных GIF'ок.
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть