Die Schnur-Lot-Methode habe ich vor knapp 10 Jahren schon ausprobiert. Die Ergebnisse ließen sich mehr oder weniger gut stitchen, aber das Handling war mir aber zu wacklig und das exakte Positionieren der Kamera dauerte mir zu lange. Daher habe ich die Methode aufgegeben anstatt sie auszubauen. Meine Alternative besteht aus einer Einbein-Lösung. Das Einbein mit Actiongrip habe ich sowieso auf 90% meiner Touren dabei, und es lässt sich für Kugelpanos schnell, sicher und sehr präzise einsetzen. Wie das geht, habe ich mit Bildern
dokumentiert.
Was mir im Video auffällt:
Aufnahme:
- Die Reihenfolge der Aufnahmen ist ungünstig. Das Nadirbild sollte gemacht werden, bevor die Wiese voller Trampelspuren ist.
- Auf eine Wiese mit blühenden Blumen braucht man keine Positionszettel. Die Blütenköpfe reichen vollkommen, dann gibt es weniger zu retuschieren.
Stitchen:
- kleiner Tipp zum Maskieren der Schattenbereiche: Du zeichnest mit dem Pinsel die Außenkontur des Schattens nach, und wechselst dann das Werkzeug, um den abgegrenzten Bereich zu füllen. Beim Zeichnen der nächsten Kontur wechselst Du zurück zum Pinsel. Das ist umständlich. Ich nutze NUR den Pinsel und halte zum Füllen die Strg-Taste gedrückt.
- Du sagst "... der Viewpoint-Controller gleicht in gewissen Grenzen Abweichungen vom Nodalpunkt aus..." und wendest diese Funktion auf alle Bilder außer dem ersten an. Du erreichst damit zwar eine Verbesserung der Passgenauigkeit, aber die Funktionsweise von Viewpoint hast Du fehlinterpretiert oder noch nicht in seiner Tiefe verstanden. Die Anwendung auf ALLE Bilder ist auch nicht im Sinne des Erfinders, obwohl sie manchen Freihand-Kugeln trotzdem nützlich sein kann. Es ergibt übrigens keinen Sinn, das erste Bild auszuschließen.
Die Viewpoint-Funktion wurde dazu geschaffen, ein schräg aufgenommenes Nadirbild nahtlos in ein Panorama einzufügen. Dazu ist die Voraussetzung, dass der Nadirbereich eine planebene Fläche ist, also keine Erhebnungen oder Vertiefungen im Nahtbereich aufweist. Die seitlich schräge Aufnahmeposition ergibt sich daraus, dass man diesen Bereich ohne Stativ und Schatten haben möchte, und die ursprüngliche Position der Kamera nicht exakt einhalten kann. Ein Bild, das auf diese Weise entsteht, lässt sich nicht mit den normalen Verformungsalogtithmen in die Kugel einpassen. Hier sind zusätzliche trapezförmige Verzerrungen notwendig, um die Perspektive deckungsgleich hinzubekommen. Es liegt in der Natur der Sache, dass das NUR bei planebenen Flächen funktionieren kann. Eine Wiese kann man mit viel gutem Willen als eine solche ansehen, aber die Höhe des Grases erzeugt trotzdem unsaubere Nahtstellen, die aber relativ leicht zu stempeln sind.
Das Anwenden dieser Funktion auf ALLE Bilder bewirkt, dass ALLE Bilder einer trapezförmigen Verzerrung freigegeben werden. Die Passgenauigkeit der Kontrollpunkte sieht damit natürlich günstiger aus, aber man bezahlt einen Preis dafür: parallele Kanten bei Gebäuden bleiben nicht parallel, und das hat unbedingten Einfluss darauf, dass man sie nicht mehr verwenden kann, um das Pano ins Lot zu setzen und das Taumeln zu korrigieren.
In freier Natur, wo es keine exakten Lotkanten gibt, halte ich diese Methode durchaus für zielführend, bei Gebäudemotiven muss man sorgfältig abwägen, ob man das wirklich so haben will.
Im Nadir-Viewpoint-Bild maskiere ich übrigens konsequent alles aus, was sich aus der maßgebenden Ebene erhebt oder absenkt. Kontrollpunkte sind ausschließlich auf der zu verzerrenden Ebene zu setzen, also keinesfalls auf Motivteilen, die höher oder niedriger liegen. Die Trapezverzerrung kann dann nicht exakt berechnet werden, weil sie nicht räumlich, sondern nur flächengebunden funktioniert.
Im Video wird der Viewpoint also nicht "wissenschaftlich exakt" angewendet, und das ist sicher in Verzweiflungsfällen auch machbar. Dennoch sollte man die genaue Funktionsweise kennen.
- Das Zenitbild wurde nicht aus der korrekten Position aufgenommen. Deshalb können seine Kontrollpunkte nicht mit den Rundum-Bildern übereinstimmen. Aus diesem Grund würde ich dem Zenitbild niemals einen Einfluss auf das gesamte Panorama erlauben. Seine Kontrollpunkte dienen ausschließlich dazu, NUR das Zenitbild auszurichten. Es dient ohnehin nur dazu, das Loch im Himmelsblau zu schließen, und deshalb gehört alles, was nicht Himmel ist, aus diesem Bild ausmaskiert. Die CPs kann man nach dem ersten Optimieren komplett löschen, oder man schaltet ihren EInfluss auf die Berechnung im Optimizer einfach ab.
- Das blinde Löschen von einzelnen Ausreißerpunkten ist bei Panoramen, die mit NPA aufgenommen wurden, ganz sicher sinnvoll, man sollte es aber ab einer gewissen Qualität nicht mehr blind machen, insbesondere dann, wenn es um viele Punkte geht. PTGui kann nur mathematisch vorgehen, aber es kann keine Wertung der Punkte nach tatsächlicher Qualität vornehmen, das ist immer noch die Aufgabe des Fotografen.
Beim Löschen von CPs gehe ich bei Freihandpanos immer kontrolliert vor. Naturgemäß ist es bei unpassendem/geschätztem Drehpunkt so, dass die Parallaxenverschiebung nicht im Hintergrund, sondern im Vordergrund stattfindet. Das ist der Grund, warum ich Hintergrundpunkte wesentlich stärker bewerte, und ich hätte in diesem Pano zuerst alle Punkte gelöscht, die näher als 5 Meter an der Kamera liegen. Die Versprungkanten an den Gebäuden wären diesen Fehlerwerten nicht mehr unterworfen und werden automatisch besser. Falls dann immer noch kleine Fehler zurückbleiben, kann man versuchen, die mit lokalen CPs zurechtzurücken. Ich bevorzuge jedoch eine andere Herangehensweise, nämlich die Maskierfunktion. Angenommen, der Stitchingfehler liegt nahe an einem Gebäuderand, dann schaue ich nach, ob dieser Gebäudeteil überhaupt gestitcht werden MUSS, oder ob er vielleicht komplett auf EINEM Bild zu sehen ist. Mit der Maskierfunktion kann ich den Verlauf der Nahtstelle so verschieben, dass diese außerhalb des Gebäudes liegt, wo sie nicht mehr auffällt, weil sie z.B. im Himmelsblau verschwindet.
Bei Freihand-Panoramen achte ich deshalb weniger auf konstante Winkelabstände der Bilder, als vielmehr darauf, dass meine Hauptmotive KOMPLETT auf einem EInzelbild zu sehen sind. Damit bin ich völlig sicher, dass die keine Stitchingfehler erzeugen KÖNNEN. Ob das ein oder zwei Bilder mehr erfordert, spielt keine Rolle, denn es erleichtert die Retusche ungemein.
Durch das Löschen der Vordergrundpunkte kommt es unweigerlich zu Stitchingfehlern im Vordergrund. Das ist der Preis, den man für freihändiges Fotografieren zahlen muss. Beim Fotografieren sollte man also Flächen mit gerasterten Böden vermeiden, die bekommt man niemals perfekt hin, außer mit viel nachträglichem Retuscheaufwand.
Ich lösche auch konsequent ALLE CPs, die ein Bild mit seinem übernächsten Nachbarn hat, und verwende ausschließlich die Punkte, die es mit seinem unmittelbaren Nachbarn hat. Damit werden Zwangszerrungen unterbunden, die in der Regel Bildbereiche betreffen, die ohnehin am Rande eine sehr großen Überlappung von anderen Inhalten abgedeckt werden. Sie dürfen bei mir keinen Einfluss auf das gesamte Pano haben.
Nachdem ich die Methoden der gezielten CP-Auswahl und der geschickten Maskierung angewendet habe, besteht eigentlich nie ein Bedarf, alle Bilder mit der Viewpoint-Funktion zu "entstellen", sondern allein das Nadirbild bestmöglich damit zu integrieren.
Nach dem perfektionierten Stitching niemals vergessen, das Pano exakt ins Lot zu setzen. Das gilt insbesondere für Freihand-Kugeln, bei denen die Ausrichtung der Kamera naturgemäß nicht genau sein kann. Das Ausrichten an einem schrägen Ankerbild nützt da nicht viel, und der Versuch einer automatischen Ausrichtung von PTGui führt auch nicht zum Ziel, denn ein Mittelwert zwischen ungefähren Ausgangswerten ist nur selten genau.
Zum Ausrichten gibt es verschiedene Methoden, die im Forum schon ausführlich beschrieben wurden. Das Anwenden von lotrechten CPs, die als Kanten definiert werden, ist vielleicht die einfachste Art. Ich bevorzuge jedoch die numerische Ausrichtung über Yaw, Pitch und Roll, die ich
hier näher erläutert habe.
Tipps & Tricks »
Tutorial Einstellung Nodalpunktadapter
(16. April 2017, 11:18)
Samstag, 28. Juni 2025, 01:39
WCF::getLanguage()->get('wcf.global.scrollUp')
