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

В видеопроигрывателе Media Player Classic Home Cinema во всё это время существовала совокупность четырёх «горячих» клавиш, позволяющих и без того достигнуть желаемого:

во-первых, сочетание клавиш Ctrl+G вызывает навигационное окно «Go To…» с приглашением перепрыгнуть в видеофайле на другое время, причём для удобства в этом окне ужé указано достигнутое время от начала файла, чтобы его было нетрудно переправить (на тот случай, если желаемое время близко к достигнутому),

во-вторых, сочетание клавиш Ctrl+A позволяет (как и во многих других программах) выделить весь текст (в данном случае — всю отмѣтку времени),

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

в-четвёртых, клавиша Escape закрывает окно «Go To…» и возвращает пользователя в основное окно видеопроигрывателя,

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

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

Но эту-то проблему я легко решил, навѣсивъ на желаемое сочетание клавиш вызов утилиты NirCmd в форме «nircmd noscript имяФайлаСкрипта» и помѣстивъ в указанный файл скрипта вот какую послѣдовательность команд NirCmd:

sendkey Ctrl up

cmdwait 100 sendkeypress Ctrl+G

cmdwait 100 sendkeypress Ctrl+A

cmdwait 100 sendkeypress Ctrl+Insert

cmdwait 100 sendkeypress Esc

cmdwait 100 sendkeypress Esc

Как нетрудно видеть, первая из этих команд имитирует отпускание клавиши Ctrl (нажатой в рамках комбинации Ctrl+PrtScr или другой подобной), а послѣдующими командами имитируются пять вышеописанных нажатий «горячих» клавиш, да не сплошняком, а со стомиллисекундною задержкою, чтобы видеопроигрыватель успѣвалъ отрабатывать свою реакцию.

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

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

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

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

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

Он содержит, в частности, ретвиты очередных микроблогозаписей о пользе ношения медицинских масок на лице, а также микроблогозаписей о появлении в мобильном браузере Opera поддержки P2P-распределённой файловой системы IPFS (а также криптовалютного кошелька с возможностью покупать биткоины и эфириум в десятках стран, а также альтернативной системы доменных имён, покупаемых за криптовалюту; список новинок Оперы впечатляет) и об ужасающих недостатках конструкции нового московского приложения для Android, предназначенного для слежки за гражданами.

#Геленджик, 21 марта (позапрошлая суббота). Я ѣду, став на #моноколесо.

Начало ѣзды: #ТолстыйМыс, набережная, южный конец #велодорожки.

Окончаніе ѣзды: центр города, Burger King.

Это та видеозапись моноколёсной ѣзды, которую я ранѣе выложил в Твиттере (ускоренною в 3,4 раза, чтобы она могла помѣститься в твиттеровское 140-секундное ограничение длины видео); сейчас считаю умѣстнымъ выложить её и в Telegram и тѣмъ напомнить, как изобиловала людьми #набережная до начала самоизоляции (то есть, напримѣръ, вон то утверждение «город и так практически пустой» — явная чепуха); кроме того, теперь эту мою видеозапись наконец можно видѣть неускоренною.

Но чтоб при утрамбовывании видеозаписи в телеграмное ограничение (1½ Gb) не слишком пожертвовать качеством, я выкладываю её, так сказать, «на вырост» — в таком формате (видеопоток AV1 со звуком Opus в контейнере MP4), который ещё только ≈год назад начал обретать популярность. Ваше устройство может его ещё не поддерживать даже в видеопроигрывателе, не то что в Telegram.

P. S. Появление поддержки AV1 не приводит автоматически к приданию формы видеопроигрывателей файлам AV1, ранѣе выложенным на каналах.

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

Надо сказать, что при этом было сомнѣніе: «закачивать ли его же?» — всё же к 2023 году из Телеграма ушла та необходимость ограничиваться полутора гигабайтами, которая побуждала создать этот видеофайл в 2020 году.

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

Хотя эта моя видеозапись сдѣлана с достаточно высокою частотою кадров (60 кадров в секунду), с её просмотром должен управиться почти любой настольный компьютер, выпущенный въ послѣдніе лѣтъ восемь или девять (то есть на чём-то подобном Sandy Bridge 2011 года или на чём-то ещё болѣе новом), если только видеопроигрыватель на нём (будь то mpv, или VLC, или Media Player Classic Home Cinema) обновлён до достаточно недавней версии, содержащей поддержку декодирования AV1.

А вот мобильные устройства традиционно выпускаются существенно болѣе хилыми, чѣмъ компы, но всё же в системе Android 10 в прошлом году объявлена была поддержка видеозаписей AV1; правда, поддержка со стороны операционной системы должна ещё сопровождаться нѣкоторою аппаратною поддержкою со стороны производителя оборудования (а не то смартфон может оказаться не достаточно производительным для 60 кадров в секунду), но пока что нам извѣстенъ только один чип, достовѣрно содержащий аппаратную поддержку AV1 (это MediaTek Dimensity 1000) и только одна модель смартфона, на нём построенная (это OnePlus 8 Lite). Если же углубляться в область недостовѣрнаго, то можно припомнить, что на сайте Macworld были домыслы о том, что компания Apple, будучи одной из официальных сторонниц формата AV1, может добавить (а может и не добавить) аппаратную поддержку этого формата в процессор A14 — и, слѣдовательно, в iPhone 12.

