Краткое содержание предшествующих сообщений: человѣчество тридцать лѣтъ живёт как с возможностью иллюстрировать web-страницы картинками, так и с широким распространением видеозаписей в цифровой форме, однако оформлять цитаты из видео в качестве зацикленных бесшовных анимаций люди научились сравнительно поздно, а средства автоматизации поиска подходящих кадров можно пересчитать по пальцам одной руки, и бóльшая часть их предназначена для macOS. Для единственного немакосёвого средства (animeloop), с 2018 года мнѣ извѣстнаго, настали непростые времена: автор утратил интерес к проекту (если вообще пережил накатывающиеся вóлны ковида), сайт закрыт, домéнное имя animeloop.org выставлено на продажу.

Но от него осталось нѣкоторое наслѣдіе.

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

Во-вторых, остался исходный код на Гитхабе. Если почитать приложенные инструкции, то становится ясно, что поставить его на Windows (особенно на семёрку) можно только со скрежетом зубов и томлением духа, поэтому я вздохнул и отвернулся.

(А было это в январе.)

Но на прошлой недѣлѣ удалось получить добрый совѣтъ о том, как можно было продолжить поиск в этом направлении. Оказывается, я пропустил вот чего: в репозитории animeloop на Гитхабе есть подраздѣлъ благодарностей («Special Thanks»), содержащий изъявление благодарности единственному другому разработчику (@ccloli) за помощь, оказанную въ непростомъ дѣлѣ сборки animeloop под Windows — иными словами, въ рѣшеніи как раз той задачи, перед которой я остановился в позапрошлом мѣсяцѣ, не желая тратить время и нервы. У этого-то помощника на Гитхабе донынѣ сохраняются форки исходного кода, и в каждом из форков — по одному-единственному готовому релизу animeloop для Windows: первая сборка совершалася посредством Visual Studio 2015, вторая — посредством mingw-w64-x86_64-gcc 8.3.0-2.

Без малѣйшаго промедления я скачал первую из этих сборок и убедился в полной работоспособности ея.

Для запуска достаточно скопировать файл аниме в пустую папку и подать вот какую команду под Windows, указав в командной строке желаемую степень многопоточности работы (смотря по количеству свободных ядер процессора) и желаемую длительность (в секундах) искомых видеоцитат, подходящих для зацикливания:

\путь\к\animeloop-cli.exe --thread 6 --max-duration 12.5 --min-duration 0.4 --output . --input аниме.mkv

Завершив работу, animeloop оставляет созданными двѣ подпапки (для цитат и для кэша), причём в имени файла каждой видеоцитаты (сохраняемой в MP4) указывается начальный и конечный номер кадра, которыми можно воспользоваться, когда захочется экспортировать найденные видеокадры в формате PNG без внесения потерь:

ffmpeg -hide_banner -i аниме.mkv -vf "trim=start_frame=начальныйНомер:end_frame=конечныйНомер,setpts=PTS-STARTPTS" frames\%6d.png

Есть двѣ причины, по которым такое может захотѣться:

① В качестве AVC-кодировщика (при сохранении видеоцитат в файлы MP4) animeloop использует OpenH264. Это избавило автора animeloop от обязанности платить лицензионные отчисления правообладателям видеоформата AVC, однако не лучшим образом сказалося на качестве сохраняемых кадров. Пересохранив видеокадры в формате PNG без внесения потерь, можно затѣмъ изготовить бесшовно зацикленную анимацию в другом видеоформате, не требующем лицензионных отчислений правообладателям (напримѣръ, в VP9 или в AV1), или ограничиться анимированным графическим форматом файла (создать анимированный GIF, анимированный PNG, анимированный WebP, анимированный AVIF, анимированный JPEG XL, etc.).

② Когда зацикливанию подвергается не особенно динамичная сцена аниме, тогда каждые два-три кадра подряд бывают одинаковыми, а найденные animeloop границы сцены могут потребовать коррекции в бóльшую или меньшую сторону, чтобы достигалася не только визуальная, но и временнáя бесшовность (не только наличие одинаковых кадров в начале и в конце сцены, но и нужное количество их).

