Франк Форс у себя в блоге разобрал эффект 3D-тоннеля, код которого умещается в 140 символов, — "Dissecting A Dweet #8: Shattered Tunnel".

Этот эффект — идейное продолжение демо "Strange Сrystals", которое в 2013 году заняло первое место на конкурсе JS1k (соревнование среди демок, которые умещаются в 1024 байт). Из статьи узнал, что canvas.width = canvas.width используют для очистки canvas. Этот хак работает благодаря тому, что при присваивании любого значения размера canvas, происходит его инвалидация. В конкурсах, подобных JS1k, этот код сокращают до canvas.width |= 0, но этот хак не рекомендуют использовать в серьёзных проектах.

Статья интересная. Рекомендую почитать, если интересуетесь графикой и code golf.

#graphics #math #js

http://frankforce.com/?p=7160

Ингвар Степанян из Google написал статью про ускорение сжатия png-изображений в Squoosh — "Bringing OxiPNG to Squoosh".

Squoosh.app, несмотря на то что работает в вебе, попадает в категорию лучших инструментов для сжатия изображений. Для работы с png в нём использовалась скомпилированная в WebAssembly C-библиотека OptiPNG. У неё есть продвинутая альтернатива — Rust-библиотека OxiPNG, основное преимущество которой поддержка многопоточности (планируют задействовать в будущих релизах Squoosh).

Первая попытка миграции на OxiPNG привела к увеличению размера сжимаемых png относительно OptiPNG. Проблема была в библиотеке miniz_oxide, которая реализует алгоритм сжатия без потерь deflate, использующийся в png. Проблемная библиотека в итоге была заменена на libdeflater. После миграции на OxiPNG скорость сжатия png в некоторых случаях ускорилась более чем в два раза, и на несколько процентов сократился объём генерируемых файлов.

Статья скорее всего будет интересна тем, кто работает с WebAssembly и кому интересно почитать про библиотеки для сжатия png.

#webassembly #tool #graphics

https://rreverser.com/bringing-oxipng-to-squoosh/

Всегда ли WebP сжимает изображения лучше чем JPEG? Этим вопросом задался Йоханнес Сипола и написал статью "Is WebP really better than JPEG?"

Google в своих исследованиях про эффективность сжатия WebP говорил про уменьшение размеров изображений на 25-34% относительно JPEG. Йоханнес предполагает, что такая цифра получилась благодаря тому, что для создания JPEG-изображений использовался референсный кодировщик — cjpeg. В то время как существует более эффективный независимый кодировщик JPEG от Mozilla — MozJPEG. При сравнении разных наборов изображений из датасета от Kodak оказалось, что WebP уступает MozJPEG на больших изображениях. При этом во всех замерах с большим отрывом лидирует новый формат изображений — AVIF.

Выводы из статьи. Используйте WebP, когда сжимаются изображения меньше 500px, когда вы не можете использовать MozJPEG и когда вы можете использовать агрессивное сжатие с потерей качества.

#graphics #optimization #benchmark

https://siipo.la/blog/is-webp-really-better-than-jpeg

Дэниэл Александерсен поделился результатами сравнения WebP и AVIF в статье "Comparing AVIF vs WebP file sizes at the same DSSIM".

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

При сравнении с оригинальными JPEG-изображениями медианное значение сокращения размера файлов при сжатии с помощью WebP составило 31.5%, у AVIF — 50.3%, на 85-ом перцинтиле 20% у WebP и 39.6% у AVIF. У WebP 2.7% изображений оказались больше оригинального изображения, у AVIF все изображения были меньше.

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

#graphics #optimization #benchmark

https://www.ctrl.blog/entry/webp-avif-comparison.html

В Chrome 85 появилась поддержка формата изображений AVIF. Джек Арчибальд написал большую статью про то, в каких случаях он может быть полезен — "AVIF has landed".

