Сегодня (25 ноября) я стал сорокачетырёхлѣтнимъ.

Прошедший год жизни был наполнен прежде всего переживаниями за русский люд, продиктованными остросюжетными событиями казахстанскими и затѣмъ ещё украинскими, наложенными на продолжающуюся ковидную эпидемию. Я сейчас не стану высказываться тут о них подробнѣе: трудно что-то прибавить к тому, что всѣмъ и без меня понятно, ещё труднѣе остаться в рамках одного сообщения в Телеграме (вѣроятно, понадобится сочинить нѣсколько сообщений, а между ними дѣлать многодневные перерывы, преисполненные тягостных раздумий).

Telegram во весь год продолжал почти полностью игнорировать проблемы и недостатки, мною в нём обнаруживаемые и сообщаемые (особенно досадным представляется продолжающееся переужатие иллюстраций сёрверами из JPEG в JPEG).

Чему я порадовался на сорок четвёртом году жизни? А вот чему:

① В Телеграме появилось скрытие спойлеров (правда, только для текста, а не для иллюстраций) и отправка видеофайлов до четырёх гигабайтов (правда, за плату). Этим возможностям я порадовался, но пользуюсь ими мало и недостаточно, в отличие от реакций, которые также появились меньше года назад, а выглядят в Телеграме так удобно, как будто много лѣтъ привычны. Telegram Desktop отдѣльно порадовал ростом качества сохраняемых (а при опредѣлённыхъ условиях — и отправляемых) иллюстраций.

② Наконец стандартизирован был графический формат файлов JPEG XL, которого я ждал года на два раньше.

③ Я освоил полезное программное обеспéчение, ранѣе мнѣ не извѣстное: и pngquant, и Efficient Compression Tool, и SVT-AV1, и PySceneDetect, и сохранение ключевых кадров из видео AV1 в файлы AVIF, совершаемое без внесения потерь и без наращивания объёма файла.

④ Я окончательно осознал то, с какими параметрами лучше всего использовать gifski при создании анимированных WebP (и зачѣмъ).

⑤ Форчан обзавёлся поддержкою видеозаписей VP9 в файлах WebM и тѣмъ дал мнѣ повод понять, что и Firefox поддерживает VP9 лучше, чѣмъ я думал до этого.

⑥ Эппловский браузер Safari в сентябре начал показывать файлы AVIF на новѣйшихъ эппловских смартфонах и съ тѣхъ поръ продолжает наращивать поддержку AVIF, то есть эппловское воздержание от поддержки AVIF закончилося. (А вот дуровское продолжается.)

⑦ Я научился создавать видеоролики со звуком USAC.

Мой лонгрид года — новый обзор возможностей AV1 на сайте Telegraph.

Одним из тѣхъ небезынтересных и увлекательных занятий, о которых я заговорил в начале своего сообщения 24 ноября, оказалось погружение в нюансы колориметрии и цвѣтовоспріятія.

По своему направлению это занятие может считаться продолжением того знакомства с возможностями и недостатками цвѣтового пространства Adobe RGB, которое я ужé упоминал в первом абзаце постскриптума 9 ноября.

Возможность для такого продолжения дала мнѣ наводка, прозвучавшая в выпуске №345 подкаста «Веб-стандарты» и отражённая в его списке ссылок.

По этой наводке я познакомился съ цвѣтовымъ пространством OKLCH и затѣмъ с его помощью свѣжимъ взглядом увидал возможности цвѣтового охвата, предоставляемого дисплеями, работающими в различных цвѣтовыхъ пространствах: sRGB, P3, Rec. 2020.

В эти дни я впервые окончательно ощутил, что внѣшняя поверхность того дисплейного цвѣтового пространства, которое модель HSL пыталась представить в форме цилиндра или хотя бы в форме двойного конуса (а в том ей помогал равнобедренный цвѣтовой треугольник и в интерфейсе цвѣтоподборщика GTK, и даже в GIMP), съ точки зрѣнія человѣческаго цвѣтовоспріятія оказывается гораздо болѣе сложною поверхностью, на которой видны и шипы (пики), и остроугольные хребты, и громадные выщербины (жёлобы, изъяны, ложбины, долины), и нѣкія волны.

