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)