Qualitätsmessung am Slant-Adapter

In diesem Beitrag stelle ich eine originelle und extrem(!) empfindliche Kontroll- und Messmethode für Kugelpanorama-Fotographen vor, die einen Slant-Adapter mit Fischauge verwenden.

Nach all dem Aufwand, den theoretischen Hintergrund der Kugelpanorama-Fotografie mittels Fischauge und Slant-Adapter zu beleuchten, sowie Kameragehäuse-Objektiv Kombinationen zu vermessen und einen Slant-Adapter zu konstruieren, stellen sich Einige möglicherweise die Frage, ob, bzw. wie man die Leistung eines realen Slant-Adapters (ob gekauft oder Eigenbau) objektivieren kann, d.h., Eigenschaften messen und untereinander vergleichbar zu machen.

Da ich mich selbst dieser Frage gegenüber sah, schildere ich hier meine Herangehensweise an diese Fragestellung und die dabei gesammelten Erkenntnisse.

Executive Summary

Als ultimativ verkürzte Executive-Summary formuliert, beruht meine im Folgenden vorgestellte Messmethode auf der Beurteilung, wie gut/exakt/genau die im Slant-Adapter durch Schrägstellung der Kamera angepeilte Bild- bzw. Sensordiagonale im Panorama-Editor von PTGui Pro als tatsächlich Senkrechte (d.h.: eine senkrechte Gerade(!!!)) abgebildet wird.

Die Methode liefert als Resultat zwei reproduzierbare Zahlenwerte:

• Slant Winkelfehler in Grad [°] – kleiner ist besser
• Horizontaler Versatz in [Pixel] – kleiner ist besser

Aus beiden Zahlenwerten können unmittelbar Optimierungsmassnahmen hergeleitet werden.

Wie kommt man auf so eine Idee?!

Ein bisschen Vorwissen hilft natürlich. Und ich beschäftige mich mit derlei Fragen bereits seit vielen Jahren. Zentral ist das Wissen darüber, dass Kugelpanoramen typischerweise in Rektangularprojektion (equirectangular projection) als 2D-Bitmaps dargestellt, bzw. gespeichert werden. Diese Projektionsart weist die Eigenschaft auf, dass vertikale Linien (Längengrade) als vertikale Geraden abgebildet werden, genauso wie horizontale Linien (Breitenkreise) als horizontale Geraden abgebildet werden. Schliesslich hilft es noch zu wissen, dass Fischaugen zwar erhebliche, aber eben keine beliebigen Verzerrungen bewirken. Insbesondere ist per definitionem garantiert, dass gerade Linien durch die Optische Achse garantiert auch als Geraden abgebildet werden. Ein Versatz zwischen einer geraden Linie und der Optischen Achse resultiert in einer mehr oder weniger ausgeprägten tonnenförmigen Verzeichnung.

In der Computergrafik werden Kugelpanoramen, repräsentiert durch 2D-Bitmaps in equirectangular projection, gerne auch für die Realisierung von Spiegelungseffekten in synthetischen Computergrafiken verwendet (siehe auch: Spherical Environment Mapping).

In einem früheren Beitrag hier hatte ich mir dieses Prinzip, bzw. dessen Umkehrung: gerade vertikale Linien in einer rectangular projection 2D bitmap werden im Kugelpanorama als Längengrade (Meridiane) dargestellt, zunutze gemacht:

Das zugehörige Kugelpanorama der obigen Abbildung lässt sich auch auf dem lokalen Rechner (nach Klick auf das Bild und Download der Bilddatei) mit dem kostenlosen FSPViewer betrachten. Beachten Sie nun die für jede rote Linie durchgehend geradlinige Verbindung entlang eines Meridians zwischen Nord- und Südpol.

Im vorliegenden Fall (Slant-Adapter) war meine Erwartung, dass eine gerade Linie durch die Optische Achse, auch wenn sie nur virtuell existiert wie z.B. eine Bild-, bzw. Sensordiagonale, in der resultierenden equirectangular projected bitmap als perfekte Gerade erscheinen müsste. Die Abweichung von dieser angestrebten Perfektion lässt sich mit hoher Genauigkeit messen und für anschliessende Korrekturmassnahmen nutzen.