Зная всё это, трудно ждать от мобильного Телеграма какой-либо способности воспроизвести эту мою видеозапись прямо сейчас (а не в будущем, когда поддержка AV1 ещё возрастёт); этой способности и нѣтъ; однако же не на одних только мобильниках, но и на компах — в программе Telegram Desktop — никакой поддержки AV1 ещё нѣтъ (кроме как в сильно модифицированных её сборках, предназначенных для репозиториев нѣкоторых версий системы Linux), потому что в коде Telegram Desktop ещё не произошёл переход к употреблению современной (четвёртой) версии FFmpeg. К счастью, 28 марта (в субботу на прошлой недѣлѣ) разработчик Telegram Desktop упоминал, что в нынешней (второй) версии его программы такой переход ужé приуготавливается, так что будущее вполне лучезарно и в этом направлении.

А вот если бы моя видеозапись сдѣлана была с меньшею частотою кадров, свойственною кинематографу (то есть не 60, а около 24 кадров в секунду — это в 2½ раза меньше), то тогда она предъявляла бы пропорционально меньшие требования и к производительности мобильных устройств, необходимой для воспроизведения. Так, напримѣръ, компания Netflix ≈2 мѣсяца тому назад (5 февраля) объявила, что для клиентов на мобильных устройствах, желающих сэкономить дорогостоящий мобильный траффик при просмотре фильмов, теперь предусматривается особая настройка, запускающая приём видеопотока в формате AV1 — и что Netflix использует собственную оптимизированную сборку видеопроигрывателя, которая поддерживает воспроизведение AV1 на современных мобильных устройствах с достаточною скоростью (без какого-либо раздражающего подёргивания) даже при использовании повышенной (десятибитной) глубины цвѣта в видеозаписи (и даже при отсутствии специальной аппаратной поддержки AV1, так как работает это всё, понятное дѣло, не только на OnePlus 8 Lite), и что рано или поздно не только их собственные (нетфликсовские), но и чьи угодно видеопроигрыватели достигнут при помощи Netflix (и с использованием открытого исходного кода dav1d) того же результата. Эта новость радует хотя бы оттого, что именно Netflix генерирует раздачею своих видеозаписей своим зрителям больше всего траффика в Интернете (больше, чѣмъ всякая другая компания — напримѣръ, вдвое больше, чѣмъ популярный видеохостинг YouTube), если вѣрить диаграмме, показанной на второй минуте доклада, обнародованного докладчиком из Фонда Мозиллы в Крайстчёрче в двадцатых числах января 2019 года (то есть менѣе чѣмъ за два месяца до того дня, когда в том же городе Брентон Таррант убил болѣе полусотни приезжих, руководясь расовою и вероисповедною ненавистью), так что именно умаление траффика Netflix наиболѣе полезно во дни массовой самоизоляции и вызванного ею роста просмотров видеозаписей в Интернете.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

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

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

Он содержит, в частности, ретвит сборника свѣдѣній о том, откуда прилетали в Краснодарский край люди, заражённые коронавирусом.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

Руководясь наводкою, оставленною на форуме Doom9 при общении тамошних поклонников AOMedia, я нашёл в Интернете склад различных конвертеров (то есть средств для преобразования информации из одного формата файлов в другой), собранных для употребления под Windows.

Бóльшая часть их не показалась для меня полезною, так как либо ужé входит составною частью в FFmpeg (а сборка FFmpeg у меня и без того есть), либо содержит готовые сборки для Windows на сайте конвертера (к которому, естественно, довѣріе куда выше, чѣмъ к складу ѿ нѣкоего незнаемого и постороннего сборщика в Интернете), и примѣры таких сборок всѣ вы без труда можете отыскать, напримѣръ, на Гитхабе у rav1e или у SVT-AV1.

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

В действительности же это моё убеждение было не болѣе чѣмъ заблуждением, так как на сайте WebP есть подраздѣлъ «WebP Converter Download», откуда ссылка ведёт в другой раздѣлъ («Precompiled Utilities») и далѣе на склад со сборками, а мнѣ просто-напросто до сих пор недоставало побуждения пойти туда, а теперь я и сходил, и скачал подходящую для себя сборку, и даже, так сказать, пощупал, то есть начал на опыте разбираться съ тѣмъ, хорошо ли хранить графические файлы в формате WebP и какая же может быть от него для меня (и не только для одного меня, а и вообще) практическая польза.

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

Во-первых, есть lossy WebP — формат, предназначенный для сжатия изображений, совершаемого с потерями данных (для достигаемого этой цѣною лучшаго утрамбовывания их). Он основывается на формате ключевых кадров видеопотока VP8.

Во-вторых, есть lossless WebP — формат, предназначенный для сжатия изображений, совершаемого без внесения потерь; этот формат не имѣетъ ни малѣйшаго ѿношенія к VP8, а вмѣсто того был сочинён на основе различных передовых методов сжатия информации (каких именно методов? — а их в 2012 году перечислил тот инженер Jyrki Alakuijala, который-то и был проектировщиком формата lossless WebP).

