Deshaker для VirtualDub, стабилизатор изображения. Опции

[Longin]

Кто работает с Deshaker для VirtualDub, отзовитесь!
Считается, что это самый лучший программный стабилизатор из всех. У кого какая информация по нему есть?

[Longin]

Кто работает с Deshaker для VirtualDub, отзовитесь!
Считается, что это самый лучший программный стабилизатор из всех. У кого какая информация по нему есть?

[GeorgyVIDEO]

Тонкая настройка

Расписанные выше установки достаточно хорошо работают в обычной ситуации, когда видео снято с одной точки, трансфокатор (zoom) установлен не на минимум, и в кадре не присутствуют объекты значительных размеров, двигающиеся в разных направлениях. Если вам кажется, что стабилизация недостаточна, можно увеличить значения параметров Motion smoothness на втором проходе. Я использовал величины до 18000. Однако это имеет и негативную сторону: при слишком больших значениях, если исходное изображение было достаточно дёрганым, на краях полученного кадра могут возникать странные явления. Это результат работы алгоритма edge compensation, т.е. заполнения нехватающих участков по краям данными из соседних кадров. Если в кадрах были движущиеся объекты вблизи краёв изображения, то подстановка участков из соседних кадров будет давать несоответствующее текущему кадру положение этих объектов относительно фона. Как правило, эти "плывущие" края не будут видны на телевизоре, т.к. на нём края изображения обрезаются (приблизительно 5%, так называемый overscan). Однако, если вы предполагаете смотреть видео на мониторе, то можно применить дополнительное увеличение центральной части кадра (Extra zoom factor установить чуть больше единицы, например, 1.05 или 1.1). Нужно понимать, что при этом мы несколько теряем в разрешении, т.к. некоторая область кадра растягивается на весь кадр.

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

Если, несмотря на повышение параметров плавности, видео всё равно дёргается, то, вероятнее всего, это вызвано неправильным определение движения на первом проходе. К примеру, если вы ведёте камеру вслед за большим движущимся объектом, то алгоритм поиска движения не сможет корректно отделить движущийся фон от движущегося в другом направлении объекта, который занимает значительную часть кадра. Вектора движения блоков будут направлены в разные стороны, и в зависимости от того, каких оказалось больше, движение всего кадра будет определяться то по фону, то по объекту. Разумеется, при попытке стабилизировать полученный видеоряд мы увидим дёргание картинки.

Чтобы исправить положение, нужно явным образом указать программе, какая часть кадра движется за счёт движения камеры (т.е. является фоном, и именно его движение чаще всего надо стабилизировать), а какая - сама по себе. Для этого в Deshaker имеется семейство параметров Ignore image area. Чтобы исключить из рассмотрения объект в середине кадра, установите параметры в строке inside: к примеру, вы хотите оставить только верхнюю и нижнюю четверти экрана, введите 144 (=высота кадра/4) в поля Top и Bottom. Возможна ситуация, когда, наоборот, нужно рассматривать только центральную часть кадра, тогда задайте значения в строке outside. Эту область легко контролировать при просмотре первого прохода: игнорируемая область закрашивается чёрным. Нужно, однако, следить за тем, чтобы в оставшейся части кадра было достаточно блоков с определяемыми векторами движения. Возможно, следует уменьшить размер блока, задаваемый параметром Block size (по умолчанию 30), только при этом ещё нужно установить Use pixels=All(most robust).

Если вы снимаете движущейся камерой, такое видео гораздо труднее поддаётся стабилизации (разумеется, это представляет сложность не только для Deshaker'а, но и для любого другого подобного программного стабилизатора). Тем не менее, Deshaker достаточно хорошо работает и в этом случае. В таких ситуациях может помочь параметр “Discard Motion of Blocks That Move >x Pixels in the Wrong Direction”, который управляет отбраковкой блоков, движущихся не в том направлении. Можно попробовать поднять его значение с 5 до, скажем, 15 или даже 30. Действие этого параметра видно на первом проходе: в случае нетривиального движения камеры блоки в кадре могут двигаться в самых различных направлениях. Красные вектора движения обозначают блоки, которые двигаются не в том направлении, что большинство блоков (а именно, вектор движения блока отличается как раз на x пикселей от среднего вектора движения для этой области кадра). По-хорошему, красные стрелки должны быть как раз у тех блоков, которые действительно принадлежат движущимся объектам в кадре, а те области, движение которых вызвано движением самой камеры, должны иметь белые вектора, в этом случае движение камеры определяется достаточно уверенно. Этот параметр и призван в какой-то степени управлять отбраковкой ненужного движения. Кстати, в обычном случае достаточно плавного движения автор фильтра рекомендует уменьшить этот параметр до 1 (на мой взгляд, довольно спорно).

Параметры из группы “Ignore Image Area” также могут использоваться в случае движения камеры: например, если вы снимаете пейзаж из окна автомобиля, то в нижней части кадра, вероятно, ннаходятся быстро движущиеся объекты ближнего плана, а в верхней - практически неподвижный дальний план, и можно пытаться привязываться именно к нему.
Также можно попытаться поиграть параметром “Discard motion of blocks that have match value <...”: попробуйте увеличить его с 300 до 500 или 600. Если не поможет, попробуйте уменьшить до 100-150.. Этот параметр вместе со следующим (Discard blocks that have 2nd best match > best-...) управляет отбраковкой блоков в малоконтрастных участках изображения. Уменьшая их, вы увеличиваете количество блоков с определяемым движением, но при этом в таких малоконтрастных областях (небо, облака, или даже поверхность воды) движения блоков могут определяться некорректно. Впрочем, неправильно определённые вектора движения отбрасываются параметром ...move > pixels in wrong direction. По собственному опыту, если в кадре слишком мало определённых блоков, то стоит уменьшать два вышеназванных параметра, чтобы увеличить их число (особенно если блоков настолько мало, что Deshaker не считает возможным достоверно определить по ним движение всего кадра. Это происходит, если их меньше 5% (по умолчанию; регулируется параметром Skip frame if <x% of blocks are OK), при этом на первом проходе строка статуса красная. В этом случае обязательно надо попытаться уменьшить "критичность" детектора движения для блоков, хотя можно и уменьшить порог отбрасывания всего кадра, иначе почти наверняка в этом месте возникнет скачок в полученном видео. Хотя если переборщить с параметрами, то случайные движения малоконтрастных блоков внесут большие помехи в результирующее движение кадра.

В конце концов, ничто не мешает разные куски клипа обрабатывать с разными установками (например, если движущийся объект, который нужно проигнорировать, находится то в левой, то в правой частях кадра), а полученные LOG-файлы склеить в обычном текстовом редакторе. Если же отдельные кадры никак не поддаются разумному определению движения, то самый простой вариант - исправить для них значения в LOG-файле руками. Например, задать такими же, как у соседнего кадра. В каждой строке LOG-файла содержится информация об одном кадре или (для чересстрочного видео) об одном поле: смещение по X, по Y, поворот и увеличение.