21 апрѣля (вчера) разработчики выкатили очередное обновление приложений и возможностей Телеграма.

Когда пользователи приложения Telegram Desktop, руководимые этой новостью, начнут обновлять Telegram Desktop до свѣжайшей версии 4.8, тогда увидят, что тексты сообщений на моём канале выглядят теперь в Telegram Desktop немного не так, как прежде. Чуть лучше.

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

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

① между инициалами и фамилией («К. А. Крылов»),

② между сокращением и послѣдующимъ именем собственным («проф. Преображенскій», «г. Анапа»),

③ внутри сокращений («и т. п.»),

④ между числом и словом, к числу относящимся («XXI вѣкъ», «часть V», «128 байтов»),

⑤ перед тире в середине предложений («Россія — наше отечество»),

⑥ между группами цифр («524 288 байтов»),

⑦ перед названиями и номерами версий софтá («Windows XP», «Firefox 113»),

⑧ опосля предлогов («в Телеграме», «на сайте»),

⑨ опосля союзов («и правильно»),

⑩ опосля частицы «не» или перед частицею «бы», «ли», «же»,

⑪ между словами любого такого краткого словосочетания, которое хочется в тексте видѣть цѣлымъ («как прежде», «чуть лучше», «в тот же день», etc.).

Когда я ещё только начинал свой канал, тогда первому десятку читателей повѣдалъ 11 августа 2019 года о том, что Telegram Desktop ещё тогда игнорировал неразрывные пробѣлы (переносил текст таким образом, как если бы пробѣлы были обычными). А в Твиттере в тот же день я подмѣтилъ, что это касалося не одного только отображения и отправки, но и обработки черновиков сообщений, созданных другими клиентскими приложениями Телеграма.

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

Так продолжалось не год и не два, но теперь эти мрачные дни остаются позади: в Telegram Desktop версии 4.8 наконец появилася нормальная человѣческая поддержка неразрывных пробѣловъ.

Теперь и пользователи Telegram Desktop увидят мои сообщения в таком виде, в каком я их задумал.

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

Кто никогда не пользовался Telegram Desktop на компé (а я знаю о таких пользователях, которые поставили Telegram под Android на смартфон или планшет, да на том и успокоились), тот никогда не досадовал от особенностей обработки неразрывных пробѣловъ в Telegram Desktop и оттого не был затронут этим вчерашним улучшением. Но для меня набирать сообщения на компьютерной клавиатуре всегда чуть проще, чѣмъ диктовать распознавателю рѣчи в смартфоне или настукивать на сенсорном экране, так что Telegram Desktop был и остаётся для меня важным подспорьем, а теперича — ещё и гораздо, гораздо болѣе удобным.

Теперь предпочесть ему приложение текстового редактора я могу только ради счётчика сѵмволовъ, остающихся до достижения 4096-сѵмвольнаго предѣла и неотправляемости сообщения.

В качестве иллюстрации к истории «войн браузеров» (они же «браузерные войны» — рѣчь идёт о многодесятилѣтней борьбе браузеров за популярность среди пользователей Интернета) посмотрѣлъ визуализацию «Web browsers over the last 28 years» в сабрэддите dataisbeautiful.

Для наглядности прилагаю это видео и тут, слегка замедлив его (а не то в первоисточнике мельтешило) и притом ещё наложив его на музыку «Radio Rock», которую любезно предоставляет ея автор (Jason Shaw) на условиях лицензии Creative Commons Attribution 4.0 International.

Обратил внимание, в частности, на четыре самых значимых успѣха, достигнутых в этой «войне»:

① В сáмом начале этой истории — в январе 1994 года — мы ужé видим нѣкій успѣхъ, а именно пик популярности браузера Mosaic, доля пользователей которого достигла 97,0%. По-видимому, это восторжествование браузера Mosaic над остальными тогдашними браузерами было совершенно заслуженным благодаря большей наглядности, им достигнутой: как вспоминает сам Berners-Lee, только с появлением Mosaic дѣло дошло до показа картинок непосредственно на web-страницах (а до него принято было открывать скачанные картинки въ сосѣднемъ окнѣ — посредством того просмотрщика картинок, какой был в операционной системе).

② В марте 1996 года доля пользователей браузера Netscape достигла 89,0%. Это отражает, как я понимаю, осознание тогдашними пользователями цѣнности новинок, появившихся в Netscape Navigator версии 2, среди которых и JavaScript, и плагины, и куки, и атрибут color тега font, и зацикленные GIF-анимации.