В-третьих, есть ещё animated WebP — формат для хранения анимированных изображений без звука, основанный на двух предшествующих форматах, так как каждый кадр анимации может быть сохранён с потерями, а может и без потерь.

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

Однако же, если смотрѣть из нынешнего (2020) года на результаты, то может показаться (и небезосновательно), что этот психологический приём сработал «с точностью до наоборот», упростив отказ от внедрения WebP (дескать, велика ли потеря при отказе от поддержки всего-навсего одного формата) и притом отказ одним махом от внедрения всѣхъ трёх вариантов WebP (даже когда один чѣмъ-то полезнѣе остальных), так что доля поддержки WebP (отсутствующей в эппловских браузерах до сих пор, а в Файерфоксе — до версии 64 включительно) в настоящее время оцѣнивается как равная ≈80% во всей Всемирной Паутине и менѣе 70% в России (и ничего в этом нѣтъ удивительного с её-то стремлением к айфонам да к айпэдам, которое охватило даже и Дмитрия Анатольевича Медведева).

Поэтому полезно освободиться от воздействия этого гугловского психологического приёма.

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

Формат lossy WebP задумывался как замѣна для JPEG на случай необходимости сжать изображения цѣною внесения потерь. Существует исследование Google, показывающее превосходство качества сжатых изображений в формате lossy WebP над качеством сжатых изображений в формате JPEG равного им объёма, гдѣ качество измѣрялося по объективному показателю (SSIM), а затѣмъ ещё показывающее, что при равном качестве файл WebP получается иногда на четверть, а иногда и на треть меньше, чѣмъ файл JPEG. Существует также альтернативное исследование Фонда Мозиллы (сохранившееся в Архиве Интернета), которое показывает, что в зависимости от выбора оцѣнки: Y-SSIM, RGB-SSIM, IW-SSIM, PSNR-HVS-M — файлы WebP равного качества могут быть и больше, и меньше, и примѣрно равны файлам JPEG по объёму, так что итог этого исследования был назван в 2013 году и затѣмъ ещё в 2014 году не позволяющим прийти к убеждённости в превосходстве lossy WebP над JPEG, а вмѣсто того всѣмъ надо, дескать, стремиться к тому, чтобы получше сжимать файлы JPEG (и для такого сжатия этот фонд создал MozJPEG). Этим же исследованием было показано, что ключевые кадры видеоформата HEVC сжимают изображение (при равных показателях SSIM его качества) гораздо лучше, чѣмъ JPEG и чѣмъ lossy WebP.

Получается, что lossy WebP при примѣрно равной JPEG степени сжатия поддерживается менѣе широко, а выбранный подход (создание формата сжатия изображений на основе извѣстнаго формата ключевых кадров нѣкотораго видеопотока) получше работает на основе болѣе новыхъ, чѣмъ VP8, видеоформатов, так что на этом пути lossy WebP сперва оказывается обойдён форматом HEIF (на основе видеоформата HEVC), который (в отличие от WebP) поддерживается в продуктах Apple (начиная от iOS 11 и притом под названием HEIC вмѣсто HEIF), а в будущем — обойдён и форматом AVIF (на основе видеоформата AV1).

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

Напримѣръ, так как производительность видеопроигрывателей еле-еле начала подбираться к кадрам размѣромъ 4K и 8K, то предѣльный размѣръ кадра VP8, хотя бы и запроектированный «на вырост», всего ≈вдвое больше них, так что и размѣръ изображения в WebP не может превосходить 16383×16383 пиксела.

Напримѣръ, так как видеокадр рассматривается как недѣлимый, то формат WebP не предусматривает постепенной (чересстрочной) развёртки файла (файл показывается по мѣрѣ загрузки всегда только сверху вниз).

Напримѣръ, так как быстрая смѣна кадров позволяет въ полной мѣрѣ полагаться на то, что цвѣтовая чувствительность зрѣнія человѣка отстаёт от яркостной, то и для lossy WebP обязательна цвѣтовая субдискретизация 4:2:0 (всегда один пиксел цвѣтности на 2×2 пиксела яркости), хотя иллюстрацию могут (и будут) рассматривать дольше кадра, что сдѣлает болѣе явною нечёткость цвѣтовых контуров.

Кроме того, WebP наслѣдуетъ от VP8 восьмибитность цвѣтовыхъ каналов, за предѣлы TrueColor ему не выйти.

Ото всѣхъ этих недостатков lossy WebP будет свободным будущий формат JPEG XL, о достоинствах которого я упоминал ужé на моём канале в Telegram 26 декабря прошлого (2019) года въ нѣскольких сообщениях, начиная вон с того. А ещё JPEG XL будет меньше сглаживать картинку, чѣмъ это дѣлается форматом HEIC (основанном на видеокадрах HEVC, одержавших побѣду над lossy WebP в исследовании Фонда Мозиллы). А ещё JPEG XL будет поддерживать обратимое переужатие информации из файлов JPEG.

Всё это — причины уходить с JPEG именно на JPEG XL, а lossy WebP для этой роли не сгодился.

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

