Comments 15
Метод Ransac называется. Как правило работает :) и ограничение на 90 градусов -просто неудачно выбранный matching алгоритм
Не очень понятно, как матчинг алгоритм может влиять на наше ограничение в 90 градусов, т.к. мы получили все точки: сифта, серфа, орб, все они есть. Матчинг алгоритм единственное, где может дать осечку — это создать фолсы. Но у нас фолсов нет, мы их чистим, и чистим точно хорошо.
Ransac же, насколько я понимаю, используется только в поиске матрицы Гомографии.
Что скажете?
Ransac же, насколько я понимаю, используется только в поиске матрицы Гомографии.
Что скажете?
как матчинг алгоритм может влиять на наше ограничение в 90 градусов
Элемента там три: детектор, атрибуты и матчер.
Mатчинг алгоритм как и детектор может быть чувствителен к повороту, а может и нет.
Смотрите шире. OpenCV не единственная в мире.
Но у нас фолсов нет, мы их чистим, и чистим точно хорошо
???
Вы описали RANSAC c отсебятиной. Есть критерий соответствия точек хомографии(2 Homography (3x3) и 3d Homography (4x4) ). RANSAC дает матрицу удовлетворяющую большинству точек. Это и дает Вам одну из rigid (не знаю русский термин) систем координат. Можете повторить и найти еще несколько(если они есть). Все… Все остальное
Я понял. Вам нужна не гомография (проекция плоскости), а я имел в ввиду гомографию в более широком смысле чем в openCV. Вам нужна fundamental matrix.
Именно она определяет соответствия между проекциями точек rigid системы координат. Ее и ищите ransac-ом.
Именно она определяет соответствия между проекциями точек rigid системы координат. Ее и ищите ransac-ом.
И всё же… Не могли бы вы пояснить свою мысль про использование фундаментальной матрицы при работе с одной камерой, как в нашем случае?
У вас есть как минимум два фрейма с одной камеры, которые вы и сравниваете.
Допустим что камера переместилась между ними. Теперь координаты особых точек на проекции от неподвижных объектов будут связаны фундаментальной матрицей.
Допустим что камера переместилась между ними. Теперь координаты особых точек на проекции от неподвижных объектов будут связаны фундаментальной матрицей.
В общем… Поресерчили ваш совет на досуге (действительно интересно). Для фильтрации точек с движущихся объектов фундаментальная матрица отрабатывает лучше. Но фильтрует точки она так же, как и в нашем подходе, — не полностью. Всё ещё остаются точки, лежащие на неподвижных объектах. А ограничение на 90 градусов, даже если бы фильтрация и получилась идеальной, все равно бы оставалось (т.к. при переходе отметки в 90 градусов, движение переходит в другую плоскость).
Делать же матчинг точек с помощью фундаментальной матрицы не представляется возможным, т.к. для того, чтобы ее найти необходимо УЖЕ имееть точки, которые между собой заматчены.
Поэтому, либо мы друг друга не до конца поняли, либо будем продолжать ресерч, и в следующих версиях нашего компонента вы увидите что-то подобное.
Делать же матчинг точек с помощью фундаментальной матрицы не представляется возможным, т.к. для того, чтобы ее найти необходимо УЖЕ имееть точки, которые между собой заматчены.
Поэтому, либо мы друг друга не до конца поняли, либо будем продолжать ресерч, и в следующих версиях нашего компонента вы увидите что-то подобное.
необходимо УЖЕ имееть точки
Читать RANSAC. Точки сначала матчатся вероятностно, а потом фильтруются ранзаком.
Посмотрите как это работает в SLAM.
Вот например 8 лет назад, программа моя, жена тоже моя :)
www.youtube.com/watch?v=-6V---caG9k
Или тут у меня примерно с кодом
habr.com/ru/post/336494
Впрочем можете выбрать и другие алгоритмы. Но все равно лучше идти с мейнстримом
ПС Собственно я не использую фундаментальную матрицу, я сразу восстанавливаю облако точек и позицию камер итеративно, но Вам будет проще именно с ней.
Насколько можно понять, чтобы создать на базе вышеописанного ещё один постой и удобный стабилизатор видео реал-тайм, пригодный для встраивания в Андроид-камеры, до всего этого ещё очень далеко, верно?
Если кратко: да, верно :)
Если подробнее: задача у нас стояла более глобальная — неподвижная система координат. А под стабилизацию, которая будет охватывать все виды движения, можно переделывать этот компонент.
Если подробнее: задача у нас стояла более глобальная — неподвижная система координат. А под стабилизацию, которая будет охватывать все виды движения, можно переделывать этот компонент.
Для встраивания в камеру проще — не надо анализировать так видео, есть данные с гироскопа и датчика ускорения.
И это тоже, спасибо.
данные с гироскопа и датчика ускорения.Странно… Я полагал, что существующие стабилизаторы действуют только лишь за счёт очень быстрого анализа самой картинки (точнее, множества связанных картинок), без привлечения физических датчиков. Это мнение сложилось после прочтения популярной статьи «Вычислительная фотография», в которой описываются современные алгоритмы анализа изображений, и те эффекты, которые можно получить на основе этих алгоритмов. Применение физических датчиков в этой статье вообще не упоминается — как мне кажется, потому, что эти датчики не могут обеспечить требуемой точности (порядка одного пикселя). А алгоритмы это могут, за счёт огромной вычислительной мощности на борту аппарата.
Когда данные с матрицы получены, то особо и поздно что-то стабилизировать, при низком освещении будет сильно мылиться картинка, падать резкость.
Как раз наоборот, когда, получены данные с матрицы (несколько десятков малосовпадающих и не совпадающих фреймов, сколько память позволит) — вот тогда и начинается настоящая работа (и не только насчёт стабилизации). Вы почитайте статью «Вычислительная фотография», это не просто интересно — это увлекательно!
Sign up to leave a comment.
Стабилизация видео с движущейся камеры, или как перевести всё в неподвижную систему координат