В эти дни я впервые окончательно ощутил, что наращивание охвата цвѣтовъ (WCG, wide color gamut) приносит пользователям не только бóльшую монохроматичность основных цвѣтовъ (скажем, красного или зелёного, которые в дисплеях sRGB по техническим причинам использовали широкий спектр излучения, далёкий от монохроматичности) и даже не только бóльшую насыщенность тѣхъ промежуточных цвѣтовъ, которым прежде цвѣтности недоставало (скажем, оранжевых или голубых), но и возможность удержания прежней насыщенности въ болѣе широком диапазоне яркости в случае таких цвѣтовъ, для которых её удержание в пространстве sRGB не было возможным (то есть для которых наращивание или уменьшение яркости повлекло бы в пространстве sRGB необходимость разбавления бѣлымъ или чёрным цвѣтомъ и оттого неизбѣжнаго умаленія цвѣтности) — и всё это только вслѣдствіе WCG, то есть без опоры на такие возможности, которые приносит рост глубины (битности) цвѣта или которые обеспечиваются наращиванием дисплейного диапазона возможной яркости пикселов (наращиванием, которое обѣщаетъ идея HDR).

Вчера (29 ноября) я записал бѣглый рассказ об этом, который продлился без мáлого 2⅕ часа.

Этот-то рассказ я и прилагаю въ слѣдующемъ сообщении.

1:34 Рѣчь пойдёт о цвѣтовомъ пространстве OKLCH, недавно получившем поддержку в CSS

1:59 Основной материал взят из текста Ситника и Тёрнера во блоге Evil Martians

4:10 Смысл L и C и H

5:42 Достоинства OKLCH

9:01 Недостатки OKLCH — оборотная сторона новизны и широкого охвата цвѣтовъ

10:57 Ввиду новизны OKLCH пока годится не непосредственно в WWW, а как средство подбора цвѣтовъ

12:10 Цвѣтоподборщикъ OKLCH на сайте Evil Martians

16:09 Прошлогодняя критика HSL и трёхмѣрная форма области цвѣтовъ, доступных для воспріятія человѣкомъ, наблюдаемая в пространствах CIELAB и CIELCH

23:38 Цвѣтовыя пространства в ноябрьском черновике CSS Color Module 4

28:01 Обречённость попыток показать на экране sRGB цвѣта, находящиеся за предѣлами его возможностей

29:00 Удобство диаграммы хроматичности в координатах x и y пространства CIE 1931: наглядность цвѣтовыхъ треугольников RGB, ясный смысл «радужного периметра» (состоящего из монохроматических цвѣтовъ)

39:54 Недостаточность цвѣтовъ TrueColor для WCG (для широких цвѣтовыхъ охватов)

42:44 Rec. 2020 не имѣетъ прямого отношения к 2020 году

43:46 Обзор недостатков HSL по викистатье

52:03 «OKLCH»? — а что «не ok» в CIELCH?

55:27 Появление OKLCH в декабре 2020 года

1:02:54 Случайный выбор исходнаго цвѣта цвѣтоподборщиком OKLCH

1:05:54 Треугольник насыщенности и яркости цвѣта

1:08:16 Чрезмѣрная идеальность двойного конуса HSL

1:12:06 Диаграмма насыщенности и тона цвѣта — прямоугольное представление длины радиусов, исходящих из центральной сѣрой оси

1:17:31 Диаграмма цвѣтового тона и яркости — развёртка внѣшней поверхности цилиндра, равноотстоящего от центральной сѣрой оси

1:20:36 Предѣльная яркость и насыщенность, всё ещё обеспечивающая непрерывность цвѣтового круга

1:26:54 Самый насыщенный синий цвѣтъ средней яркости

1:30:24 Мимо красного к зелёному пику яркости и насыщенности

1:34:36 Яркая фуксия

1:38:24 Других пиков нѣтъ

1:41:06 Достоинства P3 и Rec. 2020

1:50:23 Красный пик sRGB

1:52:26 Цвѣтовые пики в P3 и Rec. 2020

2:06:24 Небесконечность цвѣтонасыщенности

Теперь у этого канала замѣтно больше читателей, чѣмъ было в это же время в среду на прошлой недѣлѣ.

Автор канала @wehearfromyanina и затѣмъ ещё автор канала @norin_ea (первый из них — 7 декабря в 23:35, а второй — 8 декабря в 0:10) упомянули только мой псевдоним и мой канал, ничего больше не поясняя о моём образе мыслей и о чём пишу — этого ужé оказалось достаточно для прихода сотен новых читателей (больше 420 человѣкъ).

Упомянувших благодарю, пришедших привѣтствую!

Принято ещё говорить «устраивайтеся поудобнѣе», но я скажу это практически, укажу реальный способ устроиться поудобнѣе: подтолкните телегу, пусть Telegram дѣлается поудобнѣе для всѣхъ (а заодно поудобнѣе и для авторов каналов, только что выше упомянутых).

К чему можно подтолкнуть телегу? — к принятию вѣрныхъ рѣшеній о желаемых удобствах.

Чѣмъ же можно подтолкнуть телегу к ним? — буквально нѣсколькими движениями пальцев: лáйками.

Привожу четыре примѣра таких желаемых удобств:

① Хорошо ли, удобно ли, что на канале @wehearfromyanina для удобного просмотра в Телеграме видеозаписей боевых дѣйствій поневоле приходится использовать контейнер MP4, содержащий видео AVC со звуком AAC? Можно было бы и поудобнѣе: болѣе новый контейнер WebM (видео VP9 со звуком Opus содержащий) поддерживает меньший размѣръ файла (примѣрно в √2 раз) при равном качестве (или большее качество кадров при равном объёме файла), причём звук Opus ужé используется Телеграмом (в голосовых сообщениях), VP9 в WebM также ужé используется Телеграмом (и в видеостикерах, и в премиальных эмоджи), осталось подтолкнуть телегу чуть дальше — пожалуйста, лайкните предложение поддерживать просмотр WebM видеопроигрывателями.

② Хорошо ли, удобно ли, что на канале @norin_ea мы видим в Телеграме раз за разом иллюстрации искусственно уменьшенными до 1280 пикселов по большей стороне (напримѣръ, фото кота, или видеокадр с клинком, или скриншот записи из Твиттера), тогда как тот же Twitter поддерживает вот ужé три года (с декабря 2019 года) до 4096 пикселов? Когда в августе 2013 года Telegram запускался на iOS, тогда это было очень хорошо (больше длины экрана iPhone 5), но сейчас не хорошо, не современно — пожалуйста, лайкните предложение разрѣшить отправку до 2560×2560 пикселов в Telegram (на сёрверной стороне к этому, по-видимому, всё готово, осталось только подтолкнуть телегу к этому).

③ Удобно ли, что Telegram норовит отправлять иллюстрации непремѣнно перекодированными в формат JPEG? Кажется, не слишком удобно, поэтому, пожалуйста, лайкните предложение не перекодировать PNG в JPEG, когда JPEG больше PNG по объёму, лайкните предложения о поддержке болѣе новых форматов (WebP и AVIF) просмотрщиком иллюстраций и альбомов, а главное — лайкните предложение отказаться от перекодировки JPEG-в-JPEG на стороне сёрвера, потому что от той перекодировки адски страдают (теряя визуальное качество) всѣ самыя популярныя (и оттого сохраняемыя и перепосылаемыя) картинки: мемы, постеры, впечатляющие фотографии, скриншоты умопотрясающих новостей, etc.

④ Не стыдно и не досадно ли, что автору канала @wehearfromyanina в комментариях предлагают вмѣсто LJ пользоваться сайтом Telegraph, расхваливая 64-килобайтовое ограничение (формально подобное LJшному 64-килобайтовому ограничению), однако поневоле приходится сообщить, что это ограничение на сайте Telegraph соблюдается не в точности? Но тогда, пожалуйста, лайкните предложение исправить подсчёт сѵмволовъ на сайте Telegraph, да заодно уж лайкните и предложение исправить вставку адресов внѣшнихъ файлов MP4 на страницы сайта Telegraph.

В сущности, этакое подталкивание телеги оказывается сродни извѣстному салонному фокусу: одному человѣку трудновато приподнять другого, но пятеро могут подымать его даже кончиками пальцев — так и тут немногие руководители Телеграма не в силах могут быть обозреть каждую небольшую возможность дальнѣйшаго малого улучшения его удобств, однако десятки людей, кончиками пальцев лайкающие ряд предложений, тем самым уж и подталкивают прогресс Телеграма помалу.

Если кто думает, что недостаточно только лайкнуть, то тогда можете ещё и репостнуть это моё сообщение.

слова Есенина, мелодия Гайдна

Когда в июле позапрошлого (2020) года я начал осваивать средство oxipng для сжатия файлов PNG, совершаемого без внесения потерь в них, то для начала ѿмѣтилъ превосходство oxipng над OptiPNG по силе сжатия (за счёт примѣненія алгоритма Zopfli файлы PNG получалися на нѣсколько процентов меньше по объёму, чаще всего около 2%, а иногда до 8% доходило) и превосходство по скорости (главным образом за счёт распараллеливания), а затѣмъ собрал 19 примѣровъ противоположного (то есть 19 таких файлов PNG, которые не мог при помощи oxipng в режиме Zopfli сжать сильнѣе).

С той поры чуть больше двух лѣтъ существенно не перемѣнялась ни сила сжатия, ни скорость работы oxipng, однако сейчас (в декабре) их неизмѣнность подошла к концу.

Во-первых, 7 декабря вышла седьмая версия oxipng, оснащённая как новым набором эвристических средств для подбора фильтров PNG под содержимое файла, так и алгоритмом заблаговременной оцѣнки эффективности такого подбора. Но тогда (в начале нынѣшняго мѣсяца) я никак не мог ощутить достоинства ни того, ни другого из этих двух улучшений, поскольку в той же версии у меня нипочём не запускалося сжатие Zopfli.