Большой удачею я считаю, что это мнение к тому же может оказаться и куда менѣе спорным: так как рѣчь пойдёт о формате, предназначенном для сжатия изображений, совершаемого без каких-либо потерь, то тут не потребуются никакие исследования, сравнивающие внѣшній видъ результатов съ тѣмъ видомъ, который обеспечивается конкурирующими форматами, тут ни к чему мýки выбора между различными вариантами подсчёта SSIM, дающими подчас противоположные оцѣнки результата (не свободные от вопросов о том, насколько та или иная метрика вида изображения соѿвѣтствуетъ или не соѿвѣтствуетъ человѣческому впечатленію), и тут нас не смутят указания на одномѣрность самогó показателя SSIM (который зачастую выдаёт сходные величины для таких искажений исходного изображения, которые человѣческое восприятие сочло бы качественно различающимися, примѣръ чего мнѣ приведён был на Nowere въ концѣ 2019 г.). Наоборот, наоборот! Рассматривая lossless WebP, мы можем навсегда сдѣлаться совершенно спокойными насчёт качества сохранения изображений в этом формате: качество-то всегда стопроцентное — и обращать наше внимание единственно на выигрыш в объёме файла, который выражается бесспорным количественным показателем (числом его байтов).

Дык что ж увидим? — оказывается, вышеупомянутый Jyrki Alakuijala превосходно сдѣлалъ свою работу, так что в качестве конкурента для PNG (то есть для единственного формата сжатия полноцвѣтныхъ изображений без потерь, сейчас поддерживаемого всѣми браузерами) формат lossless WebP годится очень хорошо: существует исследование Google, демонстрирующее способность формата lossless WebP обеспечивать сжатие содержимого большинства PNG-файлов (сжатие, оцѣниваемое ужé после переужатия этого содержимого лучшими из существующих средств для переужатия PNG, совершаемого без потерь) ещё на 20% или даже на 40% (а в среднем — где-то на четверть), а это значит, что в крупных файлах экономятся цѣлые мегабайты (то есть, для мобильных зрителей — полновѣсныя секунды их времени).

Я выделил слово «сейчас» жирностью, поскольку надеюсь, что (несмотря на всѣ коронавирусныя преграды) в нынешнем (2020) году мы всѣ дождёмся от Joint Photographic Experts Group нового формата JPEG XL, в котором также есть собственный режим для сжатия изображений, совершаемого без потерь, так что не один только PNG, но также и lossless JPEG XL составит для lossless WebP конкуренцию въ нѣкоторыхъ случаях. Въ нѣкоторыхъ, но не во всѣхъ: мнѣ удалось обнаружить такой частный случай, в котором lossless JPEG XL сжимает изображение менѣе сильно, чѣмъ даже PNG (а всё потому, что проектировщики JPEG XL решили нѣсколько пожертвовать экономиею объёма в пользу большего распараллеливания декодирования и в пользу большей простоты извлечения ѿдѣльныхъ фрагментов изображения, о чём и Jyrki Alakuijala повѣдываетъ) — а вот lossless WebP даже в этом же частном случае сжимает изображение болѣе чѣмъ на четверть сильнѣе, чѣмъ PNG.

Эта находка свидетельствует, и даже вполне неопровержимо, что и в том близком будущем, в котором JPEG XL объявится и начнёт поддерживаться интернетовскими браузерами, какие-то изображения будут лучше сжиматься без потерь посредством lossless JPEG XL, а какие-то другие — lossless WebP. (Справедливости ради надо сказать, что вышеупомянутое гугловское исследование упоминает об обнаружении и таких изображений, хотя и очень немногих, которые в PNG сжимаются без потерь лучше, нежели в lossless WebP; мнѣ-то самомý такие примѣры ещё не встречались, но я-то и интересоваться lossless WebP начал очень недавно, так что почему бы и не положиться на мнение Google по этому вопросу.)

Видя такие достоинства lossless WebP, хочется использовать его для сжатия всѣхъ такихъ полноцвѣтныхъ изображеній, которыя укладываются в границы его примѣнимости (16383×16383 пиксела и TrueColor), во всѣхъ тѣхъ случаях, когда этот формат и поддерживается, и реально обеспечивает превосходство над PNG (а в будущем — и над JPEG XL).

Выгода от употребления lossless WebP вмѣсто PNG иногда бывает больше, чѣмъ та (упомянутая предшествующим сообщением) разница объёмов, которая в исследовании Google найдена сравнением объёма lossless WebP с объёмом такого PNG, который до этого был сжат наилучшими средствами сжатия PNG без потерь. Ведь если файл PNG больше мегабайта, то его сáмой сжатой версии хочется предпочесть ту, которая сдѣлана чересстрочною по алгоритму Adam7: пусть объём файла возрастёт, но зрители со слабыми каналами связи (по которым мегабайт приходит дольше секунды) увидят полноразмѣрную (хотя размытую) версию изображения поскорѣе (для чего тогда достаточно ≈1½% файла). Примѣръ: скриншот страницы вон того фото (1440×2232 пиксела на экране QHD) занимает 1252595 байтов PNG (см. файл original.png в прилагаемом архиве), но его чересстрочная форма (файл interlaced.png) занимает ужé 1828148 байтов. А в lossless WebP изображение займёт 863158 байтов (файл lossless.webp) — это меньше мегабайта, позволяя мириться с отсутствием чересстрочности.