③ В ноябре 2002 года доля пользователей браузера Internet Explorer достигла 92,8%. Его вознесла неготовность пользователей перемѣнять браузер, установленный в операционной системе. Она же вознесла слѣдующаго лидера, когда большинство систем сдѣлалися смартфоновыми.

④ В январе 2020 года доля пользователей браузера Google Chrome достигла 82,0%. Справедливо подозрѣніе FSF насчёт того, что в вердикте Google «экосистема недостаточно заинтересована в поддержке формата JPEG XL» Google зовёт «экосистемою» самих себя.

Компы или мобильные устройства (смартфоны и планшеты) болѣе популярны? — если считать по посещениям сайтов, то мобильные устройства окажутся болѣе популярными, хотя и компы не сильно отстают.

Под управлением какóй операционной системы работают мобильные устройства? — в подавляющем большинстве случаев это будет система Android.

Въ нынѣшнемъ (2023) году к выходу готовится четырнадцатая версия системы Android, но пока что до ея появленія остаётся ещё много времени, и даже первый предпросмотровый варіантъ ея появился всего-навсего три мѣсяца назад (8 февраля).

Так что сейчас послѣднею версиею среди вышедших должна считаться система Android 13, вышедшая в августе прошлого (2022) года.

А предпослѣдняя версия Android — это Android 12 (это 2021 год, если не считать болѣе позднюю модификацию Android 12L для устройств с раскладными экранами).

А ей предшествовала версия Android 11 (2020 г.) и Android 10 (2019 г.).

Выход каждой новой версии системы Android обыкновенно сопровождается общими словами про всё хорошее. Если докладчик торопится или намѣренъ быть кратким, то скажет два слóва: «система оптимизирована». Он знает, что чуть болѣе длинная фраза «многие пользовательские и программные возможности операционной системы теперь работают быстрѣе» всё равно не содержит полного перечисления улучшений, которое заняло бы нѣсколько листов и рисковало бы утомить читателя или слушателя, даже если ни словом не сказать о том, каким способом улучшения достигнуты и, главное, какой цѣною. А между тѣмъ раз въ нѣсколько лѣтъ нѣтъ-нѣтъ, да и приходится увидать, что цѣна эта втайне оказывается неприемлемлемо высокою и страшною — и от неё, быть может, волосы должны дыбом стать на голове и волнообразно зашевелиться!

Напримѣръ, так как реализация файловых систем всецѣло отдана на уровень операционных систем, то ни одна программа, в сущности, никогда не пишет ни в какóй файл напрямую, а только сообщает операционной системе: «я желаю открыть такой-то файл на запись», «я желаю записать в такой-то открытый файл такие-то данные», «а теперь ранѣе открытый файл можно закрыть» — а система дѣлаетъ всё остальное. Это система рѣшаетъ, как файл будет располагаться на диске или твердотѣльномъ хранилище. Это система рѣшаетъ, какие данные и когда записывать в файл по мѣрѣ поступления, а какие придерживать в памяти в особом буфере (чтобы не слишком изнурять хранилище лишнею операціею записи) в надежде на то, что попозже поступит ещё кусок данных, так что можно будет одной операцией записать всё накопившееся сразу. Зачастую такие буферы опустошаются только при закрытии файла, которое оказывается поэтому не таким уж и простым или быстрым дѣломъ, как его аналог из нецифрового міра. То есть закрыть файл, ранѣе открывавшийся на запись, можно не так быстро и не так просто, как закрывают, напримѣръ, дверь — если только рѣчь не идёт про дверь в овчарню, да притом ещё, может быть, такую, в которую прямо сейчас живым потоком движется цѣлое стадо, принуждая дожидаться того, когда наконец промелькнёт и скроется волосатый хвост послѣдней овцы.

Но как ни долго ждать, пока «на диск» отправляется содержимое буфера записи, а всё же во всѣхъ версиях Android, предшествующих упомянутым выше (то есть в Android 9 и ещё раньше) закрытие файла было ещё болѣе трудоёмким. Операционная система также ещё провѣряла, был ли открыт на запись файл, до того открытия ужé существовавший — и если да, то тогда система по умолчанию предполагала намѣреніе перезаписать файл цѣликомъ, так что при закрытии укорачивала этот файл, если данные записывалися от начала файла (а не дописывалися к хвосту) и если притом общий объём записанных данных оказывался меньше, чѣмъ объём файла, существовавшего до открытия.

