Что: b0b1c55e7e310cb75e94807bcaef7f3a175f29e0
Когда: 2023-03-24 10:06:50+03:00
Темы: multimedia tip
JPEG XL vs PNG/WebP
https://github.com/libjxl/libjxl/issues/426
https://github.com/libjxl/libjxl/issues/727
JPEG XL хорош на всём что касается фотографических изображений. Но на
синтетических, типа снимков экрана терминала, он не всегда лучше PNG.
Делал я тут снимки mmc (66a73601f697c99ce2d0554eebe5017e2a0861bd) и
некоторые из них в PNG занимают немного меньше, большинство всё же
побольше. WebP при этом в два раза меньше умудряется делать размером
всё. Ничего удивительного, ожидаемо -- всё же JXL для фотографий. Но,
насколько понимаю, потенциал в виде его тьюринг-полных (почти)
predictor-ов в теории может бить PNG всегда.
Про эту особенность на GitHub libjxl-а знают. Оттуда узнал что, как раз
таки, можно задать перебор всех predictor-ов, опцией --modular_predictor=15.
--help вообще так себе у cjxl утилиты, ибо там написано же что оно и
равно 15-ти "at slowest speed", а штатный самый медленный --effort это
9-ка, которую я всегда и использую. Но нет, 15 оно не включает. Так вот
с этими опциями JXL у меня все PNG побил.
22.878 png
10.928 webp
23.568 jxl (-d 0 -e 9 -p)
19.274 jxl (-d 0 -e 9 -p -P 15)
23.568 jxl (-d 0 -e 9 -p -P 0)
18.658 jxl (-d 0 -e 9 -p -P 0 -g 3)
17.692 jxl (-d 0 -e 9 -p -P 15 -g 3)
Но тут я задался вопросом: а прогрессивное декодирование нужно ли? Я его
автоматом выставляю потому что в JPEG оно даже помогает, в PNG тоже не
вредит.
10.460 jxl (-d 0 -e 9)
10.460 jxl (-d 0 -e 9 -P 15)
15.216 jxl (-d 0 -e 9 -P 0)
16.262 jxl (-d 0 -e 9 -P 0 -g 3)
10.217 jxl (-d 0 -e 9 -P 15 -g 3)
Без игр с predictor и modular group size, JXL сразу же побил WebP! Для
меня это стало открытием. Действительно, с какой стати я посчитал что
поведение прогрессивного декодирования должно быть похоже на то, что в
JPEG? Оно очень круто в этом примере вредит сжатию.
Проверил на снимках с сайта PyDERASN-а, где WebP занимал более чем в два
раза меньше места чем PNG:
23.996 browser.webp
7.733 browser.jxl (-d 0 -e 9)
7.532 browser.jxl (-d 0 -e 9 -P 15 -g 3)
18.906 pprinting.webp
8.357 pprinting.jxl (-d 0 -e 9)
8.381 pprinting.jxl (-d 0 -e 9 -P 15 -g 3)
8.341 pprinting.jxl (-d 0 -e 9 -P 0)
JXL тут более чем в два раза бьёт WebP. Причём все эти -P/-g опции везде
по разному влияют на сжатие: где-то хуже становится, где-то лучше.
Автоматического их перебора в cjxl утилите нет. Собственно, люди пишут
собственные скрипты для этого. Попробовал "--allow_expert_options -e 10",
но это оооооочень долгая операция. Если все остальные вызовы
отрабатывали 2-3сек, то с -e10 на восьми ядрах это заняло почти 10мин, с
чуть более лучшим результатом, на этой 1920x1060x8bpp картинке:
10.217 jxl (-d 0 -e 9 -P 15 -g 3)
10.188 jxl (-d 0 -e 10)
Сгенерирован: SGBlog 0.34.0