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

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


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

А теперь о подробностях реализации.

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



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

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

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

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

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

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

И если с документацией на библиотеки для разных платформ всё довольно неплохо, то найти хоть какое-то описание устройства формата, увы, не удалось — только 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. Таким образом, проблему считывания задержек он решает.

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

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

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

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

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

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

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

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

• Распознавать одноцветные области любого размера. Можно разбивать их на набор прямоугольников, для чего есть неплохой алгоритм. Также целесообразно преобразовывать их в контур, но это омрачается необходимостью указывать все точки кривых Безье в Lottie — прямоугольниками в некоторых случаях может быть выгоднее.
• Распознавать движение. Техника, опять-таки, издревле применяющаяся в видеокодеках. Если один и тот же контур не меняет форму от кадра к кадру, но лишь координаты — стоит вместо дублирования на нескольких слоях поместить его на один слой с трансформацией.
• Распознавать «накрытие» одних областей другими. Пример:
  
  

  ......
  .O..O.
  ......
  .OOOO.
  ......
  

  
  На прямоугольник одного цвета накладываются пиксели другого цвета. Вместо того, чтобы разбивать этот прямоугольник на кучу мелких, или пребразовывать в контур сложной формы — можно просто наложить их поверх целого прямоугольника.
• Векторизация кривых и эллипсов, распознавание градиентов. Это испортит пиксельный шарм, зато на порядки улучшит сжимаемость некоторых GIF'ок. Градиенты есть даже в допотопных «колобках», я гарантирую это!
• Сжатие с потерями. В первую очередь — устранение дизеринга, да и в излишне сглаженных картинках не помешает цвета поумерить. С этим наверняка справится вышеупомянутый gifsicle.

Ссылки

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