Комментарии 23
Идея хороша, но пример совсем плох. Может там вообще в видео редактор поставили фиксированный кадр и изредка изредка «тягали»? Покажите работу в динамике: с людьми, поездом, птицами. А то вдруг их тоже «стабилизирует»?
+3
а что за продукт?
+1
Почему бы не использовать уже существующие алгоритмы матчинга? берем motion estimation или тот же SURF, получаем сматченные точки, потом аппроксимируем аффинное или перспективное преобразование (с RANSAC для стабильности), применяем к картинке, вуаля. Я использовал ME + перспективное + RANSAC для более сложной задачи, все ок. Если нужно побыстрее — меняем SURF на FAST и получаем матчинг за единицы миллисекунд!
рекомендую к просмотру
www.youtube.com/watch?v=fYUDfD2nc0A
www.youtube.com/watch?v=QdXugkXBTbc
рекомендую к просмотру
www.youtube.com/watch?v=fYUDfD2nc0A
www.youtube.com/watch?v=QdXugkXBTbc
0
Ну так, а у меня и 1.5 миллисекунды, из которых поиск корреляционного максимума — 0.3 миллисекунды, а остальное компенсация ARGB изображения методом билинейной интерполяции.
+2
Зато по точкам можно будет компенсировать поворот + не только стационарную съемку. При этом укладываясь в realtime (25 FPS)
0
Предполагаю, что судя по описанному применению решения (системы видеонаблюдения) проблема тут не только в том что нужно укладываться в реалтайм, а в том что нужно укладываться в реалтайм на 32 одновременно обрабатываемых сервером каналах. Т.е. нужно выдавать 25 х 32 = 800 FPS на имеющихся мощностях.
Решения требующие 1 ядро на обработку одной камеры в системах видеонаблюдения будут неконкурентоспособны.
Решения требующие 1 ядро на обработку одной камеры в системах видеонаблюдения будут неконкурентоспособны.
0
Какая именно «метрика» корреляционной функции у вас применялась и каков размер «центральной части»? Максимальное смещение в роликах, похоже, не очень-то большое по отношению к размеру кадра?
0
В качестве корреляционной функции использовалась сумма абсолютных разностей точек изображений. Максимальное смещение — где-то четверть от высоты изображения.
0
Следовательно, центральная часть, которая сравнивается, примерно вполовину кадра?
0
Мне кажется, ваши последовательные масштабные преобразования то же самое, что производить градиентный спуск с переменным шагом. Интересное решение.
Если вычислять корреляцию не в 9 точках на каждом шаге, а в 5 (крестиком), то количество вычислений в вашем квадратике уменьшится с 36 до 25, что существенно быстрее
Если вычислять корреляцию не в 9 точках на каждом шаге, а в 5 (крестиком), то количество вычислений в вашем квадратике уменьшится с 36 до 25, что существенно быстрее
0
Градиентный спуск с переменным шагом надо делать над исходным изображением, а не над уменьшенным (правда это частично компенсируется необходимостью строить многомасштабные изображения). У многомасштабного изображения есть другой плюс — в процессе их построения происходит усреднение и сглаживание, что уменьшает вероятность попасть в ложный локальный максимум.
0
Удивился, когда не увидел в статье слова «БПФ»/«FFT».
0
Второе видео где вода течет, та часть которая с водой ровненько так встала в половину кадра с «оригиналом», ну а на половинке где стабилизированное изображение, воды с рябью нет. Крайне удобно выбран ракурс. Можете прогнать тот же алгоритм на том же видео, но теперь уже стабилизировать ту часть где вода. Хочется посмотреть что он сделает с рябью.
0
1) Стабилизация изображения в текущей реализации возможна только для стационарных камер.— если опорный кадр постоянно сдвигать на усредненное смещение, то высокочастотные дрожания компенсируются, а сканирование (или дрейф опорного кадра) будет отслеживаться, примерно так, правда, с некоторым запаздыванием, зависящим от степени усреднения
0
Прошелся по своим старым комментариям, заметил что Вы и в самом деле написали эту статью. =)
Спасибо Вам огромное.
Спасибо Вам огромное.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Цифровая стабилизация изображения со стационарных камер — корреляционный подход