То есть в Android 9 (и ранѣе) любой перезаписанный файл автоматически укорачивался по мѣрѣ нужды (если о нежелательности этого не сообщала системе программа), а в Android 10 (и позже) не укорачивается (если программа не пожелает того в явном виде), так что операция закрытия файла стала работать (по умолчанию) замѣтно быстрѣе.

Быстрота работы — это же главное, правда?

Неправда!… но об этом — дальше.

Оптимизацию из Android 10 (версии 2019 г.), о которой я упоминал во второй половине предшествующего сообщения, в 2021 году осудил отправитель вон того отклика, доводы в котором сводились вот к чему:

① Новинка получилась недостаточно объявленною в новостях для разработчиков (в частности, на странице основных измѣненій в Android 10) и в документации.

② Измѣнилось поведение достаточно низкоуровневого программного интерфейса (буквально имѣющаго дѣло с файлами), а перемѣнилось ли (заново подстраиваясь под него) поведение болѣе высоких интерфейсов (напримѣръ, обёртывающих работу с файлами в интерфейс так называемого потокового вывода)? — как оказалось, не очень (автор отклика нашёл опечатку в одном из тестов, а затѣмъ и возможность одного из высокоуровневых интерфейсов буквально обрушиться в новом режиме явно указанной необходимости укорачивания файла в том частном случае, когда файл лежит на Google Drive).

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

Никто не задумался о том, что если между выходом Android 10 (в 2019 г.) и указанием на недодокументированность измѣненій (в 2021 г.) прошло ≈два года, то оптимизация закрытия файлов оставалась недодокументированною всё это время. Кто ещё остался «не в курсе» насчёт произошедших измѣненій и особенно насчёт необходимости новых практик программирования? Какие ещё проблемы смогут обнаружить, если пройдёт ещё два года?

И прошло ещё два года!

Настал нынѣшній (2023) год, и 13 марта разразился скандал, получивший звучное название:

АКРОПАЛИПСИС

Это название — слово «апокалипсис», первые буквы которого нарочно переправлены таким образом, чтобы получалось английское слово «crop» в значении «обрѣзка». Чтобы понять игру слов, намѣченную таким переправлением, достаточно обратить внимание на основное значение слóва «апокалипсис» («конец свѣта») и на его буквальное значение («отдёргивание завѣсы, раскрытие тайны, откровение»), а также на использование греческой приставки «а-» в качестве отрицательной (как и в словах «алогичность», «амнезия», «аморальность», «аномия», «анорексия», «апатия», etc.), ввиду чего корень «акроп» начинает означать отсутствие обрѣзки.

Как объясняет David Buchanan у себя во блоге, суть акропáлипсиса (которую обнаружил Simon Aarons и затѣмъ огласил в Твиттере) сводится вот к чему: измѣненія, внесённые гугловскими разработчиками в систему Android 10, не дошли до свѣдѣнія даже других гугловских разработчиков — а именно той команды, которая создавала программное обеспéчение для смартфонов серии Pixel. Вышеозначенный милый нюанс ускоренного закрытия файлов не был учтён в одном из таких приложений, которое является системным и оттого установлено на каждом смартфоне серии Pixel, работающих под управлением системы Android 10 или болѣе новой. (Больше того: если смартфон с завода вышел работающим под Android 9, а затѣмъ «по воздуху» был обновлён на Android 10, то также получил эту оплошность в подарок. Таковы всѣ «Пикселы» третьей серии: Pixel 3, Pixel 3 XL, Pixel 3a, Pixel 3a XL.)

И что это было за приложение? Какую системную функцию оно выполняло?

Это было средство Markup, предназначенное для обрѣзанія скриншотов.

Каждый такой пользователь, который сперва дѣлалъ скриншот (автоматически записывая его в файл), а затѣмъ желал вырѣзать только нужную часть скриншота (и отбросить всё ненужное), в результате помѣщалъ обрѣзокъ в начало файла первоначального скриншота, но хвост файла не отбрасывался в Android 10 (или въ болѣе новых): приложение Markup полагалося на поведение операционной системы, привычное по Android 9 и болѣе ранних версий. Этот хвост (содержащий нижнюю часть первоначального скриншота, записанного сверху вниз в первоначальный файл) ещё можно было декодировать и извлечь — David Buchanan и Simon Aarons сочинили такой декодировщик и помѣстили его на созданном нарочно для такого случая сайте acropalypse.app.

