Mve: Набор данных Fountain_p11

Итак, то, как вы это описали, звучит хорошо — вы создаете сцену со сценарием и запускаете featurerecon . Скрипт, однако, предназначен для Миддлбери, а не для наборов данных Strecha. Возможно, вам придется немного адаптировать его.

• Можете сами глянуть файл meta.ini и сравнить с параметрами из Стречи?
• Перед запуском featurerecon можете ли вы проверить сцену с помощью UMVE?

Что ж, поскольку в Strecha Fountain_p11 содержится только 11 изображений, я вручную создал Fountain_par.txt, поэтому я думаю, что сценарий Мидделбери будет работать нормально и мета.ini. верны, _umve_ запускается нормально, также, если запускать его до _featurerecon_, он показывает камеры со странным вращением, когда я запускаю _featurerecon_, я получаю только 1000 и что-то вроде точки, образующей конусообразную форму. проверьте изображение ниже

Кроме того, если вы заметили, что Стреча дает в своем наборе данных 2 файла камеры, которые содержат K, R, T. и еще один файл с именем P, который содержит матрицу проекции, если взять, я вычисляю p = K * [R | t], я получаю матрицу, похожую на тот, что в файле P с одним столбцом, отличается от контрольного изображения.

этот набор данных беспокоит меня, как люди использовали его для проверки вещей

По картинке сложно понять, что не так. Если вы получаете объекты в форме конуса, возможно, некоторые параметры камеры неверны. Может камеры перевернуты? Ваша математика на втором скриншоте кажется мне неправильной. Разве RT не должен иметь все нули в последней строке с единицей в правом нижнем углу?

математика верна в соответствии с моделью камеры-обскуры R 3x3 t 3x1 и k 3x3, почему я должен увеличивать RT построчно. я имею в виду, что вы можете увеличить проекцию p, если хотите сделать однородное преобразование.
Также я только что проверил в сети и обнаружил, что Стреча вычисляет свою проекцию P следующим образом: p = k * [R^T |-R^T t]
«^T» означает транспонирование, но я этого не понимаю.
вернемся к проблеме:
Fountain_par.txt - это файл, который вы можете попробовать запустить самостоятельно, если у вас есть время. я думаю, что параметры камеры, указанные в наборе данных, неверны или они несовместимы с MVE и SMVS

Может быть, у кого-то из команды есть время разобраться в этом, а у меня нет. @nmoehrle , @flanggut?

Спасибо. также я обнаружил, что все наборы данных Strecha, даже новые здесь: https://cvlab.epfl.ch/data/strechamvs тоже не работают, поэтому эта роль предполагает, что параметры камеры неверны, и заставляет меня поверить, что земля правда параметры камеры почему-то не совместимы с MVE и SMVS

Пожалуйста, разместите один из ваших файлов meta.ini здесь.

Когда я смотрю на скриншот UMVE, я вижу, что вращения неверны, виды должны образовывать дугу, обращенную к центру. Когда я экспериментировал со strecha, у меня были собственные скрипты конвертации, и, поскольку они написаны на питоне, я не пытался интегрировать их в MVE. Можете ли вы показать мне скрипт, который вы использовали для преобразования параметров камеры, или дать ссылку?

Насколько я понимаю, вы не преобразовали положение камеры (c, хранящееся в файлах камеры strecha) в перевод (t = -R * c). Далее я думаю, что была какая-то странность с файлами камеры strecha, матрица камеры находится в главном ряду, а матрица вращения - в главном столбце, или, если хотите, хранится транспонированная матрица вращения (R^t).

@simonfuhrmann вот метафайл
мета.txt
@nmoehrle хорошо, я использовал это: https://github.com/simonfuhrmann/mve/wiki/Middlebury-Datasets , чтобы получить параметры камеры.
и да, я этого не сделал (t = -R * c), поэтому я подумал, что Стреха дает вам вектор перевода t, что меня смутило, так это то, что Стеша в файле readme говорит p = k * [R ^ T | ] если он просто заменил t на c -_- . я постараюсь использовать эту информацию и посмотреть, что она дает

Этот скрипт не может анализировать файлы .camera бенчмарка strecha, он просто считывает формат параметров камеры middlebury, одну строку, которая выглядит следующим образом:
"imgname.png k11 k12 k13 k21 k22 k23 k31 k32 k33 r11 r12 r13 r21 r22 r23 r31 r32 r33 t1 t2 t3" .

Файлы .camera имеют совершенно другую структуру:

|Строка|Содержание|
|------|-|
| 1-3 | К-матрица |
| 4 | неизвестно |
| 5-7 | Р^т |
| 8 | с |
| 9 | ширина высота |

@nmoehrle yes yes я знаю, что я вручную создал файл Fountain_par.txt из .camera для 11 изображений (лень писать свой собственный синтаксический анализатор), единственное, что я не учел, это (t = -R * c) я использовал c, указанный в .camera, как t. я исправлю это позже и опубликую результаты

@nmoehrle хорошо, я думаю, что проблема решена, спасибо вам

Да, я это помню :-)