Hallo
Also wollte ich Fountain_p11 mithilfe der Ground-Truth-Kamerakalibrierung rekonstruieren, also habe ich das midelbury.sh-Skript verwendet, um die Szene zu erstellen, und dann Featurerecon verwendet. und es scheint, dass die Ground-Truth-Kamera nicht korrekt ist. Ich habe es sogar mit smvs verwendet und es hat nicht funktioniert. Ich habe auch versucht, das Ground-Truth-Modell mit der Ground-Truth-Kamera (mit meinem eigenen Code, der mit anderen Szenen gut funktioniert) neu zu fotografieren, und es hat nicht funktioniert. kann mir bitte jemand sagen, wie man den Sretcha-Datensatz richtig verwendet
BEARBEITEN:
Es scheint, dass die Parameter der Ground Truth-Kamera korrekt sind, da ich sie mit pmvs-2 verwendet habe und sie einwandfrei funktioniert hat. das ist wier
Die Art und Weise, wie Sie es beschrieben haben, klingt also gut – Sie erstellen eine Szene mit dem Skript und führen featurerecon
aus. Das Skript ist jedoch für Middlebury und nicht für Strecha-Datensätze. Eventuell musst du es ein wenig anpassen.
meta.ini
selbst anschauen und mit den Parametern von Strecha vergleichen?featurerecon
ausführen?Nun, weil in Strecha Fountain_p11 nur 11 Bilder enthält, habe ich manuell eine Fountain_par.txt erstellt, also denke ich, dass das Middelbury-Skript gut laufen wird und meta.ini. sind richtig, die _umve_ laufen gut, auch wenn sie vor _featurerecon_ laufen, zeigt es Kameras mit seltsamen Rotationen, wenn ich _featurerecon_ starte, bekomme ich nur 1000 und etwas punktförmiges, das eine kegelförmige Form bildet. Überprüfen Sie das Bild unten
Auch wenn Sie bemerkt haben, dass Strecha in seinem Datensatz 2 Dateien Kamera gibt, die K , R , T enthält. und eine andere Datei namens P, die die Projektionsmatrix enthält, wenn ich p = K*[R | t] berechne, bekomme ich eine ähnliche Matrix die in der P-Datei mit einer Spalte abweichende Check-Image-Blow.
Dieser Datensatz nervt mich, wie Leute ihn benutzt haben, um Dinge zu validieren
Auf dem Bild ist schwer zu erkennen, was falsch ist. Wenn Sie Merkmale in einer kegelförmigen Form erhalten, sind wahrscheinlich einige der Kameraparameter falsch. Kann es sein, dass die Kameras vertauscht sind? Ihre Mathematik im zweiten Screenshot sieht für mich falsch aus. Sollte RT nicht alle Nullen in der letzten Zeile haben, mit einer Eins in der unteren rechten Ecke?
Die Mathematik ist laut Lochkameramodell korrekt. R ist 3x3, t ist 3x1 und k ist 3x3, warum sollte ich RT zeilenweise erweitern. Ich meine, Sie können die Projektion p erweitern, wenn Sie eine homogene Transformation durchführen möchten.
Ich habe auch gerade im Netz nachgesehen und herausgefunden, dass Strecha seine Projektion P wie folgt berechnet: p = k * [R^T |-R^T t]
das "^T" bedeutet transponieren, aber ich verstehe das nicht.
zurück zum problem:
Fountain_par.txt hier ist die Datei, die Sie selbst ausprobieren können, wenn Sie Zeit haben. Ich denke, die im Datensatz angegebenen Kameraparameter sind falsch oder sie sind nicht mit MVE und SMVS kompatibel
Vielleicht hat jemand im Team Zeit, sich darum zu kümmern, ich nicht. @nmöhrle , @flanggut?
Danke. Außerdem habe ich herausgefunden, dass alle Strecha-Datensätze, auch neue, hier drin: https://cvlab.epfl.ch/data/strechamvs , auch nicht funktionieren, also geht diese Rolle von der Annahme aus, dass die Kameraparameter falsch sind, und lässt mich glauben, dass der Boden Truth Camera Param sind irgendwie nicht kompatibel mit MVE und SMVS
Bitte posten Sie hier eine Ihrer meta.ini
-Dateien.
Wenn ich mir den Screenshot von UMVE ansehe, sehe ich, dass die Rotationen falsch sind, die Ansichten sollen einen Bogen bilden, der in Richtung der Mitte blickt. Als ich mit Strecha experimentierte, hatte ich meine eigenen Konvertierungsskripte und da sie in Python geschrieben sind, habe ich nicht versucht, sie in MVE zu integrieren. Können Sie mir das Skript zeigen, mit dem Sie die Kameraparameter konvertiert haben, oder einen Link geben?
Meine beste Vermutung ist, dass Sie die Kameraposition (c in den Strecha-Kameradateien gespeichert) nicht in die Übersetzung (t = -R * c) umgewandelt haben. Außerdem denke ich, dass es bei den Strecha-Kameradateien eine gewisse Merkwürdigkeit gab, die Kameramatrix ist in Zeilenhaupt und die Rotationsmatrix in Spaltenhaupt, oder wenn Sie so wollen, wird die transponierte Rotationsmatrix gespeichert (R ^ t).
@simonfuhrmann hier die Metadatei
meta.txt
@nmoehrle Nun , ich habe dies verwendet: https://github.com/simonfuhrmann/mve/wiki/Middlebury-Datasets , um Kameraparameter zu erhalten.
und ja, das habe ich nicht (t = -R * c), also dachte ich, dass Strecha Ihnen den Übersetzungsvektor t gibt. Was mich verwirrt hat, ist, dass Stesha in der Readme-Datei p = k * [R^T | -R^T t ] wenn er nur t durch c -_- ersetzt hätte. Ich werde versuchen, diese Informationen zu verwenden und zu sehen, was sie geben
Dieses Skript kann die .camera-Dateien des Strecha-Benchmarks nicht parsen, es liest nur das Format der Middlebury-Kameraparameter, eine einzelne Zeile, die so aussieht:
"imgname.png k11 k12 k13 k21 k22 k23 k31 k32 k33 r11 r12 r13 r21 r22 r23 r31 r32 r33 t1 t2 t3" .
Die .camera-Dateien haben eine ganz andere Struktur:
|Zeile|Inhalt|
|------|-|
| 1-3 | K-Matrix |
| 4 | unbekannt |
| 5-7 | R^t |
| 8 | c |
| 9 | Breite Höhe |
@nmoehrle ja ja mir ist bewusst, dass ich manuell eine Datei Fountain_par.txt aus .camera für 11 Bilder erstellt habe (faul, meinen eigenen Parser zu schreiben). Das einzige, was ich nicht berücksichtigt habe, ist (t = -R * c) i verwendete c in .camera als t angegeben. Ich werde dies später beheben und die Ergebnisse posten
@nmoehrle Nun , ich denke, das Problem ist dank dir gelöst
Ja, so habe ich es in Erinnerung :-)