Далѣе я опишу ужасы послѣдствій этого открытия.

Часть неприятных послѣдствій акропáлипсиса (техническую суть которого я только что пересказал в предшествующем сообщении) сводится к тому, что отсутствие настоящей (а не кажущейся) обрѣзки скриншота (собственно «акроп») приводит к настоящему «открытию тайн» и кое для кого может устроить личный «конец свѣта» (собственно «апокалипсис»), поскольку обычаи наши устроены так, что именно конец файла (низ скриншота) всего вѣроятнѣе содержит наиболѣе тайную часть его, и это вѣрно насчёт почти любого вида тайны:

① Банковская тайна. Вообразите блоггера, который задумал получать донаты от читателей и для того завёл новую банковскую карту. Банк прислал ему документ с изображением лицевой и затѣмъ оборотной стороны карты (логичен именно такой порядок их), блоггер заскриншотил, а затѣмъ вырѣзалъ номер карты и выложил во блог. Через четыре года, когда этот обрѣзокъ ужé попал в каждый архив и кэш блогосферы (напоминаю, что технические основы акропалипсиса завершены были к 2019 году!), из него стало возможно извлечь секретный код для снятия денег.

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

③ Политическая тайна. Вообразите журналиста из «Викиликс» или другого публикатора конфиденциальной информации, в руки которого попал цѣнный скриншот секретного документа. Он предаёт огласке обрѣзокъ скриншота, но силою акропáлипсиса можно будет извлечь оттудова неотрѣзавшіяся подписи или стеганограммы, раскрыв имя конфиденциального информатора или его источник.

④ Тайна мѣстоположенія. Вообразите фотографа, который дѣлаетъ цифровой фотоснимок живописно выглядящих облаков в небесах над городом. Конечно, фотоснимок — это ужé не скриншот, но вообще-то приложение Google Markup можно использовать для обрѣзки не одних только скриншотов (и на сайте XDA Developers, и на сайте 4PDA говорится: «Its primary use is to edit screenshots, but it can be used on any image»). И если именно им отсечь небо от того, что под небом, то тогда акропалипсис обеспечит зрителям фото возможность восстановить мнимо отсечённое фотографическое изображение крыш и домов, а затѣмъ по ним опредѣлить мѣсто да и прийти к такому фотографу прямо домой, если фото сдѣлано им из собственного окошка (как происходит в первой главе манги «Asuperu Kanojo»), или на важную для него крышу дóма, если фото сдѣлано на крыше (как происходит в середине четвёртой серии второго сезона телесериала «Person of Interest»). Если наш воображаемый фотограф — военный корреспондент или боец, то тогда отсечённая часть фотографии может содержать военную тайну.

⑤ Интимная тайна. Вообразите дѣвушку, пожелавшую похвастаться перед подружками цифровым фото обнажённого торса своего приятеля, но ввиду акропáлипсиса случайно отправившую им заодно и дикпик. (Да-да, тѣлесный низъ также располагается в нижней части большинства фотоснимков.) В зависимости от юрисдикции и от возраста дѣйствующихъ лиц это не просто «посмѣются и позабудут»: кое-кому выпадет шанс на много-много десятилѣтій угодить в общегосударственный список секс-преступников, содержащий адреса проживания и даже номера автомашин — в тёплую компанию насильников и растлителей, с запретом на общение даже с родными дѣтьми и внуками, с запрещением селиться в большинстве хороших районов, с обязательным оповѣщеніемъ десятков сосѣдей и со снисходительным отношением к проявлениям их праведного гнѣва в плохих районах, etc.

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

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

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

Во-вторых, по аналогии, могут напрячься обладатели других смартфоновых приложений-обрѣзчиковъ, побѣжать на acropalypse.app в холодном поту (и, может быть, подтвердить там самыя мрачныя из своих подозрѣній).

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

Такие сайты и сервисы, которые не использовали файлы своих пользователей въ неизмѣнномъ виде, а непремѣнно переужимали каждое изображение из JPEG в JPEG с потерей качества (а к числу таких сервисов относится и Telegram — и хорошо бы Telegram перестал так дѣлать), теперь будут мысленно оправдывать такой ущерб качеству: зато, дескать, этим мы спасли всѣхъ пользователей от акропáлипсиса!

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

