Як оцінити октаву та розмір за візуальними особливостями, розміщеними в кутах Харріса

В даний час я працюю і порівнюю продуктивність декількох функціональних детекторів, які надає OpenCV як основу для візуального зіставлення функцій.

Я використовую дескриптори SIFT . Я виявив задовільну відповідність (після відхилення поганих збігів) під час виявлення особливостей MSER та DoG (SIFT) .

В даний час я тестую свій код за допомогою GFTT (Good Features to Track - Harris Corners) для порівняння, а також тому, що в остаточному застосуванні набір функцій GFTT буде доступний у процесі візуального відстеження функцій.

Я використовую, cv::FeatureDetector::detect(...)що дає мені std::vector<cv::KeyPoint>заповнені виявлені функції / ключові точки / регіони, що цікавлять . Структура cv::KeyPointмістить основну інформацію про місце розташування функції, а також інформацію про sizeта octaveв якій виявлено ключову точку.

Мої перші результати з 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 . Я ніколи його не використовував, але це, мабуть, стандартний спосіб програмного визначення параметрів. Також пам’ятайте, що хоча Keypoints має кілька властивостей, не всі мають сенс для всіх алгоритмів. Оскільки структура Keypoint використовується для різних алгоритмів, вона має всі ці поля, але іноді вони не використовуються, тому ви отримуєте ці октави = 0; ІМО.