SURF и SIFT Алгоритм отслеживания альтернативных объектов для дополненной реальности

Question

После запроса здесь и попытки SURF и SIFT, ни один из них не будет достаточно эффективным, чтобы генерировать точки интереса достаточно быстро для отслеживания потока с камеры.

Например, SURF требуется около 3 секунд для создания точек интереса для изображения, это слишком медленно для отслеживания видео, поступающего с веб-камеры, и будет еще хуже при использовании его на мобильном телефоне.

Мне просто нужен алгоритм, который отслеживает определенную область, ее масштаб, наклон и т. Д., И я могу построить поверх этого.

Спасибо

Answer 1

Я подозреваю, что ваше использование SURF может нуждаться в некоторых изменениях?

Вот ссылка на статью MIT об использовании SURF для приложений дополненной реальности на мобильных устройствах.

Выдержка:

В этом разделе мы представляем наши реализация алгоритма SURF и его адаптация к мобильному Телефон. Далее мы обсудим влияние эта точность влияет на скорость поиск ближайшего соседа и показать, что мы можем достичь порядка ускорить с минимальным воздействием на точность соответствия. Наконец, мы проконсультируйтесь по телефону реализация сопоставления изображений трубопровод. Мы изучаем производительность, использование памяти и потребление полосы пропускания по телефону.

Возможно, вы захотите взглянуть на алгоритмы OpenCV, потому что они проверены и протестированы.

В зависимости от ограничений вашего приложения вы можете уменьшить универсальность этих алгоритмов для поиска известных POI и маркеров в изображении.

Часть отслеживания POI оценивает свой вектор из одной точки в 2D-изображении в другую, а затем при необходимости подтверждает, что он все еще существует там (через характеристики пикселей). Тот же подход можно использовать для отслеживания (не повторного сканирования всего изображения) POI и POI, группы / объекта, перспективы и изменений поворота.

В Интернете есть тонны бумаг для отслеживания объектов в 2D-проекции (во многих случаях до нескольких перекосов).

Удачи!

Answer 2

Вы должны попробовать БЫСТРЫЙ детектор

http://svr -www.eng.cam.ac.uk / ~ er258 / работа / fast.html

Answer 3

Мы используем SURF для проекта, и мы нашли OpenSURF , чтобы превзойти реализацию SURF в OpenCV по сырой скорости и производительности. Мы еще не проверяли повторяемость и точность, но это намного быстрее.

---

Обновление: Я просто хотел отметить, что вам не нужно выполнять шаг соответствия SURF в каждом кадре, вы можете просто сделать это для каждого второго кадра и интерполировать положение объекта в кадре, для которого вы не выполняете SURF.

Answer 4

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

Если вам нужен (несколько) универсальный трекер, вы можете проверить PTAM. Сайт (http://www.robots.ox.ac.uk/~gk/PTAM/) в настоящее время недоступен, но вот шикарное видео о том, как он работает на iPhone (http://www.youtube.com/watch?v=pBI5HwitBX4)

Answer 5

Один вариант, который я использовал в встраиваемых системах с ограничениями, - это использование более простого детектора точек интереса: например, FAST или Shi-Tomasi. Я использовал Shi-Tomasi, так как нацеливался на FPGA и мог легко запускать ее с частотой пикселей без значительной буферизации.

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

Answer 6

Я нашел это хорошее сравнение алгоритмов обнаружения каждой функции на http://computer -vision-talks.com / 2011/01 / сравнение-opencvs-Feature-обнаружения-алгоритмов-2 /

Посмотрите. Это может быть полезно!

В соответствии с этим сравнением, и, как и предполагал mirror2image, FAST является лучшим выбором. Но это зависит от того, чего вы действительно хотите достичь.

Answer 7

Как уже упоминалось, три секунды кажутся необычно длинными. При тестировании реализации SURF в библиотеке Mahotas я обнаружил, что на это уходит в среднем 0,36 с, даже с некоторыми довольно большими изображениями (например, 1024x768). И это со смесью Python и C, поэтому я представляю, что некоторые другие реализации на чистом C будут еще быстрее.