Формат animated WebP используется для хранения анимаций, каждый кадр которых хранится в одном из вышеописанных форматов, то есть либо в формате lossy WebP, либо в формате lossless WebP, причём форматы разных кадров могут быть разными.

Анимированный lossless WebP является конкурентом для прежних форматов сжатия анимированных изображений, совершаемого без потерь: конкурентом и для анимированных GIF, и для анимированных PNG — и анимированный lossless WebP одерживает побѣду над ними благодаря болѣе высокой степени сжатия.

Так, напримѣръ, около шести лѣтъ тому назад, когда анимированные изображения снова начали входить в моду (но на новом техническом уровне начала десятых лѣтъ: не как небольшие и простенькие GIFки девяностых годов, а как отрывки видео многосотпиксельной ширины и болѣе чѣмъ мегабайтового объёма), во блоге Cloudinary появилась рекомендация выкладывать такие анимации в формате animated WebP (в качестве альтернативы для браузеров, понимающих WebP), причём не только для сокращения объёма файлов (то есть во избежание чрезмѣрныхъ расходов траффика), но и для преодоления ограничений 256-цвѣтной палитры, почти неизбѣжныхъ для GIF. (Я пишу «почти», так как gifski позволяет создавать болѣе цвѣтные кадры GIFов наложением нѣсколькихъ менѣе цвѣтныхъ кадров, хотя это и приводит к дальнейшему росту объёма.) То и другое достоинство остаётся злободневным до сих пор, обуславливая пользу от перехода на анимированные lossless WebP с прежних гифок или с APNG.

Тут надо сразу же сказать, однако же, что Cloudinary предпочитает (для ещё большей экономии объёма файлов) рекомендовать использование анимированных lossy WebP. Но сейчас, через ≈шесть лѣтъ после этой рекомендации, я могу отнестись к этому мнению Cloudinary скептически и указать вот на какое обстоятельство: так как формат анимированных изображений lossy WebP основан на формате ключевых кадров видеопотока VP8, то этот формат (в качестве средства для хранения анимаций со сжатием, сопровождающимся внесением потерь) с неизбѣжностью уступает (по соотношению объёма и качества) даже видеозаписям VP8, потому что во всякой видеозаписи, кроме ключевых кадров, также используются промежуточные, сжатые ещё сильнѣе ключевых. Слѣдовательно, если на мѣстѣ анимированного lossy WebP поставить видеофайл WebM (с видеопотоком VP8 или, тѣмъ болѣе, VP9) или видеофайл MP4 (с видеопотоком HEVC или, тѣмъ болѣе, AV1), то можно при том же объёме получить большѣе качество, а также важную дополнительную возможность использования звуковой дорожки. Придётся побеспокоиться разве что о том, что изо всѣхъ этих четырёх видеопотоков в системе iOS (то есть на айфонах и на айпэдах) браузером Safari поддерживается только HEVC, зато HEVC не поддерживается в большинстве других браузеров (и на то есть причина — угрожающая неясностью ситуация в сфере патентных отчислений за использование HEVC). Но об этом-то приходится побеспокоиться и насчёт формата WebP, тоже не поддерживаемого в Safari.

Появление видеозаписей, однако, не вполнѣ покончило с причинами использовать анимированные lossy WebP. В гугловском FAQ достоинством анимированных WebP зовут продолжение их недостатка: анимация, не содержащая промежуточных кадров, тѣмъ самым требует меньше оперативной памяти и меньше усилий процессора, так что появление нѣсколькихъ таких анимаций на одной интернетовской странице не создаст больших проблем даже для такого маломощного пользовательского устройства, которое стало бы бѣшено греться и подлагивать, если б столкнулось съ нѣсколькими полноцѣнными видеозаписями на одной странице. Но так как возможности устройств растут, то значимость этого достоинства отходит в прошлое. Ещё можно замѣтить, что пока анимация остаётся иллюстрацией (а не видеозаписью), её проще подмѣнить (для браузеров, не поддерживающих WebP) на иллюстрацию другого формата (на APNG, на анимированный GIF, а для Safari — и на видео MP4 в теге img) — подмѣнить на стороне сервера (как это дѣлаетъ Cloudinary), или на странице тегом picture (если есть, скажем, готовый APNG-аналог WebP-файла), или подпереть джаваскриптовым костылём (наподобие WebPJS или libwebpjs).

Итак, lossy WebP — это конкурент JPEG, достигший лишь спорного успѣха, так что в нынешнем году его ждут пышные похороны после появления AVIF (и затѣмъ ещё после появления JPEG XL, если оно состоится), причём до этого осталось недолго: поддержка AVIF ужé ждёт своего часа в недрах Chromium с 8 апреля, так что вскоре должна объявиться и в Google Chrome, и в Microsoft Edge, и в Opera, и во всѣхъ других браузерах, на основе Chromium созданных.

