> Я их по косточкам не разбирал.Оно и видно: png и jpg имеют мало общего, сравнить их может только дилетант. Png это по сути как .bmp.gz. Массив пикселей сжатый zlib (deflate). Правда есть фильтры. Но это битмап. Хорошо работает с чем-то типа скриншотов, схем, line-art и прочего computer-generated и т.п.. - где есть повторяющиеся области. А для фоток - сжатие маргинальное. Распаковка - бит в бит с оригиналом.
А JPG делался для фоток и real world. Другой класс алго. Использует DCT, загрубляет коэффициенты, потом энтропию кодит, за счет чего и жмет. С потерями как правило. Для line art и проч не подходит - засирает резкие переходы артефактами DCT, оно пытается грубо говоря представить все как градиент. С контрастными линиями работает фигово. Сравнивать их? А они для разного! К каждый хорош (или плох) по своему. У википедиков даже от таких гениев есть плашка "No Jpegs" - с перечеркнутым срачем джыпега на lineart.
> Но что тогда ещё такого наворотили во FLIF?
А вот его я в деталях не смотрел, увы. Еще кстати AVIF есть. AVIF to AV1 is what WEBP to VP8, I-frame от AV1 грубо говоря. Предсказуемо мощнее жыпега. Но и его я в деталях не смотрел, сжатие картинок мне менее интересно.
> Исходный коммент звучал так, словно в H.264 есть свой Тьюринг-полный язык, как
> в ZPAQ. Вот это была бы защита от устаревания.
Как показал его пример, результат получается специфичным, тормозным и не имеет хождение кроме как курьез "насколько можно сжать, если долбануться?!". Кроме того - по сути выполнять ремотный код, хоть и VM не есть безопасно как показали хардварные вулны.
>> в вот именно честном lossless они png обычно не так уж и сильно обставляют.
> Не знаю, что такое нечестный lossless,
Честный = bit-identical битмап на выходе, разумеется. Работа в режиме "архиватора". Если результат бит в бит, это лосслес. Иначе как максимум "visually lossless".
> но между JXL и PNG - пропасть. Её исследовали тут:
> https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_.../
Покорно благодарю но я не буду читать ред-байду с кучей JS. Извините. Моя ремарка лишь к тому что вы явно не поняли что JPG и PNG - разные классы технологий, для разного.
> На гигантской выборке из одной картинки jpegtran -arithmetic говорит, что 13%.
Из одной картинки? А в чем прикол? Попробовал на разных. Получил 8..11%. Не так уж плохо, но и не groundbreaking чтобы лизать кому-то пятки.
Меня вообще фирма RadGameTools хорошо отучила от кр00тых проприетарных форматов. Я как-то перегнал несколько мувиков в Bink и стер оригинал. Агаблин, нюанс в том что играется оно только их убогим плеером, распаковка в другие форматы не предусмотрено, так что бесплатный сыр от пропертариев оказался мышеловкой. И только САБЖ и сильно опосля решил мою проблему Get Data Back!
>> Зато в AV1 можно провернуть фокус когда на выходе таки LBD стрим
>> но процессинг делается в HBD
> На выходе декодера? Выглядит как украшательство, чтобы сообщить о разрядности исходника.
Это encoder-only трюк. Он выдаст LBD стрим на выход если вход LBD. Но внутрях при обработке заюзает HBD-path. Который, конечно, медленнее. Зато точнее. Пойнт в том что ошибки округления и дискретизации не будут портить картинку. Обычно малозаметно, но в плавных градиентах, особенно темных, ошибки дискретизации и округления могут стать видны "на глаз".
Характерный пример: BigBuckBunny - начальный fade in. Или любое что на это похоже, плавный градиент, особенно темноватый, бывает и в real world и в синтетике. В HBD-path AV1 это точнее отпроцессит, даже если и оформит выход как обычный поток. В метриках сильно не видно - но на глаз отсутствие "лестниц" и "дискретности" в градиенте приятнее. Как бонус - предикторы из-за отсутствия ошибок округления еще более точно угадывают - меньше данных ошибки передавать. И файло в итоге меньше, порой процентов на 10 при том же Q. Получается забавный парадокс: и визуально лучше - и меньше файло. Но, увы, ценой +30-40% к времени кодирования, HBD path by design медленнее, более широкая математика, больше данных летает.
> Чтобы повышение разрядности выглядело более официально, а не как хак.
Там нет повышения разрядности, конечно. Снижение ошибок от дискретности математики и округлений. Чтобы на выходе HBD был - вход должен быть HBD. А парадокс в том и состоит что от HBD-path выигрывает даже LBD контент. Этот эффект обнаружен и обоснован гурами с Doom9.
> Аналог вот этого?
Я vvenc не интересуюсь, так что ничего не скажу по его фичам. Получить "то же самое но обвешаное патентами и не играемое в вебе" мне малоинтересно.
> Что там вообще происходит?
Если вопрос про вон то - просто форсирование обсчета как HBD контента в LBD. Я думаю мы все можем согласиться что LBD - частный случай HBD, не так ли? И поэтому его можно отпроцессить HBD codepath. С понятной потерей перфоманса, ведь разрядности больше и данных прибавилось.
> https://gitlab.com/AOMediaCodec/avm/-/issues/26
> https://github.com/xiph/rav1e/pull/2746
Похоже на то. Для ffmpeg+libaom трюк делается так: -pix_fmt yuv420p10le. Формат выходного потока останется LBD/YUV 4:2:0 но это не помешает ему быть визуально лучше и в q-mode еще и меньше по весу из-за улучшения предсказаний.
Кто хочет может закодить с этим и без - и сравнить. Ожидаемый результтат в q-mode: кодирование на 30-40% медленнее но файло до 10% меньше и визуально лучше в ряде мест типа вот таких градиентов.
