Mithgol the Webmaster
Мицгол-вебмастер ведёт на сём канале свой малоблог в Telegram.
Основные темы (в алфавитном порядке): аниме, виртуальная реальность, Геленджик, криптоконспирология, русский антиутопизм, сайтостроение, урбанизм, 猫 etc.
💸Донат: https://t.me/ReadMithgol/92
Основные темы (в алфавитном порядке): аниме, виртуальная реальность, Геленджик, криптоконспирология, русский антиутопизм, сайтостроение, урбанизм, 猫 etc.
💸Донат: https://t.me/ReadMithgol/92
关联群组
Миѳголовскій чатъ
36
"Mithgol the Webmaster" 群组最新帖子
09.05.202501:38
Всѣмъ доброе утро, с вами вновь Mithgol the Webmaster и нерегулярная рубрика «тайныя новинки Телеграма».
Кто пожелал бы сегодня в четвёртом часу утра бустить мой канал в Телеграме, того немедленно встрѣтила бы (в интерфейсе у Телеграма) изрядно странная картина, перед которою взгляд невольно приостанавливается в недоумении.
Чтобы в точности передать вам это визуальное впечатление, я прилагаю здѣсь два скриншота, из которых первый сдѣланъ в Telegram на смартфоне под управлением системы Android, а второй — в Telegram Desktop под Windows.
На каждом из скриншотов нетрудно увидѣть, что Telegram называет мой канал получившим 25 бустов (голосов за канал, поданных пользователями услуги Telegram Premium), чего каналу хватает (и даже съ нѣкоторою лихвою) для достижения восьмого уровня забущенности, однако для достижения слѣдующаго (девятого) уровня понадобится ещё 17 бустов.
Согласитесь, здѣсь есть надъ чѣмъ призадуматься.
Во-первых, если для достижения очередного уровня требуется больше 17 бустов, то тогда каким же образом всего-навсего четверти сотни бустов могло быть достаточно (и даже с запасом) для достижения всѣхъ предшествующих восьми уровней?
Во-вторых, сумма 25+17 равна 42 и просто-напросто не дѣлится без остатка на номер слѣдующаго (девятого) уровня забущенности.
Это что же? — неужели Telegram отказался от равномѣрной шкалы забущивания, то есть отказался от такой системы, при которой для достижения каждого нового уровня забущенности каналу необходимо набирать одно и то же количество голосов, зависящее только от количества подписчиков у канала?
Нѣтъ.
Оказывается, Telegram просто-напросто показывает количество необходимых бустов некорректно, причём одинаково некорретно и под Android, и под Windows.
А почему так? — оказывается, во блоге Телеграма объявлено, что съ нынѣшняго мая каналам в Телеграме будет нужно меньше бустов для достижения очередного уровня забущенности.
(Причём произошла не такая «реноминация бустов», какая была в ноябре 2023 года. Количество бустов, доступных для раздачи каждым из обладателей услуги Telegram Premium, сейчас остаётся на прошлогоднем уровне, а измѣнилася одна только значимость их.)
Но насколько меньше теперь нужно бустов для достижения очередного уровня забущенности? — вот это как раз и во блоге Телеграма позабыли упомянуть (и до сих пор не вспомнили — скриншот блога я прилагаю в подтверждение), и до авторов приложений Телеграма перемѣнившуюся значимость бустов тоже не донесли ещё, так что они подсчитывают с ошибкою, причём с одной и той же.
(Я пишу «до авторов», потому что мрачно подозрѣваю, что на сёрверной стороне в Телеграме даже и не был предусмотрен никакой механизм, способный доносить до приложений свѣдѣнія объ измѣнившейся «цѣнѣ» очередного уровня забущенности, а вмѣсто того формула жёстко забивается в исходный код каждого приложения его автором — и обновляется только с появлением новой версии приложения.
Но, может быть, всё ещё хуже, чѣмъ я подозрѣваю. Первый-то из скриншотов, выше приложенных, я сдѣлалъ в новой версии Telegram для Android — в версии 11.11.0 — однако же и она также сообщает хѣрню вмѣсто дѣйствительнаго числа бустов, необходимых для достижения слѣдующаго уровня забущенности.)
Сам же я догадываюсь (и небезосновательно) о том, что число бустов, необходимых для достижения слѣдующаго уровня забущенности, было уменьшено ровно вдвое: если прежде один буст необходим был на каждую полную или неполную четверть тыщщи подписчиков, то теперь — на каждую полную или неполную полутыщщу. Это означает, что моему каналу (с 1270 подписчиками в настоящее время) необходимо теперь по три буста для достижения каждого очередного уровня забущенности — одно это может объяснить, отчего 25 голосов достаточно теперь для восьмого уровня (и даже съ нѣкоторымъ запасом): 3×8=24.
Но отчего это новое количество нельзя было явно упомянуть во блоге Телеграма? — отчего это количество нам пришлось выяснять эмпирически-концептуально (то есть через осознание выводов, напрашивающихся из собственного непосредственного опыта взаимодѣйствія с новинкою)? — про то одному Дурову может быть извѣстно.
Кто пожелал бы сегодня в четвёртом часу утра бустить мой канал в Телеграме, того немедленно встрѣтила бы (в интерфейсе у Телеграма) изрядно странная картина, перед которою взгляд невольно приостанавливается в недоумении.
Чтобы в точности передать вам это визуальное впечатление, я прилагаю здѣсь два скриншота, из которых первый сдѣланъ в Telegram на смартфоне под управлением системы Android, а второй — в Telegram Desktop под Windows.
На каждом из скриншотов нетрудно увидѣть, что Telegram называет мой канал получившим 25 бустов (голосов за канал, поданных пользователями услуги Telegram Premium), чего каналу хватает (и даже съ нѣкоторою лихвою) для достижения восьмого уровня забущенности, однако для достижения слѣдующаго (девятого) уровня понадобится ещё 17 бустов.
Согласитесь, здѣсь есть надъ чѣмъ призадуматься.
Во-первых, если для достижения очередного уровня требуется больше 17 бустов, то тогда каким же образом всего-навсего четверти сотни бустов могло быть достаточно (и даже с запасом) для достижения всѣхъ предшествующих восьми уровней?
Во-вторых, сумма 25+17 равна 42 и просто-напросто не дѣлится без остатка на номер слѣдующаго (девятого) уровня забущенности.
Это что же? — неужели Telegram отказался от равномѣрной шкалы забущивания, то есть отказался от такой системы, при которой для достижения каждого нового уровня забущенности каналу необходимо набирать одно и то же количество голосов, зависящее только от количества подписчиков у канала?
Нѣтъ.
Оказывается, Telegram просто-напросто показывает количество необходимых бустов некорректно, причём одинаково некорретно и под Android, и под Windows.
А почему так? — оказывается, во блоге Телеграма объявлено, что съ нынѣшняго мая каналам в Телеграме будет нужно меньше бустов для достижения очередного уровня забущенности.
(Причём произошла не такая «реноминация бустов», какая была в ноябре 2023 года. Количество бустов, доступных для раздачи каждым из обладателей услуги Telegram Premium, сейчас остаётся на прошлогоднем уровне, а измѣнилася одна только значимость их.)
Но насколько меньше теперь нужно бустов для достижения очередного уровня забущенности? — вот это как раз и во блоге Телеграма позабыли упомянуть (и до сих пор не вспомнили — скриншот блога я прилагаю в подтверждение), и до авторов приложений Телеграма перемѣнившуюся значимость бустов тоже не донесли ещё, так что они подсчитывают с ошибкою, причём с одной и той же.
(Я пишу «до авторов», потому что мрачно подозрѣваю, что на сёрверной стороне в Телеграме даже и не был предусмотрен никакой механизм, способный доносить до приложений свѣдѣнія объ измѣнившейся «цѣнѣ» очередного уровня забущенности, а вмѣсто того формула жёстко забивается в исходный код каждого приложения его автором — и обновляется только с появлением новой версии приложения.
Но, может быть, всё ещё хуже, чѣмъ я подозрѣваю. Первый-то из скриншотов, выше приложенных, я сдѣлалъ в новой версии Telegram для Android — в версии 11.11.0 — однако же и она также сообщает хѣрню вмѣсто дѣйствительнаго числа бустов, необходимых для достижения слѣдующаго уровня забущенности.)
Сам же я догадываюсь (и небезосновательно) о том, что число бустов, необходимых для достижения слѣдующаго уровня забущенности, было уменьшено ровно вдвое: если прежде один буст необходим был на каждую полную или неполную четверть тыщщи подписчиков, то теперь — на каждую полную или неполную полутыщщу. Это означает, что моему каналу (с 1270 подписчиками в настоящее время) необходимо теперь по три буста для достижения каждого очередного уровня забущенности — одно это может объяснить, отчего 25 голосов достаточно теперь для восьмого уровня (и даже съ нѣкоторымъ запасом): 3×8=24.
Но отчего это новое количество нельзя было явно упомянуть во блоге Телеграма? — отчего это количество нам пришлось выяснять эмпирически-концептуально (то есть через осознание выводов, напрашивающихся из собственного непосредственного опыта взаимодѣйствія с новинкою)? — про то одному Дурову может быть извѣстно.
09.05.202501:38
28.04.202522:57
27.04.202518:27
#Геленджик
РОД-КУРОРТ
РОД-КУРОРТ
25.04.202519:46
#Геленджик сегодня (25 апрѣля) продолжает быть прохладным (прямо сейчас +15°), идёт небольшой дождь.
Пользуясь влажностью, повылазили улитки. Фотографию улиток прилагаю.
Пользуясь влажностью, повылазили улитки. Фотографию улиток прилагаю.
21.04.202523:00
Чаще всего я выкладываю у себя на канале в Телеграме сообщения немалого размѣра, но в этом мнѣ всегда неслабо досаждало и мѣшало одно обстоятельство: Telegram начинает показывать подсчитанное им количество использованных сѵмволовъ только тогда, когда их ужé многовато в сообщении, подвергаемом редактированию. (Если же сообщение не подвергается редактированию, а набирается заново, то тогда Telegram и вовсе не начинает считать количество использованных сѵмволовъ даже тогда, когда их ужé многовато в сообщении, а тупо откусывает от сообщения его хвост и кладёт въ ѿдѣльномъ слѣдующемъ сообщении.) Очень трудно заранѣе «на глаз» угадывать, сколько сѵмволовъ осталось ввести до того момента, когда достигнет будет телеграмный лимит длины сообщения (4096 сѵмволовъ).
Можно, конечно, заблаговременно ввести какую-нибудь строку извѣстной длины — напримѣръ, повторение раз за разом «123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789» содержит по десять сѵмволовъ для каждой группы цифр, если считать группу съ послѣдующимъ пробѣломъ (как считает их и сам Telegram), так что этот примѣръ строки содержит 99 сѵмволовъ. Если начать сообщение с такой строки и затѣмъ набирать текст под нею, то перевод строки станет сотым сѵмволомъ и Telegram начнёт браниться на чрезмѣрность числа сѵмволовъ на сотню ранѣе. Но у искусственной многочисленности сѵмволовъ есть свои недостатки (напримѣръ, она препятствует отправке сообщения в Telegram ничуть не хуже, чѣмъ созданная не искусственно).
Ещё можно набирать сообщение не в Телеграме, а в текстовом редакторе, из которого затѣмъ копировать в Telegram. В большинстве таких редакторов под окном ввода текста есть строка состояния, в которой показывается номер столбца, нарастающий по мѣрѣ ввода текста в строке — можно номером столбца пользоваться как индикатором длины текста. Но у этого подхода три недостатка:
➊ В отличие от редакторов «документов» (таких редакторов, каковы и LibreOffice Writer, и Microsoft Word), редакторы «просто текста» (такие, как EmEditor или Notepad++) не способны сохранять оформление текста. Приходится заранѣе составлять параллельный список таких словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
➋ Нѣкоторые редакторы текста (напримѣръ, EmEditor) норовят при подсчёте номера столбца считать один сѵмволъ за два, если мнят его сѵмволомъ повышенной ширины. Таковы и иероглифы (напримѣръ, «魔»), и числа в кружкáх (напримѣръ, «⑪»), и многие эмоджи (напримѣръ, «🪗»), и проч. А вот Telegram с такими сѵмволами так не поступает (и правильно, а не то нам пришлось бы ещё сильнѣе экономить их в Телеграме) — значит, номер столбца в редакторе текста перестаёт быть годным аналогом телеграмнаго подсчёта сѵмволовъ.
➌ Номер столбца показывает количество текста в одной строке. Чтобы измѣрить количество текста во всём сообщении, нужно либо хорошо владѣть устным счётом четырёхзначных чисел (быстро складывать в уме всѣ номера послѣднихъ столбцовъ, сперва посмотрѣвъ ихъ в каждой из непустых строк), либо составлять всё сообщение как одну большую длинную строку, а планируемыя пустыя строки помѣчать двойным неиспользуемым сѵмволомъ (напримѣръ, «··»), замѣняя его двойным переходом на новую строку перед окончательным копированием сообщения внутрь Телеграма.
В конце концов я подзадолбался и вспомнил, что EmEditor — это скриптуемый текстовый редактор: в нём можно запускать скрипты (правда, в нём они зовутся не скриптами, а макросами, но это не принципиально) и взаимодѣйствовать с объектною моделью документа.
Вспомнив это, я сочинил для EmEditor (и прилагаю здѣсь) макрос подсчёта числа сѵмволовъ внутри выдѣленнаго текста, а если ничего не выдѣлено — то от курсора до начала файла. А почему не от начала до конца файла? — потому, что черновик может содержать наброски нѣсколькихъ сообщений или (как я это ужé упоминал чуть выше) список словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
Можно, конечно, заблаговременно ввести какую-нибудь строку извѣстной длины — напримѣръ, повторение раз за разом «123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789» содержит по десять сѵмволовъ для каждой группы цифр, если считать группу съ послѣдующимъ пробѣломъ (как считает их и сам Telegram), так что этот примѣръ строки содержит 99 сѵмволовъ. Если начать сообщение с такой строки и затѣмъ набирать текст под нею, то перевод строки станет сотым сѵмволомъ и Telegram начнёт браниться на чрезмѣрность числа сѵмволовъ на сотню ранѣе. Но у искусственной многочисленности сѵмволовъ есть свои недостатки (напримѣръ, она препятствует отправке сообщения в Telegram ничуть не хуже, чѣмъ созданная не искусственно).
Ещё можно набирать сообщение не в Телеграме, а в текстовом редакторе, из которого затѣмъ копировать в Telegram. В большинстве таких редакторов под окном ввода текста есть строка состояния, в которой показывается номер столбца, нарастающий по мѣрѣ ввода текста в строке — можно номером столбца пользоваться как индикатором длины текста. Но у этого подхода три недостатка:
➊ В отличие от редакторов «документов» (таких редакторов, каковы и LibreOffice Writer, и Microsoft Word), редакторы «просто текста» (такие, как EmEditor или Notepad++) не способны сохранять оформление текста. Приходится заранѣе составлять параллельный список таких словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
➋ Нѣкоторые редакторы текста (напримѣръ, EmEditor) норовят при подсчёте номера столбца считать один сѵмволъ за два, если мнят его сѵмволомъ повышенной ширины. Таковы и иероглифы (напримѣръ, «魔»), и числа в кружкáх (напримѣръ, «⑪»), и многие эмоджи (напримѣръ, «🪗»), и проч. А вот Telegram с такими сѵмволами так не поступает (и правильно, а не то нам пришлось бы ещё сильнѣе экономить их в Телеграме) — значит, номер столбца в редакторе текста перестаёт быть годным аналогом телеграмнаго подсчёта сѵмволовъ.
➌ Номер столбца показывает количество текста в одной строке. Чтобы измѣрить количество текста во всём сообщении, нужно либо хорошо владѣть устным счётом четырёхзначных чисел (быстро складывать в уме всѣ номера послѣднихъ столбцовъ, сперва посмотрѣвъ ихъ в каждой из непустых строк), либо составлять всё сообщение как одну большую длинную строку, а планируемыя пустыя строки помѣчать двойным неиспользуемым сѵмволомъ (напримѣръ, «··»), замѣняя его двойным переходом на новую строку перед окончательным копированием сообщения внутрь Телеграма.
В конце концов я подзадолбался и вспомнил, что EmEditor — это скриптуемый текстовый редактор: в нём можно запускать скрипты (правда, в нём они зовутся не скриптами, а макросами, но это не принципиально) и взаимодѣйствовать с объектною моделью документа.
Вспомнив это, я сочинил для EmEditor (и прилагаю здѣсь) макрос подсчёта числа сѵмволовъ внутри выдѣленнаго текста, а если ничего не выдѣлено — то от курсора до начала файла. А почему не от начала до конца файла? — потому, что черновик может содержать наброски нѣсколькихъ сообщений или (как я это ужé упоминал чуть выше) список словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
20.04.202502:46
Христосъ воскресе!
Прилагаю монограмму «ХВ», которую обнаружил нанесённою на тротуар улицы Тельмана в Геленджике.
#Геленджик
Прилагаю монограмму «ХВ», которую обнаружил нанесённою на тротуар улицы Тельмана в Геленджике.
#Геленджик
17.04.202523:21
② В командной строке у кодировщика AVIF вмѣсто прежних параметров «--minalpha 0 --maxalpha 0» можно и нужно теперь использовать единственный параметр «--qalpha 100» для принуждения кодировщика к использованию наивысшаго качества при сохранении свѣденій о прозрачности.
③ Появилась аналогичная возможность указывать баллы качества (от нуля до сотни; чѣмъ больше баллов, тѣмъ качество выше), а не значение квантизатора (от нуля до 63; чѣмъ больше это значение, тѣмъ качество меньше) и для свѣдѣніяхъ о самих пикселах (а не об их прозрачности), для чего служит в командной строке параметр «-qcolor»; но я предпочитаю не пользоваться этой новой возможностью, а по-прежнему задавать квантизатор («--advanced cq-level=…»), так как «под капотом» («за кулисами») баллы качества всё равно переводятся в величину квантизатора — и так как сто баллов больше 63, так что въ нѣкоторыхъ частных случаях (которых больше тридцати штук) измѣненіе качества на единицу не перемѣняетъ результат кодирования (и тогда на практике получается, что зря кодировал на пробу сосѣднее число баллов качества), что неудобно и досадно.
④ Появился новый вариант настройки кодировщика («--advanced tune=iq»), который способствует наращиванию качества картинки при небольшом сжатии, способствуя большему вниманию кодировщика к сохранению и незамутнению тонких деталей изображения, причём «под капотом» («за кулисами») включение этой настройки переключает дефолтное (установленное по умолчанию) состояние ещё восьми других настроек:
Я принялся экспериментировать с настройками libavif и в итоге необычно увлёкся: въ послѣдніе полтора мѣсяца много меньше удѣлялъ внимание своему каналу в Телеграме (и даже нѣсколько отвык), а больше внимания — тому внѣтелеграмному сообществу, на сайте которого выкладывал AVIF.
В итоге я пришёл к двум выводам.
Первый вывод состоит в том, что если в формате AVIF сохраняется изображение, уменьшенное по отношению къ нѣкоторому исходному JPEG, то выгодно (для лучшаго соѿношенія объёма и качества итогового файла) сперва подавить шум JPEG (используя JPEG Quant Smooth Ильи Курдюкова), затѣмъ декодировать JPEG с высокою (шестнадцатибитною) точностью (используя декодировщик jpegli с параметром «--bitdepth=16»), и вот тогда уж совершать и уменьшение изображения, и послѣдующее создание AVIF.
Второй вывод состоит в том, что зависимость объёма файла AVIF от матрицы квантизации в режиме «tune=iq» представляет собою двойную S-образную кривую. Если начинать от максимума (qm-min=15 и qm-max=15) и постепенно понижать qm-min до нуля, то сперва объём файла не сокращается и даже слегка возрастает, затѣмъ начинает быстро сокращаться, затѣмъ сокращается всё хуже (и часто значения qm-min, близкие к нулю, дают ровно такой же объём файла AVIF, какой был бы и при «qm-min=0», или даже чуть меньший). Если затѣмъ от этой точки (qm-min=0 и qm-max=15) уменьшать значение qm-max, то сперва объём файла сокращается слабо (или вовсе остаётся неизмѣннымъ), затѣмъ сильно, затѣмъ снова слабо.
Вторая S-образная кривая (достигаемая уменьшением qm-max при ужé обнулённом qm-min) появляется только в режиме «tune=iq», без которого эта кривая не возникает и уменьшать qm-max бесполезно. Но и в режиме «tune=iq» уменьшать qm-max бесполезно, потому что наблюдаемое качество изображения ухудшается так сильно, что тот же объём файла выгодно достигать другими средствами, а именно наращиванием квантизатора.
Поэтому в итоге я счёл значения матриц квантизации по умолчанию, в режиме «tune=iq» задаваемые (qm-min=2 и qm-max=10), практически не очень полезными. Если подгонять файл AVIF подъ нѣкоторое ограничение объёма, то лучше сперва найти минимальное значение квантизатора такое, при котором объём файла AVIF меньше ограничения при qm-min=0 и qm-max=15, а затѣмъ (для болѣе точнаго приближения к ограничению) повысить qm-min до 12 (что увеличит объём файла) и затѣмъ раз за разом уменьшать qm-min на единицу до тѣхъ поръ, пока объём файла AVIF не начнёт вдругорядь соѿвѣтствовать ограничению.
③ Появилась аналогичная возможность указывать баллы качества (от нуля до сотни; чѣмъ больше баллов, тѣмъ качество выше), а не значение квантизатора (от нуля до 63; чѣмъ больше это значение, тѣмъ качество меньше) и для свѣдѣніяхъ о самих пикселах (а не об их прозрачности), для чего служит в командной строке параметр «-qcolor»; но я предпочитаю не пользоваться этой новой возможностью, а по-прежнему задавать квантизатор («--advanced cq-level=…»), так как «под капотом» («за кулисами») баллы качества всё равно переводятся в величину квантизатора — и так как сто баллов больше 63, так что въ нѣкоторыхъ частных случаях (которых больше тридцати штук) измѣненіе качества на единицу не перемѣняетъ результат кодирования (и тогда на практике получается, что зря кодировал на пробу сосѣднее число баллов качества), что неудобно и досадно.
④ Появился новый вариант настройки кодировщика («--advanced tune=iq»), который способствует наращиванию качества картинки при небольшом сжатии, способствуя большему вниманию кодировщика к сохранению и незамутнению тонких деталей изображения, причём «под капотом» («за кулисами») включение этой настройки переключает дефолтное (установленное по умолчанию) состояние ещё восьми других настроек:
enable-qm=1Я принялся экспериментировать с настройками libavif и в итоге необычно увлёкся: въ послѣдніе полтора мѣсяца много меньше удѣлялъ внимание своему каналу в Телеграме (и даже нѣсколько отвык), а больше внимания — тому внѣтелеграмному сообществу, на сайте которого выкладывал AVIF.
В итоге я пришёл к двум выводам.
Первый вывод состоит в том, что если в формате AVIF сохраняется изображение, уменьшенное по отношению къ нѣкоторому исходному JPEG, то выгодно (для лучшаго соѿношенія объёма и качества итогового файла) сперва подавить шум JPEG (используя JPEG Quant Smooth Ильи Курдюкова), затѣмъ декодировать JPEG с высокою (шестнадцатибитною) точностью (используя декодировщик jpegli с параметром «--bitdepth=16»), и вот тогда уж совершать и уменьшение изображения, и послѣдующее создание AVIF.
Второй вывод состоит в том, что зависимость объёма файла AVIF от матрицы квантизации в режиме «tune=iq» представляет собою двойную S-образную кривую. Если начинать от максимума (qm-min=15 и qm-max=15) и постепенно понижать qm-min до нуля, то сперва объём файла не сокращается и даже слегка возрастает, затѣмъ начинает быстро сокращаться, затѣмъ сокращается всё хуже (и часто значения qm-min, близкие к нулю, дают ровно такой же объём файла AVIF, какой был бы и при «qm-min=0», или даже чуть меньший). Если затѣмъ от этой точки (qm-min=0 и qm-max=15) уменьшать значение qm-max, то сперва объём файла сокращается слабо (или вовсе остаётся неизмѣннымъ), затѣмъ сильно, затѣмъ снова слабо.
Вторая S-образная кривая (достигаемая уменьшением qm-max при ужé обнулённом qm-min) появляется только в режиме «tune=iq», без которого эта кривая не возникает и уменьшать qm-max бесполезно. Но и в режиме «tune=iq» уменьшать qm-max бесполезно, потому что наблюдаемое качество изображения ухудшается так сильно, что тот же объём файла выгодно достигать другими средствами, а именно наращиванием квантизатора.
Поэтому в итоге я счёл значения матриц квантизации по умолчанию, в режиме «tune=iq» задаваемые (qm-min=2 и qm-max=10), практически не очень полезными. Если подгонять файл AVIF подъ нѣкоторое ограничение объёма, то лучше сперва найти минимальное значение квантизатора такое, при котором объём файла AVIF меньше ограничения при qm-min=0 и qm-max=15, а затѣмъ (для болѣе точнаго приближения к ограничению) повысить qm-min до 12 (что увеличит объём файла) и затѣмъ раз за разом уменьшать qm-min на единицу до тѣхъ поръ, пока объём файла AVIF не начнёт вдругорядь соѿвѣтствовать ограничению.
17.04.202523:21
Самым значимым событием из числа впрямую касающихся хранения изображений сдѣлалося нынѣшнею зимою появление новой версии пакета приложений libavif, служащего для работы с файлами в формате AVIF.
В этой новой версии (вышедшей 25 февраля под номером 1.2.0; здѣсь можно прибавить, что 17 марта появилась болѣе новая версия 1.2.1, незначительно дополняющая предшественницу) можно было сразу замѣтить (и я замѣтилъ анонимно на 410чане 26 февраля, а на канале в Телеграме прилагаю скриншот чуть выше) четыре новинки:
① Кодировщик теперь может создавать изображения въ цвѣтовомъ пространствѣ YCgCo-R, обеспечивая небольшой рост экономии при таком сжатии файлов, которое совершается без внесения потерь в изображение. Технически это достигается параметром «--cicp 1/13/16» в командной строке (или другим аналогичным, но также непремѣнно с шестнадцатыми матричными коэффициентами). Но здѣсь есть сразу два малоприятных нюанса.
Первый малоприятный нюанс вот каков: я пишу «небольшой рост экономии» оттого, что получающийся файл AVIF может всё ещё получаться больше файла PNG с точно тѣми же пикселами (то есть экономия всё ещё не достаточно значительна для того, чтобы превратить малоэффективное сжатие в высокоэффективное во всѣхъ случаях).
Второй малоприятный нюанс вот каков: новинка YCgCo-R, именно в силу своей новизны, не способна корректно восприниматься декодировщиками из предшествующих версий пакета libavif — поэтому, напримѣръ, во всѣхъ существующих web-браузерах цвѣта таких AVIF показаны будут некорректно.
Можно, конечно, полагаться на то, что со временем декодировщики для YCgCo-R появятся и в программах просмотра изображений, и в web-браузерах.
С другой стороны, ужé сейчас очень понятно, что въ нѣкоторыхъ частных случаях такое никогда не сдѣлается возможным. Примѣромъ может служить система Windows 7, поддержка которой прекращается, так что для неё и новые версии браузеров не выпускают. Для этого примѣра нѣкоторымъ исключением можно назвать разве что браузер Mozilla Firefox, но и его производители ограничилися под Windows 7 одним только латанием дыр безопасности, обнаруживаемых в достаточно старой версии этого браузера (в Firefox 115) — да и это всего только до сентября 2025 г.:
В этой новой версии (вышедшей 25 февраля под номером 1.2.0; здѣсь можно прибавить, что 17 марта появилась болѣе новая версия 1.2.1, незначительно дополняющая предшественницу) можно было сразу замѣтить (и я замѣтилъ анонимно на 410чане 26 февраля, а на канале в Телеграме прилагаю скриншот чуть выше) четыре новинки:
① Кодировщик теперь может создавать изображения въ цвѣтовомъ пространствѣ YCgCo-R, обеспечивая небольшой рост экономии при таком сжатии файлов, которое совершается без внесения потерь в изображение. Технически это достигается параметром «--cicp 1/13/16» в командной строке (или другим аналогичным, но также непремѣнно с шестнадцатыми матричными коэффициентами). Но здѣсь есть сразу два малоприятных нюанса.
Первый малоприятный нюанс вот каков: я пишу «небольшой рост экономии» оттого, что получающийся файл AVIF может всё ещё получаться больше файла PNG с точно тѣми же пикселами (то есть экономия всё ещё не достаточно значительна для того, чтобы превратить малоэффективное сжатие в высокоэффективное во всѣхъ случаях).
Второй малоприятный нюанс вот каков: новинка YCgCo-R, именно в силу своей новизны, не способна корректно восприниматься декодировщиками из предшествующих версий пакета libavif — поэтому, напримѣръ, во всѣхъ существующих web-браузерах цвѣта таких AVIF показаны будут некорректно.
Можно, конечно, полагаться на то, что со временем декодировщики для YCgCo-R появятся и в программах просмотра изображений, и в web-браузерах.
С другой стороны, ужé сейчас очень понятно, что въ нѣкоторыхъ частных случаях такое никогда не сдѣлается возможным. Примѣромъ может служить система Windows 7, поддержка которой прекращается, так что для неё и новые версии браузеров не выпускают. Для этого примѣра нѣкоторымъ исключением можно назвать разве что браузер Mozilla Firefox, но и его производители ограничилися под Windows 7 одним только латанием дыр безопасности, обнаруживаемых в достаточно старой версии этого браузера (в Firefox 115) — да и это всего только до сентября 2025 г.:
11.04.202500:18
слова Джона Рональда Руэла Толкина (в переводе Зинаиды Анатольевны Бобырь), положенныя на мелодию Брайана Гарольда Мэя
26.02.202501:01
Вижу два готовых постскриптума к моему сообщению 12 ноября про близость античных людей к изобретению возможности записи звуков и изображений.
Первый постскриптум вот каков: на имиджборде 4chan появилося обсуждение вопроса о том, кто и чему смог бы научить античных греков, кабы чудом попал к ним. Гиперссылку на архивную копию (на сайте desuarchive) прилагаю, скриншот также прилагаю. Любопытно то, что идея записи звуков или изображений, насколько я мог замѣтить, не упоминалася в этом обсуждении.
Второй постскриптум вот каков: на канале @hellenistics обнаружился пересказанным анекдот о том, что в Древнем Риме никоим образом не могли бы изобрести фонограф — но потому только, что вмѣсто него могли бы изобрести соноскриптор.
Первый постскриптум вот каков: на имиджборде 4chan появилося обсуждение вопроса о том, кто и чему смог бы научить античных греков, кабы чудом попал к ним. Гиперссылку на архивную копию (на сайте desuarchive) прилагаю, скриншот также прилагаю. Любопытно то, что идея записи звуков или изображений, насколько я мог замѣтить, не упоминалася в этом обсуждении.
Второй постскриптум вот каков: на канале @hellenistics обнаружился пересказанным анекдот о том, что в Древнем Риме никоим образом не могли бы изобрести фонограф — но потому только, что вмѣсто него могли бы изобрести соноскриптор.
20.02.202520:26
"Новая историческая общность" родом из СССР – всё. Официально. Никаких больше "новиопов". Теперь – "общероссийская гражданская идентичность". Сокращённо – "огражид" ✌️
20.02.202510:05
Поэтъ промолвилъ: «Заповѣдалъ Кей-Хосровъ
Собрать брильянты и изъ нихъ сарай для дровъ —
И вырыть ровъ
Для ста костровъ,
Чтобъ въ яркомъ свѣтѣ заблисталъ сарай для дровъ».
Собрать брильянты и изъ нихъ сарай для дровъ —
И вырыть ровъ
Для ста костровъ,
Чтобъ въ яркомъ свѣтѣ заблисталъ сарай для дровъ».
06.02.202501:00
ㅤ
05.02.202502:41
Хозяйка канала @orientwitch сообщила, что въ нынѣшнемъ году сэцубун наступил на день раньше привычного дня — и что теперь таким будет каждый четвёртый год.
记录
22.04.202523:59
1.3K订阅者31.05.202423:59
0引用指数21.04.202514:16
925每帖平均覆盖率16.01.202501:36
460广告帖子的平均覆盖率28.02.202515:19
16.57%ER21.04.202514:16
72.61%ERR登录以解锁更多功能。