undistortPoints () kann keine Linsenverzerrungen verarbeiten

Wie funktioniert der Code?

Ich kann das beschriebene Verhalten mit dem von Ihnen bereitgestellten Code reproduzieren, jedoch löst eine der beiden folgenden Optionen das Problem:

• const Point3f tvec(10, 20, 30); durch const Point3f tvec(10, 20, N); ersetzen, wobei N viel niedriger ist als 0 (z. B. -300) oder viel größer als 100 (z. B. 300 ).

• Ersetzen Sie Ihren Anruf durch einen Aufruf von solvePnP in solvePnPRansac .

Warum behebt jede dieser Änderungen das unerwünschte Verhalten?

Überlegen Sie sich zuerst, was Ihr ursprünglicher Code von der Funktion solvePnP anfordert. Sie verwenden eine Rotation von ziemlich kleiner Größe, daher nehme ich zur Vereinfachung der Erklärung an, dass die Rotation Identität ist. Dann wird die Kamera an den Weltkoordinaten X = 10, Y = 20 und Z = 30 positioniert und Sie erzeugen zufällig Objektpunkte mit Weltkoordinaten (X, Y, Z), die einheitlich in [0,100] ³ gezeichnet sind . Die Kamera befindet sich also in der Mitte des möglichen Bereichs für die Objektpunkte , wie im folgenden Bild dargestellt:

Dies bedeutet, dass Objektpunkte sehr nahe an der Brennebene (d.h. der Ebene, die durch das optische Zentrum und senkrecht in Bezug auf die optische Achse verläuft) erzeugt werden können. Die Projektion im Kamerabild für solche Objektpunkte ist nicht definiert. In der Praxis ist der nichtlineare Optimierungsalgorithmus für undistortPoints jedoch selbst für Objektpunkte in der Nähe der Fokusebene nicht stabil . Diese Instabilität führt dazu, dass der iterative Algorithmus für undistortPoints divergiert, außer wenn die Koeffizienten alle null sind, da in diesem Fall die Anfangswerte während der Schätzung streng konstant bleiben.

Daher sind die zwei möglichen Lösungen, um dieses Verhalten zu vermeiden, die folgenden:

• Vermeide es, Objektpunkte in der Nähe der Brennebene der Kamera zu erzeugen, d. h. ändere den Translationsvektor oder den Bereich der Koordinaten der Objektpunkte.

• Eliminiere die Objektpunkte zu nah an der Brennebene der Kamera, deren unverzerrte Schätzung divergierte (Ausreißer), vor der PnP-Schätzung zum Beispiel mit solvePnPRansac .

Details dazu, warum undistortPoints fehlschlägt:

Hinweis: Da wir die 3D-Weltpunkte kennen, habe ich den folgenden Aufruf verwendet, um die wahren unverzerrten Koordinaten unabhängig vom Ergebnis von undistortPoints zu erhalten:

Die folgende Funktion ist eine vereinfachte Version dessen, was undistortPoints macht:

Wenn Sie Code hinzufügen, um zu überprüfen, wie sich x und y bei jeder Iteration ändern, sehen Sie, dass die iterative Optimierung abweicht, da r2 am Anfang sehr groß ist. Hier ist ein Protokollbeispiel:

Wenn r2 groß ist, ist r2*r2*r2 sehr groß, daher ist icdist sehr klein, daher beginnt die nächste Iteration mit einem sehr kleinen r2 . Wenn r2 sehr klein ist, ist icdist nahe 1, daher sind x und y jeweils auf x0 und y0 gesetzt und wir sind zurück mit einem großen r2 , etc.

Warum ist r2 an erster Stelle so groß? Weil die Punkte nahe der Brennebene erzeugt werden können, sind sie in diesem Fall weit von der optischen Achse entfernt (daher ein sehr großer r2 ). Siehe das folgende Protokollbeispiel:

Sie können sehen, dass für die meisten Punkte r2 sehr groß ist, mit Ausnahme einiger weniger (# 3, # 4 und # 7), die auch mit der besten Genauigkeit der Unverzerrung verbunden sind.

Dieses Problem ist auf den speziellen Open-Source-Algorithmus zurückzuführen, der in OpenCV implementiert wurde und aufgrund seiner Effizienz ausgewählt wurde. Andere nichtlineare Optimierungsalgorithmen (z. B. Levenberg-Marquardt) wären genauer, aber auch viel langsamer und wären in den meisten Anwendungen definitiv ein Overkill.

Lass mich durch opencv Quellen gehen. Aber zuerst präsentiere ich "pure" opencv-Funktion, die wie in den Quellen funktioniert (bitte lesen Sie unten, wie ich diesen Punkt bekommen habe) mit Ihrem Code zusammen, um zu zeigen, dass es als Bibliotheks-Bibliothek funktioniert:

R ist Rotation, t Translation, k Verzerrung. Schauen Sie sich die 'r2'-Berechnung an - sie ist x * x + y * y, aber x, y ist die Position (skaliert durch z though), unmittelbar nachdem die Translation und Rotation angewendet wurde. Und dieses steht für (wie wikipedia ) für "quadratische Entfernung in Bild projiziert durch das ideale Pinhole-Modell ". Wir können sagen, dass die Implementierung von projectPoints OK ist.

Wie ich zu diesem Ergebnis kam:

Ich grabe Version 2.4.8. Wenn Sie im calib3d-Modul zur Kalibrierung.cpp gehen, beginnen Sie mit

Nichts besonderes, oder? Keine Inhaltsmanipulation überhaupt. Lass uns tiefer gehen:

Der letzte Teil ist wichtig, weil wir mit cv :: Rodriguez eine Rotationsmatrix aus dem Rotationsvektor erzeugen. Und später in der Funktion erstellen wir auch Übersetzungsmatrix, aber immer noch keine Datenmanipulation. Gehen Sie weiter in den ProjectPoints2:

Hier legen wir Brennweiten von Kameramatrix und Hauptpunktkoordinaten fest. Außerdem setzen wir das Array k, das Verzerrungskoeferenzen enthält. Jetzt haben wir die Einrichtung der Variablen abgeschlossen. Gehen wir zu den Berechnungen:

Und wir haben die Funktion genau so, wie ich sie oben dargestellt habe /