Вопрос любителям JPEG XL

gimp, imagemagick, xnview?

Что из них распространено под Windows? ImageMagick — недостаточно распространён.

В похожих темах, что вообще хром депрекейтнуть собрался

https://en.wikipedia.org/wiki/JPEG_XL#Official_software_support

вообще хром депрекейтнуть собрался

4 года назад. А в январе 2026-го вернули.

Adobe Photoshop/Lightroom, Macos/ios.

хочу убедить авторов одной программы добавить поддержку.

Ну так подожди месяц-два, пока во всех основных браузерах завезут поддержку и тогда аргумент будет более весомый.

https://en.wikipedia.org/wiki/JPEG_XL#Official_software_support

Ага, что не нашёл Гугл, есть по ссылке из Википедии: версия Chrome не ниже 145.0.7632.0, и в chrome://flags/ включить enable-jxl-image-format.

В стабильной ветке Firefox соответствующий код отсутствует. https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c58

месяц-два, пока во всех основных браузерах завезут поддержку

Откуда инфа? Уже столько лет ждём, и вдрёг месяц-два осталось, оказывается…

Были какие-то подвижки на этом поприще недавно?

Были какие-то подвижки на этом поприще недавно?

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

В Фоксе экспериментальная поддержка. После Хромога, вероятно, довольно быстро допилят.

Макос/иос/Сафари поддерживают уже.

В спецификацию PDF включили jxl как рекомендованный формат изображений.

Я думаю к концу этого года уже много где будет.

В Фоксе экспериментальная поддержка. После Хромога, вероятно, довольно быстро допилят.

Вот фиг знает… Как всякие кнопочки передвигать и удалять, да ИИ впиливать — это они быстрые, а как что-то по существу, бывает что буквально лет 10 занимает у них.

Время покажет. Надеюсь, ты прав.

а xnview? встречаю его почти на каждом втором компе.

xnview? встречаю его почти на каждом втором компе.

Ни разу не видел. Вместо штатной смотрелки картинок — разве что IrfanView — и тот у людей с 25-летним опытом.

Были какие-то подвижки на этом поприще недавно?

В Хром вернули в релизе от 20 января, но по умолчанию отключено. Можно ожидать, что за Гуглом потянутся остальные. Главная причина, по которой внедрение застопорилось несколько лет назад — отказ Гугла.

Firefox официально не поддерживает. Установил https://addons.mozilla.org/ru/firefox/addon/jxl/ , но при открытии с локального диска тоже сохраняет на диск. Вопрос тот же.

После установки расширения идешь в about:config и устанавливаешь у параметра image.jxl.enabled значение true.

После этого тестовая картинка https://jpegxl.info/resources/jpeg-xl-test-page.html начинает отображаться. Проверено на версии 147.0.1 из оф. репы mozilla для debian.

Да, я уже понял. Будем надеяться, что не сдадут назад опять, и включат-таки по умолчанию. На отключенное по умолчанию остальным обычно пофиг. А вот если в хроме будет работать у всех, тогда да, вероятно и другие реализуют. В общем, надеемся и ждём.

Зачем?

После установки расширения идешь в about:config и устанавливаешь у параметра image.jxl.enabled значение true.

Не помогло. 147.0.1, Gentoo.

UPD: Не работает на открытых с диска файлах. Работает на картинках, отдаваемых веб-сервером, спасибо.

UPD2: Тестовая страница требует JavaScript, и из 4 картинок показывается только первая. И похоже, вместо JXL показывает PNG :)
dice.jxl, отдаваемая сервером, рисуется, но непрозрачная.
anim-icos.jxl, отдаваемая сервером, выводит только первый кадр.
Webkit-logo-P3.jxl и zoltan-tasi-CLJeQCr2F_A-unsplash.jxl, отдаваемые сервером, выводятся нормально.

В Хром вернули в релизе от 20 января

А в Хромиуме, похоже, эта ветка появится в стабильном релизе только 10 февраля.

Сравнить с AVIF (жрёт процессор) и WebP (ограничен размер). Оценить обещаную фичу пережатия JPEG-ов без новых потерь.

Inkscape и XnView MP вроде открывают.

Да, что-то вниз я тогда не посмотрел.

