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

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

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

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

Я довольно давно ужé публикую где-нибудь время от времени ту или иную видеоцитату. В моём микроблоге в Твиттере это случалось, по меньшей мѣрѣ, с августа 2017 года, а в сентябре того же года я начал аналогичные эксперименты и в гипертекстовом Фидонете. Что же касается имиджбордовских видеороликов, то я с удовольствием начал пользоваться возможностью публикации видеозаписей немедленно после её появления на Ычане в январе 2018 года и на 410чане в сентябре того же года, и я уж не говорю о тѣхъ других имиджбордах, на которых этой возможности мнѣ не пришлось дожидаться, потому что она была там прежде, чѣмъ я решил воспользоваться ею.

В апреле 2019 года я узнал ещё, что посредством приложения Overmix видеоцитата, содержащая эффект Кена Бёрнса, может быть подвергнута противоположному эффекту для реконструкции того цифрового изображения, которое значительно выше и (или) шире видеокадра и вдоль которого он проматывается.

Знаете, что было для меня во всѣ эти годы самым, самым утомительным (и притом ещё всё болѣе утомительным) при изготовлении видеоцитат? — точное указание того времени, от которого и до которого видеоцитата длится в исходном видеофайле. Первый блин был комом настолько, что для своих первых видеоцитат я указывал начальное и конечное время с небольшою точностью — всего-навсего до секунды — пока не обнаружил, что счётчик времени в видеопроигрывателе Media Player Classic Home Cinema (который я и тогда предпочитал, и до сих пор предпочитаю использовать) можно жмякнуть правой кнопкою мыши, чтобы включить режим «High precision», в котором и миллисекунды также отображаются. После этого я быстро выучил сочетания клавиш для покадрового просмотра видеозаписи, чтобы в моих видеоцитатах никогда ужé не было ни одного лишнего кадра, а позиции кадров стал указывать долями секунд. Но это-то указание и оказалось утомительным. Не так-то просто запомнить в видеопроигрывателе и затѣмъ набрать точное время в командной строке, предназначающейся для FFmpeg. Одна или двѣ цифры минут, двоеточие, двѣ цифры секунд, точка, три цифры миллисекунд — для меня это оказалось столь близким к миллеровскому предѣлу человѣческихъ возможностей, что необходимость раз за разом запомнить, а затѣмъ безошибочно набрать всю эту информацию (и тотчас забыть, чтобы повторить всё то же ещё раз с другою похожею) оказалась для меня тягостною, так что я стал для вѣрности почаще произносить всѣ цифры вслух (чтобы получалось понадёжнее, чѣмъ «про себя») и притом ещё разок-другой переключаться между командною строкою и окном видеопроигрывателя, свѣряя всё набранное, чтоб не ошибиться и затѣмъ уж не возвращаться к видеоцитате для её исправления. К началу нынешнего года я начал ощущать по отношению к этому мелкому неприятному усилию, дважды совершаемому при всяком цитировании, такое сильное отвращение, что даже стал меньше и неохотнѣе смотреть аниме в этом (зимнем) сезоне: с января по март в 2020 году — заранее вполне сознавая, что в каждой серии аниме могу встретить двѣ или три удачные сцены, заслуживающие цитирования, а также пять или десять эффектов Кена Бёрнса, по которым пожелаю создать сшивку (да, может быть, даже и больше десяти, если создатели конкретной серии аниме волею или неволею решили экономить на работе аниматоров и вмѣсто того задать работу широкоформатным художникам или фоновщикам, что нерѣдко случается при нынешнем кризисе этой творческой индустрии), так что придётся, может быть, две дюжины раз запомнить, и безошибочно набрать, и позабыть точное время, и затѣмъ ещё одно и ещё одно.

К счастью, в нынешнем Интернете (пока его не доломали мизульно-яровые цензоры) никто не одинок со своею проблемою; не был одинок и я: гораздо раньше (как раз в августе того 2017 года, когда я только начинал возёхаться с видеоцитатами) один из пользователей Media Player Classic Home Cinema ужé наѣлся трудоёмкостью копирования точного времени и пришёл к разработчикам с просьбою упростить дѣло. «Приходится использовать цѣлыхъ четыре сочетания клавиш: Ctrl+G, Ctrl+A, Ctrl+C и Escape — а это долго», — гласила его просьба.

«Ѽ, етить!» — воскликнул я при одном виде этого рецепта.

Оказалось, что я напрасно болѣе 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).