Чуть лучше чувствует себя animated WebP: это превосходная замѣна для прежних анимированных GIFов и для APNG, но сам обычай употребления файлов, хранящих зацикленные и беззвучные анимации, постепенно уступает мѣсто как видеозаписям (въ томъ числѣ — видеозаписям со звуком), так и CSS-анимациям (плавным измѣненіямъ свойств элементов страниц).

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

Вышеупомянутая психологическая уловка Google (объединение этих трёх форматов под одним названием WebP), казалось бы, за счёт непререкаемой привлекательности lossless WebP могла бы побуждать к поддержке всего WebP (то есть и двух остальных вариантов WebP, не так хорошо выдержавших испытание временем), но действительность ужаснее этого.

Ужасно положение пользователей iOS, подтверждающее тезис «Safari is the new IE» (и даже в превосходной степени: Корпорация Microsoft хотя бы допускала на Windows конкурентов IE, тогда как Apple отстаивает единственность движка Safari в системе iOS) многолетним отсутствием поддержки WebP. Это отсутствие тѣмъ болѣе удивительно, что в 2016 году компания Apple тестировала возможность поддержки WebP в бета-версиях своего браузера (в том числе и на iOS 10), но затѣмъ отказалась от поддержки WebP, никак свой отказ не объяснив.

Ужасно положение пользователей Файерфокса, которые изначально привлечены были изобилием расширений, предшествующих появлению Firefox Quantum, и поэтому во множестве остаются вѣрными доQuantumной версии браузера, не способной показывать WebP.

Для браузеров, не поддерживающих WebP, можно прилагать копию изображения в альтернативном формате в теге picture (это, напримѣръ, рекомендует Joshua Comeau), но этот обходной путь, понятное дѣло, не годится для тѣхъ сайтов, которые стремятся к экономии не одного только траффика, но также и объёма хранимых файлов — так бывает, напримѣръ, на имиджбордах, гдѣ обычно хранится превеликое множество файлов, но жёстко ограничен объём каждого файла, так что именно на имиджбордах пользователи могли бы счесть удачею возможность уйти от PNG к lossless WebP. Болѣе естественным в этом случае представляется джаваскриптовый декодировщик WebP, дѣйствующій во браузере (что-то наподобие WebPJS или libwebpjs), причём такой декодировщик пользователи могли б даже ставить себѣ сами как юзерскрипт (мнѣ попадался и примѣръ именно такого юзерскрипта, подключающего WebPJS на нѣкоторомъ сайтѣ) — в этом послѣднемъ случае администрации на имиджборде достаточно прибавить WebP в список допустимых форматов, а больше делать вообще ничего не надо.

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

Руководимый этим же представлением, я также пошёл ещё и на 410чанъ, 6 апреля рекомендовал там запустить поддержку формата WebP, приводя аргументы в его пользу (подобные изложенным на Nowere аргументам), но ѿвѣтомъ мнѣ был отказ, изложенный в форме «когда Apple добавит поддержку, тогда приходите» (а это de facto означает «никогда»).

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

Имиджборды, названные в предшествующем сообщении, не были первыми проскочившими от анимированных GIF сразу к видео: законодателем мод для них, как и во многих других имиджбордовских обычаях, приходится признать 4chan, примѣрно 7 апреля 2014 года начавший поддерживать WebM, но никогда, насколько я понимаю, не помышлявший о поддержке WebP. (Я пишу «примѣрно», потому что сам 4chan сейчас указывает эту дату под блогозаписью словами «6 years ago», не упоминая конкретный день. Но так как «The Washington Post» в статье «Meet the technology that could make GIFs obsolete» упоминает о новинке как о появившейся в понедельник, а статья его датируется восьмым апреля 2014 года, то догадываться нетрудно.)

