|
 |
||||
 |
 |
||||
Diskussion der Unzulänglichkeit des abc-Linsenmodells folgt, aber nicht mehr heute abend.
Nur so viel: man erkennt in den Diagnosebildern, dass Teilbereiche unterschiedlich gut übereinanderliegen. ------------------- Weiter im Text: ein Schritt beim Panoramabauen ist, durch geometrische Umrechnung der Originalbilder deren Bildinhalte übereinanderzulegen. Wenn das passgenau gelingt, kann man die Nahtlinie beliebig im Überlappungsbereich führen. Das kann man dazu nutzen, um diese Nahtlinie nicht durch bewegte Objekte hindurch sondern außen herum zu führen. Die Teilkomponente enblend in hugin bietet dazu die Option --visualize, mit der dann die Differenz der Bildinhalte im Überlappungsbereich in eine extra Datei geschrieben wird. Wenn keine Differenz vorhanden ist, ist der Bildinhalt schwarz. Zudem wird noch die Naht als gelbe Linie dagestellt. Vereinfacht gesagt, wird diese Nahtlinie durch so viel schwarzen Bildbereich geführt wie möglich. Der besseren Erkennbarkeit habe diese Differenzbilder von weiß auf schwarz in schwarz auf grau umgewandelt. Beide Darstellungen zeigen einen Ausschnitt. Zu erkennen ist jetzt, dass die Bilder in der Mitte wenig Kontrast haben und zu beiden Seiten hin der Kontrast zunimmt. Das ist ein deutlicher Hinweis, dass man die Kameralinse mathematisch suboptimal beschreibt. Dann funktioniert die Nahtlinie nicht mehr richtig, wenn sie nicht im mittleren Bereich verlaufen soll. Im ersten Diagnosebildpaar habe ich nur einen Verzeichnungsparameter eingeschaltet. Dass die Bilderpaare nur bereichsweise gut übereinanderliegen, ist zu erwarten. Im zweiten Diagnosebildpaar ist der Riesenschritt zu drei Verzeichnugsparameter gemacht. Eigentlich sollte das Bild nun komplett grau sein (natürlich nicht im Bereich der Wellen). Aber auch wenn es besser ist - das Verhältnis von Aufwand zu Ergebnis stimmt nicht. === Den Teilschritt der Verzerrungskorrektur kann man als Abbildung (x,y) -> (X,Y) oder in Polarkoordinaten (r,phi) -> (R,Phi) schreiben. Wenn die Linse rotationssymmetrisch ist, dann schreibt sich die Abbildung (r,phi) -> (R,phi) beziehungsweise (x,y) -> (x,y)*f(r), wobei f(r) tunlichst ein Polynom in r^2 sein sollte (man kann dann auch x^2+y^2 schreiben). In Polarkoordinaten sollte R ein Polynom (oder zumindest eine Reihenentwicklung) in r sein. Jetzt haben die Polarkoordinaten dooferweise eine Singularität bei r=0. Damit muss man zusätzlich f(-r)=-f(r) fordern, damit am Ursprung die Abbildung und die Ableitungen glatt bleiben, wie es der Physik der Linse entspricht. Leider gehören zu a und c Polynomterme gerader Potenz. Kein Problem, belassen wir a=0 und c=0. Problem ist, dass Parameter b als Einzelkämpfer übrigbleibt. |
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||
|
|
Comments
Diese Testbilder liefert einem hugin beim stitchen. Ich habe die Option --visualize eingeschaltet. In den Dateien vis-1.tif, vis-2.tif usw. sehe ich dann, ob beim stitchen irgendwas schiefgelaufen ist.
Ich bin aber nicht in der Lage, etwas dazu auf Deinem Niveau zu sagen.
Aber ein paar Bemerkungen aus meiner Sicht:
Die genaue Übereinstimmung im Überlappungsbereich ist doch auch, wenn nicht sogar wesentlicher von anderen Parametern wie Nick- und Gierwinkel des Ankerbildes abhängig sowie davon, daß die Bilder parallaxenfrei aufgenommen wurden.
Noch beim anderen P. hast Du geschrieben, daß Du auch die Zentrierungsparameter d und e berechnen ließest. Läßt Du das bei jedem P. berechnen und korrigierst Du dann den dadurch veränderten Nickwinkel des Ankerbildes?
Ganz klar, Kipp-, Nick und Gierwinkel sind fundamental. Wenn da was nicht stimmt, kann man sich die Verzerrungsparameter gleich sparen. Allerdings: das Ankerbild sollte man beliebig platzieren und drehen können, denn alle anderen Bilder passen sich ja dem an. Dem guten Überlapp ist es egal, ob der Horizont schief ist.
Und mit Parallaxe habe ich auch schon meine Erfahrungen gemacht. Insbesondere bei Panoramas mit Fotos von Drohnen, weil die schonmal einige Dezimeter hin- und herschwanken.
Zu diesen Parametern d und e, je nach Kamera und Objektiv ist das Problem unterschiedlich intensiv. Machen tu ich es nicht immer, aber im Prinzip lässt sich das bei jedem Panorama einschalten. Und weil hugin eine simultane Optimierung aller (eingeschalteten) Parameter durchführt, ist der Nickwinkel meist für mich kein Problem.
Warum? Zum einen, wenn ich vertikale und horizontale Kontrollpunkte/Linien vorgebe, werden Nickwinkel und Kippwinkel Teil der Optimierungsparameter. Zum anderen, wenn ich nach udeuschle.de ausrichte, ist das im Zwischenschritt egal. Was passieren kann, ist, dass ich den Beschnitt / crop etwas nachjustieren muss, wenn ich nach der Groboptimierung d und e hinzuschalte.
Und weil die line-CPs durchaus etwas verzerren können, wenn ungeschickt eingesetzt, deswegen vermute ich, gibt es diese Option "ignore line control points" in hugin.
Leave a comment