Деинтерлейс

[antonn]

Есть у кого что по алгоритмам деинтерлейса?
имеется массив Tbitmap, строки в каждом чередуются полукадрами, нужно получить на выходе сглаженное изображение без гребенки, при этом производительность немаловажна.
Пока рисуют полностью первый кадр и при каждой анимации в этот же буфер дорисовываю черезстрочные полукадры. Ну попробывал слегка блендить соседнюю строку (та, что в текущем кадре не задействуется, т.к. рисовалась в предыдущем) вроде "поразмытие" стало, помягче. Но если блендить слабо эффект почти незаметен, если сильно - изображение будет прыгать, золотой середины не увидел
Кто что может порекомендовать? Пытался осилить деинтерлейс из pngimage - безрезультатно, наверное жара мешает

[antonn]

Пока придумал так, что буфер с нанесенными строками копирую в еще один буфер, увеличиваю его в 2 раза по вертикали "безкачественно", сдвигаю на пиксель вниз и уменьшаю обратно в 2 раза с пересчетом среднеарифметической суммы двух пикселей по вертикали. Получается гладко, но и мелкие детали сливаются

[x128]

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

[Pavia]

Цитата antonn @ 30.07.10, 18:50

чередуются полукадрами,

Говорят иногда не чередуются.
Самое простое это интерполяция берем полу кадр вот между строками вычисляем как среднее арифметическое верхнего и нижнего. и предыдущего следующего полукадра.

Более сложный алгоритм такой разбиваем изображение на блоки размером 8х8 или 16х16. сравниваем блоки с блоками полу кадром если совпали то копируем четные или нечетные строки.

Сравнивают с движением чтобы компенсировать движение камеры.

Там где блоки не совпали пробуют блоки меньшего размера 3x3. А где не совпали и эти то делают интерполяцию.

Вообщем как-то так я особо не вникал.

[antonn]

На вики я был, на компрессион.ру (или как там ресурс называется, подборка алгоритмов сжатия, но на англицком и в виде формул, я не переварил чтобы "по проще" =)) тоже был, там просто общие принципы.
Время обработки крайне важно, но само видео от 200*150 до 320*240, бОльшего не требуется (ну это пока).
Вообще скажу что просто пишу свой формат, состоит из последовательных блоков видео длительностью по 5-10 секунд. Первый кадр в блоке всегда полный, следующие кадры содержат полукадры черезстрочные (четные с 0-й строки, нечетные с 1-й), если последний кадр не имеет пары он тоже полный. При "воспроизведении" я "на руках" имею только предыдущий буфер который был выведен на экран и текущий (полный кадр или содержащий два полукадра). В текущий я просто наношу нужные строки и все. Можно конечно препредыдущий хранить, но вот следующий недоступен.
С компенсацией движения вообще атас, но это когда писал энкодер

Цитата

Более сложный алгоритм такой разбиваем изображение на блоки размером 8х8 или 16х16. сравниваем блоки с блоками полу кадром если совпали то копируем четные или нечетные строки.

Угу, я этого уже начитался до глюков Например, какое "изображение" нужно разбивать на блоки? В моем случае это текущий буфер? Изображение может быть очень "шумным" (точнее оно почти всегда "с шумом" из-за дизеринга)

Картинки для примера сейчас не могу выложить, если нужно - вечером скину. На ИХБТ попалась какая-то тема про сравнения алгоритмов деинтерлейса, красивые умные названия. Только вот я никак не соображу по какому алгоритму они работают и какие данные для них нужны

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

[Pavia]

antonn
Лично я бы руки оторвал тому кто придумал через строчную развертку. Поэтому вам не советую встраивать в свой формат.
А для разминки можно потренироваться. Тем более часто бывает такое. Я бы посмотрел исходники VLС плеера там есть фильтр "X" он с интерлейсингом борется хорошо, даже отлично. http://www.videolan.org/vlc/
Обычно на разрешениях 200*150 до 320*240 интерлейсинг не встречается.


По поводу полукадров. Как они уж там хранятся мне неинтересно в одном кадре 2 полу кадра или по о череде. Есть сплитер который разделяет полу кадры и выдает их целыми кадрами. Поэтому я называю полу кадры просто кадрами. Вот в таком кадре четные или нечетные строки заполнены черными пикселями.

Следующий кадр легко получить если сделать временную задержку.
Ничего не выводим просто запоминаем тот кадр что к нам поступил. И так пока не накопим 3.
Теперь будем работать со вторым кадром фактически первый будет предыдущим, третий будет как раз следующим.
Как только обработаем второй выводим его сдвигаем второй на место первого третий на место второго в третий записываем следующий кадр.