Рассказ про способ запуска animeloop я сопроводил двумя сообщениями-предисловиями и двумя примѣрами результатов (бесшовных циклических анимаций).

Первый примѣръ, выложенный на три дня раньше, был взят из полнометражки «Манускрипт ниндзя» (1993 г.).

Второй примѣръ, выложенный сразу опосля основного рассказа, был взят из полнометражки «Курэнай дэнсэцъ» (2019 г.).

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

(Здѣсь в качестве примѣра прилагаю зацикленную цитату из «Криминального чтива».)

Однако в игровом кино такие цитаты не настолько совершенны, как в аниме:

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

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

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

Ѿдѣльною причиною для досады становится ограниченность тѣхъ форм, которые итог зацикливания способен принять: жалею, что Telegram не понимает ни анимированные PNG, ни анимированные WebP или AVIF.

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

Правда, довольно сложно в точности узнать, какими были ограничения кадра первого из популярных стандартов видеозаписи, а именно видеокассет VHS (стандарт 1976 года): число строк кадра этой системы опредѣлялося используемым телевизором (480 строк для американских телевизоров NTSC, 576 строк для европейских телевизоров PAL) и имѣло конкретный физический смысл (это буквально строки, проходимые электронным лучом в трубке тогдашних телевизоров), но вот понятие «число пикселов в строке» не имѣло конкретного значения для тогдашних аналоговых сигналов, поэтому его значение спорно. Какъ извѣстно, Википедию время от времени редактируют; и доредактировалися до того, что сегодня про строки VHS в ней приведены сразу двѣ оцѣнки. Первая из них сообщает, что горизонтальная чёткость равнялася 240 твл (а значит, 240×4×⅓=320 пикселов в каждой строке на тогдашних экранах 4:3). Вторая оцѣнка, ссылаясь на пособие «DVD Demystified», сообщает, что записываемый на магнитную ленту видеосигнал содержал по 333 пикселов в строчках кадров NTSC или по 335 пикселов в строчках кадров PAL. (По-видимому, автор этой оцѣнки счёл горизонтальную чёткость равною ≈250 твл.) Если же вмѣсто Википедии читать сайт Digital FAQ, то тамошняя оцѣнка числа пикселов на каждой строке VHS окажется оцѣночною («250—300») и меньшею каждой из предшествующих.

Для каждой из этих оцѣнокъ мы обнаруживаем кадр VHS сплюснутым по горизонтали ≈двукратно или ещё болѣе (для 480 строк несплюснутым был бы кадр 640×480 пикселов, как в VGA). Википедия прибавляет к этому упоминание того, что цвѣтностная горизонтальная чёткость была всего-навсего сорокапиксельною. Если считать линию содержащею 320 пикселов, то можно представить, что каждые 8 пикселов оказывались одного цвѣта (что напоминает конфликт атрибутов в графических режимах тогдашних домашних компьютеров); реальная ситуация была, разумѣется, сложнѣе, поскольку цвѣта размазывалися несовершенствами аналогового тракта.

Слѣдующимъ весьма популярным стандартом видеозаписей слѣдуетъ считать видео DVD (стандарт 1996 года). О нём в Википедии пишут (но ужé в точности, поскольку видеосигнал цифровой), что DVD допускает (для экономии) ≈половинное горизонтальное разрѣшеніе: 352×480 пикселов для NTSC, 352×576 пикселов для PAL или для SÉCAM. (На вышеупомянутой странице Digital FAQ именно такое число пикселов рекомендуют использовать при оцифровке VHS.) Причём в Википедии эта возможность надписана словами «China Video Disc resolution, 4:3».

