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

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

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

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

И дѣйствительно: по данным веб-альманаха за 2022 год, составленного HTTP Archive, только четверть иллюстраций, в Интернете обнаруживаемых, использует меньше бита на пиксел в среднем, а медианным для JPEGов оказывается удѣльный объём, равный 2⅒ бита на пиксел в среднем.

С другой стороны, по-прежнему пятимегабайтовым остаётся предѣлъ объёма иллюстраций, скачиваемых Твиттером для отображения в карточках. И предѣлъ объёма JPEGов, принимаемых Твиттером без переужатия для микроблогозаписей. И предѣлъ объёма файлов PNG, принимаемых Телеграмом на сайте Telegraph.

А на таких имиджбордах, как 4channel или Ычан, файлы больше 4 мегабайтов не принимаются большинством досок.

А также: до какого количества bpp (битов на пиксел в среднем) пришлось сжать скриншоты для того, чтобы Telegram не похѣрилъ их качество переужатием?

1,1 bpp в этом сообщении.

0,84 bpp в предшествующем сообщении.

0,58 bpp для скриншота лимитов твиттеровского API v2.

Каждое из этих ограничений сохраняется не первый год (и не второй) несмотря ни на какой рост дисков или скорости Сѣти.

И так как артефакты формата JPEG явно замѣтны (и досадны) при упомянутых ограничениях, то поддержка формата AVIF (для сообщений в Телеграме) или JPEG XL (для менѣе сильных ограничений, названных чуть выше) была бы благотворна для достигаемого качества изображений.