Во-вторых, 24 декабря вышла восьмая версия oxipng, в которой работа Zopfli была исправлена наряду с внесением ряда других улучшений, впрочем менѣе значительных по сравнению с появившимися в седьмой версии.

Вслѣдствіе этого я наконец мог сравнить работу oxipng новой версии (в режиме Zopfli) с аналогичным режимом той предшествующей версии (6.0.1), которою пользовался до этого. И, сравнив их, тотчас дѣлаю полдюжины вот каких наблюдений:

① Вижу состоявшимся отказ от распараллеливания большей части работы oxipng. Шестая версия oxipng могла очень долго занимать шесть потоков (напримѣръ, три двухпоточных ядра процессора) работою, параллельно испытывая (в реальной работе, то есть в кодировании всего изображения) всѣ пять фильтров PNG и ещё одну эвристику переключения между фильтрами. Восьмая же версия oxipng стремительно пробует цѣлый десяток разных вариантов (пять фильтров и ещё пять эвристик переключения между фильтрами), затѣмъ обнаруживает среди них такой, который лучше других подходит к файлу, затѣмъ только его и применяет (однопоточно) при переужатии PNG, а всѣми остальными вариантами полностью пренебрегает. Это выглядит не так надёжно (приходится довѣрять не сравнению реальных итогов работы разных потоков, а способности oxipng заранѣе угадать среди возможных итогов наилучший), но зато многократно сокращает нагрузку на процессор.

② Сокращение усилий оказывается далеко не таким же многократным, как сокращение многопоточности. Наиболѣе эффективною из новых эвристик (и оттого чаще всего выбираемою для работы oxipng) оказывается «грубая сила» (brute force), то есть ряд послѣдовательныхъ попыток попробовать каждый из фильтров, возможных в PNG, при сжатии очередной строчки пикселов, а затѣмъ выбрать тот фильтр, который дал наименьшее число байтов. Число потоков сократилось вшестеро, но время работы одного оставшегося потока упятерилося.

③ Эта жертва (рост времени работы) оказывается не напрасною, то есть за её счёт оказывается достигнут реальный дальнѣйшій рост эффективности: «грубая сила» опережает единственную эвристику болѣе ранних версий oxipng (по-видимому, тот классический алгоритм, который Crocker упоминал ещё в 1995 г.), позволяя уменьшить чересстрочные файлы PNG, ранѣе ужатые шестою версиею oxipng, ещё примѣрно на 1½–2½ процента их объёма. Восьмая версия oxipng оказывается настолько же лучше шестой версии, насколько в 2020 году тогдашняя версия oxipng восторжествовала над OptiPNG и тѣмъ убедила меня перейти на oxipng.

④ Мощь эвристики «грубая сила» способна до нѣкоторой степени превозмогать собою рѣдкія неудачи Zopfli: из 19 примѣровъ таких неудач 2020 года только 9 не могут быть далѣе сжаты в oxipng восьмой версии.

⑤ Эта оцѣнка эффективности субьективна: примѣры неудач Zopfli подобраны из числа моих сшивок кадров аниме, а шестую и восьмую версию oxipng я сравнивал на произведениях японских цифровых художников, взятых на Danbooru.

⑥ Хорошо бы разработчик oxipng в будущем распараллелил «грубую силу».

11 августа позапрошлого (2020) года, впервые завершив пробовать то сжатие файлов PNG по алгоритму Zopfli без внесения потерь, которое утилитою oxipng достигается, я обнаружил, что не всегда оно даёт лучший результат. Удалось обнаружить девятнадцать таких файлов PNG (главным образом моих сшивок кадров аниме), которые от этого сжатия не выиграли (то есть они были меньше по объёму до этого, когда я сжимал их в OptiPNG по другому алгоритму). И тогда я сохранил на канале архив (7-Zip), состоящий именно из этих 19 файлов.

Прошло чуть больше 2⅓ лѣтъ.

Попробовав теперь новую (восьмую, 24 декабря появившуюся) версию oxipng, содержащую нѣсколько улучшений (только что перечисленных в предшествующем сообщении), я увидал, что достигаемое ею сжатие файлов улучшилося и что поэтому из девятнадцати тогдашних файлов, мною заархивированных, бóльшая часть может быть сильнѣе ужата посредством oxipng восьмой версии. Только девять файлов продолжают оставаться исключением.

Вот имена этих девяти файлов:

Choyoyu - broken trunk deeply cut by talons.png

Isekai Cheat Magician - meeting adventurers.png

Isekai Maou to Shoukan Shoujo no Dorei Majutsu - green plains and mountain scenery near Bridge of Ulug.png