AVIF — это новый формат изображений, который основывается на видеокодеке AV1. По сравнению с другими форматами он сжимает изображения гораздо лучше, но у него есть некоторые ограничения. Для изображений, в которых важна высокая детализация, лучше использовать старый-добрый JPEG. Также AVIF не поддерживает прогрессивный рендеринг, когда изображение медленно появляется на странице по мере его загрузки. Лучше всего AVIF подходит для сжатия небольших изображений.

В статье затрагиваются вопросы производительности при сравнении AVIF c SVG. SVG по качеству превосходит все другие форматы, но сложное векторное изображение может быть очень затратным с точки зрения CPU. Поэтому SVG с большим количеством градиентов и фильтров рекомендуется конвертировать в растровое изображение.

Поддержка AVIF появилась в Chrome 85, в Firefox уже идёт работа над его внедрением. Поддержка AVIF в Safari, скорее всего, тоже не заставит себя долго ждать, так как Apple входит в группу разработчиков AV1.

#graphics #optimization

https://jakearchibald.com/2020/avif-has-landed/

Мальте Юбэл из Google написал статью про современные практики работы с изображениями в web — "Maximally optimizing image loading for the web in 2021".

В статье рассказывается про то, как избежать сдвига контента при работе с отзывчивыми изображениями, про ленивую загрузку изображений, кэширование, новый формат AVIF, использование тега <picture> и работу с размытыми заглушками.

Самым интересным в статье для меня было описание техник для снижения потребления и оптимизации CPU. Например, вставка изображений с атрибутом decoding="async" даёт сигнал браузерам о том, что декодировать изображение можно вне главного потока (в твиттере в обсуждении статьи, лид, отвечающий за рендеринг в Chrome, говорит о том, что этот атрибут не включён по умолчанию, так как загружаемый контент моргал бы при загрузке). Ещё в статье есть описание трюка с использованием размытия с помощью SVG-фильтров, благодаря этому подходу изображения размываются только один раз при загрузке, а не на каждый layout страницы как при использовании CSS-фильтров.

Небольшая и очень полезная статья. Рекомендую почитать.

#graphics #web

https://www.industrialempathy.com/posts/image-optimizations/

Джон Снейерс из Cloudinary написал статью о проблемах адаптации новых форматов изображений, и как эти проблемы могут быть решены с помощью JPEG XL — "Legacy and Transition: Creating a New Universal Image Codec".

JPEG XL — это открытый формат изображений, разрабатываемый Joint Photographic Experts Group, Google и Cloudinary. JPEG XL предоставляет прогрессивную загрузку, лучшую скорость кодирования/декодирования и лучшее качество сжатия при сравнимом объёме файла по сравнению с WebP.

Любое JPEG-изображение — это валидный JPEG XL. Трансляция из одного формата в другой требует минимальных вычислительных ресурсов, тем самым JPEG XL можно транслировать в JPEG на лету и отдавать тем браузерам, которые не поддерживают JPEG XL. То есть сайтам не нужно хранить одно и то же изображение в разных форматах для разных клиентов.

Комитет JPEG планирует отправить последнюю версию черновика стандарта в ISO и IEC в этом месяце. Если у проверяющих организаций не будет вопросов, то черновик будет опубликован как международный стандарт в июле.

#graphics

https://cloudinary.com/blog/legacy_and_transition_creating_a_new_universal_image_codec

Причины отсутствия поддержки AVIF в Safari

Джон Хеншоу написал небольшой пост про причины отсутствия поддержки AVIF в Safari — "Why WebKit supports AVIF but Safari does not".

Поддержка AVIF есть в Chrome и Firefox, единственным браузером, который не поддерживает новый формат изображений, остаётся Safari. Похожая ситуация была с WebP — Safari стал последним браузером, который добавил его поддержку. Со стороны это может показаться странным, потому что декодер AVIF был добавлен в WebKit в апреле 2021. Проблема заключается в том, что Safari не использует код WebKit для декодирования изображений, он делегирует эту работу системным библиотекам. Это означает, что поддержку нового формата в Safari стоит ждать тогда, когда его поддержка появится на уровне всей операционной системы.

#graphics #safari

https://www.coywolf.news/webmaster/why-webkit-supports-avif-but-safari-does-not/