Unzulänglichkeit im abc-Linsenmodell   7250
previous panorama
next panorama

Labels

Details

Location: auf der Forth Road Bridge      by: Klaus Föhl
Area: United Kingdom      Date: 2017-03-16
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

Daumen hoch! Solche Versuche müssen auch gemacht werden, auch wenn ich jetzt nicht grad die Muße habe, die Entstehung der Testbilder genau zu verstehen.
2020/06/18 08:47 , Oliver Bayer
Umrechnen der Teilbilder in die Zieldarstellung, dann Helligkeitsdifferenz zweier Teilbilder nehmen.

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.
2020/06/18 20:34 , Klaus Föhl
Klaus, Danke auch für Deine Antwort beim anderen P.
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?
2020/06/19 19:33 , Heinz Höra
Heinz, gerne geschehen. Ich bin halt Ästhet, und es fuchst mich, wenn man alles richtig macht, aber am Rand und insbesondere in den Ecken die Diskrepanz trotzdem noch einige Pixel beträgt. Manchmal muss man die Naht durch Pfeiler oder Masten legen, und die sehen durchgeschnitten nicht wirklich gut aus.

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.
2020/06/19 20:25 , Klaus Föhl
Klaus, bei dem, was Du aufgrund meiner Frage zu d und e geschrieben hast, haben wir evtl. aneinander vorbei geredet. Da ich d und e immer aus der Optimierung ausschließe, muß ich erst noch ein paar Beispiele berechnen lassen, bevor ich dazu noch mal etwas sage. Doch zu den explizit von Dir genannten vertikalen und horizontalen Kontrollpunkte wollte ich Dich fragen, ob Du weißt, wie das Optimierungsverfahren diese behandelt. Haben diese im Fehlervektor genau das gleiche Gewicht wie die normalen CP?
2020/06/21 19:38 , Heinz Höra
Gewicht der horizontalen und vertikalen Kontrollpunkte? Nein, ich weiß es nicht. Ich vermute, dass gleiches Gewicht wie normale CP.

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.
2020/06/21 23:58 , Klaus Föhl
Interessante Diskussion, so kurz nach dem Urlaub aber etwas zu technisch ;)
2020/06/24 17:14 , Jens Vischer

Leave a comment


Klaus Föhl

More panoramas

... in the top 100