Isekai Maou to Shoukan Shoujo no Dorei Majutsu - Shera L Greenwood in ecstasy.png

Kyokou Suiri - Steel Lady Nanase has instantly become more violent.png

Lord El-Melloi II Case Files - observing the gates leading to the world of fairy.png

Maou-sama, Retry! - Aku surprised a bit.png

Princess Connect! Re Dive - sunset dinner.png

Suzumiya Haruhi no Yuuutsu - a bench in the park where Asahina Mikuru sits telling Kyon about Suzumiya Haruhi (closer view).png

Я выкладываю их тут в архиве, но не ѿдѣльно, а вмѣстѣ с остальными десятью (так что всего их по-прежнему девятнадцать), чтоб заодно можно было наглядно оцѣнить степень сжатия остального десятка файлов PNG и воочию убедиться в том, что их сжатие получилося не особенно значительным, но что оно налицо.

Общий объём файлов уменьшился, зато вырос объём архива (7-Zip); причины не знаю.

Предшествующую полудюжину наблюдений за поведением восьмой версии oxipng можно пополнить (и пополняю) вот ещё какими:

⑦ Я пишу об употреблении oxipng для сжатия чересстрочных файлов PNG (то есть с пикселами, перераспредѣлёнными по алгоритму Adam7), потому что на нѣсколькихъ примѣрахъ попробовал и убедился, что нечересстрочные файлы PNG всё ещё и лучше, и быстрѣе сжимает не oxipng (хотя бы и восьмой версии), а Efficient Compression Tool.

⑧ Мощь эвристики «грубая сила» не слѣдуетъ считать непревосходимою, потому что в одном из частных случаев (файл «Isekai Maou to Shoukan Shoujo no Dorei Majutsu - green plains and mountain scenery near Bridge of Ulug.png» в только что приведённом архиве антагонистов Zopfli) она даёт больший объём файла (то есть худший результат) по сравнению с эвристикою «highest Shannon entropy», которую автоматически подбирает и использует oxipng. Это означает, что можно сжимать каждую ѿдѣльную строку пикселов наилучшим образом (потому что именно так работает «грубая сила»), а всё же не наилучшим образом сжать весь файл. (А как это вообще возможно? Это что же, оптимальность сжатия послѣдующихъ строк пикселов оказывается «в плену» рѣшеній, принятых для предыдущих строк пикселов и успѣвшихъ «отравить собою» хаффмановское дерево в рамках алгоритма DEFLATE?) Ещё оказывается, что автоподбор эвристик в oxipng способен заранее распознать эту ситуацию и выбрать другую эвристику. (У меня нѣтъ вообще ни одной догадки о том, что лежит в основе этой умопотрясающей способности, так что её понимание придётся отложить до тѣхъ поръ, когда я найду время и желание читать исходный код oxipng.)

⑨ Автоподбор эвристик в oxipng не слѣдуетъ считать безошибочным, потому что в одном из частных случаев (вон то изображение дѣвушки с подсолнухами на фоне кумулонимбуса и глубокого синего неба) oxipng рѣшаетъ использовать нулевой фильтр (возможно, руководясь однообразием многих первых строк пикселов файла, изображающих пустое небо?), однако эвристика «грубая сила» сжимает этот файл сильнѣе на 3¾%. Если бы не было предшествующего наблюдения (о неидеальности этой эвристики), то тогда при виде такой ошибки автоподборщика можно было бы вообще отказаться от автоподбора и впредь всегда запускать сжатие PNG только одним способом (выбирать фильтры PNG только «грубою силою», то есть только полным перебором их). Но так как предшествующее наблюдение означает, что и такой подход не всегда обеспечивал бы наилучший результат, то тогда поневоле придётся дѣлать только одно: всякий раз сперва сжать файл PNG тем способом, который автоматически подберёт oxipng (с параметром «-f 0-9»), а затѣмъ (или параллельно) сжать тот же файл PNG «грубою силою» (запуская oxipng с параметром «-f 9») и сравнить с предшествующим результатом по объёму получающегося файла, вручную выбрать наилучший объём. (Разумѣется, такой двукратный запуск oxipng не требуется в том случае, когда oxipng ещё при первом запуске самостоятельно рѣшаетъ прибѣгнуть именно ко «грубой силе», как это чаще всего и случается.)