Я тут пишу «я предвижу», но это просто фигура рѣчи. Тут не надо быть слишком прозорливым, достаточно заглянуть в Twitter да почитать, как Jon Sneyers осуждает Discord за предпринятое Дискордом (в начале апрѣля, насколько я понял) массовое переужатие в JPEG всѣхъ изображений, загруженных пользователями в прошлом. Это просто ужас, каким рукожопым получилось переужатие:

① Само выражение «переужатие в JPEG» как бы подразумевает, что новый файл получается хотя бы поменьше старого, однако Jon Sneyers сообщает, что Discord не во всѣхъ случаях достиг этого. (Увы, этим страдает и Telegram! — я вот ужé больше двух лѣтъ назад сообщал, что отправляемый файл от переужатия в JPEG может тут распухнуть!)

② Переужатие совершилося агрессивно и привело к значительным потерям качества: Jon Sneyers прикидывает, что работал кодировщик libjpeg-turbo, ориентированный на 75 баллов качества из ста. (Так как по максимуму их сто, то можно условно сказать «на 75% качества». Но это будет не болѣе чѣмъ метафорою. Важно не забывать, что в строгом смысле «стопроцентным», то есть идеально соѿвѣтствующимъ первоисточнику, качество не будет никогда: кодировщик JPEG занимается переужатием и похѣриваетъ часть качества исходного изображения, даже когда работает «на всѣ сто». Между прочим, качество JPEG и в Телеграме не лучше, чѣмъ достигнутое в Дискорде, но об этом напишу как-нибудь в другой раз.)

③ При переужатии всѣмъ изображениям была навязана цвѣтовая субдискретизация 4:2:0, дополнительно похѣрившая качество тѣхъ изображений, которые изначально были отправлены без субдискретизации.

④ Из старых файлов в новые не были скопированы (а вмѣсто того оказались стёртыми) цвѣтовые профили ICC, так что новые файлы будут восприниматься как расположенные въ цвѣтовомъ пространстве sRGB. И если исходный файл был создан въ болѣе широком цвѣтовомъ пространстве Display P3 (как вон та дѣвочка в затопленном городе) или в Adobe RGB 1998 года (как вон та дѣвочка перед грозою), то цвѣтовой охват сузился с искажением цвѣта ≈каждого пиксела (окромя нецвѣтныхъ: бѣлыхъ, сѣрыхъ, чёрных).

А надо было всего только оптимизировать JPEG без переужатия (автор jpegoptim выпустил 25 марта новую версию и даже приложил к ней готовые сборки для Windows, для macOS и для Linux) или откусить часть файла, слѣдующую за концом структур данных JPEG (как это дѣлаютъ во избавление от RARJPEG).

Оба анонса про развитие цвѣтовыхъ возможностей браузера Mozilla Firefox, мною 4 февраля пересказанные, оказались в строгом смысле преждевременными.

Обѣщанныя новинки: и поддержка указания в CSS таких цвѣтовъ, которые находятся за предѣлами цвѣтового охвата sRGB, и поддержка анимированных AVIF — дѣйствительно появилися в марте в Firefox 111, однако не для широкого круга пользователей, а для узкого круга экспериментаторов. Та и другая поддержка спрятана была за своею скрытою настройкою, то есть посмотрѣть на её работу можно было только тому, кто зайдёт на страницу «about:config» и найдёт (и включит, так как исходно она отключена) нужную настройку, заранѣе откуда-нибудь зная имя ея.

Имя настройки layout.css.more_color_4.enabled, необходимой для поддержки новых способов задания цвѣта, сообщили веборазработчикам на странице «Firefox 111 for developers».

А имя настройки, необходимой для поддержки анимированных AVIF, не сообщили даже там. Пользователям, на страницу «about:config» зашедшим, осталася одна только возможность самостоятельно забить в поиск слово «AVIF» и затѣмъ догадаться по смыслу, что настройка image.avif.sequence.enabled позволит невозбранно достигнуть желаемого.

Включение той и другой настройки наконец совершилося по умолчанию (и тѣмъ обеспечило поддержку той и другой возможности во браузере для широкого круга его пользователей) двумя мѣсяцами позднѣе — не в Firefox 111, а в Firefox 113 — не в марте, а в мае нынѣшняго года.