Больше чем 1 следующий кадр лучше не получать, для согласования фаз и другие проблемы есть. Хотя польза тоже есть.

По поводу формул. Это как с иероглифами просто надо запомнить что какая формула означает. Без подготовки тяжело.

Разбиваем на блоки два изображения. То которое выведено и тот полу кадр что обрабатываем. Полу кадр предварительно можно подвергнуть интерполяции между строк.
По поводу дизиринга. Тут от способа сравнения зависит, в принципе мешать не должен нч фильтер (blur матриц 3х3).
Правда хороший способ сравнения не найду. Как то работ мало.

[antonn]

Я сделал и с полным кадром, и с возможностью интерлейса. Пока с реализованным "АА-по вертикали" картинка поживее выглядит на "эффективных" 20fps, чем на "честных" 12fps, да и занимает меньше места. Но смазанее, пока это отталкивает, вот и ищу алгоритмы. Попытки бленда на 15-30% с соседними строками заканчивались "прыганием" кадра, это вроде как нормально в этом случае, видел в редакторах галку "дрожание" которая видимо и убирает этот эфект. Блюрить с разным шагом пробывал, размытие довольно сильно ощущается на тонких линиях, вообще четкость сильно страдает.
VCL попробую глянуть.

Материала действительно не много, в плане не голой теории, а практической реализации и применения.

Добавлено 31.07.10, 11:07
Да, требования к размеру для хранения еще жесче, чем для нагрузки на CPU

[x128]

Цитата Pavia @ 31.07.10, 10:40

Лично я бы руки оторвал тому кто придумал через строчную развертку.

Чересстрочная развертка пришла в цифру из аналога и связанно это с стандартами телевидения и устройством ЭЛТ. Цифровые видео форматы поддерживают такую возможность для совместимости с телевизионными стандартами.

Цитата antonn @ 31.07.10, 11:03

Пока с реализованным "АА-по вертикали" картинка поживее выглядит на "эффективных" 20fps, чем на "честных" 12fps

Для маленькой частоты кадров применение чересстрочной развертки бессмысленно, разве для хранения/передачи не сжатых кадров для экономии.

antonn, если ты пишешь свой кодер/декодер видео, лучше потратить усилия и процессорное время на более качественное кодирование чем на полумеры.

[Sapersky]

Мне тоже кажется, что создавать самому себе проблему с деинтерлейсом нет смысла.
Можно попробовать другую "телевизионную" фишку - перевод из RGB в YUV, т.е. яркость отдельно, цветность отдельно, цветность пишется с более низким разрешением. Хотя некоторое размытие тоже будет, из-за необходимости интерполировать цветность, но возможно меньше, чем с деинтерлейсом.

И кстати, я бы не стал сразу отказываться от готовых кодеков: http://www.free-codecs.com/
Я имею в виду относительно простые VFW-кодеки вроде Arithyuv или CamStudio Lossless. Даже если в конечном итоге будешь писать сам - можно попробовать скорость/качество разных методов (того же YUV), не тратя время на их реализацию.
Использование через VFW достаточно простое, в конечном итоге всё сводится к твоим любимым битмапам:
http://sapersky.narod.ru/files/AviHandler_VFW.rar

Ещё, я в своё время тестировал запись видео в играх наподобие Fraps - и самым лучшим по соотношению размер/скорость оказался банальный MJPG, т.е. последовательная запись кадров в Jpeg.

time size type
MJPG: 1900 650 lossy
CSCD (CamStudio lossless): 2420 1670 lossless
HFYV (HuffYUV): 2415 5370 lossy a bit
MSVC (станд. кодек Win): 2737 760 lossy

Хотя, возможно, для твоих картинок лучше подойдёт какой-то другой метод.

[Pavia]

Решил ссылку привести.
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_filter/deinterlace.c

[antonn]