Перепроверил. «Size Comparison» отображает нормально. Если пытаться сохранить картинку «zoltan-tasi-CLJeQCr2F_A-unsplash.jxl» из браузера, то да сохраняет как «zoltan-tasi-CLJeQCr2F_A-unsplash.png». Если открыть в GIMP и посмотреть «Свойство изображения», то будет писать «Тип файла: Изображение JPEG XL».

file тоже пишет, что это «JPEG XL container».

Варианты «Alpha Transparency», «Wide Gamut» и «Animations» не отображаются. Пишет «Your browser does not currently support JPEG XL».

Откуда инфа? Уже столько лет ждём, и вдрёг месяц-два осталось, оказывается…

Google Chrome 145 Released With JPEG-XL Image Support

https://www.phoronix.com/news/Chrome-145-Released

Проверил сам: пока нужно включить специальный флаг в chrome://flags/ (поиск по jpeg) – тестовая страница jpeg-xl работает.

https://jpegxl.info/resources/jpeg-xl-test-page.html

В спецификацию PDF включили jxl как рекомендованный формат изображений.

мне вот интересно, какой сумасшедший использует в pdf все самые свежие фичи. При том что для portable шоб наверняка ставишь версию 1.1 и испотзуешь для растра два формата - JPEG и тот, который как djvu - слоями - для сканов (и то, если знаешь, такое в природе есть).

мне вот интересно, какой сумасшедший использует в pdf все самые свежие фичи. При том что для portable шоб наверняка ставишь версию 1.1 и испотзуешь для растра два формата - JPEG и тот, который как djvu - слоями - для сканов (и то, если знаешь, такое в природе есть).

Я почти уверен, что большинство пользователей pdf даже не понимают о чем ты говоришь (в т.ч. и я). Когда нужен pdf, просто делаешь экспорт и что там по дефолту стоит – на то Божья воля :)

тестовая страница jpeg-xl работает

Круто! А где он ещё нужен?

А где он ещё нужен?

Огромное число JPEG-ов в сети сжимается с параметрами, установленными под производительность начала 1990-х — когда машины были слабыми, а арифметическое сжатие защищено патентами, разрешалось только Хаффмана. Простая перепаковка JPEG-ов jpegtran -arithmetic и даже jpegtran -optimize может уменьшить файлы на треть. JXL по размеру в разы меньше.

P.S. А ещё там есть прозрачность и анимация :)

Об этом написано в стартовом посте :)

JXL по размеру в разы меньше.

Ну и что? С трудом представляю, что все кинулись конвертировать свои йобибайты картинок в JPEG XL.

А я - без труда. Тот же гугл форсит AV1, а раньше VP8/9, как раз в связи с ёттабайтами видео на YT.

Dropbox когда-то lepton разработал. Проект в настоящее время похоронен. Но не удивлюсь, если у таких крупных хостеров картинок внутри файлы лежат не просто в jpeg. Ведь на тот же SMR все уже перешли ради 20% экономии.

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

Правильно, именно поэтому всем пофиг. Люди решают свои собственные проблемы, а проблемы гугл пусть решает гугл.

Я вот прям спать не могу, пытаюсь решить проблему трафика в мировом масштабе.

С трудом представляю, что все кинулись конвертировать свои йобибайты картинок в JPEG XL.

Когда большинство пользователей будут гарантировано его понимать, сервера тихо и незаметно начнут отдавать jxl вместо jpg. Как сейчас некоторые отдают по умолчанию webp, а jpg и png — только по платной подписке. Не уверен, что есть смысл перегонять webp в jxl, но jpg — точно есть. И не знаю, победит ли он avif.

Ты рассуждаешь с позиции локалхоста.

С позиции локалхоста, хранящего терабайты отсканированных страниц, бумажные оригиналы которых давно утрачены, тоже имеет смысл перегонять всё в форматы меньшего размера, которые не привносят новые искажения. Нежелательно гнаться за новыми форматами AVIF и WebP, особенно если сканы изначально не в PNG, а из-за нехватки места всё жали в JPEG. А вот на JXL заменить JPEG будет целесообразно. Когда поддержка стабилизируется, а не как сейчас.

Ну и то, что может касаться почти каждого: у всех есть телефон, на нем фоточки, если они будут занимать на 20-30% меньше, то выиграет каждый.

у всех есть телефон, на нем фоточки, если они будут занимать на 20-30% меньше, то выиграет каждый.