Если оттудова перейти по гиперссылке, разъясняющей понятие «China Video Disc», то тогда становится видно, что при создании стандарта Super Video CD (он же SVCD) в 1998 году в него были включены китайские наработки формата Chinese Video Disc (он же CVD), оперативно созданного к 1997 году съ намѣреніемъ откликнуться на появление DVD в предшествующем (1996) году и обеспечить возможность записи на CD видеофайлов в экономном DVD-совмѣстимомъ разрѣшеніи (352 пиксела в строке) в DVD-совмѣстимомъ видеоформате (H.262) с почти совмѣстимымъ звуком (MP2, но с частотою дискретизации 44,1 кГц вмѣсто DVDшных 48 кГц). За счёт этого, с одной стороны, вертикальное разрѣшеніе удвоили по сравнению с прежними CD (в Википедии пишут, что на прежних Video CD было 352×240 пикселов для NTSC, 352×288 пикселов для PAL или для SÉCAM) и перешли к формату H.262 (вмѣсто MPEG-1 на обычных Video CD). С другой стороны, путём дичайшего видеосжатия продолжили запихивать видео на CD, оттянули неизбѣжность перехода на DVD.

В Архиве Интернета сохранилось упоминание и о том, что ещё в 2009 году сплюснутыми по горизонтали (до 544×576 пикселов) были кадры нѣсколькихъ каналов британского цифрового телевѣщанія.

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

14 апрѣля Twitter обрадовал покупателей своей платной услуги (Twitter Blue) новою возможностью публикации таких микроблогозаписей, которыя вообще-то отнюдь уж не «микро», потому что способны будут вмѣщать до десяти тыщщ сѵмволовъ. Частью этой услуги притом сдѣлается возможность выдѣлять текст курсивом или повышенною жирностию в Твиттере.

Постоянные читатели моего канала могут помнить, что наращивание длины твиттеровских сообщений в прошлом было для меня источником нѣкотораго беспокойства: когда оно было ещё только кратким сообщением о том, что Маск доведёт эту длину до 4000 сѵмволовъ, тогда въ послѣднемъ абзаце моего сообщения 13 декабря прошлого (2022) года я размышлял, не распухнут ли вязáнки твиттеровских сообщений, которые я выкладываю в IPFS и затѣмъ гиперссылкою на канал. Позже (в начале моего сообщения 20 февраля) я убедился наглядно, что ничего для меня не измѣнилось с приходом 4000-сѵмвольности, поскольку Twitter начал отдавать усечённые тексты сообщений через тот API (программный интерфейс), которым я их забираю оттудова.

Опираясь на это знание, позавчера я ужé не очень беспокоился о том, сможет ли Twitter нормально обрѣзать десятитысячесѵмвольное сообщение (если смог обрѣзать 4000 сѵмволов, то тогда и с десятком тыщщ должен управиться невозбранно), однако оставалась нѣкоторая неясность насчёт жирного или курсивного текста: какую форму обретёт размѣтка такого текста (будет ли это нѣкоторое подобие языка HTML, или Markdown, или BBCode?), сможет ли мой обработчик переварить её?

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

Результат оказался крайне обескураживающим: Twitter не допустил моё средство читать сообщения, кратко сообщив о невозможности авторизации и приложив номер ошибки (32).

Поискав (в самóм же Твиттере) по словосочетанию «error 32», я увидал только одно подходящее сообщение. Его автор обращался 6 апрѣля к своим читателям с вопросом о том, не знает ли кто-нибудь способ исправить твиттеровскую ошибку 32, но ужé въ слѣдующемъ сообщении собрался просто ждать с мыслью о том, что и у других ботов аналогичная проблема.

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

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

К счастью, всё обошлось: ошибка 32 пропала сама собою, мой обработчик вдругорядь заработал, а Twitter оказался отдающим через API не просто усечённые сообщения, но и избавленные от размѣтки (так что обычным выглядит в них и курсив, и жирный текст). Слѣдовательно, я могу опять (как было и в феврале) ничего не мѣнять в исходном коде обработчика.

Для кого-то этот рассказ — просто «единичный случай» и даже, может быть, «ошибка выжившего»; но кому-нибудь другому удастся извлечь из моей истории тот же совѣтъ, которым Александр Дюма-отец завершил роман про Монте-Кристо:

— Ждать и надѣяться!

☦️ ХРИСТОСЪ ВОСКРЕСЕ! ☦️

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).