Sapersky
Сначала у меня был формат с полным кадром, интерлейс попробывал в качестве опыта по уменьшению размера видеофайла, ну как бы "вкусно" выглядит размер почти в 2 раза меньше
Изображения в кадре с индексированной палитрой (оптимизированная и задизеринная), пиксель - byte. В кадре с двумя полукадрами палитра делится на два для каждого полукадра (по 128 цветов).
Пробовал я хранить только изменившиеся блоки (первый кадр полный, последующие только изменившиеся части), пробовал "оптимизировать" кадр заливая одним цветом неизменившуюся область (сжатие zlib'ом делаю), пробовал сделать компенсацию движения (впрочем это сильно громко сказано - "пробовал", я бы сказал что нифига не вышло, т.к. время поджимает, а разбираться там немало ). Пока интерлейс неплохо смотрится.
Запись "в реалтайме" вестись в этот формат не будет, запись я могу делать в mjpeg, от обсуждаемого "формата" требуется только компактное хранения, скорость вывода в буфер для последующих истязаний и чистота от различных патентов и зависимости от системных кодеков. Но пока по размеру на диске жрет оно прилично

[Pavia]

antonn
Я тебе прикол расскажу про патенты. Сейчас патент на MPEG2 подошел к концу(в 2010 должен закончится). А вот MPEG4 всё еще под патентом. А отличия там с гулькин нос.
1. Сделали поддержку более больших разрешений. Ну как сделали просто разрешили.
2. Сделали поддержку разбиения на более мелкие блоки.

Фактически ничтожные. Как только умудрились запатентовать не ясно.
А при этом они еще что-то хотят от свободных кодеков.
А также декодер MPEG4 стоит на $100 баксов дороже. В общем хотят урвать да побольше.


Вы бы видео выложила тогда можно будет подумать что сделать.

[Sapersky]

Цитата

Изображения в кадре с индексированной палитрой

Если картинки 8-битные - чем тогда GIF не угодил? Там всё уже есть, и палитра может быть индивидуальная для каждого кадра, и хранение только изменений по сравнению с предыдущим кадром (я, правда, не уверен что кодек сам может эти изменения определять - скорее всего нет, но может быть, есть "умные" редакторы?). И срок патентов уже истёк.
Ещё был такой специально заточенный под игры кодек - Smacker/SMK, морды-лица персонажей в Starcraft 1 им рисовались. В те времена был платным, не знаю как сейчас. Вроде бы уже устаревшая технология, могли бы забесплатно раздавать...
Ну и опять же MJpeg. По качеству, конечно, это дело вкуса, какие артефакты предпочесть, Jpeg-овские или от дизеринга. Но скорость, хотя это и кажется странным, у Jpeg зачастую выше чем у lossless-методов вроде zlib, во всяком случае при использовании IJL.

З.Ы. Впрочем, понятно, что альтернативы тебе не очень (или даже совсем не) нужны... ну может какие-то детали позаимствуешь для Своего Кодека

Сообщение отредактировано: Sapersky - 01.08.10, 19:46

[antonn]

Цитата

Если картинки 8-битные - чем тогда GIF не угодил?

Звук, произвольные размеры кадров, у каждого кадра своя палитра (у гифа такое может быть?), кадр может быть и 32 битный с альфой. Но самое главное что мне придется нефигово заморочиться с изучением чужих форматов, а это хоть и полезно, но время.
Да, ты прав, я не собираюсь брать готовое, особенно если оно похоже просто на контейнер и формат которые у меня есть свои, мне лишь надо было деинтерлейс смострячить (причем не отсебянину, а хотелось услышать как это делают "взрослые") Тестю пока, велосипедничаю, код с VCL я вроде бы где-то уже видел

Цитата

Но скорость, хотя это и кажется странным, у Jpeg зачастую выше чем у lossless-методов вроде zlib, во всяком случае при использовании IJL.

я там выше не зря говорил про блоки по 5-10 секунд длительностью. Используются два блока, первый рисуется, второй подгружается (и даже в собственном потоке =)), в "момент Х" они меняются местами Поэтому скорость выдирания кадра из файла на текущий момент не критична.

[Sapersky]

Цитата

Звук, произвольные размеры кадров, у каждого кадра своя палитра (у гифа такое может быть?)

Палитра - может, я уже писал. В комплекте с TGifImage есть утилита/пример GifExplorer, она показывает всю "подноготную", палитры и прочее.
Насчёт произвольных размеров не совсем понял - то ли макс. размеры (до 65535*65535), то ли разные по размеру кадры в одном видео (может быть).
Звук - нет, хотя теоретически, насколько я понял, можно делать свои расширения формата (прочие программы будут их просто пропускать).
http://home.onego.ru/~chiezo/gif.htm
Понятно, что не хочется заморачиваться с изучением "чужого" формата, с другой стороны, есть готовый код для загрузки/рендера + разные редакторы-утилиты.
Хотя, мне самому готовый код (смотрел KOLGif) не сильно понравился в своё время, наложение с прозрачным цветом через GDI - страшное дело. В результате пришлось изрядно повозиться, переписывая по-своему.