> Jxl совершенно точно поддерживается в Qt (сторонний плагин, но всё же работает

В таком виде это мало кому будет надо, имхо.

> прекрасно), а это значит, что он полностью поддерживается в любой qt-based программе.

И все б ничего, только у меня gtk-based десктоп пока (XFCE). Может это и изменится, но вот прямо плагин кутей мало чем поможет, да еще сторонний почему-то.

> Кроме того, он есть в XnView и ImageMagick,

Мне что, всем юзерам их расставлять? Второй к тому же страшило (вьюшка) и дыряв как черти что по жизни, за что и был мной выпилен везде. Нельзя так косячить в либах работающих с внешними данными.

> это можно считать, он поддерживается софтом в 99% случаев.

Я этот кульый тезис не подтверждаю, на примере моего окорока. Вот webp это еще может сказать - из-за браузеров. И то в лисах он только несколько последних версий, особенно анимахи (которые ваши конкуренты вроде не умеют, это уже скорее GIF'у подарок).

> и собственной смотрелкой поверх sdl1, никакой поддержки в кутях и ничего такого.

Ну да, им просто никто не пользуется, и он как суслик - где-то есть.

>>Меня не интересуют такие уровни сжатия в lossy
> Зато потребителей контента они очень интересуют, это нужно понимать тоже.

Не похоже на типового хомяка с браузером. У тех хорошие экраны - HiDPI, огрехи даже с лупой не найдут. А на офисной TFT'е и матрице ноута про качество речь и не идет. Конечно есть эстеты типа меня с большим ips монитором, но даже я фоты в галерее с лупой рассматривать не буду, и время загрузки больше анноит чем огрехи (тем более что DPI тоже повышенный). Да и мало таких как я.

> А вот артефакты мало кому нравятся (/me выразительно смотрит на webp,

Я не вижу на нем никаких особых артефактов которые меня откровенно напрягали бы в типичных сценариях. А размер меньше жыпега. Или гифа (если прокатило).

> который пихают не смотря ни на что).

А пихают его потому что браузерами жрется и на тех уровнях сжатия все же обычно задвигает жыпега по битрейт-качество.

> Lossless это любой формат, из которого можно восстановить все исходные данные (не
> 1 в 1, просто с 0 потерь). Если этот формат позволяет в 2-3-10 раз эффективнее
> сжать данные, тем лучше.

Теоретически да. Практически - даже равки не сильно парят. Ну да, их сколько-то гигз. Винчи емкие, а ремотным юзерам я их не собираюсь, они открыть не смогут все-равно, как и jxl.

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

Теоретически да. Практически есть и иные соображения - по типу поддержки этого софтом и возможности без гемора отредактировать или конвертировать.

> Повторное лосси кодирование с минимумом дефектов -- это одна из основных фишечек
> jxl, он позволяет из lossy исходника получить очень качественно перекодированное изображение
> уже на данном этапе.

Когда я планирую множественное редактирование это заранее будет lossless формат, потому что гадать кто как попортит картинку за 100500 итераций мне не в кассу. И я не хочу присягать на верность до гроба единственному формату - со временем наверняка появится более эффективный, а как их артефакты взаимодействуют - отдельный вопрос.

> Пользователи это очень оценят (у них нет доступа к исходным данным).

Пользователи обычно не перекодируют картинки.

>>Рандомные вариации размера - следствие того что разное содержимое разное
> В случае с видеокодеками, это в первую очередь следствие тараканов у энкодера

Разный объем энтропии в входной информации - не таракан, а основа основ. У видеокодеков есть понятие "простой сцены" и "сложной сцены". Это частично применимо и к картинкам.

Более того, бороться с этим глупо. Зазырьте у гугля параметры для fire and forget кодирования ffmpeg'ом (они так кодируют под ютуб). Это "constrained quality". Кодек работает в режиме фиксированного качества если битов хватает, а если материалец сложный что пипец - врубается cap битрейта, предотвращающий огромные файлы, хоть качество и страдает. В этом есть свой пойнт - если у половины юзеров "эта гадость все время крутится!!!111"  т.к. качаться не успевает, это намного хуже чем пара лишних артефактов. Это же и времени загрузки фот в галерее касается.

> тёмные изображения, однако по факту там вместо изображения окажется мешанина пятен.

С другой стороны, человеческий глаз не особо то замечает это, особенно если не знает заранее что искать. "Problem solved!". Весь пойнт lossy - выкинуть как можно больше, так чтобы это незаметно было.

> Зато размер, да.

Ну так можно накинуть битрейта - закодирует получше.

> его можно прекрасно декодировать в тот же png и уже с
> тем работать, если поддержки в нужном софте нет

Лишняя операция, которая транжирит время на чисто техническую рутину, не айс.

> (рекомендую иногда всё же обновляться - она там появится рано или поздно, можно ещё
> попинать разрабов).

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

> Никто не устанавливал требования к размеру. Но тот же webp не справляется,
> и ещё хуже он справляется, если попросить от него приемлемое качество

Кодирование в lossy вообще априори _может_ быть итеративным процессом. Из-за разной сложности кодирования разных сцен. Попытки уравнять размер файлов энным кодеком независимо от содержимого ведут только к тому, что придется накинуть битов столько, чтобы всегда хватало даже очень сложным сценам, а простые сцены будут с сильным избытком битов дающим крайне маргинальные улучшения. Это очень субоптимально.

> avif с heic. А вот jpeg и jpeg-xl прекрасно справляются, размер
> всегда будет пропорционален качеству (если артефакты не лезут из-за недостатка битрейта,
> что не случится случайно).

На самом деле даже у жыпега размер при энном качестве бывает довольно разным. Сравните кодирование фото без шума с плавным градиентом и без множества мелких деталей vs сильно зашумленое, допустим. По размеру файла иногда даже можно уровень шума прикинуть - ну вот хреново шум матрицы жыпегу, он не для этого делался и неэффективен в кодировании рандома :)

Еще бывают всякие штуки типа jpegoptim - способные отвоевать несколько процентов вообше без потерь. Просто обычные кодеры не заморачиваются некоторыми странными оптимизациями, а некоторые, вот, вполне. Существует бесконечное количество способов кодирования 1 формата, не все они одинаковые по эффективности.

>>в этих сканах реально содержится столько инфо что там реально каждый пиксел важен
> Именно так,

Сколько сканов я видел - они были чем угодно но не этим.

> кроме того, мелкие детали могут оказаться текстом или важными деталями
> которые сведут с ума кодировщик

Ну вот тут вам наверное виднее, у меня из 600 dpi контента только очень специфичные вещи, которые уж точно не показательны (и прекрасно давятся png, но это не сканы).

> и в лучшем случае тот их удалит, или же полезут артефакты.

Вообще во всех виденных мной сканах, буквы и детали занимали чуть более чем дохрена пикселей, так что 600 было сильным оверкиллом, а не особо ценные сразу в 300 по жизни сканили для ускорения и экономии места, но последний раз я этим занимался много лет назад...

>>хорошим ресайзером
> Если бы они ещё были, без distort resize никуда. И поскольку это
> уже кодирование с потерями, нет никакого смысла оставлять lossless

Ну как бы в 600 dpi - могу себе представить что вот это уже довольно жирное. И если этого реально дофига - тогда я поверю что с этим что-то сделать хочется.

> - можно сразу перегонять в 90-150dpi. И, как правило, результат на экране при
> этом намного лучше, чем самый лучший уменьшенный вариант просмотрщика.

Тут такое соображение что из оригинала сделать 90-150dpi хорошим ресайзером опять же не проблема, а инфо в 300dpi все же останется больше чем в 90.