Упоминание поддержки анимированных AVIF (правда, сформулированное нѣсколько тяжёлым языком) и упоминание новых цвѣтовыхъ возможностей CSS даже появилось в сообщении 9 мая о выходе новой версии (Firefox 113) на сайте Фонда Мозиллы.

Однако, вопреки обыкновению, выход этой новой версии состоялся настолько поспѣшно, что ужé всего-навсего через три дня (12 мая) Фонд Мозиллы принуждён был выпустить слѣдующую (поправочную) версию — Firefox 113.0.1 — и новость о её выходе содержала упоминание сразу трёх обнаруженных и исправленных ошибок (то есть, если раздѣлить одно на другое, то в среднем получится ровно по одному исправлению в сутки), среди которых была ошибка цвѣтопередачи, проявившая себя именно на тѣхъ экранахъ (съ цвѣтовымъ охватомъ болѣе широким, чѣмъ у sRGB), на которые рассчитана была поддержка новѣйшихъ цвѣтовыхъ возможностей языка CSS.

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

Но могло быть и хуже.

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

А так со вчерашнего дня Firefox встал в ряды тѣхъ браузеров, которые поддерживают современныя цвѣтовыя возможности в CSS и в AVIF.

Теперь единственным сколько-нибудь популярным браузером, всё ещё не поддерживающим во Всемирной Паутине просмотр никаких AVIF: ни анимаций, ни неподвижных картинок — остаётся Microsoft Edge. Но надолго ли он останется таковым? — есть вѣскіе признаки того, что не надолго. В отладочной версии этого браузера (в Edge Canary) поддержка AVIF замѣчена была в середине прошлаго мѣсяца (15 апрѣля), причём в скрытой форме (требуется запуск браузера командною строкою, параметр --enable-features=msEdgeAVIF содержащею). Отладка и эксперименты потребуют нѣсколькихъ мѣсяцевъ, но со временем и Edge начнёт поддерживать формат AVIF по умолчанию и притом в официальной версии браузера.

Хорошо бы грядущая поддержка анимированных AVIF в Edge не отстала надолго от поддержки неанимированных, а не то синтаксис тега <picture> в языке HTML5 приуготовит и для Edge такие грабли, по которым прогулялися Firefox и Safari — и о которых я рассказывал ровно ⅔ года назад (13 сентября 2022 г.).

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

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

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

① Если иллюстрация используется не только в готовом виде, то есть если на сайте гдѣ-нибудь предусматривается такая миниатюра (thumbnail), которую надобно жмякнуть мышóю для открытия полноразмѣрнаго изображения, то тогда сайту нужен миниатюризатор. Но движок миниатюризатора воспринимает ограниченное количество форматов графических файлов (потому что их поддержку реализует не сам, а полагается на возможности операционной системы, или языка программирования, или какого-нибудь графического пакета), поэтому наиболѣе новые форматы будут запрещены. (Напримѣръ, пакет imagemagick в системе Debian в настоящее время доставляет шестую версию ImageMagick и оттого не понимает формат AVIF. Ещё примѣръ: функция getimagesize в языке PHP получила поддержку AVIF только тогда, когда версия 8.2.0 этого языка была выпущена в декабре 2022 года. Но это современные примѣры — а если миниатюризатор сочиняли в прошлом десятилѣтіи, то тогда и поддержку формата WebP могли не обеспечить, а не только формата AVIF.)

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

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

④ Сайт сталкивается съ тѣмъ, что обратною стороною сокращения расходов на объём (траффик, хранение) изображений становятся расходы на переужатие изображений. Поневоле сайт должен сократить затраты процессорного времени (которые не бесплатны), поэтому он приходит к использованию таких кодировщиков изображений, которые силе сжатия предпочитают скорость работы (напримѣръ, libjpeg-turbo может работать в 34—59 раз быстрѣе, но при этом сжимать JPEG в среднем на 20% хуже, чѣмъ MozJPEG). Но если файлы получаются больше при равном качестве, то тогда их качество сильнѣе страдает при том (большем) сжатии, которое требуется для того, чтобы уложиться в прежнее (малое) ограничение объёма.

Такое падение качества ужé печально, но «дальше — больше».

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

