Mve: Conjunto de datos Fountain_p11

Entonces, la forma en que lo describiste suena bien: creas una escena con el guión y ejecutas featurerecon . El guión, sin embargo, es para Middlebury y no para los conjuntos de datos de Strecha. Puede que tengas que adaptarlo un poco.

• ¿Puede echar un vistazo al archivo meta.ini usted mismo y compararlo con los parámetros de Strecha?
• Antes de ejecutar featurerecon , ¿puede inspeccionar la escena con UMVE?

Bueno, debido a que Strecha fountain_p11 contiene solo 11 imágenes, creé manualmente un fountain_par.txt , así que creo que el script de Middelbury funcionará bien y meta.ini. son correctos, _umve_ funciona bien también si lo ejecuta antes de _featurerecon_ muestra cámaras con rotaciones extrañas cuando ejecuto _featurerecon_ obtengo solo 1000 y algo que forma un punto con forma de cono. mira la imagen de abajo

Además, si notó que Strecha proporciona en su conjunto de datos 2 archivos de cámara que contienen K , R , T. y otro archivo llamado P que contiene la matriz de proyección si tomo calculo p = K*[R|t] obtengo una matriz similar a el que está en el archivo P con una columna diferente, golpe de imagen de verificación.

este conjunto de datos me está molestando, ¿cómo lo usó la gente para validar cosas?

Es difícil ver en la imagen lo que está mal. Si obtiene funciones en forma de cono, es probable que algunos de los parámetros de la cámara sean incorrectos. ¿Puede ser que las cámaras estén invertidas? Tus matemáticas en la segunda captura de pantalla me parecen incorrectas. ¿No debería RT tener todos ceros en la última fila, con un uno en la esquina inferior derecha?

las matemáticas son correctas según el modelo de cámara estenopeica R es 3x3 t es 3x1 yk es 3x3 ¿por qué debería aumentar RT por fila? Quiero decir que puedes aumentar la proyección p si quieres hacer una transformación homogénea.
También acabo de comprobar en la red y descubrí que Strecha calcula su proyección P así: p = k * [R^T |-R^T t]
el "^T" significa transponer pero no entiendo esto.
de vuelta al problema:
fountain_par.txt aquí está el archivo que puede intentar ejecutar script y featurerecon en él mismo si tiene tiempo. creo que los parámetros de la cámara proporcionados en el conjunto de datos son incorrectos o no son compatibles con MVE y SMVS

Tal vez alguien en el equipo tenga tiempo para investigar esto, yo no. @nmoehrle , @flanggut?

Gracias. También descubrí que todos los conjuntos de datos de Strecha, incluso los nuevos aquí: https://cvlab.epfl.ch/data/strechamvs tampoco funcionan, por lo que este rol supone que los parámetros de la cámara son incorrectos y me llevan a creer que el terreno Los parámetros de la cámara de verdad de alguna manera no son compatibles con MVE y SMVS.

Publique uno de sus archivos meta.ini aquí.

Cuando miro la captura de pantalla de UMVE puedo ver que las rotaciones son incorrectas, se supone que las vistas forman un arco mirando hacia el centro. Cuando experimenté con strecha, tenía mis propios scripts de conversión y, dado que están escritos en python, no intenté integrarlos en MVE. ¿Puede mostrarme el script que usó para convertir los parámetros de la cámara o dar un enlace?

Mi mejor suposición es que no convirtió la posición de la cámara (c almacenada en los archivos de la cámara strecha) en la traducción (t = -R * c). Además, creo que hubo alguna rareza con los archivos de la cámara strecha, la matriz de la cámara está en la fila principal y la matriz de rotación está en la columna principal, o si lo desea, la matriz de rotación transpuesta está almacenada (R^t).

@simonfuhrmann aquí el metaarchivo
meta.txt
@nmoehrle bueno, usé esto: https://github.com/simonfuhrmann/mve/wiki/Middlebury-Datasets para obtener los parámetros de la cámara.
y sí, no lo hice (t = -R * c) así que pensé que Strecha te da el vector de traducción t lo que me confundió es que Stesha en el archivo Léame dice p = k * [R^T |-R^T t ] si simplemente reemplazó t por c -_- . Trataré de usar esta información y veré lo que da.

Este script no puede analizar los archivos .camera del punto de referencia de strecha, solo lee el formato de parámetros de la cámara de Middlebury, una sola línea que se ve así:
"imgname.png k11 k12 k13 k21 k22 k23 k31 k32 k33 r11 r12 r13 r21 r22 r23 r31 r32 r33 t1 t2 t3" .

Los archivos .camera tienen una estructura completamente diferente:

|Línea|Contenido|
|------|-|
| 1-3 | matriz K |
| 4 | desconocido |
| 5-7 | R^t |
| 8 | do |
| 9 | ancho alto |

@nmoehrle sí, sí, soy consciente de que creé manualmente un archivo fuente_par.txt desde .camera para 11 imágenes (perezoso para escribir mi propio analizador) lo único que no consideré es (t = -R * c) i usó c dado en .camera como t. arreglaré esto más tarde y publicaré los resultados

@nmoehrle bueno, creo que el problema se resolvió gracias a ti

Sí, así es como lo recuerdo :-)