Como estimar a oitava e o tamanho dos recursos visuais posicionados nos cantos de Harris

Atualmente, estou trabalhando e comparando o desempenho de vários detectores de recursos fornecidos pelo OpenCV como base para a correspondência visual de recursos.

Eu estou usando descritores SIFT . Consegui uma correspondência satisfatória (após rejeitar correspondências incorretas) ao detectar os recursos MSER e DoG (SIFT) .

Atualmente, estou testando meu código com o GFTT (Bons recursos para rastrear - cantos de Harris) para obter uma comparação e também porque na aplicação final, um conjunto de recursos do GFTT estará disponível no processo de rastreamento de recursos visuais.

Estou usando o cv::FeatureDetector::detect(...)que me fornece um std::vector<cv::KeyPoint>preenchido com os recursos / pontos-chave / regiões de interesse detectados . A estrutura cv::KeyPointcontém informações básicas sobre a localização do recurso, bem como informações sobre sizee octaveem que o ponto-chave foi detectado.

Meus primeiros resultados com o GFTT foram terríveis até comparar os parâmetros sizee típicos octaveem diferentes tipos de recursos:

• MSER define o tamanho (entre 10 e 40 px) e deixa a oitava em 0
• DoG (SIFT) define o tamanho e a oitava ( proporção tamanho / oitava entre 20 e 40)
• GFTT os parâmetros são sempre : tamanho = 3 , oitava = 0

Presumo que isso ocorra porque o objetivo principal dos recursos GFTT não era para ser usado na correspondência, mas apenas no rastreamento. Isso explica a baixa qualidade dos resultados da correspondência, uma vez que os descritores extraídos desses recursos minúsculos deixam de ser discriminatórios e invariantes para muitas coisas , incluindo pequenas mudanças de 1 pixel.

Se eu definir manualmente a sizede GFTT de 10-12 , eu obter bons resultados, muito semelhantes ao usar MSER ou cão (SIFT) .

Minha pergunta é: existe uma maneira melhor de determinar quanto aumentar o size(e / ou octave) do que apenas ir-com-10-ver-se-funciona ? Quero evitar a codificação do sizeaumento, se possível, e determiná-lo programaticamente, mas a codificação está correta , desde que eu tenha argumentos sólidos para fazer backup das minhas escolhas do novo algoritmosize / sizeaumentar / sizeestimar .

Não tenho certeza de que haja realmente uma boa resposta à sua pergunta precisa: o espaço de escala do SIFT e do SURF foi realmente desenvolvido para estimar automaticamente o "bom" tamanho relevante da vizinhança em torno de um ponto-chave em forma de esquina (que são as boas características rastrear são).

Agora, respostas mais positivas seriam:

• crie um banco de dados de pontos-chave e boas correspondências (por exemplo, usando padrões de calibração quadrados) e crie uma avaliação de desempenho automatizada nesse banco de dados para encontrar o tamanho correto. Essa tarefa pode realmente ser automatizada (consulte o trabalho de Mikolajczyk e Schmid sobre a avaliação de correspondência de pontos)

• incorpore seus bons recursos em uma pirâmide de imagens para também ter algum tipo de escala associada a eles. Você pode procurar referências em pontos de interesse FAST e Harris em várias escalas, que fazem algo muito semelhante a este procedimento.

Para encontrar heuristicamente o tamanho máximo do bloco, você pode calcular estimativas de suas imagens com um desfoque de caixa (que é mais ou menos o que o operador blockSize faz) e ver quando o canto desaparece. Observe, no entanto, que mais desfoque afasta o canto da sua verdadeira localização.

Se você está realmente procurando alguma solução rápida e suja, tente tamanhos entre 5x5 e 11x11 (tamanhos típicos usados ​​na correspondência de blocos estéreo). Se você estiver procurando por um critério intelectualmente satisfatório, tente maximizar a probabilidade de uma boa correspondência de dois pontos de recurso abaixo do seu nível de ruído.

Para ajudar a determinar os melhores parâmetros para os detectores, o OpenCV possui o AjusterAdapter para esse fim. Eu nunca o usei, mas provavelmente é a maneira padrão de determinar programaticamente os parâmetros. Lembre-se também de que, embora os Keypoints tenham várias propriedades, nem todos fazem sentido para todos os algoritmos. Como a estrutura Keypoint é usada para algoritmos diferentes, ela possui todos esses campos, mas às vezes eles não são usados, é por isso que você obtém essas oitavas = 0; IMO.