➊ Так как на нѣкоторые наиболѣе новые графические форматы (AVIF и нерѣдко WebP) накладывается либо жёсткий запрет, либо автоматическое преобразование въ болѣе ранній формат (чаще всего — в JPEG), то инерция сознания подталкивает хозяев сайта к тому, чтобы сократить употребление и ещё одного формата (а именно PNG) в пользу JPEG. Так как сохранение в формате PNG происходит без внесения потерь (а в формате JPEG — с внесением потерь), то отказ от PNG в пользу JPEG воспринимается как способ дальнѣйшей экономии объёма файла. Однако же ещё 15 лѣтъ назад (в 2008 году) Louis Brandy в своей работе «My First and Last Webcomic» совершенно вѣрно перечислил такие сорта картинок: скриншоты с текстом, графики, логотипы, чертежи, иллюстрации с надписями — со сжатием которых JPEG справляется довольно скверно или вносит в них искажения, хорошо замѣтныя на нефотографических фонах (и «расходящиеся волны» вокруг линий, и «вьющуюся мошкару» вокруг мелких деталей, и «размытие по квадратику» у острых углов и у диагоналей). Поэтому отказ от PNG в пользу JPEG в лучшем случае приводит къ дальнѣйшему падению качества изображений, в худшем случае порождает ещё и JPEG большего объёма, чѣмъ исходный PNG — но если сайт проектируется с расчётом на полный и безусловный отказ от PNG, то тогда даже такие распухшие файлы (худшие и по качеству, и по объёму) приходится использовать вмѣсто исходных.

➋ Стремление ещё усилить экономию может понуждать сайт къ замѣнѣ нѣкоторыхъ чётких ограничений объёма нечёткими, имѣющими чисто техническое происхождение — и тогда, напримѣръ, вмѣсто формулировки «файл переужимается из PNG в JPEG, если превосходит такой-то удѣльный объём» (или не удѣльный) появляется формулировка «…если занимает в JPEG меньше мѣста опосля переужатия нашим кодировщиком». Очевидная польза — дальнѣйшая экономия мѣста и траффика. Очевидный недостаток — неспособность юзеров заранее угадать, окажется ли тот или иной файл переужатым, особенно если сайт пользуется своим собственным кодировщиком (а не каким-нибудь общеизвѣстнымъ) и никому его не предоставляет.

➌ Дно бездны стремления к экономии — это полный отказ от строгой формулировки ограничений объёма файла в пользу обязательного переужатия каждого файла в формат JPEG на стороне сайта (тѣмъ кодировщиком и съ тѣми настройками, которые неизвѣстны юзерам — и которые, даже однажды угаданные хотя бы примѣрно, могут впредь перемѣняться без какого-либо увѣдомленія). В сущности, «слишком хорошо — тоже нехорошо», и на этом днище экономия въ извѣстной мѣрѣ обращается в свою противоположность, порождая безысходность всеобщих потерь:

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

⓶ Сайт теряет деньги на хранении и передаче файлов, если использует итог перекодировки в любом случае (то есть даже когда получающийся JPEG превосходит исходный файл по объёму). Вы полагаете, может быть, что таких идиотских сайтов не бывает? — увы, 4channel поступает именно так!

⓷ Цифровые иллюстрации парадоксально теряют качество, над ними горько посмѣивается Рэндалл Манро.

⓸ Ещё менѣе распространённым и болѣе трудоёмким становится стремление юзеров к самостоятельному сжатию изображений. Рѣчь идёт ужé не просто о том, чтоб найти кодировщик JPEG, превосходящий собою кодировщик на сайте: приходится подыскивать каждому JPEG тот порог качества его, выше которого сайт решит использовать свой итог перекодировки.

На какой стадии того пути, который очерчен двумя предшествующими сообщениями, располагается Twitter?

Наступил ли Twitter на грабли отказа от поддержки новых форматов и необходимости быстрого сжатия в ущерб качеству? — да, наступил: публикуемые файлы WebP автоматически перекодируются в JPEG (85 баллов качества из ста), и притом Нолан О'Брайен сообщил в январе 2019 года, что тогдашний твиттеровский кодировщик JPEG и в другом случае (при кодировании не WebP, а PNG в JPEG) напоминал собою libjpeg-turbo, работающий с этим же числом баллов качества (85 из 100) в режиме цвѣтовой субдискретизации 4:2:0 и постепенного «наведения на рѣзкость» (progressive encoding).

Наступил ли Twitter на грабли ограничения PNG и нечёткости правил? — увы, и в этом также замѣченъ.