Если переделывать приложения для съёмки под новый формат, может иметь смысл писать новые фотографии в WebP или AVIF. У меня на десктопе оба работают быстрее JPEG XL при лучшем сжатии. Возможно, с распространением JPEG XL допилят библиотеки или изменят дефолтные настройки для ускорения.

Ну я когда о нём узнал, неплохо так сэкономил место на маленьком диске, на один каталог с 1-2 тыс. фоток было сэкономлено от 20 до 30% места.

У меня на десктопе оба работают быстрее JPEG XL при лучшем сжатии.

Ну, мне кажется это не очень актуально. Возможность сэкономить 20-30% мне кажется более полезной.

У меня в настройках камеры есть возможность выбрать обычный jpeg и heic (хз вообще что это такое). Я думаю, НУ, ЧАЙ НЕ НУЛЕВЫЕ, МОЖЕМ СЕБЕ ПОЗВОЛИТЬ СОВРЕМЕННЫЙ ФОРМАТ! А потом оказалось, что thumbnailer в Гноме его плохо поддерживает. В половине фоток показывает превью, в половине нет. Вернулся на jpeg. Так и живем :)

heic (хз вообще что это такое)

Один кадр HEVC (H265).

Ну например на сайтах (всякие фото, картинки, аватары, бэкграунды, интерфейс) уменьшение объёма передаваемых данных ускорит загрузку, особенно на мобильном интернете, уменьшит трафик. Ну и я бы и на локалхосте свои картинки хранил в JPEG XL, если бы он лучше поддерживался в софте. Он и в Lossless умеет более эффективно, чем PNG — конвертнул бы PNG-шки, да, место бы сэкономил.

heic (хз вообще что это такое)

«High Efficiency Image Coding». Сравнивал его недавно для видео с AV1 и VP9. При равном размере качество изображения HEVC заметно хуже, заметные артефакты появляются раньше или их больше. Но средства для его аппаратного кодирования и декодирования распространённее, чем для VP9. И они выпускаются дольше, чем для AV1.

У меня на десктопе оба работают быстрее JPEG XL при лучшем сжатии.

Ну, мне кажется это не очень актуально.

Если загрузка фотографии на Ryzen 9 происходит не мгновенно, это заставляет задуматься :) А когда я их на 10-летнем процессоре использовал, там ожидание загрузки крупных JXL и AVIF здорово раздражало. При том, что AVIF и WebP часто меньше.

Но повторю, JXL иногда показывает настолько плохие результаты, что подозреваю его кривую поддержку в ImageMagick, Qt6 и libjxl.

При равном размере качество изображения HEVC заметно хуже, заметные артефакты появляются раньше или их больше

Какие настройки x265 использовались?

Какие настройки x265 использовались?

Пришёл к выводу, что самое главное — -rc constqp

Сжимал картой Nvidia:

ffmpeg -i infile.mp4 -c:v h264_nvenc -multipass 2 -preset p7 -rc constqp outfile.mp4

ffmpeg -i infile.mp4 -c:v av1_nvenc -rc constqp outfile.mp4

ffmpeg -i infile.mp4 -c:v hevc_nvenc -rc constqp outfile.mp4

и варьировал -qp

Если правильно помню, без -qp качество одинаковое, но видео hevc в полтора раза больше av1. Если варьировать -qp и довести hevc до того же размера, появляются заметные артефакты.

VP9 сжимал софтово, поэтому экспериментировал меньше, сходу не нашёл, какие параметры использовал. Если правильно помню, на VP9 с минимумом параметров получил размер близкий к AV1 без заметных артефактов.

Сжимал картой Nvidia

В этом и проблема. Надо на cpu, с libx264/libx265 — качество при том же битрейте будет в разы лучше.

Сжатие на видеокарте — это только для стриминга годится.

подозреваю его кривую поддержку в … libjxl

А есть какие-то другие реализации JPEG XL? (А, что-то на Расте переписывают). :-D

в ImageMagick, Qt6

Было бы удивительно получать другой результат, ведь они зависят от libjxl.

А есть какие-то другие реализации JPEG XL?

Есть. J40 (только декодирование), hydrium, jxl-oxide

J40 (только декодирование), hydrium

На https://jpeg.org/jpegxl/software.html нет, видимо ещё не заслужили.

jxl-oxide

Тоже только декодирование.