Драма, нѣсколькими словами очерченная въ послѣднемъ абзаце предшествующего сообщения, началась ещё в январе 2015 года, когда во блогозаписи «Stickers Done Right» пользователей Телеграма обрадовали извѣстіемъ о появлении поддержки стикеров. Так как тогда в первом из стикерпаков стикеров было не очень много (меньше полутора десятков!), то пользователям предложено было создавать свои собственные стикеры в качестве частично прозрачных изображений и сохранять их в WebP, а каждый клиент Telegram (такой, как Telegram Desktop, напримѣръ) с этого дня начал отображать любой файл WebP, скинутый в чат, в качестве стикера. Во блогозаписи восхвалялася способность WebP хорошо сжимать частично прозрачные изображения — способность, благодаря которой Telegram сдѣлался способным отображать стикеры впятеро быстрее, чѣмъ во прочих мессенджерах. Мѣсяца через четыре (в мае того же 2015 года) не только свои стикеры, но и свои наборы стикеров стало можно создавать, отправляя боту @stickers частично прозрачные изображения в формате PNG, помѣщающиеся в квадрат 512×512 пикселов вплотную (то есть одна из сторон прямоугольника прозрачного холста такого изображения должна быть равною 512px, а вторая — равна или меньше).
Всё это было (да и остаётся) таким ошарашивающим монументом живѣйшаго абсурда, что вопросов от недоумения при его виде появляется так много и так сразу, что поневоле приходится остановиться даже в раздумьях о том, в каком порядке задавать их.
Если в Telegram Desktop нажать на скрепку и выбрать графический файл для вбрасывания его в чат, то появляется переключатель с позициями «Send as a photo» и «Send as a file». Что помѣшало прибавить к нему ещё третью позицию «Send as a sticker» для всѣхъ графических файлов (или только для WebP), а не создавать тождество сущностей «WebP» и «стикер»?
Если разработчики Telegram обнаружили (и похвалили!) высокую эффективность сжатия WebP, то что могло заставить их ограничиться её использованием только для стикеров? Почему нельзя хранить в этом формате и многое другое для экономии объёма и для ускорения передачи и приёма? Разве нѣтъ таких изображений, которые можно было бы конвертировать при отправке не в JPEG с потерями, а в lossless WebP без потерь, причём попробовать при отправке оба формата и выбросить JPEG, если файл lossless WebP меньше его, и тѣмъ достигнуть экономии по объёму, а не одной только безупречности внѣшняго вида нѣкоторыхъ изображений? (Подозреваю, что изрядная часть канала @PixeLove могла бы и обойтись без проJPEGовывания, и приходить к подписчикам побыстрее.) А разве нѣтъ таких GIF-анимаций, которые можно было бы конвертировать при отправке не в MP4 с потерями (и начать это с 2016 г.), а в анимированный lossless WebP без потерь (и начать это с 2015 г.), и притом с большей экономией по объёму? (Вряд ли вышеупомянутый примѣръ из хвоста гугловского FAQ о WebP единственен.)
А что там с использованием WebP не как внутрителеграмного хранилища, а как первоисточника изображения (пускай затѣмъ и преобразуемого в JPEG или MP4 при отправке)? Как можно восхвалять формат WebP за его степень сжатия изображений, но не готовиться к тому, что люди в так называемом реальномъ мірѣ (за предѣлами Телеграма) также пользуются этим форматом (восхваляя его также и за то же) и оттого они начнут рано или поздно притаскивать и в Telegram используемые ими изображения в файлах WebP — да такие, при создании которых никто и не мыслил об этих изображениях как о стикерах для Телеграма? Почему на эти файлы нельзя воздѣйствовать переключателем с позициями «Send as a photo» и «Send as a file»? Если во блогозаписи «Stickers Done Right» от стикера требуется прозрачность, то почему непрозрачные изображения из файлов WebP также стикеризуются? Если бот @stickers требует от стикера соѿвѣтствіе опредѣлённымъ размѣрам, то почему изображения из файлов WebP других размѣровъ также стикеризуются? Наконец, если анимированными стикерами работают не анимированные WebP, а экспортированные векторные изображения из Adobe After Effects, то почему из содержимого файлов animated WebP вырѣзается первый кадр анимации и также стикеризуется?
Всё это было (да и остаётся) таким ошарашивающим монументом живѣйшаго абсурда, что вопросов от недоумения при его виде появляется так много и так сразу, что поневоле приходится остановиться даже в раздумьях о том, в каком порядке задавать их.
Если в Telegram Desktop нажать на скрепку и выбрать графический файл для вбрасывания его в чат, то появляется переключатель с позициями «Send as a photo» и «Send as a file». Что помѣшало прибавить к нему ещё третью позицию «Send as a sticker» для всѣхъ графических файлов (или только для WebP), а не создавать тождество сущностей «WebP» и «стикер»?
Если разработчики Telegram обнаружили (и похвалили!) высокую эффективность сжатия WebP, то что могло заставить их ограничиться её использованием только для стикеров? Почему нельзя хранить в этом формате и многое другое для экономии объёма и для ускорения передачи и приёма? Разве нѣтъ таких изображений, которые можно было бы конвертировать при отправке не в JPEG с потерями, а в lossless WebP без потерь, причём попробовать при отправке оба формата и выбросить JPEG, если файл lossless WebP меньше его, и тѣмъ достигнуть экономии по объёму, а не одной только безупречности внѣшняго вида нѣкоторыхъ изображений? (Подозреваю, что изрядная часть канала @PixeLove могла бы и обойтись без проJPEGовывания, и приходить к подписчикам побыстрее.) А разве нѣтъ таких GIF-анимаций, которые можно было бы конвертировать при отправке не в MP4 с потерями (и начать это с 2016 г.), а в анимированный lossless WebP без потерь (и начать это с 2015 г.), и притом с большей экономией по объёму? (Вряд ли вышеупомянутый примѣръ из хвоста гугловского FAQ о WebP единственен.)
А что там с использованием WebP не как внутрителеграмного хранилища, а как первоисточника изображения (пускай затѣмъ и преобразуемого в JPEG или MP4 при отправке)? Как можно восхвалять формат WebP за его степень сжатия изображений, но не готовиться к тому, что люди в так называемом реальномъ мірѣ (за предѣлами Телеграма) также пользуются этим форматом (восхваляя его также и за то же) и оттого они начнут рано или поздно притаскивать и в Telegram используемые ими изображения в файлах WebP — да такие, при создании которых никто и не мыслил об этих изображениях как о стикерах для Телеграма? Почему на эти файлы нельзя воздѣйствовать переключателем с позициями «Send as a photo» и «Send as a file»? Если во блогозаписи «Stickers Done Right» от стикера требуется прозрачность, то почему непрозрачные изображения из файлов WebP также стикеризуются? Если бот @stickers требует от стикера соѿвѣтствіе опредѣлённымъ размѣрам, то почему изображения из файлов WebP других размѣровъ также стикеризуются? Наконец, если анимированными стикерами работают не анимированные WebP, а экспортированные векторные изображения из Adobe After Effects, то почему из содержимого файлов animated WebP вырѣзается первый кадр анимации и также стикеризуется?