Obecnie pracuję i porównuję wydajność kilku detektorów funkcji udostępnianych przez OpenCV jako podstawę wizualnego dopasowania funkcji.
Używam deskryptorów SIFT . Osiągnąłem zadowalające dopasowanie (po odrzuceniu złych dopasowań) podczas wykrywania funkcji MSER i DoG (SIFT) .
Obecnie testuję mój kod za pomocą GFTT (Good Features to Track - Harris corners), aby uzyskać porównanie, a także dlatego, że w końcowej aplikacji zestaw funkcji GFTT będzie dostępny z procesu wizualnego śledzenia funkcji.
Używam, cv::FeatureDetector::detect(...)
co zapewnia mi std::vector<cv::KeyPoint>
pełen wykrytych funkcji / kluczowych punktów / regionów zainteresowania . Struktura cv::KeyPoint
zawiera podstawowe informacje na temat lokalizacji obiektu, jak również informacje na temat size
i octave
w którym został wykryty KeyPoint.
Moje pierwsze wyniki z GFTT były okropne, dopóki nie porównałem typowych size
i octave
parametrów w różnych typach funkcji:
- MSER ustawia rozmiar (od 10 do 40 pikseli) i pozostawia oktawę na 0
- DoG (SIFT) ustawia zarówno rozmiar, jak i oktawę ( stosunek wielkości do oktawy między 20 a 40)
- GFTT parametrami są zawsze : rozmiar = 3 , oktawa = 0
Zakładam, że dzieje się tak, ponieważ głównym celem funkcji GFTT nie było używanie w dopasowywaniu, a jedynie w śledzeniu. To tłumaczy niską jakość dopasowywania wyników, ponieważ deskryptory wyodrębnione z takich drobnych funkcji przestają być dyskryminujące i niezmienne dla wielu rzeczy , w tym małych przesunięć o 1 piksel.
Gdybym ręcznie ustawić size
z GFTT do 10 - 12 , mam dobre wyniki, bardzo podobne do przypadku korzystania MSER lub Dog (przesiać) .
Moje pytanie brzmi: czy istnieje lepszy sposób na określenie, o ile można zwiększyć size
(i / lub octave
), niż po prostu iść z 10-zobaczyć-jeśli-to-działa ? Chcę uniknąć size
podwyższenia na sztywno, jeśli to możliwe, i ustalić to programowo, ale twarde kodowanie jest w porządku, o ile mam solidne argumenty potwierdzające mój wybór nowego algorytmusize
/ size
zwiększenia / size
oszacowania .