Comments 23
Идея хороша, но пример совсем плох. Может там вообще в видео редактор поставили фиксированный кадр и изредка изредка «тягали»? Покажите работу в динамике: с людьми, поездом, птицами. А то вдруг их тоже «стабилизирует»?
а что за продукт?
Почему бы не использовать уже существующие алгоритмы матчинга? берем 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
Ну так, а у меня и 1.5 миллисекунды, из которых поиск корреляционного максимума — 0.3 миллисекунды, а остальное компенсация ARGB изображения методом билинейной интерполяции.
Зато по точкам можно будет компенсировать поворот + не только стационарную съемку. При этом укладываясь в realtime (25 FPS)
Предполагаю, что судя по описанному применению решения (системы видеонаблюдения) проблема тут не только в том что нужно укладываться в реалтайм, а в том что нужно укладываться в реалтайм на 32 одновременно обрабатываемых сервером каналах. Т.е. нужно выдавать 25 х 32 = 800 FPS на имеющихся мощностях.
Решения требующие 1 ядро на обработку одной камеры в системах видеонаблюдения будут неконкурентоспособны.
Решения требующие 1 ядро на обработку одной камеры в системах видеонаблюдения будут неконкурентоспособны.
Какая именно «метрика» корреляционной функции у вас применялась и каков размер «центральной части»? Максимальное смещение в роликах, похоже, не очень-то большое по отношению к размеру кадра?
Мне кажется, ваши последовательные масштабные преобразования то же самое, что производить градиентный спуск с переменным шагом. Интересное решение.
Если вычислять корреляцию не в 9 точках на каждом шаге, а в 5 (крестиком), то количество вычислений в вашем квадратике уменьшится с 36 до 25, что существенно быстрее
Если вычислять корреляцию не в 9 точках на каждом шаге, а в 5 (крестиком), то количество вычислений в вашем квадратике уменьшится с 36 до 25, что существенно быстрее
Градиентный спуск с переменным шагом надо делать над исходным изображением, а не над уменьшенным (правда это частично компенсируется необходимостью строить многомасштабные изображения). У многомасштабного изображения есть другой плюс — в процессе их построения происходит усреднение и сглаживание, что уменьшает вероятность попасть в ложный локальный максимум.
Удивился, когда не увидел в статье слова «БПФ»/«FFT».
Второе видео где вода течет, та часть которая с водой ровненько так встала в половину кадра с «оригиналом», ну а на половинке где стабилизированное изображение, воды с рябью нет. Крайне удобно выбран ракурс. Можете прогнать тот же алгоритм на том же видео, но теперь уже стабилизировать ту часть где вода. Хочется посмотреть что он сделает с рябью.
1) Стабилизация изображения в текущей реализации возможна только для стационарных камер.— если опорный кадр постоянно сдвигать на усредненное смещение, то высокочастотные дрожания компенсируются, а сканирование (или дрейф опорного кадра) будет отслеживаться, примерно так, правда, с некоторым запаздыванием, зависящим от степени усреднения
Прошелся по своим старым комментариям, заметил что Вы и в самом деле написали эту статью. =)
Спасибо Вам огромное.
Спасибо Вам огромное.
Sign up to leave a comment.
Цифровая стабилизация изображения со стационарных камер — корреляционный подход