Через два мѣсяца с небольшим (18 июня 2014 года) поддержка анимаций появилась в Твиттере, причём изначально о ней было объявлено словами «можете загружать и просматривать анимированные GIF», но при пристальном вглядывании пользователям вскоре сдѣлалось ясным (как, напримѣръ, было сказано вон в той статье на сайте Mashable через два дня), что всѣ загруженные GIFы на самомъ дѣлѣ преобразовывались в видеозаписи MP4. А вот поддерживать WebP, по-видимому, Twitter не очень склонен: тѣ самыя правила на его сайте, которые объявляют о возможности опубликовать PNG «как есть» (без серверного переужатия) при определённых обстоятельствах (например, для малобитных или малопиксельных изображений, или для растущих в объёме при преобразовании в JPEG) и о возможности опубликовать JPEG «как есть» при сочетании определённых признаков (малый размѣръ, малый объём, неповёрнутость, достаточная степень сжатия) — тѣ же правила объявляют, что загруженные WebP в любом случае будут преобразованы в формат JPEG с качеством 85%. Это не радует, во-первых, потому, что lossless WebP не хуже PNG может распухнуть в объёме при преобразовании в JPEG, а во-вторых, потому, что animated WebP теряет, разумѣется, всю свою анимацию при таком преобразовании. Тут надо прибавить (и прибавляю), что animated WebP — не единственный такой формат анимации, который не укладывается на прокрустово ложе «анимированные GIF с преобразованием в MP4» и с которым за это Twitter решил побороться и побѣдить. Менѣе полугода назад (в конце декабря 2019 года) пользователи Твиттера были огорчены тѣмъ, что обнаруженная недѣлей ранѣе возможность публиковать анимированные PNG была у них отобрана Твиттером; и даже болѣе того: при этом Yahoo широко опубликовал слухи (позже поместив в постскриптум опровержение их), согласно которым злоумышленники воспользовались этой новой возможностью использовать анимации (не отключаемые через интерфейс Твиттера, в отличие от отключаемых MP4) для того, чтобы преступно атаковать эпилептиков, вызывая приступ. Но напрашивается вот какой вопрос: а для чего людям вообще понадобилось прибѣгнуть к анимированным PNG, если у них до этого была возможность загружать анимированные GIF в Твиттер? — уж конечно, они были недовольны либо результатами преобразования в MP4 (происходящего с внесением потерь, тогда как анимированные PNG сохраняют каждый кадр без потерь), либо недостаточною цвѣтностью анимированных GIFов: кадры анимированных PNG полноцвѣтны, тогда как каждый кадр анимированного GIF ограничивается 256-цвѣтною палитрою, а если для преодоления этого недостатка использовать пространственное и временнóе раздѣленіе нѣсколькихъ малоцвѣтныхъ кадров (какъ дѣлаетъ gifski), то нѣкоторые пикселы будут бѣшено моргать (сильнѣе, чѣмъ на дешёвых TN-дисплеях, также использующих временнóе раздѣленіе соседствующих цвѣтовъ для передачи промежуточных), да и упереться в официальные твиттеровские ограничения GIF (не больше 350 кадров, не больше 15 мегабайтов) будет очень просто. Возможно, этот же вопрос задали себѣ и в Твиттере, и тогда пользователям было обѣщано, что анимированные PNG, загруженные до отключения возможности такой загрузки, останутся — и даже что в будущем рассмотрен будет вопрос об обустройстве подобной возможности, но лучше и безопаснее (а значит, с предусмотренным отключением их для эпилептиков). Но вот ужé и апрель, а новых анимированных PNG (и тѣмъ болѣе WebP) нѣтъ в Твиттере.

Приведённый в предшествующем сообщении список сайтов, в 2014 году перешедших от поддержки анимированных GIF к поддержке видеоформатов, не стал бы полным без упоминания о том, что и сайт imgur (в октябре того же 2014 года) объявил о запуске нового формата GIFV, суть которого состояла (да и по сей день состоит) в конвертировании присланных его посетителями анимированных GIF на стороне сервера в видеозаписи одновременно двух форматов: WebM и MP4 — чтобы в дальнейшем каждому зрителю доставался тот формат, который поддерживается его браузером. Зато их страница загрузки файлов и доныне (через 5½ лѣтъ) не поддерживает загрузку файлов WebP (причём не только анимированных, но и простых), да ещё и никак не предупреждает посетителя об этом. Если только скинуть туда файл WebP (да ещё потратить время на ожидание окончания загрузки его на imgur), то тогда можно ещё дождаться сообщения об ошибке.

Казалось бы, этим состоявшимся в 2014 году переходом (с GIF-анимаций на видео, но не на WebP) двигала нѣкая логика: видеоформатное сжатие кадров и современнее, и происходит с потерями, так что должно порождать меньший объём файла. И так бы оно всегда и получалось, но только если бы в animated WebP всегда содержалось сжатие кадров способом lossy WebP, которое требует меньше усилий процессора и меньше оперативной памяти, но и слабѣе сжимает, чѣмъ современные видеоформаты. А между тѣмъ в animated WebP может использоваться и сжатие способом lossless WebP, использующее цѣлый ряд таких приёмов, которые в видеоформатах не применяются, зато по отношению к простым GIFкам (в которых несложные контуры, немногие цвѣта, отсутствуют плавные цвѣтовые переходы) дают превосходные результаты: и потери не вносятся в изображение при сжатии, и результат получается меньше по объёму файла, чѣмъ видео разумного качества (тут понятно, что можно и в видеофайл внести такие значительные потери, что он получится ещё меньше, но результат никого не обрадует). Один примѣръ именно такого частного случая приводится в хвосте гугловского FAQ об animated WebP: есть GIFка с пританцовывающим бананом, занимающая 86978 байтов, и преобразование её в видеоформат WebM порождает файл объёмом 32290 байтов, что очень хорошо, поскольку сжатие болѣе чѣмъ в два раза позволяет (по примѣру imgur) сохранять эту анимацию вмѣсто GIF в двух разных видеоформатах (и при этом всё же явно выиграть не только в объёме раздаваемого траффика, а ещё и в объёме хранимых файлов), однако же если вмѣсто WebM использовать анимированный lossless WebP, то тогда файл с результатом окажется ещё в 6½ раз меньше — 4764 байта. Болѣе того: так как FAQ тот — давнишний, то всѣ вы можете улучшить тогдашний результат Google ещё почти на треть, просто скачав новѣйшую версию (1.0.3) их программы gif2webp (как часть libwebp) и запустив команду «gif2webp dancing-banana.gif» самостоятельно — получится файл объёмом 3632 байта, в ≈24 раза меньше исходного GIF. Всё это означает, и даже вполне наглядно, что въ нѣкоторыхъ частных случаях анимированные lossless WebP не только благодаря отсутствию потерь, но и благодаря объёму файла недосягаемо превосходят результаты преобразования анимированных GIF в видеофайлы, так что давнее (с 2014 года) пренебрежение форматом WebP (и безусловное предпочтение ему видеоформатов, не всегда его превосходящих), проявленное множеством сайтов: и на имиджбордах, и в Твиттере, и у imgur — это печально.

