После ряда экспериментов можно догадываться, что и разработчики в Telegram также набрели на нѣкоторые из только что заданных мною вопросов (разумѣется, набрели даже раньше, чѣмъ я успѣлъ задать их) — и, задавшись ими, пришли к выводу о том, что придавать вид стикеров достаточно крупным файлам WebP не слѣдуетъ: методом тыка можно обнаружить, что достаточно крупные файлы WebP всё-таки отображаются почти «как файл» и в Telegram под Android, и в Telegram Desktop под Windows.
Я пишу «почти», потому что всякий другой файл, отправляемый «как файл», можно снабдить текстовою подписью до его отправки (а если выбрать в контекстном меню пункт редактирования, то и после отправки), однако же этакие достаточно крупные файлы WebP снабдить текстовою подписью никоим образом нельзя.
А ещё я неопредѣлённо пишу «достаточно крупные», поскольку это понятие, по-видимому, не было чётко опредѣлено и одинаково реализовано разработчиками. Можно обнаружить (и я обнаружил) такой файл WebP, который в Telegram Desktop под Windows будет выглядеть почти «как файл», однако в Telegram под Android будет показан как стикер. Болѣе того: это понятие, по-видимому, не привязано къ размѣру файла, так как можно обнаружить (и я обнаружил) два таких файла WebP одинаковаго размѣра (1920×2668 пикселов), из которых один файл (большего объёма, потому что lossless WebP) будет показан в Telegram под Android почти «как файл», а другой файл (меньшего объёма, потому что lossy WebP) в Telegram под Android будет показан как стикер.
То и другое и третье я считаю багом, о чём и сообщил в @BugReports, приложив всѣ обнаруженные примѣры.
Но иррациональность ситуации вокруг WebP в Telegram не исчерпывается вышеизложенными вопросами: можно задавать и другие.
Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому надо отправить WebP не как стикер, а как иллюстрацию или как файл? Зачѣмъ принуждать пользователя к преобразованию изображения из одного формата в другой при посредстве сторонней программы или чужого сайта, если сам Telegram, когда рѣчь идёт не о WebP, невозбранно способен прочитать изображение из PNG и пересохранить в JPEG? Мы же знаем, что и из WebP он также умѣетъ читать.
А какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому пришёл одиночный стикер (в формате WebP) и которому стикер настолько понравился, что пользователь захотел прибавить его къ нѣкоторому стикерпаку, но бот @stickers принимает только PNG и с болѣе жёсткими требованиями къ размѣру? Почему бот @stickers не принимает готовые WebP даже в том случае, когда они подходят по размѣру? (Если разработчики бота @stickers создают стикерпаки только в формате lossy WebP и притом опасаются накопления ошибок сжатия от послѣдовательных пересохранений из lossy WebP в lossy WebP, то можно же хотя бы lossless WebP принимать? Если были дополнительные опасения насчёт того, что начнут тогда из lossy WebP в lossless WebP перегонять для обхода ограничения, то тогда что мѣшаетъ сейчас из lossy WebP в PNG перегонять для обхода ограничения?)
Почему стикеры могут содержать прозрачные области, а обыкновенные иллюстрации — не могут? Нельзя ли частично прозрачные изображения обнаруживать и перегонять не в формат JPEG (вообще не поддерживающий прозрачность), а в формат WebP (дѣлая автоматический выбор в пользу lossy WebP или lossless WebP по объёму файла)?
Если анимированные GIF объёмом до 10 мегабайтов преобразуются в MP4 (для экономии объёма и траффика), а больше 10 мегабайтов не преобразуются (чтобы преобразовальник не надорвался), но всё же показываются анимированными, то нельзя ли то же самое дѣлать и с анимированными WebP, и с анимированными PNG? Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому нужно отослать анимированный WebP или анимированный PNG? Можно ли надеяться, что пользователь возьмёт в руки FFmpeg и самостоятельно создаст MP4 с потерей качества, если этакий-то пользователь может взять в руки и gifski, тѣмъ болѣе что объём получающегося GIF в Telegram ограничен аж 1½ гигабайтами?
Я пишу «почти», потому что всякий другой файл, отправляемый «как файл», можно снабдить текстовою подписью до его отправки (а если выбрать в контекстном меню пункт редактирования, то и после отправки), однако же этакие достаточно крупные файлы WebP снабдить текстовою подписью никоим образом нельзя.
А ещё я неопредѣлённо пишу «достаточно крупные», поскольку это понятие, по-видимому, не было чётко опредѣлено и одинаково реализовано разработчиками. Можно обнаружить (и я обнаружил) такой файл WebP, который в Telegram Desktop под Windows будет выглядеть почти «как файл», однако в Telegram под Android будет показан как стикер. Болѣе того: это понятие, по-видимому, не привязано къ размѣру файла, так как можно обнаружить (и я обнаружил) два таких файла WebP одинаковаго размѣра (1920×2668 пикселов), из которых один файл (большего объёма, потому что lossless WebP) будет показан в Telegram под Android почти «как файл», а другой файл (меньшего объёма, потому что lossy WebP) в Telegram под Android будет показан как стикер.
То и другое и третье я считаю багом, о чём и сообщил в @BugReports, приложив всѣ обнаруженные примѣры.
Но иррациональность ситуации вокруг WebP в Telegram не исчерпывается вышеизложенными вопросами: можно задавать и другие.
Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому надо отправить WebP не как стикер, а как иллюстрацию или как файл? Зачѣмъ принуждать пользователя к преобразованию изображения из одного формата в другой при посредстве сторонней программы или чужого сайта, если сам Telegram, когда рѣчь идёт не о WebP, невозбранно способен прочитать изображение из PNG и пересохранить в JPEG? Мы же знаем, что и из WebP он также умѣетъ читать.
А какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому пришёл одиночный стикер (в формате WebP) и которому стикер настолько понравился, что пользователь захотел прибавить его къ нѣкоторому стикерпаку, но бот @stickers принимает только PNG и с болѣе жёсткими требованиями къ размѣру? Почему бот @stickers не принимает готовые WebP даже в том случае, когда они подходят по размѣру? (Если разработчики бота @stickers создают стикерпаки только в формате lossy WebP и притом опасаются накопления ошибок сжатия от послѣдовательных пересохранений из lossy WebP в lossy WebP, то можно же хотя бы lossless WebP принимать? Если были дополнительные опасения насчёт того, что начнут тогда из lossy WebP в lossless WebP перегонять для обхода ограничения, то тогда что мѣшаетъ сейчас из lossy WebP в PNG перегонять для обхода ограничения?)
Почему стикеры могут содержать прозрачные области, а обыкновенные иллюстрации — не могут? Нельзя ли частично прозрачные изображения обнаруживать и перегонять не в формат JPEG (вообще не поддерживающий прозрачность), а в формат WebP (дѣлая автоматический выбор в пользу lossy WebP или lossless WebP по объёму файла)?
Если анимированные GIF объёмом до 10 мегабайтов преобразуются в MP4 (для экономии объёма и траффика), а больше 10 мегабайтов не преобразуются (чтобы преобразовальник не надорвался), но всё же показываются анимированными, то нельзя ли то же самое дѣлать и с анимированными WebP, и с анимированными PNG? Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому нужно отослать анимированный WebP или анимированный PNG? Можно ли надеяться, что пользователь возьмёт в руки FFmpeg и самостоятельно создаст MP4 с потерей качества, если этакий-то пользователь может взять в руки и gifski, тѣмъ болѣе что объём получающегося GIF в Telegram ограничен аж 1½ гигабайтами?