⑩ Если сравнивать эффективность шестой и восьмой версии oxipng не на примѣрахъ произведений японской визуальной культуры, а на различных сочетаниях текстов и простых (не художественных, а справочных) иллюстраций, то тогда новая версия oxipng (и её «грубая сила» полного перебора всѣхъ фильтров PNG) оказывается ещё болѣе эффективною. Попробовав заново сжать 3855×4096 пикселов растрового рендера векторного файла, изображающего величину охвата различных цвѣтовыхъ пространств, я получил 4½% экономии. Попробовав заново сжать 1280×4074 пикселов скриншота страницы сайта «Cambridge in Colour», сравнивающей цвѣтовое пространство Adobe RGB (1998 года) и sRGB, я получил 4¾% экономии. Попробовав заново сжать 1280×9660 пикселов скриншота страницы «The Case for JPEG XL», я получил 7¼% экономии и так удивился, что на всякий случай ещё раз перепровѣрилъ то, точно ли я попробовал ужé сжатый файл PNG, а не несжатый (то есть точно ли именно таков был результат примѣненія шестой версии oxipng к этому файлу). Но ошибки не было: восьмая версия и впрямь настолько опередила шестую в этом примѣрѣ.

Закончился 2022 год, но не закончилося подведение итогов года. Я продолжаю их подведение.

Прежде всего хочу указать вот на что: за весь год наибольшее число реакций и репостов вызвало то моё сообщение, в котором содержалось обращённое к вам предложение подтолкнуть телегу.

Сейчас поэтому я рад сообщить, что оно было не напрасно: нам удалось подтолкнуть телегу в одном из направлений, о которых тогда шла рѣчь.

В шестом часу вечера 2 января появилась версия 4.5.1 приложения Telegram Desktop, которая содержит (в окне экспериментальных настроек) переключатель, запускающий возможность отправки иллюстраций величиною до 2560 пикселов по большей стороне (а не только до 1280, как было до этого). Если эта новинка вызовет благоприятную реакцию пользователей, а не какую-нибудь неприязнь (ну, скажем, порождённую возросшим временем скачивания крупных иллюстраций, совершаемого через небольшие каналы мобильной связи), то тогда станет потихоньку распространяться и по другим приложениям Телеграма в наступившем году.

Считаю, что важную роль в произошедшем сыграли ваши лайки. Их было немало: вам удалось ≈удвоить то количество лайков, которое было прежде (с 11 марта по 12 декабря) накоплено моим предложением о двукратном наращивании величины картинок в Телеграме. И вот это предложение было услышано и реализовано непосредственно в Телеграме. Можно порадоваться, и радуюсь.

Вдобавок хочу обратиться (и вот обращаюсь) со словом надежды к таким моим читателям, которые до сих пор ещё ни на что не понадѣялись и не лайкнули ни одно из моих предложений, тогда перечисленных (дескать, всё равно ничего не измѣнится от этого). Правда, три недѣли назад было меньше возможности надѣяться; но теперь, раз уж одно из предложений реализовано, то перед вами повод надѣяться (и далеко не безосновательно) на реализацию нѣкоторыхъ других и лайкать с чуть большею энергиею и даже, может быть, с воодушевлением.

☦️ СЪ ПРОШЕДШИМЪ РОЖДЕСТВОМЪ! ☦️

Руководимый рождественскою искренностью, я хочу сознаться, что в моём предшествующем сообщении получилась хитрость: рассказывая о впечатляющем и понятном результате подталкивания телеги, который будет имѣть ясныя и немедленныя благотворныя послѣдствія (шутка ли: предѣльный размѣръ картинок в Телеграме удвоился!), я нарочно придерживал до другого времени рассказ о ничуть не менѣе впечатляющей и даже чуть раньше явившейся новинке, которую я предлагал, но подталкивать не просил, полагая её эффект менѣе понятным и менѣе широко примѣнимымъ, а оттого предвидя не особенно немедленное и не особенно обширное наступление благотворных послѣдствій.

Суть такова: разработчики приложения Telegram Desktop добавили ему способность (начиная от бета-версии под номером 4.4.2, которая была собрана ещё 28 декабря) показывать из файлов MP4 видеопотоки в формате AV1. Этот видеоформат к настоящему времени получил поддержку десятков значительных компаний, но по сути является новинкою, созданною в 2018 году объединением и улучшением только трёх болѣе ранних видеоразработок, которыми были VP10 (из Google), Daala (из Фонда Xiph и Фонда Мозиллы) и Thor (из Cisco). Единое цѣлое вышло настолько лучше суммы его частей, что существующий вот ужé ≈20 лѣтъ формат Advanced Video Coding (AVC, он же H.264; первая его версия создана в мае 2003 года), который всѣ мы привыкли видѣть в MP4, превосходится форматом AV1 примѣрно двукратно по соѿношенію качества и объёма файла.

Иными словами, если кому-нибудь надо не просто вырѣзать кусок видео для цитирования, а и непремѣнно переужать с внесением потерь (а не то не помѣщается), то тогда при равном качестве в формате AV1 видеофайл будет ≈вдвое меньшим, чѣмъ в формате AVC. При равном же объёме качество AV1 будет выше. (Вообразите для примѣра, что рядом лежат стомегабайтовое видео AV1 и стомегабайтовое видео AVC, переужатые из одного первоисточника. Качество AV1 при этом будет примѣрно таким, которое было бы у двухсотмегабайтового видео AVC.)