Testdaten

Als Testdaten verwende ich im Folgenden drei (von acht) original hochaufgelöste und unbearbeitete, mit meinem damaligen Slant-Adapter aufgenommene Einzelbilder für mein Kugelpanorama/Little Planet vom Gipfel des (Flüela) Schwarzhorns:

Hier das resultierende Kugelpanorama, und hier der resultierende Little Planet. Für beide würde ich behaupten, dass sie – trotz der vorliegenden Mängel, die ich in diesem Artikel aufzeigen werde – ganz passabel gelungen sind.

Wenn man diese drei unbearbeiteten Bilder in ein neues Projekt in PTGui Pro einfügt, sieht das zunächst einmal so aus:

Abgesehen davon, dass der vorliegende Panoramaansatz den Zenit knapp nicht abdeckt, kann man noch nicht erkennen, worauf es hier eigentlich ankommt, da die Bilddiagonale der Ausgangsbilder bisher nur als gedachte, unsichtbare Linie existiert. Um deren Lage und Verlauf sichtbar zu machen, habe ich in einer Kopie der Testdaten in jedes Bild eine Bilddiagonale (von links-oben nach rechts-unten) eingezeichnet und die Übung wiederholt:

Die Testbilder sehen nun so aus:

In einem neuen PTGui Pro Projekt zeigt sich das folgende Zwischenergebnis:

Gemessen an meinen Erwartungen ist das Ergebnis dieses Versuchs zumindest «überraschend». Gemessen am Ziel bei der Verwendung eines Slant-Adapters ist das Ergebnis eindeutig schlecht. Woran liegt es? Der «Bildparameter»-Dialog von PTGui Pro klärt auf:

Der «Gierwinkel» entspricht der von mir als «Schwenkwinkel» bezeichneten Drehung um die vertikale Schwenkachse. Ich habe ein Schwenkraster von 45° – entsprechend 8 Einzelbildern für eine komplette Zeile – verwendet. Hier ist alles wie es sein soll.

Der «Nickwinkel» gibt die Abweichung der Blickrichtung aus der Horizontalen nach oben bzw. unten an. Da alle Einzelbilder mit dem gleichen Slant-Adapter aufgenommen wurden, weisen alle Einzelbilder hier den gleichen Wert von 7.8° auf. Dieser leicht nach oben ausgerichtete Blick sollte eigentlich zur Folge haben, dass eine leichte Überlappung der Einzelbilder im Zenit stattfindet, was anscheinend knapp verfehlt wurde. Auch diese Informationen liegen im wesentlichen im Rahmen meiner Erwartungen.

Als Fehlerursache erweist sich schliesslich, dass der «Rollwinkel» (= Slant-Winkel) von 37.3° um satte 3.61° vom Zielwert ATAN( 24 / 36 ) = 33.69° abweicht. (Das Argument des Arcustangens «24 / 36» bezeichnet das Bildseitenverhältnis des Vollformat-Sensors meiner A9). Das Kameragehäuse steht um diesen abweichenden Winkelbetrag «zu flach» in Richtung Landscape-Orientierung, anstatt die Bild- bzw. Sensordiagonale exakt auf der Spitze zu balancieren..

Offensichtlich habe ich bei der Erstellung meines Slant-Adapters unsauber gebastelt bzw. geklebt. Ich hatte aber – ehrlich gesagt – auch nicht damit gerechnet, dass diese scheinbar geringe Abweichung in niedrigen, einstelligen Gradbereich vom Sollwert derart dramatische Auswirkungen haben würde – wieder was gelernt!

Simulation eines korrekten Slant-Winkels

