Mve: Conjunto de dados Fountain_p11

Então a maneira como você descreveu parece boa -- você cria uma cena com o script e executa featurerecon . O script, no entanto, é para Middlebury e não para conjuntos de dados Strecha. Você pode ter que adaptá-lo um pouco.

• Você pode dar uma olhada no arquivo meta.ini e comparar com os parâmetros do Strecha?
• Antes de executar featurerecon , você pode inspecionar a cena com o UMVE?

Bem, porque no Strecha font_p11 contém apenas 11 imagens eu criei manualmente um font_par.txt , então acho que o script Middelbury funcionará bem e o meta.ini. estão corretos o _umve_ funciona bem também se executado antes do _featurerecon_ ele mostra câmeras com rotações estranhas quando eu executo o _featurerecon_ eu recebo apenas 1000 e algo ponto formando cone como forma. verifique a imagem abaixo

Além disso, se você notou que Strecha fornece em seu conjunto de dados 2 arquivos camera que contém K , R , T. e outro arquivo chamado P que contém a matriz de projeção se eu calcular p = K*[R|t] eu recebo uma matriz semelhante a aquele no arquivo P com um golpe de imagem de verificação de coluna diferente.

este conjunto de dados está me incomodando como as pessoas o usaram para validar coisas

É difícil ver pela imagem o que está errado. Se você obtiver recursos em forma de cone, alguns dos parâmetros da câmera provavelmente estão errados. Pode ser as câmeras são invertidas? Sua matemática na segunda captura de tela parece errada para mim. O RT não deveria ter todos os zeros na última linha, com um no canto inferior direito?

a matemática está correta de acordo com o modelo de câmera pinhole R é 3x3 t é 3x1 ek é 3x3 por que eu deveria aumentar RT por linha. quero dizer, você pode aumentar a projeção p se quiser fazer alguma transformação homogênea.
Também acabei de verificar na net e descobri que Strecha calcula sua projeção P assim: p = k * [R^T |-R^T t]
o "^T" significa transpor, mas eu não entendo isso.
voltando ao problema:
font_par.txt aqui está o arquivo que você pode tentar executar script e featurerecon nele mesmo se tiver tempo. eu acho que os parâmetros da câmera fornecidos no conjunto de dados estão errados ou não são compatíveis com MVE e SMVS

Talvez alguém da equipe tenha tempo para investigar isso, eu não. @nmoehrle , @flanggut?

Obrigada. também descobri que todos os conjuntos de dados Strecha, mesmo os novos aqui: https://cvlab.epfl.ch/data/strechamvs também não funcionam, então esse papel a suposição de que o parâmetro da câmera está errado e me leva a acreditar que o chão os parâmetros da câmera de verdade não são compatíveis com MVE e SMVS

Por favor, poste um de seus arquivos meta.ini aqui.

Quando olho para a captura de tela do UMVE, posso ver que as rotações estão incorretas, as visualizações devem formar um arco olhando para o centro. Quando experimentei o strecha, eu tinha meus próprios scripts de conversão e, como eles são escritos em python, não tentei integrá-los ao MVE. Você pode me mostrar o script que você usou para converter os parâmetros da câmera ou fornecer um link?

Meu melhor palpite é que você não converteu a posição da câmera (c armazenada nos arquivos da câmera strecha) na tradução (t = -R * c). Além disso, acho que houve alguma estranheza com os arquivos da câmera strecha, a matriz da câmera está na linha principal e a matriz de rotação está na coluna principal ou, se preferir, a matriz de rotação transposta é armazenada (R^t).

@simonfuhrmann aqui o meta-arquivo
meta.txt
@nmoehrle bem, usei isso: https://github.com/simonfuhrmann/mve/wiki/Middlebury-Datasets para obter os parâmetros da câmera.
e sim, eu não (t = -R * c) então eu pensei que Strecha lhe dá o vetor de tradução t o que me confundiu é que Stesha no arquivo leia-me dizer p = k * [R^T |-R^T t ] se ele acabou de substituir t por c -_- . vou tentar usar esta informação e ver o que dá

Este script não pode analisar os arquivos .camera do benchmark strecha, ele apenas lê o formato dos parâmetros da câmera middlebury, uma única linha que se parece com isso:
"imgname.png k11 k12 k13 k21 k22 k23 k31 k32 k33 r11 r12 r13 r21 r22 r23 r31 r32 r33 t1 t2 t3" .

Os arquivos .camera têm uma estrutura totalmente diferente:

|Linha|Conteúdo|
|------|-|
| 1-3 | Matriz K |
| 4 | desconhecido |
| 5-7 | R^t |
| 8 | c |
| 9 | largura altura |

@nmoehrle sim sim estou ciente de que criei manualmente um arquivo font_par.txt de .camera para 11 imagem (com preguiça de escrever meu próprio analisador) a única coisa que não considerei é (t = -R * c) i usado c dado em .camera como t. vou corrigir isso depois e posto os resultados

@nmoehrle bem, acho que o problema foi resolvido graças a você

Sim, é assim que me lembro :-)