В настоящее время я работаю и сравниваю производительность нескольких детекторов функций, предоставляемых OpenCV, в качестве основы для визуального соответствия функций.
Я использую SIFT дескрипторы. Я выполнил удовлетворительное сопоставление (после отклонения неверных совпадений) при обнаружении функций MSER и DoG (SIFT) .
В настоящее время я тестирую свой код с помощью GFTT («Хорошие возможности для отслеживания - углы Харриса»), чтобы получить сравнение, а также потому, что в окончательной заявке набор функций GFTT будет доступен в процессе визуального отслеживания функций.
Я использую cv::FeatureDetector::detect(...)который предоставляет мне std::vector<cv::KeyPoint>заполненные обнаруженные функции / ключевые точки / области интереса . Структура cv::KeyPointсодержит основную информацию о местоположении описываемого объекта, а также информацию о sizeи octaveв котором Keypoint было обнаружено.
Мои первые результаты с GFTT были ужасны , пока я не сравнивал типичные sizeи octaveпараметры в различных типах функций:
- MSER устанавливает размер (от 10 до 40 пикселей) и оставляет октаву равной 0
- DoG (SIFT) устанавливает размер и октаву ( соотношение размер / октава между 20 и 40)
- GFTT параметры всегда : размер = 3 , октава = 0
Я предполагаю, что это потому, что основная цель функций GFTT состояла не в сопоставлении, а только в отслеживании. Это объясняет низкое качество результатов сопоставления, поскольку дескрипторы, извлеченные из таких крошечных функций, перестают быть дискриминационными и инвариантными ко многим вещам , включая небольшие сдвиги в 1 пиксель.
Если я вручную установлю sizeдля GFTT значение 10–12 , я получу хорошие результаты, очень похожие на те, которые используются при использовании MSER или DoG (SIFT) .
У меня вопрос: есть ли лучший способ определить, на сколько увеличить size(и / или octave), чем просто пойти с 10-смотри, если это работает ? Я хочу избежать жесткого кодирования sizeувеличения, если это возможно, и определить его программно, но с жестким кодированием все в порядке, пока у меня есть веские аргументы, подтверждающие мой выбор нового алгоритмаsize / sizeувеличения / sizeоценки .
источник
Ответы:
Я не уверен, что на самом деле есть хороший ответ на ваш точный вопрос: масштабируемость SIFT и SURF была фактически разработана для автоматической оценки «хорошего» релевантного размера окрестности вокруг угловой точки (что является хорошими функциями отслеживать есть).
Теперь более положительные ответы будут:
создать базу данных ключевых точек и хороших совпадений (например, используя квадратные калибровочные шаблоны) и создать автоматическую оценку производительности в этой базе данных, чтобы найти правильный размер. Эта задача действительно может быть автоматизирована (см. Работу Миколайчика и Шмида об оценке соответствия точек)
встраивайте свои хорошие функции в пирамиду изображений, чтобы иметь с ними некоторый масштаб. Вы можете найти ссылки на многомасштабные точки интереса FAST и Harris, которые делают нечто очень похожее на эту процедуру.
Чтобы эвристически определить максимальный размер блока, вы можете вычислить оценки ваших изображений с размытым изображением (что более или менее соответствует оператору blockSize) и посмотреть, когда исчезает угол. Обратите внимание, однако, что больше размытия отводит угол от его истинного местоположения.
Если вы действительно ищете быстрое и грязное исправление, попробуйте размеры от 5x5 до 11x11 (типичные размеры, используемые при подборе стереоблоков). Если вы ищете интеллектуально удовлетворяющий критерий, то постарайтесь максимально увеличить вероятность хорошего соответствия двух характерных точек под вашим уровнем шума.
источник
Чтобы помочь вам определить наилучшие параметры для детекторов, для этой цели в OpenCV есть AjusterAdapter . Я никогда не использовал его сам, но это, вероятно, стандартный способ программного определения параметров. Также имейте в виду, что хотя ключевые точки имеют несколько свойств, не все имеют смысл для всех алгоритмов. Поскольку структура Keypoint используется для разных алгоритмов, в ней есть все эти поля, но иногда они не используются, поэтому вы получаете те октавы = 0; ИМО.
источник