Panorama Community

Die grafische Darstellung ist gut und praktisch, aber nicht so genau abzulesen.
Wer es lieber rechnet oder die Tabelle gerade verlegt hat, kann diese kleine Excel-Tabelle verwenden:

Beide Threads sind jetzt in der Trickkiste enthalten.

Gruß
Ralf

Hier eine grafische Darstellung zu dem Thema.

Anmerkung meinerseits dazu: Ja das Bild wird hochskaliert, wenn der Faktor Pi verwendet wird. Aber wenn der Betrachter in die Würfelecke schaut und einen kleinen Bildwinkel einstellt, wird die Würfelfläche ja wieder auf den Kreisausschnitt "projiziert", wo ja der Monitor sitzt. Dann habe ich wieder Pixel auf Pixel, also die maximale Auflösung, die ich wiedergeben kann.
Nachteil: Durch das größere Format, wird der Speicherbedarf größer.

Bei dem Faktor 4 verliert man halt an Qualität/Auflösung, wenn das Panorama in Würfelflächen abgespeichert wird, denn die Bereiche, wo die Kugel den Würfel berührt, werden um 21% herunter skaliert.
Die Kanten, werden pixelgenau abgebildet. Die Ecken werden weiterhin hochskaliert.

Das durchschnittliche Optimum liegt dann vielleicht bei Faktor 3,6 ;-) .

Gruß

Richard

Das ist hier die Frage.
(pi, π, 3,14…)

Hää?! Worum geht es hier?
Um die Frage warum man bei der Umwandlung eines equirectangularen Panoramas die Breite durch 4 oder durch Pi teilt und welche Auswirkungen dies hat. Und - warum überhaupt wandeln wir unser schönes Kugelpanorama in einen weniger schönen Würfel um.

Letztere Frage lässt sich am schnellsten beantworten, darum fangen wir damit an.
Ganz einfach - eine Kugel ist für einen Computer mit seiner "verpixelten, polygonalen Denkweise" eine ungünstige Form.
Oft werden Rundungen aus Polygonen (Vielecke) und deren Flächen geformt, da reelle Rundungen sehr rechenintensiv sind. So ist es auch bei unseren Panoramen.

Kugelähnlicher Ball aus Polygonen (Drei- und Vierecke):


Es gibt wenige Panorama-Viewer die auch sphärisch darstellen können (z.B. PTViewer und immervision) diese sind aber nicht sehr "leistungsfähig" und neigen zu Darstellungsfehlern im Zenith-/Nadirbereich. Einige Viewer können mit equirectangularen Projektionen umgehen (Pano2VR, krpano, etc. … lange Liste… gibt es u.a. im PanoTools Wiki), diese projizieren das equi-Panorama aber lediglich in ein kugelähnliches Model. Das ist auch bei den "Großen" (Autodesk, Nemetschek,…) so üblich, aber man muss dann die Projektion für dieses Model anpassen. Es muss für dieses Objekt eine Zentralprojektion mit angepasster Projektionfläche erstellt werden, um dann die projizierten Texturen auf die einzelnen Polygonflächen aufzutragen. Dies ist so rechenintensiv das ein normaler Panorama-Viewer das niemals in Echtzeit hinbekommen würde. Ein (nicht soo gutes) Beispiel ist der Detail-Viewer in PTGUI - er ist in der Lage das Panorama gut darzustellen - braucht dafür aber recht lang, also kein flüssiger Bildlauf. Vielleicht kennen auch noch einige den PanoGL Viewer - der ist in der Lage ein equi gut darzustellen, wandelt es aber vorher recht lang um.
Deshalb gehen viele Viewer dort auf einen Kompromiss ein und nutzen das für die Kugel optimierte, equirectangulare Bild und tragen dies auf ein kugelähnliches Polygonen-Konstrukt auf - daher auch die wohl bekannten Wellenlinien in der Darstellung - ist auch hier im Foren Viewer (krpano) zu sehen.

Hier mal ein Beispiel einer equirectangularen Projektion einer Kugel auf dem oben gezeigtem "Polygonen-Ball".
Die Wellenlinie sind deutlich sichtbar, da die Projektion nicht für diese Objekt vorbereitet wurde.


