Как оценить октаву и размер для визуальных элементов, расположенных в углах Харриса


9

В настоящее время я работаю и сравниваю производительность нескольких детекторов функций, предоставляемых 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оценки .


1
Эй, Пенелопа: посмотрите эту ссылку, этот парень уже проделал хорошую работу. [ Computer-vision-talks.com/2011/08/…

@Sistu Эй, это похоже на очень хорошее общее сравнение дескрипторов в общем случае и с плоским объектом, но я работаю над определенными видами изображений, и мне нужно сделать свой собственный тест. Кроме того, вопрос был гораздо более конкретным, чем «мне нужны справочные материалы, сравнивающие производительность различных типов расшифровщиков». Это хорошая ссылка, проверим.
Пенелопа

Ответы:


4

Я не уверен, что на самом деле есть хороший ответ на ваш точный вопрос: масштабируемость SIFT и SURF была фактически разработана для автоматической оценки «хорошего» релевантного размера окрестности вокруг угловой точки (что является хорошими функциями отслеживать есть).

Теперь более положительные ответы будут:

  • создать базу данных ключевых точек и хороших совпадений (например, используя квадратные калибровочные шаблоны) и создать автоматическую оценку производительности в этой базе данных, чтобы найти правильный размер. Эта задача действительно может быть автоматизирована (см. Работу Миколайчика и Шмида об оценке соответствия точек)

  • встраивайте свои хорошие функции в пирамиду изображений, чтобы иметь с ними некоторый масштаб. Вы можете найти ссылки на многомасштабные точки интереса FAST и Harris, которые делают нечто очень похожее на эту процедуру.

Чтобы эвристически определить максимальный размер блока, вы можете вычислить оценки ваших изображений с размытым изображением (что более или менее соответствует оператору blockSize) и посмотреть, когда исчезает угол. Обратите внимание, однако, что больше размытия отводит угол от его истинного местоположения.

Если вы действительно ищете быстрое и грязное исправление, попробуйте размеры от 5x5 до 11x11 (типичные размеры, используемые при подборе стереоблоков). Если вы ищете интеллектуально удовлетворяющий критерий, то постарайтесь максимально увеличить вероятность хорошего соответствия двух характерных точек под вашим уровнем шума.


Я искал решение, которое было бы немного более быстрым и грязным, чем то, что вы предлагаете. Кроме того, я могу определить, является ли совпадение хорошим или плохим только после того, как мои ключевые точки извлечены и сопоставлены с чем-то. Даже если я сопоставляю их совершенно случайно, я получаю несколько хороших совпадений - поэтому ваше первое предложение не очень полезно. Что касается второй части, более быстрой и грязной: я знаю, что нет идеального параметра, но, как я уже сказал, увеличение размера до 12 помогло - качество было сопоставимо с сопоставлением SIFT и MSER. У меня просто нет аргументов, чтобы выбрать 12 из 100 или более 34 ...
Пенелопа

0

Чтобы помочь вам определить наилучшие параметры для детекторов, для этой цели в OpenCV есть AjusterAdapter . Я никогда не использовал его сам, но это, вероятно, стандартный способ программного определения параметров. Также имейте в виду, что хотя ключевые точки имеют несколько свойств, не все имеют смысл для всех алгоритмов. Поскольку структура Keypoint используется для разных алгоритмов, в ней есть все эти поля, но иногда они не используются, поэтому вы получаете те октавы = 0; ИМО.


Я знаю , что некоторые типы особенностей не лучший тип для некоторых целей иногда, но недавние работы пытаются подходы , где они используют более 1 типа v.features / процентных регионах и достичь лучших результатов с комбинацией чем с любым одним типом самостоятельно (могу добавить ссылки на работы, если вам интересно). Кроме того, то, что я делаю, - это, по крайней мере, частичное исследование, поэтому я должен делать попытку и оценивать результаты, достигнутые с различными типами ключевых точек, даже если некоторые из этих результатов не так хороши, как состояние дел. Изобразительное искусство. Я посмотрю в AdjusterAdapter, спасибо.
Пенелопа

Я только что просмотрел функцию интерфейса. Он может только увеличивать или уменьшать количество функций, обнаруживаемых детектором. Кроме того, у меня нет проблем с обнаруженными функциями. Я просто хотел бы откорректировать их размер, чтобы их можно было лучше использовать при сопоставлении (увеличение размера до 10 делает это, но у меня нет конкретной (достаточной) аргументации для этого выбора)
Пенелопа
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.