Panorama Photo

Tolles Motiv, passendes Licht, sauber ausgearbeitet. Manchmal wundert man sich, warum man nachdem das Bild schon über 50 Mal angeklickt wurde, man der erste ist, der ein Herz vergibt.

Das Problem mit den Verzeichnungen am Bildrand kenne ich. Die einfachste Art, es zu lösen, ist, beim Fotografieren der Einzelbilder über den Bildausschnitt hinaus noch Aufnahmen zu machen und diese Bereiche nach dem Stitchen dann zu beschneiden. Ansonsten bleibt dir nur, die Retusche in Photoshop. Aber über die von dir angesprochenen "Randerscheinungen" kann man getrost hinwegblicken.

Ja, alle drei Brücken dort sind beeindruckend. Im National Museum in Edinburgh hatte ich 2018 auch interessantes über die jeweilige Erstellung gesehen. VG Martin

Klaus, hugin verwendet bei der Optimierung m. E. genau so wie PTGui die PanoTools von Prof. Dersch. Und bei ihm wird für die Objektiv-Verzeichnung ein Polynom 4. Grades verwendet. Bei PTGui sind es die Parameter a, b, c. Und es ist klar, das auch hierbei die größten Abweichungen an den Rändern eines Bildes auftreten.
Deshalb bringt auch der Vorschlag von Dieter überhaupt nichts, denn es werden die Paramater jeden Bildes optimiert und nicht "die des gesamten Panoramabildes.
Mein Vorschlag, der mir jetzt dazu einfällt, wäre, die Verzeichnung der Bilder schon vor dem Stitchen durch einen besser arbeitenden Algorithmus zu minimieren. Canon DPP käme z. B. für das von Dir verwendete EOS M3-Objektiv in Frage.
Ich werde das auch noch mal bei meinem Panorama Nr. 14919 anschauen.

Hallo Heinz, mir ist die damals von Prof. Dersch eingeführte abc-Parametrisierung wohlbekannt. Von diesem Polynom vierten Grades entspricht der versteckte Parameter d genauer v*d der Brennweite. Im Prinzip bleiben die Parameter abc zur Korrektur von Verzeichnungen. Aber mit etwas besseren Mathematikkenntnissen (Singularität, holomorph und Polarkoordinaten sollten einem was sagen) kann man leicht einsehen, dass die Parameter a und c Schrott sind, weil sie eine Wurzel-Singularität in der Abbildungsfunktion dort einführen, wo eine echte Linse keine hat. Bleibt also nur ein einziger guter Parameter, der Kissen-Tonnen-Parameter b.

Ja, es gibt Programme, welche im Linsenmodell besser arbeiten. Einige implementieren das Brown-Conradi-Modell, nicht alle nennen es so.

Danke, dass Du das mal für EOS-M3 untersuchen möchtest. Aber ich hatte auch noch einige andere Kameras in der Vergangenheit. Diese abc-Unzulänglichkeit tritt recht generell zum Vorschein. Was mich ärgert, ist dass das Hinzufügen von zwei Polynomtermen ungerader Potenz eigentlich so einfach wäre...

Mathe und verbogener Pylon hin oder her.....mir gefällt es. Leider fehlt die Beschriftung.

Beschriftung hat etwas gedauert. Der firefox auf meinem Hauptrechner ist bei manchen websites zu wählerisch, also muss ich die synthetischen udeuschle-Panoramas auf einem separaten Rechner generieren. Jetzt ist orientiert und beschriftet.

Danke, Klaus, daß Du erläutert hast, was Deiner Meinung nach unzureichend am in den Pano Tools verwendeten Linsenmodell ist. Gibt es dazu Berichte, die man sich anschauen könnte.
Aus der praktischen Erfahrung ergibt sich aber, daß bei fast allen Aufgaben akzeptable Lösungen mit diesem Linsenmodell herauskommen.
Leider habe ich bisher nicht erfahren können, wie im Prinzip die Optimierung in den Pano Tools bewerkstelligt wird. Daß das nicht so einfach neu zu programmieren ist, zeigt doch, daß hugin und PTGui das so mit diesem Linsenmodell übernommen haben.
Klaus, daß die Verbiegung hier bei dem linken Pfeiler im Panorama auf das Linsenmodell zurückzuführen ist, ist das mehr als eine Vermutung?
Was mein Vorschlag, mit Canon DPP die Verzeichnung der Bilder vor dem Stitchen herauszurechnen, bringt, könntest Du doch selbst mal ausprobieren. Das sind dann andere Anfangswerte für die Optimierung, wie die aber laufen wird, könte ich nicht sagen.
Ich habe so ein einfaches Beispiel mit zwei weitwinklligen Bildern von Windrädern, die starke tonnenförmige Verzeichnung hatten, gestitcht. Und obwohl ich vorher mit DPP die Vezeichnung einwandfrei beseitigt hatte, hatten die Parameter a, b und c die Werte 0,054, -0,14 und 0,13. Das waren ähnliche Werte (0,078, -0,2 und 0,13) wie in dem Fall, als ich die Bilder ohne Vorbehandlung gestitcht hatte. In beiden Fällen gab es kerzengerade Windräder.