Вы можете догадаться теперь, почему я придержал рассказ о новинке и скромно оцѣниваю небольшую ширь возможнаго примѣненія ея.

Заранѣе предвижу, что при виде поддержки AV1 полудюжина первых мыслей обычного пользователя Телеграма будет какою-нибудь такою:

① Ну да, результат не менѣе впечатляющий, чѣмъ рост изображений до 2560 пикселов: там двукратна разница по ширине (или высоте), а тут двукратна разница по объёму. Притом же рост изображений надо включать в настройках Telegram Desktop, а просмотр AV1 работает сразу. Хорошо!

② Но картинки (фото, мемы, скриншоты, etc.) кто угодно кладёт в Telegram частенько, а многие ли (и часто ли) кладут видео?

③ Даже если кладут видео в Telegram, то чаще всего весь файл цѣликомъ «как есть», а не цитируют его кусок. Часто ли случается так, чтобы видеофайл «как есть» ужé был в формате AV1?

④ Даже если цитируют кусок видео, то чаще рѣжутъ от подходящего ключевого кадра (особенно если тот разумно был расположен в начале новой сцены) и до желаемого окончания цитаты. Такой кусок не требует перекодировки, совершаемой с внесением потерь в файл, так что не приходится заботиться о качестве её результата.

⑤ Возможно ли вообще, чтоб видеофайл в Телеграме упёрся в двухгигабайтовое ограничение объёма пересылаемых файлов? — если и возможно, то всегда можно купить услугу Telegram Premium, которая обеспечит и способность отправлять до четырёх гигабайтов, и другие полезные способности.

⑥ Разве не владельцы так называемых «пиратских» каналов, распространяя нелицензионные копии видеофильмов и телесериалов, чаще всего упираются в двухгигабайтовое или четырёхгигабайтовое ограничение? «Пиратам» же и Telegram Premium не так повадно оплатить (с большою вѣроятностью их забанят по DMCA, так что деньги окажутся потраченными зря), так что для них ограничение чаще оказывается двухгигабайтовым — не на них ли рассчитана новинка, приносящая в двухгигабайтовом видеофайле «четырёхгигабайтовое качество»? Кажется, только на них, а обычному пользователю не нужна!

Реальная применимость AV1 всё же шире, о чём я расскажу въ слѣдующемъ сообщении.

Итак, в предшествующем сообщении я предвидѣлъ, что при виде появления поддержки нового видеоформата (AV1), невзирая на его ≈двукратное превосходство над AVC по объёму файла при равном качестве (по оцѣнкамъ Facebook, оглашённым в 2018 году и затѣмъ ещё в 2021 году), первая полудюжина мыслей пользователей Телеграма будет неизбѣжно в итоге склоняться к тому выводу, что этакая новинка не особенно нужна в Телеграме (с его-то двухгигабайтовым ограничением объёма файла, а для оплативших услугу Telegram Premium и четырёхгигабайтовым, в которое трудновато упереться), а если кому и нужна, то прежде всего так называемым «пиратам».

Сам же я вижу, что практическая примѣнимость AV1 окажется в Телеграме нѣсколько болѣе широкою, зная в её пользу ещё семь аргументов:

① Скорость скачивания видеофайлов (и вообще файлов), доступная пользователям Телеграма, искусственно ограничивается (это ограничение снято только у купивших услугу Telegram Premium или получивших её в подарок). Поэтому, даже если видеофайл ещё не упирается в двухгигабайтовое или четырёхгигабайтовое ограничение объёма, то и тогда создатель видеофайла может пожелать уменьшить удѣльный объём (битрейт: количество килобитов в секунду) для того, чтобы возможность «потокового» просмотра видеозаписи по мѣрѣ ея скачиванія (возможность, существующая в Телеграме вот ужé ≈5 лѣтъ с 6 февраля 2018 года) не нарушалася «заиканиями» скачивания.

② Если создатель видеофайла руководится потребностями таких зрителей, у которых скорость мобильного Интернета невысока (бойцы в окопах, гражданские лица в сельской мѣстности или в городской толпе: на концерте, на митинге, на набережной при просмотре водных фейерверков, etc.), то тогда может пожелать ещё сильнѣе уменьшить битрейт.

