В смысле взаимного проигрыша положение Телеграма и его пользователей выглядит ещё хуже, чѣмъ обозначенное в предшествующем сообщении положение Твиттера.
Наступил ли Telegram на грабли отказа от поддержки новых форматов и необходимости быстрого сжатия в ущерб качеству? — да, наступил: вам не удастся обойтись без перекодирования в JPEG при отправке WebP или при отправке AVIF, и хотя (в отличие от твиттеровского О'Брайена) работники Телеграма никогда не сознавалися даже примѣрно, какой кодировщик JPEG употребляется на сёрвере, а всё-таки можно пристально вглядываться в его результаты и убедиться, что они хуже по качеству картинки, чѣмъ достигаемые в MozJPEG или в jpegli при равном объёме файла.
Наступил ли Telegram на грабли ограничения PNG и отказа от чётких ограничений на объём картинок в пользу болѣе частой перекодировки в JPEG? — ещё как наступил! Telegram зашёл по этому пути так далеко, как это вообще возможно: не только перекодирование PNG в JPEG происходит обязательно (даже тогда, когда при этом не только ухудшается качество картинки, но и возрастает объём ея), но и перекодирование из JPEG в JPEG обязательно и многократно. Переужатие JPEG-в-JPEG происходит перед отправкою (насколько я знаю, отключено оно только в Telegram Desktop и только для файлов JPEG, тратящих не больше полубайта на пиксел в среднем). Переужатие JPEG-в-JPEG происходило перед сохранением принятых файлов в Telegram Desktop до 9 марта 2022 г., а затѣмъ было выключено. Но важнѣе всего, что переужатие JPEG-в-JPEG (с внесением потерь в изображение) происходит на сёрверной стороне, а почему важнѣе? — потому, что сёрвер вносит наибольший вклад в сжатие изображений в Телеграме. Хорошо ещё, что (в отличие от переужатия PNG) результат сёрверного переужатия JPEG используется Телеграмом (отправляется собѣседникамъ, публикуется на канале, etc.) только тогда, когда он меньше отправленного JPEG по объёму.
Формально всё это позволяет пользователю Телеграма, располагая мощным кодировщиком (MozJPEG, jpegli и проч.), отправлять болѣе качественные файлы JPEG до тѣхъ поръ, пока он сжимает их ещё и сильнѣе (по объёму файла), а не просто качественнѣе, чѣмъ сам Telegram. Практически же ему приходится соревноваться с кодировщиком, модель и параметры работы которого не извѣстны, а также учитывать и влияние декодировщика (полученный на сёрвере файл JPEG сперва декодируется в пикселы, которые-то затѣмъ поступают кодировщику), модель и параметры работы которого также не извѣстны (но качество, во всяком случае, хуже knusperli).
Как может быть устроено такое соревнование?
Ну, напримѣръ, пользователь может постепенно наращивать степень сжатия JPEG до тѣхъ поръ, пока не найдёт пороговое значение, по достижению которого Telegram прекратит использование результата сёрверного сжатия.
А будет ли такой пользователь всякий раз опосля отправки очередного результата сжатия выходить из Saved Messages (или из отложенных, или куда он там отправил результат), затѣмъ чистить кэш (в Telegram Desktop для того надо зайти в меню Settings и жмякнуть подпункт Advanced → Manage local storage → Clear all), перезапускать клиент Телеграма, перезаходить и скачивать ужé обработанный на сёрвере (а не кэшированный на клиенте) файл JPEG, чтоб сравнить и увидать, перемѣнился ли объём его?
Вряд ли. Такія бѣшеныя затраты усилій трудно вообразить. Разумнѣе перебрать цѣлый диапазон параметров кодировщика (напримѣръ, запустить jpegli командою «cjpegli --distance=1.1» и затѣмъ перебирать до «cjpegli --distance=1.6» через одну десятую), составить альбом получившихся картинок, сразу весь отправить — тогда чистить кэш придётся только один раз перед скачиванием этого альбома. Найдя пороговое значение десятых долей, можно составить второй альбом (ужé из девяти картинок) для перебора сотых долей значения параметра (от 1.51 до 1.59, напримѣръ), затѣмъ третий альбом для перебора тысячных долей.
Такой пользователь зря тратит время, но и Telegram зря тратит хранилище, раз уж хранит даже стёртые картинки и даже в секретных чатах. Обязательность сжатия JPEG, задуманная для экономии, ≈удвадцатеряет эти взаимные потери.
Наступил ли Telegram на грабли отказа от поддержки новых форматов и необходимости быстрого сжатия в ущерб качеству? — да, наступил: вам не удастся обойтись без перекодирования в JPEG при отправке WebP или при отправке AVIF, и хотя (в отличие от твиттеровского О'Брайена) работники Телеграма никогда не сознавалися даже примѣрно, какой кодировщик JPEG употребляется на сёрвере, а всё-таки можно пристально вглядываться в его результаты и убедиться, что они хуже по качеству картинки, чѣмъ достигаемые в MozJPEG или в jpegli при равном объёме файла.
Наступил ли Telegram на грабли ограничения PNG и отказа от чётких ограничений на объём картинок в пользу болѣе частой перекодировки в JPEG? — ещё как наступил! Telegram зашёл по этому пути так далеко, как это вообще возможно: не только перекодирование PNG в JPEG происходит обязательно (даже тогда, когда при этом не только ухудшается качество картинки, но и возрастает объём ея), но и перекодирование из JPEG в JPEG обязательно и многократно. Переужатие JPEG-в-JPEG происходит перед отправкою (насколько я знаю, отключено оно только в Telegram Desktop и только для файлов JPEG, тратящих не больше полубайта на пиксел в среднем). Переужатие JPEG-в-JPEG происходило перед сохранением принятых файлов в Telegram Desktop до 9 марта 2022 г., а затѣмъ было выключено. Но важнѣе всего, что переужатие JPEG-в-JPEG (с внесением потерь в изображение) происходит на сёрверной стороне, а почему важнѣе? — потому, что сёрвер вносит наибольший вклад в сжатие изображений в Телеграме. Хорошо ещё, что (в отличие от переужатия PNG) результат сёрверного переужатия JPEG используется Телеграмом (отправляется собѣседникамъ, публикуется на канале, etc.) только тогда, когда он меньше отправленного JPEG по объёму.
Формально всё это позволяет пользователю Телеграма, располагая мощным кодировщиком (MozJPEG, jpegli и проч.), отправлять болѣе качественные файлы JPEG до тѣхъ поръ, пока он сжимает их ещё и сильнѣе (по объёму файла), а не просто качественнѣе, чѣмъ сам Telegram. Практически же ему приходится соревноваться с кодировщиком, модель и параметры работы которого не извѣстны, а также учитывать и влияние декодировщика (полученный на сёрвере файл JPEG сперва декодируется в пикселы, которые-то затѣмъ поступают кодировщику), модель и параметры работы которого также не извѣстны (но качество, во всяком случае, хуже knusperli).
Как может быть устроено такое соревнование?
Ну, напримѣръ, пользователь может постепенно наращивать степень сжатия JPEG до тѣхъ поръ, пока не найдёт пороговое значение, по достижению которого Telegram прекратит использование результата сёрверного сжатия.
А будет ли такой пользователь всякий раз опосля отправки очередного результата сжатия выходить из Saved Messages (или из отложенных, или куда он там отправил результат), затѣмъ чистить кэш (в Telegram Desktop для того надо зайти в меню Settings и жмякнуть подпункт Advanced → Manage local storage → Clear all), перезапускать клиент Телеграма, перезаходить и скачивать ужé обработанный на сёрвере (а не кэшированный на клиенте) файл JPEG, чтоб сравнить и увидать, перемѣнился ли объём его?
Вряд ли. Такія бѣшеныя затраты усилій трудно вообразить. Разумнѣе перебрать цѣлый диапазон параметров кодировщика (напримѣръ, запустить jpegli командою «cjpegli --distance=1.1» и затѣмъ перебирать до «cjpegli --distance=1.6» через одну десятую), составить альбом получившихся картинок, сразу весь отправить — тогда чистить кэш придётся только один раз перед скачиванием этого альбома. Найдя пороговое значение десятых долей, можно составить второй альбом (ужé из девяти картинок) для перебора сотых долей значения параметра (от 1.51 до 1.59, напримѣръ), затѣмъ третий альбом для перебора тысячных долей.
Такой пользователь зря тратит время, но и Telegram зря тратит хранилище, раз уж хранит даже стёртые картинки и даже в секретных чатах. Обязательность сжатия JPEG, задуманная для экономии, ≈удвадцатеряет эти взаимные потери.