猫、 #Геленджик, Геленджикский проспект, 25 апрѣля.
Эта фотография уменьшена до 1280 пикселов ширины, затѣмъ сжата посредством jpegli с параметром «--distance=1.567» (сборкою cjpegli, датированною 16 мая и основанною вон на том коммите репозитория JPEG XL), затѣмъ доужата без внесения потерь (посредством jpegoptim версии 1.5.3).
Ея нынѣшній объёмъ позволяет этой фотографии попасть в Telegram без дополнительного переужатия JPEG-в-JPEG, совершаемого на стороне сёрвера Telegram (переужатие-то происходит, но сёрвер получает, по-видимому, результат большего объёма и оттого использует мой вариант фото, а не переужатый).
Эта фотография — примѣръ, иллюстрирующий собою мысль двух послѣднихъ абзацев предшествующего сообщения:
если хотя бы каждый двадцатый пользователь Телеграма будет стремиться к достижению болѣе высокого качества иллюстраций, чѣмъ обеспечиваемое сжатием на сёрвере,
и притом если каждый такой пользователь будет подбирать желаемую величину качества, своему кодировщику JPEG указываемую, до третьего знака послѣ запятой (как я подобрал величину «1.567»: это не механическое сочетание подряд идущих цифр «5», «6» и «7» — я провѣрилъ величину «1.566» и убедился в том, что порождаемый ею больший файл подвергается переужатию в Telegram),
и притом если каждый такой пользователь будет пользоваться вышеозначенным «альбомным методом» для избавления себя от слишком частой очистки кэша, то есть если он будет сперва посылать альбом вариантов иллюстрации, созданных нѣсколькими значениями первого знака послѣ запятой (от «1.1» до «1.6», напримѣръ), затѣмъ альбом из девяти вариантов для второго знака послѣ запятой (от «1.51» до «1.59» в моём примѣрѣ), затѣмъ альбом из девяти вариантов третьего знака (от «1.561» до «1.569» в моём примѣрѣ),
то тогда 5% пользователей (даже желая отправлять фото в том же темпе, что и остальные пользователи Телеграма) создадут больше ½ хранимых Телеграмом иллюстраций.
Предпочтёт ли тогда Telegram сдѣлать сёрверное переужатие не столь обязательным? Предпочтёт ли наказывать таких пользователей?
Эта фотография уменьшена до 1280 пикселов ширины, затѣмъ сжата посредством jpegli с параметром «--distance=1.567» (сборкою cjpegli, датированною 16 мая и основанною вон на том коммите репозитория JPEG XL), затѣмъ доужата без внесения потерь (посредством jpegoptim версии 1.5.3).
Ея нынѣшній объёмъ позволяет этой фотографии попасть в Telegram без дополнительного переужатия JPEG-в-JPEG, совершаемого на стороне сёрвера Telegram (переужатие-то происходит, но сёрвер получает, по-видимому, результат большего объёма и оттого использует мой вариант фото, а не переужатый).
Эта фотография — примѣръ, иллюстрирующий собою мысль двух послѣднихъ абзацев предшествующего сообщения:
если хотя бы каждый двадцатый пользователь Телеграма будет стремиться к достижению болѣе высокого качества иллюстраций, чѣмъ обеспечиваемое сжатием на сёрвере,
и притом если каждый такой пользователь будет подбирать желаемую величину качества, своему кодировщику JPEG указываемую, до третьего знака послѣ запятой (как я подобрал величину «1.567»: это не механическое сочетание подряд идущих цифр «5», «6» и «7» — я провѣрилъ величину «1.566» и убедился в том, что порождаемый ею больший файл подвергается переужатию в Telegram),
и притом если каждый такой пользователь будет пользоваться вышеозначенным «альбомным методом» для избавления себя от слишком частой очистки кэша, то есть если он будет сперва посылать альбом вариантов иллюстрации, созданных нѣсколькими значениями первого знака послѣ запятой (от «1.1» до «1.6», напримѣръ), затѣмъ альбом из девяти вариантов для второго знака послѣ запятой (от «1.51» до «1.59» в моём примѣрѣ), затѣмъ альбом из девяти вариантов третьего знака (от «1.561» до «1.569» в моём примѣрѣ),
то тогда 5% пользователей (даже желая отправлять фото в том же темпе, что и остальные пользователи Телеграма) создадут больше ½ хранимых Телеграмом иллюстраций.
Предпочтёт ли тогда Telegram сдѣлать сёрверное переужатие не столь обязательным? Предпочтёт ли наказывать таких пользователей?