③ Нѣкоторые элементы Телеграма используют гораздо болѣе жёсткое ограничение объёма файлов, чѣмъ двухгигабайтовое. Напримѣръ, область предпросмотра гиперссылок, расположенная под сообщениями, не появляется для гиперссылок на видеофайлы, превосходящие 20 мегабайтов. Так как длина обычного сообщения ограничивается в Телеграме 4096 сѵмволами, но длина подписи под видео ограничивается 1024 сѵмволами (2048 для купивших Telegram Premium), то нѣкоторымъ пользователям повадно экономить, сочиняя обычные сообщения и располагая видео под ними (в области предпросмотра), для чего достаточно поставить гиперссылку на такое видео первою в сообщении. От поддержки AV1 разумная длина таких видео ≈удвоится (или возрастёт качество).

④ Ещё меньшею (пятнадцатимегабайтовою) величиною ограничивается объём видеофайла, доступного для просмотра незалогиненным зрителям. (Примѣръ: если напечатать адрес https://news.1rj.ru/str/kepka_support/143575 в адресной строке браузера и нажать на ввод, то покажется не видеопроигрыватель, а сообщение «Media is too big» с кнопкою «VIEW IN TELEGRAM».) Той же величиною ограничены приложения к сообщениям на официальном сайте жалоб и предложений Телеграма (поэтому мой болѣе чѣмъ восьмиминутный видеорассказ о необходимости чинить счётчик сѵмволовъ на сайте Telegraph был приложен к моей жалобе именно в формате AV1).

⑤ Сайт Telegraph, созданный (в ноябре 2016 года) как хранилище пространных текстов (не помѣщающихся в сообщения Телеграма), принимает видеофайлы объёмом не болѣе пяти мегабайтов, чѣмъ дѣлаетъ использование AV1 почти совершенно неизбѣжнымъ в них.

⑥ Кто стремится к экономии своего траффика и оттого служит нам источником таких видеофайлов, которые «с сáмого начала» скачиваются в формате AV1? Не только «видеопираты» (напримѣръ, среди няторрентов видео AV1 кучно идёт с 2020 года), но и YouTube (там создаются AV1-варианты не только для новых видеороликов, но и для популярных старых).

⑦ При цитировании видеозаписи не всегда можно полагаться на то, что в ней ключевые кадры расставлены в начале сцен, обеспечивая возможность выхватить готовый кусок видеопотока без необходимости переужатия. Ключевые кадры могут быть расставлены иначе (без учёта измѣненій содержимого кадров) или рѣже (если измѣненія случаются часто, а битрейт надо экономить). Даже и сцена может быть одной и той же (примѣръ этого приведу въ слѣдующемъ сообщении).

Поглядите-ка на вот это высказывание Холмогорова о бандеровщине, взятое из тридцать шестого выпуска «Холмогорской рѣзьбы».

Во-первых, оно интересно отрицанием возможности подѣлить Украину между РФ и Польшею.

Во-вторых, оно прекрасно иллюстрирует собою мысль послѣдняго абзаца моего предыдущего сообщения: не только самому мне нельзя было найти ключевого кадра, удобного для начала цитирования, но и ютьюбному автоматическому расстановщику ключевых кадров нельзя было ориентироваться при расстановке на какие-нибудь рѣзкія перемѣны содержимого кадров, потому что их нѣтъ: сидят люди, плавно двигаются и говорят, больше ничего. Поэтому при цитировании неизбѣжна перекодировка, и поэтому можно рѣшить прибѣгнуть к AV1 для экономии качества. Я и рѣшилъ.

В-третьих, на примѣрѣ этого видео многим сдѣлается видно, что поддержка AV1 существует не только в Telegram Desktop, куда её добавили на послѣдней недѣлѣ прошлаго года, но и в Telegram под Android, куда её никто никогда не добавлял, так что она опирается единственно на возможности операционной системы, работая с тремя нюансами:

① нужна система Android 10 или новѣе,

② бездѣйствуетъ предпросмотр, работает только непосредственный просмотр видеозаписи: чтобы начать смотрѣть, от пользователя требуется собраться с духом и ткнуть пальцем «зависший» первый кадр (или вообще пустоту, если рѣчь идёт о предпросмотре внѣшней гиперссылки),

③ под Android можно просматривать и видео AV1, снабжённое звуком в формате USAC (также извѣстномъ как xHE-AAC), а не только въ болѣе ранних форматах звука (Opus, Vorbis, AAC и проч.).

В-четвёртых, аналогичной поддержки совсѣмъ нѣтъ на эппловских устройствах, поэтому тамошние пользователи не смогут смотрѣть в Телеграме AV1-содержащие MP4-файлы (и принуждены будут скачивать их и затѣмъ открывать каким-нибудь AV1-понимающим видеопроигрывателем — может быть, VLC сгодится?) до тѣхъ поръ, пока лайки под моим предложением поддержать AV1 в Телеграме не побудят разработчиков к обеспéчению бóльших видеовозможностей, чѣмъ предоставляемыя операционною системою.