В смысле взаимного проигрыша положение Телеграма и его пользователей выглядит ещё хуже, чѣмъ обозначенное в предшествующем сообщении положение Твиттера.
Наступил ли 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, задуманная для экономии, ≈удвадцатеряет эти взаимные потери.
👏1🤯1
猫、 #Геленджик, Геленджикский проспект, 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 сдѣлать сёрверное переужатие не столь обязательным? Предпочтёт ли наказывать таких пользователей?
👏5🤔2
Ну что, довольно мрачно прозвучали послѣднія абзацы моего предшествующего сообщения?
Во всяком случае, я не желал бы того, чтобы это выглядѣло как какая-нибудь угроза или ультиматум. Не я, а Telegram технически поставил себя в этакую не очень уютную ситуацию, закладываясь на нераспространённость стремления к большему качеству иллюстраций до такой степени, что даже пятипроцентная распространённость такого стремления среди пользователей ужé угрожала бы удвоить расходы на хранение иллюстраций. И хороший выход наружу из этой ситуации — только один: заблаговременное (то есть не требующее провѣрки загрузкою в Telegram) знание о том, когда иллюстрация будет принята «как есть», а когда окажется принудительно переужатою из JPEG в JPEG.
Это знание могло бы достигаться гласным отказом от сёрверного переужатия JPEG в случае небольших по размѣру или по объёму иллюстраций — я предлагал такой отказ болѣе двухъ лѣтъ назадъ, однако моё предложение до сих пор не было принято и реализовано.
Это знание также могло бы быть достигнуто, если бы пользователи у себя на компé способны были запускать то средство, которым сам Telegram пользуется для переужатия JPEG, и наглядно убеждаться в том, получается ли результат переужатия больше или меньше исходного файла, то есть будет ли этот файл принят «как есть» или будет для того нуждаться в самостоятельном дополнительном доужатии. Но, разумѣется, для того нужно знать достовѣрнѣйше, какое средство сжатия JPEG используется на сёрверной стороне. «Мы не знаем, что это такое — если б мы знали, что это такое! — мы не знаем, что это такое».
Ну хорошо. Мы не знаем. Но в каких случаях и с какой точностью можно догадываться о том, какое средство и с какими настройками использует Telegram для сжатия JPEG?
Кажется, у меня есть вариант ѿвѣта на этот вопрос: как О'Брайен уподобил твиттеровский кодировщик работе libjpeg-turbo, так поступлю и я с телеграмным кодировщиком и декодировщиком.
Установите libjpeg-turbo версии 2.1.5.1 (эта версия — наиболѣе послѣдняя, если не считать бета-версии) и обработайте провѣряемый файл такой командою:
① Точно ли эта команда имитирует результат сжатия на сёрвере? — нѣтъ, не точно! — но разница по объёму файла, как правило, не превосходит собою разницу между файлами JPEG, изготовленными с двумя сосѣдними настройками качества. Поэтому для подбора необходимого порогового качества часто годится.
② Почему libjpeg-turbo? — потому, что другого быстрого кодировщика JPEG ещё не было, когда создавали Telegram. По-видимому, Telegram пользуется если и не libjpeg-turbo, то каким-нибудь близким аналогом.
③ Почему 87? — потому, что исходный код Telegram Desktop использует это некруглое число. (Должно быть, разработчики сёрверных и клиентских программ сговорились об одном и том же количестве баллов качества, но используют разные кодировщики JPEG.)
④ Когда эта команда перестаёт давать пусть неточный, но хотя бы подходящий по объёму результат? — ну, напримѣръ, когда провѣряемымъ оказывается не «голый» JPEG, а снабжённый дополнительными заголовками метаданных, то тогда исчезает возможность полагаться не только на результат работы приведённой выше команды, но даже ещё и на предположение (всегда казавшееся неколебимо надёжным) о том, что Telegram не будет использовать «распухший JPEG» (результат переужатия из JPEG в JPEG, оказавшийся превосходящим исходный файл по объёму) и что, дескать, сравнение объёмов достаточно для предсказания поведения Telegram. Примѣръ этого — въ слѣдующемъ сообщении.
Во всяком случае, я не желал бы того, чтобы это выглядѣло как какая-нибудь угроза или ультиматум. Не я, а Telegram технически поставил себя в этакую не очень уютную ситуацию, закладываясь на нераспространённость стремления к большему качеству иллюстраций до такой степени, что даже пятипроцентная распространённость такого стремления среди пользователей ужé угрожала бы удвоить расходы на хранение иллюстраций. И хороший выход наружу из этой ситуации — только один: заблаговременное (то есть не требующее провѣрки загрузкою в Telegram) знание о том, когда иллюстрация будет принята «как есть», а когда окажется принудительно переужатою из JPEG в JPEG.
Это знание могло бы достигаться гласным отказом от сёрверного переужатия JPEG в случае небольших по размѣру или по объёму иллюстраций — я предлагал такой отказ болѣе двухъ лѣтъ назадъ, однако моё предложение до сих пор не было принято и реализовано.
Это знание также могло бы быть достигнуто, если бы пользователи у себя на компé способны были запускать то средство, которым сам Telegram пользуется для переужатия JPEG, и наглядно убеждаться в том, получается ли результат переужатия больше или меньше исходного файла, то есть будет ли этот файл принят «как есть» или будет для того нуждаться в самостоятельном дополнительном доужатии. Но, разумѣется, для того нужно знать достовѣрнѣйше, какое средство сжатия JPEG используется на сёрверной стороне. «Мы не знаем, что это такое — если б мы знали, что это такое! — мы не знаем, что это такое».
Ну хорошо. Мы не знаем. Но в каких случаях и с какой точностью можно догадываться о том, какое средство и с какими настройками использует Telegram для сжатия JPEG?
Кажется, у меня есть вариант ѿвѣта на этот вопрос: как О'Брайен уподобил твиттеровский кодировщик работе libjpeg-turbo, так поступлю и я с телеграмным кодировщиком и декодировщиком.
Установите libjpeg-turbo версии 2.1.5.1 (эта версия — наиболѣе послѣдняя, если не считать бета-версии) и обработайте провѣряемый файл такой командою:
\путь\к\djpeg -fast -dct float провѣряемый.jpg | \путь\к\cjpeg -progressive -quality 87 -outfile результат.jpgЕсли результат получится больше по объёму, чѣмъ провѣряемый файл JPEG (или меньше, но не болѣе чѣмъ на 256 байтов разницы), то тогда очень высока вѣроятность того, что провѣряемый файл будет принят «как есть» Телеграмом (но не забудьте отправить файл из Telegram Desktop, чтоб надёжно исключить ещё и переужатие файла, совершаемое перед отправкою), а переужат на стороне сёрвера он не будет. Но что значит «очень высока вѣроятность»? — на этот счёт я немедля должен сдѣлать сразу нѣсколько уточнений:
① Точно ли эта команда имитирует результат сжатия на сёрвере? — нѣтъ, не точно! — но разница по объёму файла, как правило, не превосходит собою разницу между файлами JPEG, изготовленными с двумя сосѣдними настройками качества. Поэтому для подбора необходимого порогового качества часто годится.
② Почему libjpeg-turbo? — потому, что другого быстрого кодировщика JPEG ещё не было, когда создавали Telegram. По-видимому, Telegram пользуется если и не libjpeg-turbo, то каким-нибудь близким аналогом.
③ Почему 87? — потому, что исходный код Telegram Desktop использует это некруглое число. (Должно быть, разработчики сёрверных и клиентских программ сговорились об одном и том же количестве баллов качества, но используют разные кодировщики JPEG.)
④ Когда эта команда перестаёт давать пусть неточный, но хотя бы подходящий по объёму результат? — ну, напримѣръ, когда провѣряемымъ оказывается не «голый» JPEG, а снабжённый дополнительными заголовками метаданных, то тогда исчезает возможность полагаться не только на результат работы приведённой выше команды, но даже ещё и на предположение (всегда казавшееся неколебимо надёжным) о том, что Telegram не будет использовать «распухший JPEG» (результат переужатия из JPEG в JPEG, оказавшийся превосходящим исходный файл по объёму) и что, дескать, сравнение объёмов достаточно для предсказания поведения Telegram. Примѣръ этого — въ слѣдующемъ сообщении.
👍5
if only you knew how bad things really are.xyb9.1.jpg
44.4 KB
Минимальный объём файла JPEG (если сравнивать при равном достигаемом качестве) в настоящее время достигается кодировщиком jpegli, работающим в режиме перевода иллюстрации въ цвѣтовое пространство XYB (этот способ мощнѣе, чѣмъ MozJPEG, на 30—35 процентов).
В качестве наглядного примѣра такого сжатия я прилагаю тут («как файл») иллюстрацию размѣромъ 1000×773 пиксела, сжатую до объёма 45418 байтов. Нетрудно раздѣлить и убедиться, что она тратит не болѣе половины бита на один пиксел в среднем.
На этой иллюстрации изображён один из самых мрачных (даже кровавых) вариантов стародавнего мрачного мема «If only you knew how bad things really are» («Если бы только вы знали, как плохи дѣла на сáмомъ дѣлѣ»). Если отправить этот файл из приложения Telegram Desktop (с марта 2022 года не переужимающего при отправке иллюстрации, не тратящие болѣе полубайта на пиксел в среднем и не превосходящие 1280 пикселов по большей стороне), причём отправлять не «как файл», а «как картинку» (поставить галочку «Compress the image» в Telegram Desktop), а затѣмъ выйти из чата и очистить кэш (выбрать пункт Settings → Advanced → Manage local storage → Clear all), а затѣмъ перезапустить Telegram Desktop и перезайти в чат, чтобы сохранить отправленную картинку и сравнить её объём с исходным, то тогда приходится наблюдать полную гармонию мрачного содержимого иллюстрации и мрачного результата её сохранения. Лично у меня сохранённым оказывается файл JPEG объёмом 91100 байтов, то есть превосходящий исходный файл по объёму — превосходящий болѣе чѣмъ в два раза!
Цвѣта пикселов этого файла (отправленного и «как файл», и «как картинка») притом показываются в Telegram Desktop под Windows искажёнными (пространство XYB использует профиль ICC четвёртой версии, а Telegram Desktop под Windows ограничивается поддержкою профилей ICC только второй версии, господствовавшей до 2001 года). Но сёрвер Телеграма не убирает этот профиль из файла и не вносит в профиль измѣненія, так что настоящая причина использования вдвое распухшего файла JPEG может оказаться и другою.
В качестве наглядного примѣра такого сжатия я прилагаю тут («как файл») иллюстрацию размѣромъ 1000×773 пиксела, сжатую до объёма 45418 байтов. Нетрудно раздѣлить и убедиться, что она тратит не болѣе половины бита на один пиксел в среднем.
На этой иллюстрации изображён один из самых мрачных (даже кровавых) вариантов стародавнего мрачного мема «If only you knew how bad things really are» («Если бы только вы знали, как плохи дѣла на сáмомъ дѣлѣ»). Если отправить этот файл из приложения Telegram Desktop (с марта 2022 года не переужимающего при отправке иллюстрации, не тратящие болѣе полубайта на пиксел в среднем и не превосходящие 1280 пикселов по большей стороне), причём отправлять не «как файл», а «как картинку» (поставить галочку «Compress the image» в Telegram Desktop), а затѣмъ выйти из чата и очистить кэш (выбрать пункт Settings → Advanced → Manage local storage → Clear all), а затѣмъ перезапустить Telegram Desktop и перезайти в чат, чтобы сохранить отправленную картинку и сравнить её объём с исходным, то тогда приходится наблюдать полную гармонию мрачного содержимого иллюстрации и мрачного результата её сохранения. Лично у меня сохранённым оказывается файл JPEG объёмом 91100 байтов, то есть превосходящий исходный файл по объёму — превосходящий болѣе чѣмъ в два раза!
Цвѣта пикселов этого файла (отправленного и «как файл», и «как картинка») притом показываются в Telegram Desktop под Windows искажёнными (пространство XYB использует профиль ICC четвёртой версии, а Telegram Desktop под Windows ограничивается поддержкою профилей ICC только второй версии, господствовавшей до 2001 года). Но сёрвер Телеграма не убирает этот профиль из файла и не вносит в профиль измѣненія, так что настоящая причина использования вдвое распухшего файла JPEG может оказаться и другою.
❤2👍2👎1
Твиттеровский API (сирѣчь программный интерфейс), мною используемый для считывания собственных микроблогозаписей и ретвитов, вдругорядь перестал работать под конец мая — и на сей раз, в отличие от аналогичнаго апрѣльскаго происшествия, наивныя попытки ожидания и надежды оказалися совершенно бесплодными — и это Маск тому виною, как выясняется.
Первая ласточка пролетѣла (первый звоночек прозвенѣлъ) ещё в середине декабря прошлого (2022) года, когда Amir Shevat повѣдалъ на сайте TechCrunch, что Twitter в 2021 и в 2022 году планировал развивать свой API в сторону большей открытости и программных интеграций (как однажды ужé было в 2006—2012 гг.), однако в ноябре 2022 года эти планы зарубили и поувольняли 98% персонала, работавшего в поддержке API.
Вторая ласточка пролетѣла (второй звоночек прозвенѣлъ), когда 2 февраля ужé нынѣшняго (2023) года Twitter анонсировал отключение бесплатного API (на этот счёт Chris Moody замѣтилъ, что это не сулит Твиттеру ничего хорошего).
Третья ласточка пролетѣла (третий звоночек прозвенѣлъ), когда в конце марта Twitter объявил, что бесплатный API всё же оставят, но ограничат его возможности с апрѣля.
Ни въ февралѣ, ни даже въ апрѣлѣ Twitter всё же не вырубил мнѣ бесплатный доступ к читающему API — а вот под конец мая вырубил (скриншот страницы API v2, на которой показана бесплатность только создания или стирания микроблогозаписей, прилагаю).
Оформлено отключение доступа было грубо: пользователям API, начиная съ апрѣля, показывали КРАСНОЕ сообщение о нарушении приложением правил Твиттера (видеоскриншот закономѣрнаго охѣрѣнія прилагаю), и только совѣты друг другу (вон там, напримѣръ) могли сообщить, что с приложением всё ok, но что новые ограничения не дают ему работать.
Практически всё это значит, что автоматически создавать вязанки своих микроблогозаписей (навроде вон той) я впредь не смогу, если не стану (а я не стану) платить Твиттеру по 100 долларов въ мѣсяцъ. Для сравнения напомню: Дуров за год услуги Telegram Premium (при покупке, а не при подарке) брал в феврале 1990 рублей.
Первая ласточка пролетѣла (первый звоночек прозвенѣлъ) ещё в середине декабря прошлого (2022) года, когда Amir Shevat повѣдалъ на сайте TechCrunch, что Twitter в 2021 и в 2022 году планировал развивать свой API в сторону большей открытости и программных интеграций (как однажды ужé было в 2006—2012 гг.), однако в ноябре 2022 года эти планы зарубили и поувольняли 98% персонала, работавшего в поддержке API.
Вторая ласточка пролетѣла (второй звоночек прозвенѣлъ), когда 2 февраля ужé нынѣшняго (2023) года Twitter анонсировал отключение бесплатного API (на этот счёт Chris Moody замѣтилъ, что это не сулит Твиттеру ничего хорошего).
Третья ласточка пролетѣла (третий звоночек прозвенѣлъ), когда в конце марта Twitter объявил, что бесплатный API всё же оставят, но ограничат его возможности с апрѣля.
Ни въ февралѣ, ни даже въ апрѣлѣ Twitter всё же не вырубил мнѣ бесплатный доступ к читающему API — а вот под конец мая вырубил (скриншот страницы API v2, на которой показана бесплатность только создания или стирания микроблогозаписей, прилагаю).
Оформлено отключение доступа было грубо: пользователям API, начиная съ апрѣля, показывали КРАСНОЕ сообщение о нарушении приложением правил Твиттера (видеоскриншот закономѣрнаго охѣрѣнія прилагаю), и только совѣты друг другу (вон там, напримѣръ) могли сообщить, что с приложением всё ok, но что новые ограничения не дают ему работать.
Практически всё это значит, что автоматически создавать вязанки своих микроблогозаписей (навроде вон той) я впредь не смогу, если не стану (а я не стану) платить Твиттеру по 100 долларов въ мѣсяцъ. Для сравнения напомню: Дуров за год услуги Telegram Premium (при покупке, а не при подарке) брал в феврале 1990 рублей.
😱4👍1🔥1
Кто смотрѣлъ эппловскую презентацию, открывавшую собою WWDC 2023 5 июня, тот мог легко замѣтить (или, наоборот, легко пропустить), что примѣрно на пятьдесят четвёртой минуте (или ещё позже, если глядѣть необрѣзанную видеозапись первоначальной видеотрансляции) был показан бѣлый экран, сплошь наполненный перечислением новых возможностей новой версии браузера Safari. (Тут я прилагаю ≈сорокасекундную видеоцитату, а заодно и копию конкретного видеокадра.) И въ лѣвой части пятой строки того перечисления было простое сочетание шести букв черезъ пробѣлъ: «JPEG XL». Браузер Safari, начиная с версии 17 Beta, будет способен показывать иллюстрации в формате JPEG XL.
Сокращение «XL» означает «extended life» (продлённая жизнь), потому что формат JPEG XL способен продлить жизнь старым JPEG, обеспечивая обратимое пересохранение в новом формате, совершаемое не просто с экономией объёма (достигающей ≈20,6% для копии видеокадра, приложенной к этому моему сообщению) и даже не просто без внесения потерь в пикселы, но и с возможностью въ дальнѣйшемъ реконструировать файл JPEG, любой байт которого идентичен исходному.
Но и внѣ частного случая старых JPEGов объём изображений, сжатых без внесения потерь, меньше в JPEG XL, чѣмъ в других форматах, во браузерах WWW поддерживаемых — в большинстве случаев. (Бывают, хотя и рѣдко, скриншоты текста, ещё сильнѣе сжимаемые в WebP без потерь.)
По силе сжатия, совершаемого с внесением потерь, JPEG XL опережает (при равном остаточном качестве изображения) всѣ остальные поддерживаемые в WWW форматы иллюстраций, окромя формата AVIF, сохраняющего превосходство в двух таких областях примѣненія, с которыми JPEG XL справляется хуже:
➊ при сжатии анимаций,
➋ при реально мощном сжатии неанимированных изображений, тратящем не больше бита (или даже полубита) на пиксел в среднем.
Сочетание всѣхъ упомянутых выше возможностей означает, что долгой жизни заслуживает и сам формат JPEG XL — можно предположить по аналогии, что он будет с нами так же долго, как старый JPEG (то есть лѣтъ тридцать по меньшей мѣрѣ).
Сокращение «XL» означает «extended life» (продлённая жизнь), потому что формат JPEG XL способен продлить жизнь старым JPEG, обеспечивая обратимое пересохранение в новом формате, совершаемое не просто с экономией объёма (достигающей ≈20,6% для копии видеокадра, приложенной к этому моему сообщению) и даже не просто без внесения потерь в пикселы, но и с возможностью въ дальнѣйшемъ реконструировать файл JPEG, любой байт которого идентичен исходному.
Но и внѣ частного случая старых JPEGов объём изображений, сжатых без внесения потерь, меньше в JPEG XL, чѣмъ в других форматах, во браузерах WWW поддерживаемых — в большинстве случаев. (Бывают, хотя и рѣдко, скриншоты текста, ещё сильнѣе сжимаемые в WebP без потерь.)
По силе сжатия, совершаемого с внесением потерь, JPEG XL опережает (при равном остаточном качестве изображения) всѣ остальные поддерживаемые в WWW форматы иллюстраций, окромя формата AVIF, сохраняющего превосходство в двух таких областях примѣненія, с которыми JPEG XL справляется хуже:
➊ при сжатии анимаций,
➋ при реально мощном сжатии неанимированных изображений, тратящем не больше бита (или даже полубита) на пиксел в среднем.
Сочетание всѣхъ упомянутых выше возможностей означает, что долгой жизни заслуживает и сам формат JPEG XL — можно предположить по аналогии, что он будет с нами так же долго, как старый JPEG (то есть лѣтъ тридцать по меньшей мѣрѣ).
👍10🤔1
То реально мощное сжатие изображений, при котором на долю каждого пиксела остаётся меньше бита (или даже меньше полубита) в среднем, которое я упоминал въ предпослѣднемъ абзаце моего предшествующего сообщения, может казаться (и небезосновательно) чрезмѣрностью.
Сторонники этой точки зрѣнія с удовольствием расскажут вам о том, что объёмы жёстких дисков год от года становятся всё обширнѣе, так что прямо сейчас невозбранно можно купить двадцатитерабайтник тысяч за тридцать рублей (скриншот прилагаю), или о том, что аналогично возрастают скорости мобильного и проводного соединения с Интернетом, так что передать с сайта к зрителю достаточно быстро можно и картинку, тратящую кратно больше битов на пиксел в среднем.
И дѣйствительно: по данным веб-альманаха за 2022 год, составленного HTTP Archive, только четверть иллюстраций, в Интернете обнаруживаемых, использует меньше бита на пиксел в среднем, а медианным для JPEGов оказывается удѣльный объём, равный 2⅒ бита на пиксел в среднем.
С другой стороны, по-прежнему пятимегабайтовым остаётся предѣлъ объёма иллюстраций, скачиваемых Твиттером для отображения в карточках. И предѣлъ объёма JPEGов, принимаемых Твиттером без переужатия для микроблогозаписей. И предѣлъ объёма файлов PNG, принимаемых Телеграмом на сайте Telegraph.
А на таких имиджбордах, как 4channel или Ычан, файлы больше 4 мегабайтов не принимаются большинством досок.
А также: до какого количества bpp (битов на пиксел в среднем) пришлось сжать скриншоты для того, чтобы Telegram не похѣрилъ их качество переужатием?
1,1 bpp в этом сообщении.
0,84 bpp в предшествующем сообщении.
0,58 bpp для скриншота лимитов твиттеровского API v2.
Каждое из этих ограничений сохраняется не первый год (и не второй) несмотря ни на какой рост дисков или скорости Сѣти.
И так как артефакты формата JPEG явно замѣтны (и досадны) при упомянутых ограничениях, то поддержка формата AVIF (для сообщений в Телеграме) или JPEG XL (для менѣе сильных ограничений, названных чуть выше) была бы благотворна для достигаемого качества изображений.
Сторонники этой точки зрѣнія с удовольствием расскажут вам о том, что объёмы жёстких дисков год от года становятся всё обширнѣе, так что прямо сейчас невозбранно можно купить двадцатитерабайтник тысяч за тридцать рублей (скриншот прилагаю), или о том, что аналогично возрастают скорости мобильного и проводного соединения с Интернетом, так что передать с сайта к зрителю достаточно быстро можно и картинку, тратящую кратно больше битов на пиксел в среднем.
И дѣйствительно: по данным веб-альманаха за 2022 год, составленного HTTP Archive, только четверть иллюстраций, в Интернете обнаруживаемых, использует меньше бита на пиксел в среднем, а медианным для JPEGов оказывается удѣльный объём, равный 2⅒ бита на пиксел в среднем.
С другой стороны, по-прежнему пятимегабайтовым остаётся предѣлъ объёма иллюстраций, скачиваемых Твиттером для отображения в карточках. И предѣлъ объёма JPEGов, принимаемых Твиттером без переужатия для микроблогозаписей. И предѣлъ объёма файлов PNG, принимаемых Телеграмом на сайте Telegraph.
А на таких имиджбордах, как 4channel или Ычан, файлы больше 4 мегабайтов не принимаются большинством досок.
А также: до какого количества bpp (битов на пиксел в среднем) пришлось сжать скриншоты для того, чтобы Telegram не похѣрилъ их качество переужатием?
1,1 bpp в этом сообщении.
0,84 bpp в предшествующем сообщении.
0,58 bpp для скриншота лимитов твиттеровского API v2.
Каждое из этих ограничений сохраняется не первый год (и не второй) несмотря ни на какой рост дисков или скорости Сѣти.
И так как артефакты формата JPEG явно замѣтны (и досадны) при упомянутых ограничениях, то поддержка формата AVIF (для сообщений в Телеграме) или JPEG XL (для менѣе сильных ограничений, названных чуть выше) была бы благотворна для достигаемого качества изображений.
👍4
screenshot.jxl
148.9 KB
Мысли о сильном сжатии, изложенныя в моём предыдущем сообщении, можно иллюстрировать на примѣрѣ скриншота, там приложенного. Этот скриншот содержит 1280×1152 = 1474560 пикселов. Значит, рассуждая об использовании не болѣе ½ битов на пиксел в среднем, мы говорим о таком объёме файла, который не превосходил бы 1474560 / 16 = 92160 байтов для этого скриншота. В качестве наглядной иллюстрации я предлагаю четыре файла:
① Файл PNG объёмом 218 883 байта. Это исходный скриншот, сжатый (без внесения потерь) посредством Efficient Compression Tool. Тот JPEG, который приложен к предшествующему сообщению, всего-навсего на 8% меньше этого PNG — на мой взгляд, достигнутая экономия не стóит потерь, внесённых JPEGованием, так что по уму Телеграму (да и Твиттеру) слѣдовало бы принимать файлы PNG такого удѣльнаго объёма (1,19 bpp) без принудительного перекодирования в JPEG.
② Файл AVIF объёмом 91833 байта. Его качество изображения куда лучше, чѣмъ у того файла JPEG, который был приложен к моему предшествующему сообщению — а вѣдь разница по объёму болѣе чѣмъ двукратна! На этом примѣрѣ видно, что возможности нового формата (AVIF) позволяют неслабо экономить как объём, так и качество изображения (причём одновременно) при таком малом удѣльном объёме (≈½ bpp), который в рамках старого формата (JPEG) достигался бы только при досадных потерях качества.
③ Файл JPEG XL объёмом 91791 байт. Видно, что его алгоритм сжатия, совершаемого с внесением потерь, скверно работает при настолько малом количестве битов — чрезмѣрно размазывает отдѣльные пикселы. Появление JPEG XL не потеснит AVIF в этой области сильного сжатия: достоинства JPEG XL требуют большего удѣльнаго объёма.
④ Файл JPEG XL объёмом 152 445 байтов. Этот файл большего удѣльнаго объёма (0,827 bpp) — примѣръ возможностей сжатия без потерь, в JPEG XL заложенных (как нетрудно сосчитать, по силе сжатия он опережает PNG болѣе чѣмъ на 30%).
Сравнивать изображения, хранимые в этих новых форматах, приходится в просмотрщике, понимающем как AVIF, так и JPEG XL. (Ну, напримѣръ, в XnView MP.)
① Файл PNG объёмом 218 883 байта. Это исходный скриншот, сжатый (без внесения потерь) посредством Efficient Compression Tool. Тот JPEG, который приложен к предшествующему сообщению, всего-навсего на 8% меньше этого PNG — на мой взгляд, достигнутая экономия не стóит потерь, внесённых JPEGованием, так что по уму Телеграму (да и Твиттеру) слѣдовало бы принимать файлы PNG такого удѣльнаго объёма (1,19 bpp) без принудительного перекодирования в JPEG.
② Файл AVIF объёмом 91833 байта. Его качество изображения куда лучше, чѣмъ у того файла JPEG, который был приложен к моему предшествующему сообщению — а вѣдь разница по объёму болѣе чѣмъ двукратна! На этом примѣрѣ видно, что возможности нового формата (AVIF) позволяют неслабо экономить как объём, так и качество изображения (причём одновременно) при таком малом удѣльном объёме (≈½ bpp), который в рамках старого формата (JPEG) достигался бы только при досадных потерях качества.
③ Файл JPEG XL объёмом 91791 байт. Видно, что его алгоритм сжатия, совершаемого с внесением потерь, скверно работает при настолько малом количестве битов — чрезмѣрно размазывает отдѣльные пикселы. Появление JPEG XL не потеснит AVIF в этой области сильного сжатия: достоинства JPEG XL требуют большего удѣльнаго объёма.
④ Файл JPEG XL объёмом 152 445 байтов. Этот файл большего удѣльнаго объёма (0,827 bpp) — примѣръ возможностей сжатия без потерь, в JPEG XL заложенных (как нетрудно сосчитать, по силе сжатия он опережает PNG болѣе чѣмъ на 30%).
Сравнивать изображения, хранимые в этих новых форматах, приходится в просмотрщике, понимающем как AVIF, так и JPEG XL. (Ну, напримѣръ, в XnView MP.)
👍5🔥1👏1🏆1
This media is not supported in your browser
VIEW IN TELEGRAM
Предыдущее сообщение продолжаю вопросом: а какой прок от всѣхъ достоинств формата AVIF, если Telegram позволяет отправлять AVIF только «как файл»? — вѣдь отправляться и отображаться «как иллюстрация», то есть во всю ширь столбца сообщений и притом с готовым просмотрщиком (который откроется на весь экран, если иллюстрацию жмякнуть мышóю или ткнуть пальцем, и в котором можно наращивать её увеличение), в Телеграме могут только три формата:
① JPEG (единственный в Telegram формат картинок),
② MP4 (единственный в Telegram формат видео),
③ GIF (если объём GIF превосходит 10 мегабайтов и тѣмъ избѣгаетъ автоматического преобразования в MP4).
Можно просить Telegram прибавить и AVIF к этому списку, а можно пойти на хитрость, взяв FFmpeg и обернув AVIF в однокадровую видеозапись MP4 несложною командою:
Но у этого обходного пути есть и недостатки:
➊ Нужна пустая звуковая дорожка («anullsrc»), иначе MP4 без звука будет воспринят «как GIF» и показан не во всю ширь.
➋ Telegram под Android подчас не показывает миниатюру AVIF-в-MP4 (зависит от ширины?).
➌ «Родной» просмотрщик в Telegram под Android не сможет показать MP4, если в исходном AVIF не было субдискретизации 4:2:0.
➍ Версии Телеграма для iOS и macOS не показывают AVIF-в-MP4, так как в эппловских операционках нѣтъ поддержки видео AV1.
① JPEG (единственный в Telegram формат картинок),
② MP4 (единственный в Telegram формат видео),
③ GIF (если объём GIF превосходит 10 мегабайтов и тѣмъ избѣгаетъ автоматического преобразования в MP4).
Можно просить Telegram прибавить и AVIF к этому списку, а можно пойти на хитрость, взяв FFmpeg и обернув AVIF в однокадровую видеозапись MP4 несложною командою:
ffmpeg -f lavfi -i anullsrc -i исходный.avif -c:v copy -c:a aac -b:a 8k -movflags +faststart -shortest итог.mp4
Это преобразование не вносит потерь и оттого оказывается обратимым — из такого MP4 другой командою можно извлечь файл AVIF, не идентичный исходному, но содержащий точно тѣ же значения пикселов:ffmpeg -i такой.mp4 -c copy аналог.avif
Такой AVIF-в-MP4 может превосходить телеграмное ограничение ширины картинок и доходить до 4K (примѣръ 3840×1731 пиксел прилагаю), сносно выглядит при мáлом удѣльномъ объёмѣ (меньше ½ bpp в прилагаемом примѣрѣ), не теряет качество при сохранении и отправке, показывается телеграмным просмотрщиком и подлежит в нём увеличению щипком (в Telegram под Android) или Ctrl+плюсом (в Telegram Desktop).Но у этого обходного пути есть и недостатки:
➊ Нужна пустая звуковая дорожка («anullsrc»), иначе MP4 без звука будет воспринят «как GIF» и показан не во всю ширь.
➋ Telegram под Android подчас не показывает миниатюру AVIF-в-MP4 (зависит от ширины?).
➌ «Родной» просмотрщик в Telegram под Android не сможет показать MP4, если в исходном AVIF не было субдискретизации 4:2:0.
➍ Версии Телеграма для iOS и macOS не показывают AVIF-в-MP4, так как в эппловских операционках нѣтъ поддержки видео AV1.
🔥3❤1👍1🤯1
Полтора послѣднихъ мѣсяца (весь май и ½ июня) я время от времени видал в Геленджике, как ѣздоки на разных двухколёсных средствах ѣзды: и на мотоциклах, и на велосипедах, и даже на самокатах — подымают их на дыбы и далѣе ѣдутъ, балансируя на заднем колесе. Такіе ѣздоки попадáлись и попарно ѣдущими рядом друг с другом, а не только поодиночке. И вроде бы таких ѣздоковъ вижу много больше въ нынѣшнемъ году, нежели когда бы то ни было в прошлые годы видал любителей этакой эквилибристики.
Благодаря каналу @r_chp теперь ещё вижу на видеозаписи, что и в Томске нѣчто в этом же роде происходило на улице — причём не оттого вижу, что ѣздока, балансирующего на заднем колесе, засняли там на видео нарочно, руководясь удивлением от его манеры ѣзды, а оттого только, что он проѣхалъ близко (и незадолго до) столкновения автомашин, так что по случайности угодил, как говорится, «в кадр». И коль скоро этакая случайность вообще возможна, то можно предположить распространённость явления.
Таких ѣздоковъ я вправе заподозрить в том, что они просто-напросто желают (сознательно или безсознательно) того только, чтобы ѣздить по своим городам (будь то #Геленджик, или Томск, или ещё какой-нибудь другой город) на моноколёсах и оттого каждую секунду во время ѣзды наслаждаться состоянием балансирующаго равновѣсія (притом поддерживаемаго многокиловаттным мотором), но что поскольку жизненные обстоятельства не позволили им этого, то тогда поневоле пришлось купить (или арендовать) чего-нибудь другое: самокат, велосипед, мотоцикл — и затѣмъ поднимать это немоноколёсное транспортное средство на дыбы, как бы наказуя его за то, что оно двухколёсно.
Такое желание много старше нынѣшнихъ ѣздоковъ: сознание человѣчества не менѣе 120 лѣтъ устремлялося к моноколесу. Как свидѣтельство этого я привожу три разныя репродукціи одного и того же рисунка 1903 г., по-видимому отчасти карикатурнаго — он появлялся в LJ kazagrandy, «Коммерсантъ» приводил его въ замѣткѣ и в галерее «Из жизни мотористов», и наконец Веломузей Андрея Мятиева показал тот же рисунок с подписью.
Благодаря каналу @r_chp теперь ещё вижу на видеозаписи, что и в Томске нѣчто в этом же роде происходило на улице — причём не оттого вижу, что ѣздока, балансирующего на заднем колесе, засняли там на видео нарочно, руководясь удивлением от его манеры ѣзды, а оттого только, что он проѣхалъ близко (и незадолго до) столкновения автомашин, так что по случайности угодил, как говорится, «в кадр». И коль скоро этакая случайность вообще возможна, то можно предположить распространённость явления.
Таких ѣздоковъ я вправе заподозрить в том, что они просто-напросто желают (сознательно или безсознательно) того только, чтобы ѣздить по своим городам (будь то #Геленджик, или Томск, или ещё какой-нибудь другой город) на моноколёсах и оттого каждую секунду во время ѣзды наслаждаться состоянием балансирующаго равновѣсія (притом поддерживаемаго многокиловаттным мотором), но что поскольку жизненные обстоятельства не позволили им этого, то тогда поневоле пришлось купить (или арендовать) чего-нибудь другое: самокат, велосипед, мотоцикл — и затѣмъ поднимать это немоноколёсное транспортное средство на дыбы, как бы наказуя его за то, что оно двухколёсно.
Такое желание много старше нынѣшнихъ ѣздоковъ: сознание человѣчества не менѣе 120 лѣтъ устремлялося к моноколесу. Как свидѣтельство этого я привожу три разныя репродукціи одного и того же рисунка 1903 г., по-видимому отчасти карикатурнаго — он появлялся в LJ kazagrandy, «Коммерсантъ» приводил его въ замѣткѣ и в галерее «Из жизни мотористов», и наконец Веломузей Андрея Мятиева показал тот же рисунок с подписью.
😁8👍5