Nun lag es also für mich zunächst nahe, den Slant-Winkel des Slant-Adapters einstellbar zu machen, um in der Praxis den korrekten Wert ggf. iterativ einstellen zu können. Aus Gründen der Vereinfachung entschied ich mich, die Ergebnisse eines bezüglich des Slant-Winkels einstellbaren Slant-Adapters ins Virtuelle zu verlagern: indem ich die Testbilder vor dem Stitchen in PTGui Pro per Bildbearbeitungsprogramm um variable Winkelbeträge verdrehen würde.

In einer ersten Testrunde habe ich die Testbilder des vorigen Durchlaufs inklusive eingezeichneter Diagonale um einen Betrag von etwa 3.7° im UZS verdreht und erneut in PTGUI Pro eingelesen. Das Ergebnis war sowohl ernüchternd, als auch erhellend: da korrespondierende Punkte (= Kontrollpunkte) in der Überlappungszone zweier benachbarter Teilbilder gleich bleiben, macht PTGui Pro die manuelle Verdrehung schlicht rückgängig, und es ergeben sich keine neuen Erkenntnisse bezüglich der Bildschirmdiagonale.

Das brachte mich auf die Idee, in Gimp die Bitmapdiagonale in eine erste Ebene, und den Bildinhalt in eine zweite Ebene zu legen. Durch die Verdrehung des Bildinhalts ensteht nämlich auf jeder Bildseite ein keilförmiger Bereiche ohne Bildinformation. Das verändert aber nicht das rechteckige Format der Bitmap. Die Bitmapdiagonale verblieb nun bei der rechteckigen Bitmap, während nur der Bildinhalt verdreht wurde. Etwa so:

Diese Manipulation der Testbilder habe ich in einer weiteren Kopie aller ursprünglichen Testdaten/Testbilder vorgenommen und dann als *.jpg Dateien exportiert. Die Testbilder sahen nun so aus:

Nach Einlesen dieser neuesten Version der Testbilder in PTGui Pro und «Anordnen» der Einzelbilder präsentierte sich dieses Bild, was mir tatsächlich ein erstes «Wow!» 😎 entlockte:

Dieser zweite Ansatz erwies sich offensichtlich als korrekt: der rotierte Bildinhalt bestimmt die Verdrehung der mit der Bitmap verbundenen Bitmapdiagonalen. Tatsächlich ist das vorige Bild das Endergebnis einer akribischen Versuchsreihe, mit variierender Verdrehung des Bildinhalts in 1/100 (i.W.: einhundertstel) Grad-Schritten, bis ich bei einer Verdrehung von 3.68° das obige Ergebnis erzielt hatte. Bevor hier jemand die Nase rümpft: natürlich hatte ich den Zielbereich vorab per binärer Suche passend eingegrenzt. 💪

Symmetrie als Optimierungskriterium bei der Verdrehung

Warum war ich genau bei drei-Punkt-sechs-acht Grad Verdrehung zufrieden?

Der Panorama-Editor von PTGui Pro zeigt das resultierende (Teil-)Kugelpanorama in Äquirektangular Projektion. Wegen der gewollten Ausrichtung des Nickwinkel «leicht nach oben» ist der Zenit des Kugelpanoramas mit den verdrehten Testbildern nun übrigens knapp geschlossen, während der Nadir weiterhin keine Bildinformation enthält. Trotzdem gilt immer, dass die oberste Pixelreihe der equirectangular bitmap den Zenit kodiert, während die unterste, bisher leere Pixelreihe den Nadir kodiert. So weit – so gut.

Nun ist es so, dass diese equirectangular bitmap ein Kugelpanorama beschreibt, und eine Kugel in jeder erdenklichen Hinsicht symmetrisch ist. Daher war meine Annahme, dass auch die Abbildung der grünen Bitmapdiagonalen bezüglich der horizontalen Mittellinie des Panorama-Editors symmetrisch zu sein hätte. Beide Äste oberhalb und unterhalb der horizontalen Mittellinie weisen vom Äquator ausgehend nach rechts. Eine geringfügig kleinere Verdrehung als 3.68° hatte dazu geführt, dass der obere Ast nach rechts, und der untere Ast nach links weist, ähnlich wie bei den ursprünglichen, unverdrehten Testbildern. Umgekehrt hatte eine geringfügig grössere Verdrehung als 3.68° einen «Umschlag» der Kipprichtung bewirkt, so dass der obere Ast nach links gewiesen hatte, und der untere Ast nach rechts.