Ещё в 2016 году мы видим в Твиттере обязательное перекодирование из PNG в JPEG для всѣхъ изображений, окромя прозрачных (потому что прозрачность в JPEG не поддерживается), и видим сообщество микроблоггеров наносящим ѿвѣтный удар: въ апрѣлѣ 2016 года создаётся translucent — средство для придания одному пикселу (в верхнем лѣвомъ углу изображения) небольшой прозрачности (0,4%), чтобы этим способом обдурить тогдашний движок Твиттера и отключить JPEGование обработанного этим способом изображения, сохранённого в формате PNG.

Я не слѣдилъ за происходящим, но вроде бы нѣкоторое время Twitter ужесточал требования, а поклонники PNG наращивали искусственную прозрачность. Это закончилось в феврале и марте 2019 года переходом на новый набор правил (дѣйствующій до сих пор), ориентирующийся на малый размѣръ или малый удѣльный объём файла PNG и совершенно игнорирующий количество прозрачных пикселов и степень их прозрачности. Обширные категории файлов PNG: малоразмѣрные PNG (900×900 пикселов и меньше), PNG с фиксированною палитрою, сѣрые PNG с небольшим числом оттѣнковъ сѣраго (однобитные, двухбитные, четырёхбитные) — объявлены были не подлежащими JPEGованию. (Узнав об этом в том же году, я порадовался.) Но для всѣхъ прочих файлов PNG обязательно происходило кодирование в JPEG, итог которого затѣмъ сравнивался с исходным PNG по объёму и публиковался вмѣсто него, если оказывался меньшим. Вы сознаёте, я надѣюсь, что это правило — нечёткое, опирающееся единственно на способности твиттеровского кодировщика JPEG, не доступного для скачивания пользователями, так что за предѣлами неJPEGуемых сортов PNG лишь экспериментально можно провѣрить, будет ли конкретный PNG оставлен «как есть» при публикации в Твиттере.

В 2020 год Twitter вступил с не менѣе ясными правилами и для JPEG, также заботящимися об исключении (въ нѣкоторыхъ разумных рамках) преобразования JPEG-в-JPEG с потерею качества. Теперь JPEG стали публиковаться «как есть», если одновременно выполняли четыре условия: не превосходили 4096 пикселов по большей стороне, не превосходили 5 мегабайтов, не тратили больше 8 битов на пиксел в среднем и не содержали в заголовке инструкцию о необходимости довернуть изображение (на 90° в ту или иную сторону или на 180°). Нетрудно видѣть, что эти правила чётко излагают желаемые ограничения и объёма, и размѣра, и частного ѿ дѣленія одного на другое. Сами по себе эти правила хороши, как и правила PNG — но контраст чёткости правил JPEG и нечёткости правил PNG создаёт обстоятельства взаимного проигрыша.

Микроблоггер, который желал опубликовать свой PNG, но нарвался на автоматическое перекодирование в JPEG, с 2020 года получил возможность стерѣть полученный JPEG (и всю свою микроблогозапись), а затѣмъ опубликовать заново, создав JPEG из PNG самостоятельно. Никто не мѣшаетъ ему выключить субдискретизацию и вообще придать этому JPEG максимум качества въ предѣлахъ 5 мегабайтов и 8 битов на пиксел. Но микроблоггер теряет время на попытку выложить PNG, а PNG теряет качество при любом преобразовании в JPEG (даже совершаемом на 100 баллах качества из 100 возможных и притом посредством кодировщика, ориентированного на качество — а не на скорость работы, как кодировщик самогó Твиттера), а Twitter принуждается хранить файл JPEG большего объёма, чѣмъ был PNG. Это и есть обѣщанная выше ситуация взаимного проигрыша.

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

Наступил ли 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, задуманная для экономии, ≈удвадцатеряет эти взаимные потери.

猫、 #Геленджик, Геленджикский проспект, 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 сдѣлать сёрверное переужатие не столь обязательным? Предпочтёт ли наказывать таких пользователей?

Ну что, довольно мрачно прозвучали послѣднія абзацы моего предшествующего сообщения?

Во всяком случае, я не желал бы того, чтобы это выглядѣло как какая-нибудь угроза или ультиматум. Не я, а 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. Примѣръ этого — въ слѣдующемъ сообщении.

Минимальный объём файла 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 может оказаться и другою.