> Ох ты ж, не сравнивай, куда тебя понесло?Так это не я полез JPG с PNG сравнивать.
> JPEG, очевидно, к тому, что в нём Хаффман заменяется на арифметическое кодирование
> одной вышеупомянутой командой. Если ты хотел сказать "результаты сравнения Хаффмана и
> арифметика в JPEG никак нельзя переносить на lossless-картинки, потому что...", то
> ты этого не сказал.
А вы неплохи в чтении мыслей. ИМХО потому что JPG и PNG деланы под радикально разный контент и сценарии использования EntropyCoder. PNG намного ближе к "обычному архиватору" в этом плане и в архиверах разница от замены хаффмана на арифметика считанные проценты.
> В JPEG они слишком легко сравниваются, уж извините,
В любом случае - это прикольная находка, спасибо.
> а препарированием PNG для замены Хаффмана мы оба не занимались, во FLIF тоже не лезли.
Я изучал более-менее generic компрессоры которые от PNG не так уж отличаются и что там арифметики могут видел. Единственное крупное отличие PNG от архивера - префильтры. Современные архиверы впрочем умеют в префильтры и сами порой, а арифметик как EC из фавора выпал. Потому что тормоз, а со временем придумали ряд способов которые не патентованы и лучше работают. Наиболее свежее на тему - выводки ANS (asymmetric numeral system). Сочетает скорость хаффмана и сжатие арифметика. За что и юзается в НОВЫХ компрессорах.
>> курьез "насколько можно сжать, если долбануться?!"
> Зато математика долгоживучая - пример хороший, сферичность в вакууме его не портит.
Скорее программирование. К данным подшит по сути анпакер в формате виртуальной машины как я понимаю. По своему забавно, но единственная практическая ценность - несколько маньяков сделали убер-сжатие близкое к теоретическим лимитам. Но жмет пару кило в час и что хуже, распаковывает тоже, и рам жрет.
> Зачем писать "в честном lossless они png обычно не так уж и сильно обставляют",
Под честным lossless имеется в виду кодирование того что удобно для PNG. Всякие фоточки и проч - PNG для них и не создан. На lineart LZ может конеретно развернуться и взять свое. А если основное отыгрывается энтропией и преобразованиями, PNG туда никогда и не метил. Он "замена гиф".
> явно не поняли"? Одна таблица по ссылке. Оптимизированный PNG получился на
> 46% больше, чем JXL. В 2020 году, на солидном датасете.
Остается вопрос какие цели датасет преследовал. Ну и с практической точки зрения - да, PNG точно можно улучшить. Он старый. Зато...
1) Жрется вообще всем от чуть ли не с IE6, позволяет полноцветные картинки, и проч.
2) Не так уж и плохо жмет, если юзать по назначению. Т.е. схемы, графики, скрины программ, вот это все.
3) На его основе сделан APNG. Он жмет анимахи лучше GIF. И имеет забойнейший плюс: вот там реально обратная совместимость. Декодеры которые не знают про APNG - покажут первый фрейм который является валидным статичным PNG. И юзеры хоть что-то увидят. А не как вон там - это MP4, но у вас он играться не бу, дескать, что бардак и лулзы создает.
А так бандвиз от картинок напрягает только сильно некоторые сайты. Это ж не видео где даже пара мувиков может создать боль если на него юзеров набежит.
> Патенты истекли, для чтения стандарта жипега даже к itu.int
Ну так мышиная возня экспертов исы и сместилась куда-то в другие варианты. Может закончиться тем что все пробурчат что "раз AV1 везде есть, поюзаем AVIF, код уже есть!" и исовские эксперты надеящиеся подпихнуть чего-то патентованого опять обломятся.
> Не, про ситуацию с поддержкой. С первой ссылкой я промахнулся - это
> AV2, а багтрекер aom (AV1) не пролил свет на --use-16bit-internal в
> aomenc, в rav1e аналога, как видно, ещё нет, SVT-AV1 пока остаётся за кадром.
Я у себя просто нарулил билд ffmpeg с x264/x265/libaom/libvpx и еще немного, все из перечисленного гитовых версий. Как билдить Н.Е.Х. на хрусте и интерфейсить их либу в кастомную локацию узнает кто-нибудь другой. У SVT1 дурные требования к хардвару и приоритеты, откровенно обслуживает интересы интела. Libaom хорошо жмет и девелопается сбалансировано, без неинтересных мне загонов "под последний интелский проц" или "фигня, зато на хрусте". Так что если эти штуки вам интересны и вы понимаете почему - вот и изучите что они могут. Мне оказался интереснее libaom по общему набору свойств, я его и изучил. А чтобы составить мнение как это vs 264/265 я взял последние версии одних из наиболее мощных кодеков, x264 вообще чуть ли не лучшая реализация 264 считается, да и x265 явно не хучший как референс. Ну и VP9 логично взять как того кто серьезно сел на пятки 265. Тем более что я умею VP9 кодировать "выше среднего", что делает его интересным "референсом" на тему "насколько я этот уровень побью?".
> То есть ты делаешь так: ffmpeg [-i in.mkv]* -pix_fmt yuv420p10le -c:v libaom-av1
> out.mkv и получаешь на выходе 8 бит? Это невозможно.
Упс, я перепроверил - таки выход формально апгрейдится. А вот откуда я взял что он так и останется LBD - вот это вопрос.
> просто кодируешь 10-битное видео и что-то себе придумываешь про high/low bit
> depth. Ты ни разу в MediaInfo/ffprobe закодированного файла не смотрел?
Да вот почему-то отложилось что в ffprobe видел идентичные для файлов выводы. А нифига, пишет про 10le для второго. А за дотошность спасибо, очень круто когда кто-то разбирается в топике - и снабжен скепсисом и перепроверяет. Я так тоже проверил ваши (?) слова про arith vs jpg :P. У меня вышло 8..11%, поменьше чем у вас, но тоже неплохо так то.
> * Ниже предлагал вместо этого генерировать видео ради воспроизводимости у нас: [-f
> lavfi -i mandelbrot=s=2000x2000 -vframes 1]
Я ради воспроизводимости юзаю нежатые RAW последовательности от Xiph, они более похожи на real world сценарии. И не испорчены чужими артефактами, любой новый артефакт как на ладони. Потому что метрики это круто, но финальный судья - зритель.
В BigBuckBunny например есть пара сложных для кодеков мест: начальный fade in и титры. В первом они норовят сартефачить, ибо деликатный плавный темноватый градиент - мерзко смотрится в стопкадре если отличается от идеала. И с 8-битным процессингом он в AV1 грубоват даже если бандвиза хватает и проч. А форсирование 10le - совсем другая история. И титры в конце - нехило стресстестят motion compensation а заодно - и к каким артефактам может привести. Ну или TOS3K - 3000 нежатых фреймов Tears Of Steel, там и фильмообразный контент и sci-fi. Эти кадры не зависят от декодеров, постпроцессинга, .... и похожи на обычный нормальный контент. Чем и интересны.
Более того - я сравнивал сугубо 2-проходное кодирование. Тупо потому что извините, но 1-проходным я не пользуюсь почти. Мне не интересны сценарии далекие от того чем я потом буду пользоваться для себя. Если я трачу время - я должен поиметь с этого какой-то измеримый бонус для себя, а не просто изучение всей мыслимой фигни на планете как энтомолог.
> - на входе энкодера 10 бит (HBD) из-за yuv420p10le
> - повышение разрядности уже произошло из-за yuv420p10le
> - на выходе HBD - на входе HBD, почему ты не замечаешь?
Да, я все же прогнал что выход как HBD не маркируется. Но реально лучше выглядит даже LBD, допустим тот же BBB из yuv420p (y4m, укачан, по моему, с xiph.org). Особенно вон тот градиент в начале.
С LBD пайпом AV1 может казать любые цифры, обставляя в кривых вон тех, в целом визуальное качество лучше. Но! Если на начальном fade in нас встречает в стопкадре дискретизация градиента, это обидно. И радости с офигенных метрик вот так - сильно меньше. Метрики метриками, А глаза глазами. А с вон тем - и файло меньше (даром что "HBD") и - вот - последняя претензия к качеству картинки испарилась. После этого я уже не знаю что ему предъявить, так что можно просто взять и насладиться кодированием вместо этого :)
Справедливости ради это все же computer-generated эффект, хоть и LBD, и в многих иных мувиках такое может и не встретиться. И все же. Если знать что искать... а я знаю. И квадратики. И дискретизацию. И мыло. И красный испохабленый 420, ...
