Итак, как же понимать то, что произошло под конец апрѣля с фото кота?
Чтобы хорошо объяснить это, предлагаю такой мысленный эксперимент.
Вообразите себе нѣкоего поклонника качественной отправки иллюстраций в Telegram, который терпеливо раз за разом повторяет четыре простых шага:
① Понижает объём и качество иллюстрации, совершая переужатие в JPEG. Напримѣръ, использует ImageMagick и MozJPEG командою «magick convert имяИсходногоФайла -background black -alpha remove -alpha off ppm:- | cjpeg -quality числоБалловКачества -outfile итог.jpg», от раза к разу понижая число баллов качества. (Часть параметров этой команды вписаны на случай переужатия частично прозрачных изображений и подкладывают под них чёрный фон, так так формат JPEG не поддерживает прозрачность.)
② Опосля переужатия контролирует удѣльный объёмъ (то есть количество битов, приходящихся в среднем на один пиксел изображения). Напримѣръ, использует архив libwebp и подаёт команду «get_disto итог.jpg итог.jpg», глядя только на послѣднее из выводимых ею чисел (количество bpp, то есть битов на пиксел).
③ Совершает пробную отправку получившегося файла в Telegram, причём непремѣнно из Telegram Desktop. Напримѣръ, кладёт файл JPEG в чат «Saved Messages» или использует отложенную отправку в другом чате.
④ Жмякнув мышóю только что отправленный файл, пересохраняет его на диск и сверяет с отправленным, чтобы увидать, насколько Telegram Desktop ухудшил качество при отправке.
Такой экспериментатор непремѣнно обнаружил бы, что постепенное уменьшение числа баллов качества MozJPEG (от 100 до 0) приводит и к постепенному уменьшению количества bpp (хотя и не в прямой пропорциональности). Это соѿвѣтствуетъ здравому смыслу и не создаёт никакого сюрприза.
Такой экспериментатор непремѣнно обнаружил бы также, что как только постепенное уменьшение качества приводит к тому, что количество bpp уменьшается ниже четырёх, так сразу и наступает отказ от переужатия: файл, пересохраняемый из «отложки» в Telegram Desktop, байт-в-байт идентичен отправляемому. То есть у файлов, сохраняемых на четвёртом шаге, наблюдается значительный «пик качества».
Дык вот и я обнаружил то же сáмое; только, в отличие от воображаемого экспериментатора, мнѣ не потребовалося проявлять для того гигантское терпение, а достаточно было прочитать соѿвѣтствующій кусок исходного кода Telegram Desktop.
На этом этапе очень легко было обрадоваться и даже прийти въ непомѣрный восторг при мысли о том, что всѣмъ тѣмъ авторам каналов, которые публикуют не только и не столько тексты, сколько красочные иллюстрации (фотографии, живопись, кинокадры, мемы, etc.), можно рѣзко нарастить качество иллюстраций, соблюдая всего четыре несложных правила:
⓵ Самостоятельно сжать иллюстрацию, не довѣряя её сжатие Telegram Desktop, но удерживаясь въ предѣлахъ 4 bpp. (Потратив минуту-другую на перебор параметров, можно поднырнуть под 4 bpp в районе 95 баллов качества MozJPEG, тогда как Telegram Desktop всегда понижает до 87 баллов, поскольку стремится быстрѣе отправить файл и для того сжать его за один раз, не утруждая пользователя ожиданием такого болѣе качественного итога, который потребовал бы долгого перебора вариантов сжатия.)
⓶ Использовать не построчное хранение пикселов JPEG, а постепенную «наводку на рѣзкость» («progressive JPEG»).
⓷ Ни ширина, ни высота иллюстрации не должна быть больше 1280 пикселов.
⓸ Отправить иллюстрацию непремѣнно из Telegram Desktop.
Но, к сожалению, эта мысль и этот восторг были преувеличенными и невѣрными: хотя Telegram Desktop отказался от переужатия таких файлов JPEG, и без того изрядно сжатых (4 bpp — не ахти какой объём файла), но от переужатия не отказалася сёрверная часть Телеграма, так что любыя усилія, нацѣленныя на достиженіе наивысшаго качества въ предѣлахъ 4 bpp, оказываются похѣренными переужатием.
Могу только в очередной раз призвать всѣхъ вас залогиниться на официальном сайте жалоб и предложений Telegram и прологосовать за предложение об отказе от переужатия JPEG в JPEG, совершаемого на сёрверной стороне.
К нынешнему дню это предложение получило 107 голосов за него, 3 гóлоса против него.
Чтобы хорошо объяснить это, предлагаю такой мысленный эксперимент.
Вообразите себе нѣкоего поклонника качественной отправки иллюстраций в Telegram, который терпеливо раз за разом повторяет четыре простых шага:
① Понижает объём и качество иллюстрации, совершая переужатие в JPEG. Напримѣръ, использует ImageMagick и MozJPEG командою «magick convert имяИсходногоФайла -background black -alpha remove -alpha off ppm:- | cjpeg -quality числоБалловКачества -outfile итог.jpg», от раза к разу понижая число баллов качества. (Часть параметров этой команды вписаны на случай переужатия частично прозрачных изображений и подкладывают под них чёрный фон, так так формат JPEG не поддерживает прозрачность.)
② Опосля переужатия контролирует удѣльный объёмъ (то есть количество битов, приходящихся в среднем на один пиксел изображения). Напримѣръ, использует архив libwebp и подаёт команду «get_disto итог.jpg итог.jpg», глядя только на послѣднее из выводимых ею чисел (количество bpp, то есть битов на пиксел).
③ Совершает пробную отправку получившегося файла в Telegram, причём непремѣнно из Telegram Desktop. Напримѣръ, кладёт файл JPEG в чат «Saved Messages» или использует отложенную отправку в другом чате.
④ Жмякнув мышóю только что отправленный файл, пересохраняет его на диск и сверяет с отправленным, чтобы увидать, насколько Telegram Desktop ухудшил качество при отправке.
Такой экспериментатор непремѣнно обнаружил бы, что постепенное уменьшение числа баллов качества MozJPEG (от 100 до 0) приводит и к постепенному уменьшению количества bpp (хотя и не в прямой пропорциональности). Это соѿвѣтствуетъ здравому смыслу и не создаёт никакого сюрприза.
Такой экспериментатор непремѣнно обнаружил бы также, что как только постепенное уменьшение качества приводит к тому, что количество bpp уменьшается ниже четырёх, так сразу и наступает отказ от переужатия: файл, пересохраняемый из «отложки» в Telegram Desktop, байт-в-байт идентичен отправляемому. То есть у файлов, сохраняемых на четвёртом шаге, наблюдается значительный «пик качества».
Дык вот и я обнаружил то же сáмое; только, в отличие от воображаемого экспериментатора, мнѣ не потребовалося проявлять для того гигантское терпение, а достаточно было прочитать соѿвѣтствующій кусок исходного кода Telegram Desktop.
На этом этапе очень легко было обрадоваться и даже прийти въ непомѣрный восторг при мысли о том, что всѣмъ тѣмъ авторам каналов, которые публикуют не только и не столько тексты, сколько красочные иллюстрации (фотографии, живопись, кинокадры, мемы, etc.), можно рѣзко нарастить качество иллюстраций, соблюдая всего четыре несложных правила:
⓵ Самостоятельно сжать иллюстрацию, не довѣряя её сжатие Telegram Desktop, но удерживаясь въ предѣлахъ 4 bpp. (Потратив минуту-другую на перебор параметров, можно поднырнуть под 4 bpp в районе 95 баллов качества MozJPEG, тогда как Telegram Desktop всегда понижает до 87 баллов, поскольку стремится быстрѣе отправить файл и для того сжать его за один раз, не утруждая пользователя ожиданием такого болѣе качественного итога, который потребовал бы долгого перебора вариантов сжатия.)
⓶ Использовать не построчное хранение пикселов JPEG, а постепенную «наводку на рѣзкость» («progressive JPEG»).
⓷ Ни ширина, ни высота иллюстрации не должна быть больше 1280 пикселов.
⓸ Отправить иллюстрацию непремѣнно из Telegram Desktop.
Но, к сожалению, эта мысль и этот восторг были преувеличенными и невѣрными: хотя Telegram Desktop отказался от переужатия таких файлов JPEG, и без того изрядно сжатых (4 bpp — не ахти какой объём файла), но от переужатия не отказалася сёрверная часть Телеграма, так что любыя усилія, нацѣленныя на достиженіе наивысшаго качества въ предѣлахъ 4 bpp, оказываются похѣренными переужатием.
Могу только в очередной раз призвать всѣхъ вас залогиниться на официальном сайте жалоб и предложений Telegram и прологосовать за предложение об отказе от переужатия JPEG в JPEG, совершаемого на сёрверной стороне.
К нынешнему дню это предложение получило 107 голосов за него, 3 гóлоса против него.