В январе 2016 года в книге именно таких печалей появилась ещё одна, причём совершенно особенная, страница: Telegram во блогозаписи «GIF Revolution» объявил, что для любителей анимированных GIFов настало время возрадоваться, так как впредь такие GIFы будут Телеграмом перекодироваться в MP4, что означает экономию до 95% объёма и оттого возможность передавать и получать анимацию до 20 раз быстрее. Можно ли прибавить, что Telegram при этом повёл себя будто Twitter и отказался от употребления изображений в формате WebP? — нѣтъ, этого прибавить нельзя; но для WebP была уготована не многим лучшая участь, чѣмъ полнѣйшій отказ от поддержки: формат WebP в Telegram был загнан в своего рода загон, в своего рода гетто.

Драма, нѣсколькими словами очерченная въ послѣднемъ абзаце предшествующего сообщения, началась ещё в январе 2015 года, когда во блогозаписи «Stickers Done Right» пользователей Телеграма обрадовали извѣстіемъ о появлении поддержки стикеров. Так как тогда в первом из стикерпаков стикеров было не очень много (меньше полутора десятков!), то пользователям предложено было создавать свои собственные стикеры в качестве частично прозрачных изображений и сохранять их в WebP, а каждый клиент Telegram (такой, как Telegram Desktop, напримѣръ) с этого дня начал отображать любой файл WebP, скинутый в чат, в качестве стикера. Во блогозаписи восхвалялася способность WebP хорошо сжимать частично прозрачные изображения — способность, благодаря которой Telegram сдѣлался способным отображать стикеры впятеро быстрее, чѣмъ во прочих мессенджерах. Мѣсяца через четыре (в мае того же 2015 года) не только свои стикеры, но и свои наборы стикеров стало можно создавать, отправляя боту @stickers частично прозрачные изображения в формате PNG, помѣщающиеся в квадрат 512×512 пикселов вплотную (то есть одна из сторон прямоугольника прозрачного холста такого изображения должна быть равною 512px, а вторая — равна или меньше).

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

Если в Telegram Desktop нажать на скрепку и выбрать графический файл для вбрасывания его в чат, то появляется переключатель с позициями «Send as a photo» и «Send as a file». Что помѣшало прибавить к нему ещё третью позицию «Send as a sticker» для всѣхъ графических файлов (или только для WebP), а не создавать тождество сущностей «WebP» и «стикер»?

Если разработчики Telegram обнаружили (и похвалили!) высокую эффективность сжатия WebP, то что могло заставить их ограничиться её использованием только для стикеров? Почему нельзя хранить в этом формате и многое другое для экономии объёма и для ускорения передачи и приёма? Разве нѣтъ таких изображений, которые можно было бы конвертировать при отправке не в JPEG с потерями, а в lossless WebP без потерь, причём попробовать при отправке оба формата и выбросить JPEG, если файл lossless WebP меньше его, и тѣмъ достигнуть экономии по объёму, а не одной только безупречности внѣшняго вида нѣкоторыхъ изображений? (Подозреваю, что изрядная часть канала @PixeLove могла бы и обойтись без проJPEGовывания, и приходить к подписчикам побыстрее.) А разве нѣтъ таких GIF-анимаций, которые можно было бы конвертировать при отправке не в MP4 с потерями (и начать это с 2016 г.), а в анимированный lossless WebP без потерь (и начать это с 2015 г.), и притом с большей экономией по объёму? (Вряд ли вышеупомянутый примѣръ из хвоста гугловского FAQ о WebP единственен.)

А что там с использованием WebP не как внутрителеграмного хранилища, а как первоисточника изображения (пускай затѣмъ и преобразуемого в JPEG или MP4 при отправке)? Как можно восхвалять формат WebP за его степень сжатия изображений, но не готовиться к тому, что люди в так называемом реальномъ мірѣ (за предѣлами Телеграма) также пользуются этим форматом (восхваляя его также и за то же) и оттого они начнут рано или поздно притаскивать и в Telegram используемые ими изображения в файлах WebP — да такие, при создании которых никто и не мыслил об этих изображениях как о стикерах для Телеграма? Почему на эти файлы нельзя воздѣйствовать переключателем с позициями «Send as a photo» и «Send as a file»? Если во блогозаписи «Stickers Done Right» от стикера требуется прозрачность, то почему непрозрачные изображения из файлов WebP также стикеризуются? Если бот @stickers требует от стикера соѿвѣтствіе опредѣлённымъ размѣрам, то почему изображения из файлов WebP других размѣровъ также стикеризуются? Наконец, если анимированными стикерами работают не анимированные WebP, а экспортированные векторные изображения из Adobe After Effects, то почему из содержимого файлов animated WebP вырѣзается первый кадр анимации и также стикеризуется?