Also - Equirectangular eignet sich nicht sonderlich gut für eine Immersion (virtuelle Darstellung) an einem üblichen Computer-System - (im Planetarium ist das was anderes…)
Polygone müssen her! Und! Die Texturen der Polygone müssen durch die richtige Projektion (Umwandlung des Pixelgitters) vorbereitet werden!
Nun kann man sich an kugelähnlichen Gebilden, wie oben gezeigt oder auch dem PhiloSphere, versuchen - wird aber schnell feststellen das es mit all den "Schnipseln" sehr aufwendig bis unmöglich ist zu arbeiten, geschweige denn Retusche oder Anpassungen durch zu führen.
Außerdem gilt je weniger und gleichförmiger die Polygone, desto leichter ist es das Model zu berechnen.
Da liegt der Würfel mit seinen 6 gleich großen, rechtwinkligen, parallelen Flächen nahe.

Aus rund mach eckig!
Wie geht das?
Da gibt es z.B. ein ganzen Themenbereich drüber - Die Kartografie. Die wollen wir hier aber nicht weiter erwähnen, also bevor ich Euch jetzt erzähle, dass die Erde eine Scheibe ist, oder mir hier die Geocacher "heiss laufen", bleiben wir beim Thema
Um Kugelpanoramen zu Würfeln "zu formen" benutzt man im allgemeinen die gnomonsiche Projektion (oder auch Pano2VR

Dazu wird eine eben Projektionsfläche gewählt und der zu projizierende Körper von seiner Mitte aus (Zentralperspektive) mit einem definierten Winkel "durchleuchtet". Schiebt man diese Projektionsfläche bis an das Objekt heran, erhält man bei 90° Öffnungswinkel (horizontal und vertikal), eine Würfelfläche mit den Kantenlängen "Kugelumfang / Pi". - daher Pi

Um dies zu veranschaulichen habe ich einen Objektfilm vorbereitet.

Waldgnomon

Entfernt man die Projektionsfläche von dem Objekt (Umfang/<Pi) wird die Projektion größer. Das bringt uns aber nichts, da wir mit Pixeln arbeiten und eine Vergrößerung der Projektion nicht zur Erhöhung der Detailauflösung führen würde.

Das heißt, teilt man die Breite eines Panoramas durch Pi erhält man die kleinstmögliche Kantenlänge der Würfelfläche, die ALLE projizierten Details (res. Pixel) enthält!

Das heißt auch, dass eine Würfelfläche mit einer Kantenlänge kleiner als Breite/Pi nicht alle Details enthalten kann, sofern wir mit Pixelgittern zu tun haben.

Was passiert da genau mit unseren Pixeln?
Um uns das dabei durchgeführte Remapping (Verformung des Pixelgitters) etwas besser vor Augen zu führen, habe ich ein equirectangulares Bild mit den Abgrenzungen der Würfelflächen versehen und ein Schachbrett-Muster drüber gelegt. Aus diesem Bild habe ich ein Referenzbild mit FOV=90° (field of view, HFOV & VFOV) geschnitten um es für spätere Vergleiche mit den projizierten Würfelflächen heran zu ziehen.


Bei der gnomonischen Projektion einer pixeligen Kugel wird an dem Punkt, an dem die Projektionsfläche das Objekt berührt, das Pixelgefüge nicht verzerrt. Je weiter ein Pixel von der Projektionsmitte entfernt ist, desto größer ist seine Positionsveränderung innerhalb der Pixelmatrix. - d.h. ab einem auflösungsabhängigen Punkt entstehen Leerräume zwischen den projizierten Pixeln - diese müssen aufgefüllt (interpoliert) werden. Man muss Pixel hinzurechnen! - Dazu später.
Nun haben wir wie oben gezeigt aber keine Kugel sondern ein Panorama im equirectangularem Format - eine Art der zylindrischen Projektion.
Das heißt vor der gnomonischen Projektion wir das equi um eine Kugel gelegt. Dabei entstehen Stauchungen und Streckungen in Nadir- und Zenithbereichen.
Die vertikalen Würfelflächen (entlang des Äquators) erfahren alle die gleiche Deformation des Pixelgitters und sehen wie folgt aus:


Die Zenith- und Nadirflächen werden wesentlich stärker deformiert (fast komplett neu berechnet), es werden Pixel zusammengefügt, die vorher nicht zusammen waren, und es werden sogar Pixelreihen mit kompletter Breite des Panoramas bis auf wenige Pixel (1 oder 4 in der Mitte) reduziert:


...

Die oben erwähnte Auffüllung der Pixel-Leerräume, im äußeren Bereich des Projektionskreises, stellt häufig ein Problem dar. Theoretisch sollte sie sich das ja wieder relativieren wenn man den Würfel dann erneut zentral betrachtet (wie wir am Monitor), dem ist aber leider nicht so. Denn die Interpolations-Algorythmen die bei der Auffüllung der "Pixellücken" und beim Remapping behilflich sind hinterlassen mehr oder weniger starke Aliasing-Effekte (Stufeneffekte), Unschärfen oder Fehlstellen. Das ist auch motivabhängig. Es gibt aber auch kleine "Helferlein" die dabei helfen diesen Effekten entgegen zu wirken - Die Anti-Aliasing-Filter.
Da gibt es eine ganze Reihe, die alle ihre Vor- und Nachteile haben - vor allem überwogen die Nachteile wenn ein Pixelgefüge vergrößert wurde, wie es in den Rand-/Eckenbereichen der Würfelflächen, der Fall ist. Um dem entgegen zu wirken wurde im allgemein dazu geraten die Kantenlänge der Würfelflächen mit Hilfe von Breite/4 zu ermitteln. Da es dann, wie es heißt, zumindest auf der 0°-Linie zu geringeren Deformationen führen würde, da ja die tatsächliche Pixelbreite von einem HFOV=90° erhalten bleibt. Das es sich etwas anders verhält wurde hier im Forum ja schon gezeigt (Ich glaube das war Pano-Toffel).
Eine Verkleinerung der Würfelflächen zur Optimierung der Randbereiche zieht aber auch eine Verkleinerung des Mittenbereiches mit sich - Man entschiedet / entschied sich da also für "das geringere Übel"

Mit der Zeit hat sich das aber etwas geändert - Auch die Filter wurden weiter entwickelt - bzw. mittlerweile haben wir die Rechen-Power für die aufwendigeren Filter, die es früher schon gab, aber einfach nicht alltagstauglich waren. Einige Filter sind sogar so gut, dass die oben genannte Relativierung wieder annähernd stattfinden kann - es kommt beim Betrachten im Viewer zu keinem erkennbaren "Eckeneffekt". - (Allein da gibt es ganze Arbeiten drüber - Auswirkungen von Form und Lage der Projektionsfläche)

Gehen wir doch kurz auf die Größenverhältnisse der Projektionen zueinander ein. Dazu habe ich die Würfelflächen mit dem Referenzbild überblendet.


So betrachtet wird sehr gut deutlich, das bei einer Verkleinerung (unten links), wie es bei Breite/4 der Fall ist, nahezu kein Pixel mehr an seiner ursprünglichen Position der Pixelmatrix aus dem equi zu finden ist - fast das gesamte Bild wird interpoliert und neu berechnet.
An der Überblendung "Breite / Pi & Referenz" (unten rechts) kann man sehr gut sehen, dass es im Mittenbereich nur zu einer leichten Deformation des ursprünglichen Gefüges kommt, wie für eine transversale gnomonische Projektion üblich. Es bleiben dort alle Details erhalten!

Pixelbending - oder auch Pixel bändigen
Kommen wir nun einmal grob zu den Anti-Aliasing Filtern.
Der eine ist eher scharf und neigt zum aliasing, der andere ist eher unscharf hat aber weiche Kanten und flimmert weniger bei Bewegungen. Wieder andere eignen sich besonders zum vergrößern und werden teuer verkauft, dann gibt es wieder welche die sich besonders für Bewegungen (Spiele, Video) eignen. Einige sind sehr rechenintensiv, andere wiederum flink oder werden direkt von der Hardware unterstützt. - Das ist ein Riesenthema - und da gibt es tausendunddrei Meinungen zu…. Am Besten selbst probieren! Für den einen ist der eine Filter "unwirtschaftlich" da zu langsam, der nächste findet sowieso alle Panoramen nicht scharf genug und dann mag der übernächste wieder das Flimmern nicht… - ich mag es eher weich.
Dann ist es auch noch so das einige Viewer und einige Monitore nicht alle Filter "mögen".
Erschreckend ist eigentlich nur, das PS immer noch standardmäßig bicubic einsetzt - absolut nicht zu gebrauchen - für unseren Zweck jedenfalls.
Die vorherige Übersicht ist da schon ein gutes Beispiel - Alles was da besonders "pixelt" ist mit PS gemacht, die rote Linie um das Referenzbild, Schrift und Verbindungen.
Die Ergebnisse einer Pixel-Interpolation sind immer motivabhängig! - Das heisst probieren ist angesagt. Was bei Teppich oder Parkett gut aussieht, ist bei Stein u.U. ungeeignet und überzeichnet, oder aber, es kommt bei Teppich o.ä. feinen Strukturen zu unscharfen Überblendungen.
Wenn man auf nicht zurückführbare Probleme beim Stichen oder Blending trifft ist der Interpolator oft ein guter Ansatz (Feather). Interpolation ist eine nicht unwesentliche Aufgabe für unsere Stitchsoftware!
Bei PTGUI kann man grob sagen, je weiter unten in der Liste, desto besser und langsamer sind die Filter
Hier mal einige Beispiele zu Interpolations-Filtern:
Ich habe dafür das Nadirbild verwendet, da es wie oben erwähnt nahezu komplett remaped wird - da wird auch gut sichtbar wie die Qualität beim Verkleinern ist.
Das erste kommt dem PS standard sehr nahe…
Mitchell ist recht schnell, eher weich und wird von vielen bei Bewegung als angenehm empfunden.
Die unteren beiden sind eher Schärfen und Krümmungen optimiert - brauchen aber auch deutlich länger und neigen zu Flimmern.


Beachten sollte man dann noch, das nicht unbedingt jedes Programm dazu geeignet ist ein Panorama zu remapen (Pixel verschieben) - das gilt auch für vergrößern oder verkleinern, schärfen und tonemapping - das Programm sollte schon den späteren Verwendungszweck kennen und berücksichtigen, um angewandte Filter und Interpolationen den Deformationsbereichen anzupassen. - Das heisst Panos besser mit Pano2VR, PTGUI,… in der in der Größe Anpassen.
Und, unnötiges Remapping vermeiden - nicht hin und her Wandel und vorher überlegen welche Größe man benötigt, um sie direkt ausgeben zu lassen.

So, was denn nun?

Pi or not to pi?

Nee, wieder keine Antwort!
Die gibt es wohl auch nicht so pauschal.
Fakt ist, will man alle mühevoll eigefangenen Details auch wieder darstellen, für irgendwelche Gigapixel Geschichten, oder so, kommt man an Breite/Pi nicht vorbei.
Fakt ist aber auch, das man dann auch generierten "Pixelmüll" mit abspeichert.
Letztlich ist es eine Frage der Vorliegenden Auflösung und dem späteren Verwendungszweck. Wenn man ein Objektiv mit stärken Randunschärfen hat, wo dann wohlmöglich Stitchbereich und Projektions-Deformation in einen Bereich fallen, sollte man vielleicht nicht noch unbedingt den Rand weiter entschärfen indem man Breite/Pi verwendet, und auf 4 zurückgreifen. Erhält man ein so großes equi, dass man eh immer verkleinert, stellt sich die Frage auch nicht.
Ich wandele mit Pi, weil ich die zusätzlichen Pixel gut gebrauchen kann, außerdem achte ich eh meist darauf, die "Hauptmotive" möglichst mittig an zu ordnen, auch schon bei der Aufnahme. Die zusätzliche Rechenzeit für eine gute Interpolation nehme ich gern in Kauf - ist ja auch relativ

Viele Grüße
Daniel