Lieber Heinz,

Für den stitch hatte ich nur den Parameter b verwendet. Dass ein Parameter zu wenig sein kann, keine Überraschung.

Heute abend habe ich mich nochmals dem Panorama in hugin gewidmet, um sicher zu sein, Dir korrekte Antworten geben zu können. Dabei habe ich festgestellt, dass meine Linsenachse zur Mitte des Sensors um (31,-37) Pixel verschoben ist. In hugin sind dies die Parameter d und e. Auf den Effekt der Verbiegung der Brückenmasten hat dies kaum Einfluss.

Ich habe jetzt mehrmals mit verschiedenen Parametersätzen gearbeitet. Wenn ich heute abend noch darf, werde ich eine neue Version mit Erklärungsanhang hier auf pp hochladen, Parametersatz abcde.

Die Verbiegung der Masten kommt natürlich daher, dass ich nur den Parameter b verwendet habe. Phänomenologisch drei statt einen Verzerrungsparameter einzusetzen muss im registrierten Bereich eine Verbessung ergeben, und das tut es auch.

Die Kehrseite der Medaille: im Bereich außerhalb der Passpunkte wird die Passung dadurch überproportional schlechter. Für dieses Panorama habe ich das nicht nachgewiesen, aber für einige frühere, wenn die Artefakte mal gar zu übel waren. Wie Du richtig schreibst, meistens gibt man sich mit dem Ergebnis zufrieden.

Kurz zu Zahlen. hugin gibt ja mittlere Abweichung, Standardabweichung und maximale Abweichung an. Ich habe diese mal notiert für ein paar Parametersätze:
nix 10.16 10.02 43.20
b de 0.92 0.91 5.60
abc de 0.33 0.22 1.32
Eine deutlich Verbessung, wenn der eine Tonnenparameter b hinzukommt.
Zwei weitere Parameter hinzu, und nur eine Verbesserung von Faktor 3 bis 4. Wenn das nicht nur Phänomenologie wäre, müsste da mehr als eine Größenordnung an Verbesserung herausspringen.

Du fragst, wo man das nachlesen oder nachschauen kann. Das paper von Conrady findet sich auf dem Netz, und er erläutert die Mathematik. Brown hat einfach Fotogrammetrie betrieben, sein Originalpaper, das alle zitieren, ist auf dem Netz nicht zu finden (ich lasse mich gerne eines besseren belehren) aber ein paar Folgepaper; für Brown ist es Mittel zum Zweck, und er macht es einfach richtig - vielleicht weil er annimmt, dass anderen klar ist, warum es so sein muss...

Auf die Unzulänglichkeit der abc-Parametrisierung habe ich mehrfach auf auf hugin-ptx hingewiesen. Meine postings sind dort wohl einige Jahre alt, sollten sich aber noch finden lassen. Das Problem angegangen wurde allerdings nicht, vielleicht ist der Leidensdruck nicht gross genug, vielleicht sind Leute, die seriös Photogrammetrie betreiben wollen, ohnehin schon von hugin abgewandert.

Der Optimierungsalgorithmus ist nicht das Problem. Als Leute Karten aus mehreren Fotografien zusammensetzen wollten, gab es genug Druck, dass die Parameter TrX TrY TrZ mit eingebaut wurden. Den Formelteil a*r^3+b*r^2+c*r+d um die Terme r^4 und r^6 zu erweitern liegt auf dem gleichen Schwierigkeitsniveau.

Warum hugin und dann PTGui das so übernommen haben? In den panotools sind etliche clevere Ansätze und Algorithmen drin, da zweifelt man nicht von vornherein. Man hat es halt "schon immer" so gemacht. Meine Einschätzung.

Eigentlich sollte ich das Ganze mal sauber aufschreiben, und nicht nur wieder einmal in einem Forum posten.

Abschließend zwei Punkte für die praktische Arbeit. Wegen der unvollkommenen Parametrisierung empfehle ich dringend für Passpunkte/Kontrollpunkte (CPs):
1) CPs nur zwischen Bilderpaaren, welche ineinander überblendet werden
2) CPs nur in der Nähe der Naht bzw. Überblendungslinie
Ich weiß, die üblichen Empfehlungen lauten anders.

Damit sei es erstmal genug für heute abend. Beste Grüße
Klaus