Um die Symmetrie auch bei unvollständiger Darstellung des durch die Bitmapdiagonalen repräsentierten Längengrades abzuschätzen, habe ich mich auf auf den folgenden Ausschnitt des Panorama-Editors konzentriert:

Der untere Ast des (grünen) Meridians ist aus bekannten Gründen nur unvollständig enthalten. Ich habe daher – bestmöglich – vom Nadir aus ein weisses Rechteck eingezeichnet, dessen Höhe durch das untere (sichtbare) Ende der Bitmapdiagonalen (grün) bestimmt wird, und dessen Breite dem Abstand des Endpunkts der grünen Bitmapdiagonalen von der vertikalen Mittellinie des Panorama-Editors entspricht. Der rechte obere Eckpunkt (rot) des unteren weissen Rechtecks markiert diesen Punkt.

Das weisse Rechteck habe ich nun an der horizontalen Mittellinie gespiegelt. Dessen obere linke Ecke liegt nun exakt im Zenit. Nun markiert dessen untere rechte Ecke (rot) den Schnittpunkt mit dem grünen Abbild der Bitmapdiagonalen. Auch wenn in diesem Schritt «Augenmass» involviert war, sollte die Idee und deren Ziel klar geworden sein: Die Symmetrie der Anordnung habe ich nur anhand des zwischen beiden roten Punkten liegenden Teils der grünen Bitmapdiagonalen beurteilt. Wegen der exakt gleichen Grösse der beiden weissen Hilfsrechtecke erschien mir die Symmetrie lt. Augenmass bei einer Verdrehung der Testbilder um 3.68° hinreichend genau erreicht.

Der Vollständigkeit halber: der «Bildparameter»-Dialog von PTGui Pro zeigt nun für alle Einzelbilder einen Rollwinkel (= Slantwinkel) von 33.6° an, also nur noch um 0.09° abweichend vom theoretischen Sollwert.

Das bisher erzielte Zwischenergebnis stellt zwar bereits eine markante Verbesserung gegenüber der Ausgangssituation dar. Trotzdem stört mich immer noch, dass die eigentlich geradlinige Bitmapdiagonale als gewölbte Linie abgebildet wird, mit der konvexen Seite nach links weisend. Zudem verlief die grüne Linie nicht exakt entlang der vertikalen Mittellinie des Panorama-Adapters, sondern wies einen leichten Versatz nach rechts auf:

Instinktiv habe ich nun angenommen, dass ich die Ebene mit dem Bildinhalt um einen gewissen Betrag nach rechts verschieben müsste, damit die Rückverschiebung beim Ausrichten der Einzelbilder in PTGui Pro die grüne Repräsentation der Bitmapdiagonalen nach links, und somit durch das Bildzentrum verschieben würde. Wodurch die Wölbung der grünen Linie verschwinden müsste.

So war es dann auch. 🤓

In einer wiederum akribischen und in Einzel-Pixel-Schritten durchgeführten Versuchsreihe (wiederum mit vorgeschalteter Eingrenzung des Zielbereichs per binärer Suche) habe habe ich für meinen Slant-Adapter einen optimalen Verschiebungswert von 20 Pixeln ermittelt, bei dem die grüne Bitmapdiagonale nahezu perfekt geradlinig und entlang der vertikalen Symmetrielinie des Panorama-Editors verläuft, wie im Eingangsbild dieses Artikels gezeigt. Den Wert von 20 Pixeln als Verschiebungswert muss man sich übrigens genauso wenig merken wie die Verdrehung um 3.68°, weil beide Werte spezifisch sind für die konkreten Mängel meines Eigenbau-Slant-Adapters.

