>>5098
Я не против того, чтобы Nowere поддерживал JPEG XL — но вот только не вмѣсто WebP, а со свободою выбора между JPEG XL и WebP.
Необходимость свободы выбора обуславливается двумя причинами.
Во-первых, в настоящее время не существует даже стандарта, описывающего JPEG XL, не говоря ужé о какой-либо полной реализации этого стандарта браузерами. Болѣе того: можно съ увѣренностью прогнозировать, что и через год (27 июня 2021 года) либо ещё не будет ни того, ни другого, либо стандарт-то ужé будет, но ещё не будет реализации, поскольку с реализациею браузеростроители медлят. Мы всѣ ясно видим такое промедление на примѣре формата AVIF, поддержка которого сейчас есть только в одном браузере (в Firefox; по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1625363 подробности), но экспериментальная, неполная, по умолчанию отключённая в настройках (надо лезть и включать, а для того заранее знать, куда лезть), неэффективная (по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1634751 подробности), а вѣдь на дворѣ ужé лѣто 2020 года. Слѣдовательно, отказ от поддержки WebP, совершаемый прямо сейчас в пользу неясно когда в будущем ожидаемого формата JPEG XL (в 2022 году? — может быть, и ещё позже?), выглядит нехорошим повторением пословицы про синицу в руках и про журавля в небе, тѣмъ болѣе что никто не исключал факторы, способные замедлить появление JPEG XL или помѣшать ему, а среди таких факторов угадывается и вторая волна коронавируса (помноженная на bus factor группы JPEG или браузеростроителей, а также способная вызвать экономический спад и оттого упадок финансирования), и вѣроятность патентной склоки (наподобие https://en.wikipedia.org/wiki/JPEG#Patent_controversy в прошлом). А прямо сейчас единственным подмножеством JPEG XL, которое можно запускать во браузерах (в форме WebAssembly), является гугловский алгоритм Brunsli (переужатие JPEG без потерь), по адресу https://google.github.io/brunsli/ демонстрируемый. Этот алгоритм полезен только в одном случае: когда под рукою есть готовый JPEG и необходимость переужать его без потерь. Если же есть исходное растровое изображение и есть намѣреніе сжать его с потерями, то результат такого сжатия будет выглядеть лучше не после сжатия в JPEG с потерями (и послѣдующаго доужатия в Brunsli без дальнейших потерь), а после сжатия в WebP с потерями, если сравнивать результаты съ примѣрно равными объёмами файлов. (Чтобы такое сравнение было честным, для наращивания качества JPEG слѣдуетъ использовать современный кодировщик MozJPEG, использующий trellis optimization и black-on-white deringing via overshoot, причём одновременно — а для наращивания качества WebP слѣдуетъ использовать недокументированный препроцессор «-pre 5», мною по адресу https://twitter.com/FidonetRunes/status/1276181902324629509 позавчера упомянутый, который запускает segment-smooth и luma-weighed chroma subsampling, причём одновременно.) Поэтому-то в большинстве случаев WebP нужен прямо сейчас.
Comment too long. Click
here to view the full text.