> ты собираешься сэмплинг делать не поблочный,а чохом картинку? Поблочно, но учитывая существование соседей.
> Ну, все в принципе, здорово (как раз вейвлетное преобразование отлично работает
> в варианте 320x200, а больше для "VHS" не надо)
Оно не только там нормально работает, Dirac британские броадкастеры делали для качественного HD и выше, под броадкастерские нужды. Но сейчас все хотят лить видео через инет, надо хорошую картинку при минимальном битрейте. Там Dirac звезд не хватает, больше всего работ в этом направлении досталось VP9. Ну и AV1 по наследству.
Кстати в Daala придумали фокус с блоками, lapped transform сделан так что блочность не образуется. Скрины с злой степенью сжатия очень убедительные.
> - только вот как ты тут собрался transform обнаружить и закодировать?
В смысле - обнаружить? Блок обычно кодируют пытаясь минимизировать размер закодированного при минимуме отличий от оригинала, если время позволяет. Детали выбранной конкретики transform кодер передает декодеру в битовом потоке. Я к тому что при кодировании блока можно попытаться целенаправленно минимизировать различия по границам с соседями, как дополнительный критерий. Но может подраться с минимизацией размера. Lapped transform выглядит логичнее - лучше результат и не выглядит как костыль.
> А если нет - тогда это mpng какой-то получаетсо, с соответствующими затратами
> на кодирование и размером на выходе.
По ощущениям это прапрадедушка идей lapped transform-а, только кривее. Я не Монти :)
> это вынужденная мера - для transform. для mjpeg ты размер блока можешь
> произвольно выбрать (правда, опять же, ничем не прочитается, ну и хрен
> с ним), у него траснформа нету.
Радость от произвольного размера блока умеренная. Позволяет лучше адаптироваться к характеру картинки, но лишь до некоторых пределов.
> квадратики, они не (только) от этого (на фото-jpeg'ах никаких квадратиков нет, обычное
> ровное мыло)
Мыло оно наверное только если вьюшка сделала постпроцессинг. Иначе это скорее "ступеньки". И прочий ringing на резких границах.
> мне что-то подсказывает, что на зашумленных аналоговым мусором картинках оно плохо работает.
Шум и DCT карму портит. Высокачастотная составляющая, случайная. И на нее или придется извести море битов для правдоподобного кодирования, или сильно смешается с остальным, все испортится и получится характерная жуть. Я не возьмусь убрать сильный шум из фото если по нему jpeg-ом прошлись. В видео можно потрепыхаться третьим измерением.
> том, что он по задумке работает с уже разок закодированным блочным
> transform-кодеком, поэтому вроде бы не за что и бороться.
Если до нас уже был кодек - пусть декодер делает loop filter, чтоли. Без этого есть шанс что границы блоков не состыкуются, поскольку decision making кодека может не совпасть. Кодировать чужой артефакт как фичу картинки явно фэйловая идея. Надо море битов извести чтобы сохранить... артефакт?! Кодек же не знает что это не фича картинки. А так то картинка лучше чем была не станет, кто бы сомневался.
> header) не жует, падает с sigsegv. до примерно 2010го года жевал,
> а потом что-то "оптимизировали".
Если бы это было у меня, я бы глянул gdb'ом что там да и пнул причастных. Дел на 10 минут.
> Файлы, как ты понимаешь, сильно старше и ни разу не менялись. Да, vhc.
> Нет, это нельзя съездить и переснять, этого места больше нет.
Да я понимаю. У меня тоже есть ряд таких цифровых артефактов, которые хрен переснимешь, но все-таки в более разумных форматах.