Zur Dokumentation der enormen Empfindlichkeit der Anzeige auf kleinste Änderungen im Betrag der Verschiebung zeige ich noch die Ergebnisse bei einer Abweichung von ±2 Pixel vom Idealwert:

Bringt das überhaupt was?

Wer jetzt sofort in die Werkstatt hechten möchte um seinem Slant-Adapter spanhebend oder kaltverformend auf die Sprünge zu helfen, den möchte ich ein wenig bremsen:

Der Vergleich zwischen den unmodifizierten Ausgangsbildern und den verdrehten und verschobenen Testbildern stellt sich wie folgt dar:

Eine Verbesserung ist zwar sichtbar, der durchschnittliche und maximale Kontrollpunktabstand konnten – ausgehend von bereits niedrigem Niveau – nochmals etwa halbiert werden. Trotzdem ist das wohl nicht wirklich «weltbewegend», denn der Optimierer von PTGui Pro fand auch die Ausgangsversion bereits «sehr gut». Von daher würde ich die beschriebenen Tests und evtl. Anpassung nur denjenigen empfehlen, die hartnäckige und ansonsten unerklärliche Probleme mit ihren Slant-Adaptern haben und auch im kürzesten Nahbereich evtl. auftretende Parallaxenfehler zurückdrängen wollen.

Oder Käufern, die dem vollmundigen Versprechen höchster(!) Präzision eines Anbieters derartiger Slant-Adapter einmal belastbar auf den Zahn fühlen wollen 😉

Einfluss des Nickwinkels auf Zenit und Nadir

Zur Erinnerung: der Nickwinkel bezeichnet den Winkel, um den die Kamera abweichend von der Horizontalen nach oben oder unten schaut. Kann man sich eigentlich gut merken, wenn man selbst (bejahend) mit dem Kopf «nickt».

Wie sich zufällig und als Nebeneffekt meiner obigen Versuche herausgestellt hat, lässt sich mittels einer möglichst optimalen Vertikalausrichtung der Bilddiagonale im Slant-Adapter der kleinste erforderliche Nickwinkel minimieren, bei dem der Zenit gerade noch geschlossen wird. Eine derartige Minimierung führt umgekehrt dazu, dass die leere Rosette im Nadir ebenfalls minimiert wird.

Dieser Effekt lässt sich ebenfalls aus einem optimal ausgerichteten Testbild herauslesen. Dies beruht auf dem Umstand, dass ein Bild in äquirectangularer Projektion bezüglich vertikaler Linien längentreu ist. Längentreu bedeutet, dass gleiche Strecken gleichen Winkeln entsprechen. Dementsprechend darf man an die Y-Achse der äquirectangular projizierten Bitmap eine Skala mit linearer Unterteilung von -90° bis +90° anlegen. Etwa so:

Ins Bild klicken für eine vergrösserte Darstellung.

Eingezeichnet sind diesmal die Längen- und Breitengrade im 10° Raster. Jedes dieser gleich grossen(!) Quadrate repräsentiert einen Bereich von 10° x 10° , woher diese Projektionsart auch ihren Namen «äquirectangular» bezieht. Wenn man die mittige Vertikale mit der Blickrichtung des Betrachters (Gierwinkel) gleichsetzt, dann repräsentieren die vertikalen Begrenzungslinien (Pixelreihen) links und rechts aussen übrigens den Längengrad exakt hinter dem Bildbetrachter.

Wenn man sich nun die linke (oder rechte) obere Bitmapecke anschaut, kann man ablesen, dass ein optimal ausgerichtetes Einzelbild den Zenit um etwa 5° überlappt, und die grüne Bildschirmdiagonale auf der Rückseite des Betrachters wieder um diesen Betrag nach unten zeigt:

Der Bildparameter-Dialog von PTGui Pro hatte angezeigt, dass alle Einzelbilder mit einem Nickwinkel von 7.8° aufgenommen worden waren. Wenn man inzwischen weiss, dass daraus bei optimaler Einstellung des Slant-Adapters eine Überlappung des Zenit um 5° resultiert, dann schlummert hier erhebliches Optimierungspotenzial.