Diplomarbeit Nichtlineare Texturprojektion mit Java3D und OpenGL Frank Wippermuller ¨

Betreuer: Dipl.Ing. Jan-Friso Evers-Senne Institut fur ¨ Informatik und Praktische Mathematik der ¨ zu Kiel Christian-Albrechts-Universitat Multimediale Systeme zur Informationsverarbeitung Prof. Dr.-Ing. Reinhard Koch

¨ 2002 04. Marz

Inhaltsverzeichnis 1 Einleitung

1

2 Grundlagen

3

2.1

2.2

Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

Primitive . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

Clipping . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.3

Texturen und Texturprojektion . . . . . . . . . . . . . . .

6

Projektive Geometrie . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.1

Projektiver Raum . . . . . . . . . . . . . . . . . . . . . .

9

2.2.2

Zusammenhang zwischen euklidischen und homogenen Koordinaten . . . . . . . . . . . . . . . . . . . . . . . . .

9

Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.1

Szenenparameter . . . . . . . . . . . . . . . . . . . . . .

10

2.3.2

Der Visualisierungsprozess . . . . . . . . . . . . . . . . .

12

2.4

Das Kameramodell . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.5

O PEN GL und JAVA 3D . . . . . . . . . . . . . . . . . . . . . . .

17

2.3

3 Berechnung und Darstellung von Panoramen 3.1

3.2

19

Rotational Mosaicing . . . . . . . . . . . . . . . . . . . . . . . .

21

3.1.1

Registrierung . . . . . . . . . . . . . . . . . . . . . . . .

22

3.1.2

Iterative Sch¨atzung . . . . . . . . . . . . . . . . . . . . .

23

3.1.3

Rotationsmodell . . . . . . . . . . . . . . . . . . . . . .

23

3.1.4

Realisierung des Rotational Mosaicing . . . . . . . . . .

26

Darstellung des Panoramas . . . . . . . . . . . . . . . . . . . . .

27

iii

iv

4

5

6

INHALTSVERZEICHNIS 3.2.1

Aufbau eines Texturtr¨agers . . . . . . . . . . . . . . . . .

28

3.2.2 3.2.3

Texturzuweisung . . . . . . . . . . . . . . . . . . . . . . 31 ¨ Uberlappungsbereiche . . . . . . . . . . . . . . . . . . . 32

3.2.4

Mittelwertfilter . . . . . . . . . . . . . . . . . . . . . . .

34

3.2.5

Radialfilter . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.2.6

Optimierung des Speicherbedarfs des Radialfilters . . . .

39

Interaktiver Ausgleich von Linsenverzerrungen

41

4.1

Berechnung von Linsenverzerrungen . . . . . . . . . . . . . . . .

42

4.2

Berechnung der einfachen radialen Entzerrungsfunktion . . . . . .

43

4.3

Visueller Ausgleich von Linsenverzerrungen . . . . . . . . . . . .

44

Ergebnisse und Diskussion

47

5.1

Beispiele f¨ur Panoramen . . . . . . . . . . . . . . . . . . . . . .

47

5.2

Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.2.1

51

Vergleich der Filter . . . . . . . . . . . . . . . . . . . . .

Zusammenfassung

A Implementierung

55 57

A.1 Das IVT-Plugin SpherePart3D . . . . . . . . . . . . . . . . . . .

57

A.2 Interactive Mosaic Viewer (IMV) . . . . . . . . . . . . . . . . . .

58

A.3 Interactive Undistorter (IU) . . . . . . . . . . . . . . . . . . . . .

60

Danksagungen

63

Erkl¨arung

65

Kapitel 1 Einleitung Die digitale Bildverarbeitung besch¨aftigt sich mit der Verarbeitung von Kameraaufnahmen zur Rekonstruktion aufgenommener Szenen. Eine vereinfachte An¨ wendung ist die Erzeugung von Ubersichtsbildern durch Zusammensetzen der ¨ aufeinander folgenden Einzelbilder. Solche Ubersichtsbilder werden Panoramen oder Mosaike genannt. Panoramen bilden einen gr¨oßeren r¨aumlichen Darstellungswinkel einer Szene ab, als es mit einer Darstellung von Einzelbildern einer Sequenz nacheinander m¨oglich w¨are. Anwendungsbeispiele von Panoramen gibt es viele, sie reichen von klassischen zusammengesetzten Luft- und Satellitenaufnahmen bis hin zur medizinischen Nutzung durch eine Zusammensetzung von aufgenommenen Teilen des Augenhintergrundes. Die Hauptaufgabe der Erstellung von Panoramen besteht in der Registrierung gleicher, d.h. sich u¨ berlappender, Bildteile. Diese Information ist neben der Panoramaerzeugung noch f¨ur andere Anwendungen, wie die Kompression von Bilddaten oder die Erh¨ohung der Aufl¨osung, verwendbar. Der Schwerpunkt dieser Arbeit liegt auf der effizienten interagierbaren Darstellung der berechneten Panoramen durch eine Nutzung von 3D-Hardware-Beschleunigung, genauer: durch eine lineare Interpolation einer nichtlinearen Texturprojektion auf eine Projektionsfl¨ache in einem virtuellen Raum durch O PEN GL bzw. JAVA 3D. Die Interaktion besteht dabei in einer Explorationsm¨oglichkeit der 1

2

Kapitel 1. Einleitung

virtuellen Szene durch den Betrachter, d.h. der Betrachter kann sich innerhalb der Szene frei bewegen, die Szene kann rotiert werden und der Darstellungswinkel l¨asst sich anpassen. F¨ur die eigentliche Berechnung der Panoramen wird das so genannte Rotational-Mosaicing-Verfahren [SS97] verwendet. Ein weiterer Schwerpunkt dieser Arbeit besteht im Ausgleich von radial durch die Kameralinse verzerrten Bildern in Echtzeit. Dies l¨asst sich analog zur Darstellung der Panoramen durch eine hardwarebeschleunigte lineare Interpolation einer nichtlinearen Texturprojektion durch O PEN GL bzw. JAVA 3D l¨osen. Im folgenden Kapitel werden die mathematischen und geometrischen Grundlagen wie die projektive Geometrie, das verwendete Kameramodell und die grundlegenden Eigenschaften von O PEN GL und JAVA 3D eingef¨uhrt. Anschließend wird ein Verfahren zur Erzeugung und Darstellung von Panoramen aus einer Sequenz von Einzelbildern vorgestellt. Kapitel 4 beschreibt eine radiale Entzerrung von Kamerabildern, die durch Nutzung von 3D-Hardware-Beschleunigung in Echtzeit durchgef¨uhrt werden kann. Das f¨unfte Kapitel pr¨asentiert beispielhaft Ergebnisse, die unter Nutzung der im Rahmen dieser Arbeit entwickelten Software entstanden sind. Ferner begr¨undet das Kapitel, warum O PEN GL bzw. C++ gegen¨uber JA VA 3D als Basis f¨ ur die Implementierung bevorzugt wurde. Zum Schluss folgt eine

Zusammenfassung und schließlich ein Anhang, der zusammengefasst die wichtigsten Klassen und Strukturen der entwickelten Software vorstellt.

Kapitel 2

Grundlagen

Ein Schwerpunkt der in dieser Arbeit verwendeten Verfahren ist eine effiziente Darstellung durch Nutzung von 3D-Hardwarebeschleunigung. Um diese verwenden zu k¨onnen, m¨ussen die entsprechenden Software-Schnittstellen – in dieser Arbeit wurden daf¨ur O PEN GL und JAVA 3D gew¨ahlt – angesprochen werden. Die¨ ses Kapitel wird eine kurze Ubersicht u¨ ber die beiden Schnittstellen geben und die Grundlagen erl¨autern, die f¨ur deren Nutzung n¨otig sind.

Abschnitt 2.1 erl¨autert die grundlegenden Begriffe, die im weiteren Verlauf der Arbeit verwendet werden und Abschnitt 2.2 gibt eine kurze Einf¨uhrung in die projektive Geometrie. Der darauf folgende Abschnitt 2.3 unterteilt die Parameter¨ubergabe an die Schnittstellen in seine einzelnen Schritte und erl¨autert diese, ¨ und gibt anschließend einen kurzen Uberblick u¨ ber den eigentlichen Prozess der Visualisierung, der intern mit den u¨ bergebenen Parametern stattfindet. Schließlich stellt Abschnitt 2.4 das im weiteren Verlauf der Arbeit verwendete Kameramodell ¨ vor, und der letzte Abschnitt, 2.5, gibt eine kurze Ubersicht u¨ ber die wesentlichen Unterschiede von O PEN GL und JAVA 3D. 3

4

Kapitel 2. Grundlagen

2.1 2.1.1

Grundbegriffe Primitive

Szenen, die durch 3D-Hardware beschleunigt werden sollen, m¨ussen aus direkt durch die Hardware unterst¨utzten Objekten, so genannten Primitiven, bestehen. Im Falle von O PEN GL und JAVA 3D handelt es sich dabei um Punkte, Linien und konvexe Polygone beliebiger Eckenzahl. Die Punkte, Linienendpunkte und Polygonecken werden im Folgenden Knoten, Linien und Polygonkanten werden Kanten genannt. Abschnitt 2.3.2 erl¨autert die Schritte der Visualisierung, unter anderem die so genannte Rasterisierung. Unter einem gerasterten Primitiv wird im Folgenden die zweidimensionale Form eines Primitivs nach dem Rasterisierungsschritt verstanden.

2.1.2

Clipping

Bei der Visualisierung einer Szene kann nur ein Ausschnitt des tats¨achlichen Umfangs der Szene dargestellt werden. Dieser Ausschnitt wird durch ein Sichtvolumen definiert, dessen R¨ander die Darstellungsfl¨ache eingrenzen. Es muss sich dabei nicht zwangsl¨aufig um einen quaderf¨ormigen Bereich handeln, bei der perspektivischen Projektion etwa besteht das Sichtvolumen aus einem Pyramidenstumpf (s. Abschnitt 2.2). Um ein fehlerfreies Bild zu erhalten, muss die außerhalb des Volumens liegende Bildinformation abgeschnitten bzw. verworfen werden. Dieser Prozess des Zurechtschneidens der Szenenobjekte bzw. Primitive wird Clipping, das begrenzende Volumen Clippingvolumen und im Falle eines zweidimensionalen Clippings der begrenzende Bereich Clippingbereich genannt. Bei O PEN GL werden die Primitive gegen ein normiertes Sichtvolumen, das so genannte kanonische Sichtvolumen, geclippt, das durch Anwendung der perspektivischen bzw. Parallel-Projektion entsteht und dessen normierte Form das Clipping gegen¨uber der allgemeinen Form deutlich vereinfacht. F¨ur die Punkte p = (x, y, z, w) in homogenen Koordinaten, die sich innerhalb dieses normierten

2.1. Grundbegriffe

5

Sichtvolumens befinden, gilt: −w ≤ x, y, z ≤ w. Stellt man fest, dass sich mindestens ein Knoten eines Primitivs außerhalb des Clippingvolumens befindet, und sich ferner alle seine Kanten nicht mit dem Clippingvolumen schneiden, kann das Primitiv nur komplett außerhalb liegen. Dann kann es komplett von der Darstellung bzw. weiteren Verarbeitung ausgeschlossen und damit als Nebeneffekt des Clippings Rechenzeit gespart werden. Sind allerdings Schnittpunkte vorhanden, m¨ussen die Knoten, die außerhalb des Clippingvolumens liegen, entfernt und daf¨ur Ersatz-Knoten an den Kanten des Clippingvolumens zum zu clippenden Primitiv hinzugef¨ugt werden. Abbildung 2.1 verdeutlicht diesen Schritt. Ein effizienter Algorithmus, der ein beliebiges Polygon an einem zweidimensionalen Viereck clippt, ist etwa der Liang-Barsky-Algorithmus. Dieser Algorithmus wird in der Literatur oft beschrieben, u.a. in [FvDH91], und kann relativ einfach auf den dreidimensionalen Fall erweitert werden.

Abbildung 2.1: Clipping eines Dreiecks, das sich teilweise außerhalb des Clippingbereichs befindet, im zweidimensionalen Fall. Es entsteht das dunkel gezeichnete Viereck.

Ein Test, ob sich ein Primitiv komplett außerhalb des Clippingvolumens befindet, kann etwa durch Anwendung der dreidimensionalen Erweiterung des CohenSutherland-Testes effizient erfolgen, der die Umgebung des Clippingvolumens in sechs Zonen einteilt, denen jeweils ein Bit zugeordnet wird. Durch Schnittbildung der Zonenbits je zweier Knoten kann dann eine triviale Akzeptanz bzw. Ablehnung jeder Kante und damit des ganzen Primitivs1 berechnet werden. 1

Es gibt F¨alle, in denen der Cohen-Sutherland-Test nicht eindeutig sagen kann, ob sich eine

Linie komplett außerhalb des Clippingvolumens befindet. In diesen F¨allen wird trotzdem von ei-

6

Kapitel 2. Grundlagen

2.1.3

Texturen und Texturprojektion

Ein wesentlicher Bestandteil dieser Arbeit ist die Abbildung von Bildern auf Oberfl¨achen bzw. im Kontext von O PEN GL und JAVA 3D auf Primitivoberfl¨achen. Diesen Prozess nennt man Texturprojektion oder auch Texturierung, die zu projizierenden Bilder Texturen. Die einzelnen Bildpunkte der Textur heißen Texel. Texturen werden innerhalb eines eigenen zweidimensionalen (u, v)-Koordinatenraums, den so genannten Texturkoordinaten, 0 ≤ u, v ≤ 1, definiert. F¨ur O PEN GL und JAVA 3D gilt zus¨atzlich, dass die Texturen in einer Breite und H¨ohe vorliegen m¨ussen, die jeweils einer Potenz zur Basis Zwei entsprechen. Grundlage f¨ur die Texturprojektion sind im Vorfeld f¨ur jeden Primitivknoten festgelegte Texturkoordinaten. Es gibt mehrere Techniken zur Texturprojektion, die sich haupts¨achlich in der Art und G¨ute der perspektivischen Korrektur und der Filterung unterscheiden. Der erste Ansatz zur Texturprojektion stammt von Catmull [Cat74] und wurde von Blinn und Newell [BN76] verfeinert. Da in dieser Arbeit ein Schwerpunkt auf die Hardwarebeschleunigung gelegt wird, soll im Folgenden der Algorithmus beschrieben werden, der bei den g¨angigen Grafikkarten angewandt und durch entsprechende O PEN GL-Implementierungen delegiert wird. Perspektivische Korrektur Die Texturprojektion wird auf das zweidimensional abgebildete Primitiv angewendet. Ein naiver Ansatz w¨urde einfach linear die Texturkoordinaten zwischen den Knoten interpolieren und damit f¨ur jeden Pixel eine Texturkoordinate erhalten. Dieser liefert aber nur ein korrektes Ergebnis, wenn das jeweilige Primitiv parallel zur Ebene des Betrachters liegt, in den anderen F¨allen l¨asst die fehlende perspektivische Verk¨urzung das Bild verzerrt erscheinen, da die Tiefenwerte z im allgemeinen Fall nicht linear im Abbildungsraum, d.h. nicht linear in Fensterkoordinaten, sind. Eine L¨osung f¨ur dieses Problem liefert die Beobachtung von Moreton [HM91]: 1/z ist linear im Abbildungsraum, und damit auch nem Schnittpunkt ausgegangen, der bei einer der Berechnung anschließenden Relevanzpr¨ufung auf seine G¨ultigkeit u¨ berpr¨uft und gegebenenfalls verworfen werden muss.

2.1. Grundbegriffe

7

u/z und v/z. Speichert man nun f¨ur jeden Knoten des Primitivs die Parameter (r1 , r2 , r3 ) = (u/z, v/z, 1/z) und interpoliert linear zwischen den Knoten, k¨onnen f¨ur jeden Pixel die perspektivisch korrekten Texturkoordinaten berechnet werden, indem die beiden interpolierten ersten Parameter durch den interpolierten dritten Parameter geteilt werden. Sollen weitere Rasteroperationen wie Schattierung etc. angewendet werden, k¨onnen sie ebenfalls mittels dieser Methode perspektivisch korrekt durchgef¨uhrt werden. Dazu muss die Parameterliste nur um die jeweiligen zu interpolierenden Operationsparameter, geteilt durch z, erweitert werden. In der Regel ist die perspektivische Verzerrung aber nur bei der Texturprojektion so auff¨allig, dass der Aufwand der zus¨atzlichen Divisionen lohnt. Im Zuge der Texturprojektion mit perspektivischer Korrektur wird f¨ur jeden Pixel u.a. sein Tiefenwert bzw. der 1/z-Wert gewonnen. Da ein z-Puffer-Algorithmus diese Information auch ben¨otigt, kann dieser Schritt nach einer Texturprojektion gespart werden. Filterung Texturen sind rechteckig, aber nachdem sie auf ein Primitiv projiziert und in Fensterkoordinaten transformiert wurden, entsprechen die einzelnen Texel nur selten den einzelnen Bildschirmpixeln. Je nach der benutzten Transformation kann ein einzelnes Bildschirmpixel alles zwischen einem kleinen Teil eines Texels (Vergr¨oßerung) bis zu einer großen Menge von Texeln (Verkleinerung) umfassen. In beiden F¨allen ist es unklar, welche und zu welchem Anteil Texelwerte verwendet werden sollen. Die Festlegung dieser Berechnungen wird Filterung genannt. O PEN GL bietet zwei Vorgehensweisen der Filterung an: 1. Wahl des Texels, das der Texturkoordinate des darzustellenden Pixels am n¨achsten kommt (auch bekannt als nearest-neighbour) 2. bilineare Interpolation eines 2 × 2-Arrays von Texeln, die der Texturkoordinate des darzustellenden Pixels am n¨achsten kommen. Beide Methoden k¨onnen getrennt f¨ur den Vergr¨oßerungs- und Verkleinerungsfall ausgew¨ahlt werden.

8

Kapitel 2. Grundlagen Eine Verbesserung bzw. Verfeinerung der skizzierten Methoden stellt das so

genannte MIP-Mapping dar. Dabei werden zu jeder Textur zus¨atzlich verkleinerte Versionen gespeichert, und bei der Texturierung f¨ur jeden Pixel eine Auswahl getroffen, welcher Miniaturisierungsgrad verwendet wird. Auch hier kann eine Optimierung durch eine lineare Interpolierung von zwei benachbarten MIP-MapGraden erreicht werden. Blending und Alphamaps Nachdem Primitive projiziert und texturiert wurden, werden die resultierenden Fragmente in den Darstellungspuffer geschrieben. Statt sie einfach zu kopieren, k¨onnen sie aber auch mit den schon vorhandenen Werten im Puffer kombiniert bzw. addiert werden. Der Prozess der Kombination der Farbwerte wird Blending genannt. Dazu wird f¨ur jeden Pixel im Puffer eine zus¨atzliche Komponente, der Alphawert α, 0 ≤ α ≤ 1, gespeichert. Der Alphawert gibt den Wert an, mit dem die dazugeh¨origen Farbkomponenten bei einer Kombination mit den alten Pufferwerten, die ihrerseits durch die alten Alphawerte gewichtet werden, gewichtet werden sollen. Wird z.B. ein Pixel des Darstellungspuffers, dem ein Alphawert von 0.7 zugewiesen wurde, mit einem Pixel mit Alphawert 0.3 kombiniert, so ist das Ergebnis eine Addition des 70%-gen Farbwertes des alten Pixels im Puffer mit dem 30%-gen Wert des hereinkommenden neuen Pixels. Eine Anwendung des Blendings, die auch in dieser Arbeit verwendet wird (s. Abschnitt 3.2.3.1), ist z.B. die Mittelwertbildung mehrerer texturierter Objekte. Jedem Texel einer Textur kann ein eigener Alphawert und damit eine eigene Gewichtung zugewiesen werden. Dazu muss eine so genannte Alphamap erzeugt werden, die f¨ur jedes Texel der Textur den dazugeh¨origen Alphawert definiert.

2.2

Projektive Geometrie

Die projektive Geometrie bettet den euklidischen Raumes in den projektiven Raum ein. Dadurch ist es m¨oglich, z.B. Translationen und perspektivische Projektionen durch eine Matrixmultiplikation in homogenen Koordinaten darzustellen [Woe01].

2.2. Projektive Geometrie

2.2.1

9

Projektiver Raum

Der n-dimensionale projektive Raum Pn kann mathematisch als die Menge aller eindimensionalen Unterr¨aume eines (n + 1)-dimensionalen Vektorraums V (n+1) verstanden werden. Anschaulich kann man sich P als den Raum der Geraden durch den Ursprung vorstellen. Diese Geraden werden Punkte des projektiven Raumes genannt. Ein Punkt x ist in einem n-dimensionalen projektiven Raum Pn somit durch einen Vektor der L¨ange (n + 1) gegeben. Die Koordinaten des Punktes x = [x1 , . . . , xn+1 ] ∈ Pn nennt man homogene oder auch projektive Koordinaten. Der Nullvektor sei dabei kein Element von Pn , d.h. mindestens eine Komponente der homogenen Koordinaten muss ungleich Null sein. Da die Punkte eines euklidischen Raumes Rn in einen projektiven Raum Pn h¨oherer Dimension eingebettet sind, ergibt sich eine Besonderheit f¨ur die Gleichheit von Punkten: Zwei Punkte x, y ∈ Pn nennt man genau dann gleich, wenn es ein Skalar 0 6= λ ∈ R gibt, so dass f¨ur alle 1 ≤ i ≤ (n + 1) : xi = λyi gilt [Woe01]. Die homogenen Koordinaten eines Punktes sind also nur bis auf einen skalaren Faktor festgelegt, so dass ein euklidischer Punkt in homogenen Koordinaten nicht eindeutig festgelegt ist, sondern sich mit verschiedenen Koordinaten darstellen l¨asst. Die Gleichheit bezieht sich also nicht auf die Werte seiner Koordinaten sondern vielmehr auf den mit ihm im euklidischen Raum korrespondierenden Punkt (sofern dieser existiert) bzw. die Richtung des Vektors.

2.2.2

Zusammenhang zwischen euklidischen und homogenen Koordinaten

F¨ur jeden Punkt eines euklidischen Raumes gibt es also eine Menge von gleichen homogenen Koordinaten, die sich nur durch einen skalaren Faktor unterscheiden. In sp¨ateren Betrachtungen wird nur P3 benutzt. F¨ur diesen Raum wird der Zusammenhang zwischen euklidischen und homogenen Koordinaten im Folgenden dargestellt.

10

Kapitel 2. Grundlagen

Von euklidischen zu homogenen Koordinaten Ein Raumpunkt in euklidischen Koordinaten Pe ∈ R3 l¨asst sich als ein Punkt im projektiven Raum Ph ∈ P3 darstellen:   xe    Pe =  y e   ze

⇒

  xe    ye   Ph = λ  z  ,  e 1

(2.1)

mit λ ∈ R. F¨ur jedes λ 6= 0 wird der gleiche Punkt P dargestellt, f¨ur λ = 0 liegt der Spezialfall des Nullvektors vor. Dieser ist nach Definition jedoch nicht im projektiven Raum enthalten.

Von homogenen zu euklidischen Koordinaten Projektive Koordinaten lassen sich nur in euklidische Koordinaten umwandeln, wenn der Wert des letzten Elements w einer projektiven Koordinate Ph ungleich Null ist. Dann ergibt sich die Abbildung eines Punktes Ph in euklidische Koordinaten wie folgt:   xh    yh  4  Ph =   z  ∈ R ∧ w 6= 0  h w

 ⇒

Pe =



xh  yw   h w zh w

(2.2)

2.3 Visualisierung 2.3.1

Szenenparameter

Um eine Szene mit O PEN GL bzw. JAVA 3D zu visualisieren, muss sie in Form von Parametern der jeweiligen Schnittstelle u¨ bergeben werden. Dieser Prozess der Parameter¨ubergabe kann in die folgenden gemeinsamen Hauptschritte eingeteilt werden [WNDS99]:

2.3. Visualisierung

11

1. Erzeugung von Objekten bzw. zusammengesetzten Primitiven innerhalb eines virtuellen dreidimensionalen Raums. Dienen diese als Texturtr¨ager – in der Praxis meistens der Fall – , m¨ussen ihnen Texturen bzw. ihren Knoten Texturkoordinaten zugewiesen werden. 2. Angabe der Transparenz bzw. Alphawerte der Primitive. Es gibt mehrere M¨oglichkeiten, dies zu tun: a) Die Transparenz wird einmalig vor dem Zeichnen des Primitivs festgelegt. Dann gilt sie f¨ur das gesamte Primitiv. b) F¨ur jeden Knoten kann einzeln eine Transparenz bestimmt werden. Dann wird die tats¨achliche Transparenz f¨ur Punkte zwischen den Knoten interpoliert. c) F¨ur jedes Texel der Textur kann eine Transparenz durch ein entsprechendes Pixel einer Alphamap festgelegt werden. 3. Festlegung der Beleuchtung, d.h. der Positionen der Lichtquellen und der Art des Lichtes. Im Allgemeinen werden im Falle von vorhandenen Lichtquellen den Primitiven Materialien bzw. Lichtbrechungseigenschaften zugeordnet. Da im weiteren Verlauf der Arbeit keine Beleuchtung eingesetzt wird, soll in diesem Kapitel von einer Vertiefung der Beleuchtungsmechanismen abgesehen werden. 4. Angabe der Position und der optischen Achse des Betrachters / der virtuellen Kamera 5. Festlegung des Sichtvolumens durch Angabe des Blickwinkels (engl. Field of View) und der near- und far-clipping-plane. Der daraus entstehende Pyramidenstumpf, der den darzustellenden Inhalt begrenzt, stellt die perspektivische Form der Projektion dar2 . Abbildung 2.2 veranschaulicht diese Projektionsform.

2

Tats¨achlich ist bei O PEN GL bzw. JAVA 3D jede beliebige Form der Projektionsmatrix, z.B.

auch eine orthographische Projektion, m¨oglich, nicht nur die der perspektivischen Projektion.

12

Kapitel 2. Grundlagen near−clipping−plane

far−clipping−plane

FOVy

Abbildung 2.2: Betrachtungs-Volumen bei einer perspektivischen Projektion. Dabei bezeichnet FOVy den vertikalen Darstellungswinkel.

2.3.2

Der Visualisierungsprozess

Im Folgenden wird davon ausgegangen, dass JAVA 3D auf O PEN GL aufbaut oder wenigstens auf einer Schnittstelle aufsetzt, die sich nicht wesentlich hinsichtlich der Visualisierungsreihenfolge von O PEN GL unterscheidet3 . Dann kann f¨ur beide Schnittstellen der interne Prozess der Visualisierung durch folgende Schritte beschrieben werden, bei denen die u¨ bergebenen Szenenparameter verarbeitet werden: • Transformationen der Primitiv- bzw. Struktur-Knoten: 1. Translation bzw. Rotation der Knoten der Primitive entsprechend der Betrachterposition und der optischen Achse. Dazu kann man sich leicht klarmachen, dass eine Bewegung der Betrachterposition einer entgegengesetzten Bewegung der Primitive gleichkommt. Die so entstandenen Koordinaten werden Augkoordinaten genannt. 2. Anwendung der Projektion, d.h. der Parallel- oder perspektivischen Projektion, auf die Punkte in Augkoordinaten. Das Sichtvolumen wird dadurch normiert, es entsteht das so genannte kanonische Sichtvolumen mit homogenen Koordinaten: Alle Punkte p = (x, y, z, 1) ∈ R4 3

Tats¨achlich ist in der Praxis O PEN GL eine h¨aufig verwendete Basis f¨ur JAVA 3D.

2.3. Visualisierung

13

innerhalb des Sichtvolumens werden auf die Punkte p0 = (x0 , y 0 , z 0 , w0 ), die so genannten Clipping-Koordinaten, mit −w0 ≤ x0 , y 0 , z 0 ≤ w0 , innerhalb des kanonischen Sichtvolumens abgebildet. Im Falle der perspektivischen Projektion wird w0 = z, bei der Parallelprojektion w0 = 1 gesetzt. 3. Clipping gegen das Sichtvolumen: Die Kanten der Primitive in ClippingKoordinaten werden auf ihre Schnittpunkte mit dem kanonischen Sichtvolumen untersucht. Gibt es keine Schnittpunkte und liegt mindestens ein Knoten außerhalb des kanonischen Sichtvolumens, muss das Primitiv nicht dargestellt bzw. weiter verarbeitet werden. Bei vorhandenen Schnittpunkten muss das Primitiv gem¨aß Abschnitt 2.1.2 angepasst werden. Die Parameter wie Texturkoordinaten etc. der neuen bzw. ver¨anderten Knoten werden durch lineare Interpolation der Parameter der Originalknoten, auf deren Kante die neuen Knoten liegen, gewonnen. 4. Perspektivische Teilung der Punkte in Clipping-Koordinaten: p00 = 0

0

0

0

(x00 , y 00 , z 00 , 1) = ( wx 0 , wy 0 , wz 0 , w ), f¨ur w0 6= 0. Es entstehen normierw0 te Koordinaten. Das kanonische Sichtvolumen wird dadurch in das so genannte normierte Sichtvolumen u¨ berf¨uhrt, einen W¨urfel mit Kantenl¨ange 2, der zentral im Ursprung liegt. 5. Viewport-Transformation: Die Viewport-Transformation berechnet aus den normierten Koordinaten die Bildschirm-Koordinaten. Der Viewport gibt einen rechteckigen Ausschnitt des Bildschirms an, in dem das Bild dargestellt wird. Seine Gr¨oße wird ausgedr¨uckt in FensterKoordinaten, in die die normierten Koordinaten durch die ViewportTransformation u¨ berf¨uhrt werden. • Rasterisierung: Die Rasterisierung konvertiert ein projiziertes, durch die Viewport-Transformation skaliertes Primitiv in eine Reihe von so genannten Fragmenten“. Jedes Fragment besteht aus seinen Bildschirm-Koordinaten, ” seiner Farbe, seiner Transparenz und seiner Tiefe. Unter Ber¨ucksichtigung

14

Kapitel 2. Grundlagen

Betrachter− abhängige Transformation

projektive Transformation

Aug−Koordinaten

perspektivische Teilung

Clipping−Koordinaten

Viewport− Transformation

normalisierte Koordinaten

Fenster−Koordinaten

Abbildung 2.3: Die Transformationsschritte der Visualisierung.

von z.B. Linienstil, Linienst¨arke und Punktgr¨oße wird bestimmt, welche Pixel in Fenster-Koordinaten von den einzelnen Primitiven bedeckt werden und f¨ur die damit Fragmentinformationen berechnet werden m¨ussen. Diese Informationen werden aus Operationen gewonnen, die direkt auf den Fragmenten arbeiten. Dazu z¨ahlt u.a. die Projektion der jeweiligen Texturen auf die Fragmente der Primitive, die bei geeigneter Implementierung neben den Farb- und Transparenzwerten auch die Tiefenwerte liefert. Weitere Fragmentoperationen sind z.B. Nebel (d.h. ein Ausblenden mit zunehmender Tiefe) und Antialiasing (d.h. eine Ber¨ucksichtigung des Abdeckungsgrades eines Pixels durch ein Fragment), die in dieser Arbeit aber nicht weiter behandelt werden. Schließlich werden die Fragmente unter Ber¨ucksichtigung der Transparenzwerte in den Darstellungspuffer bzw. in den Viewport kopiert bzw. addiert. Bei aktiviertem z-Puffer wird ein Fragment nur dann geschrieben, wenn sein Tiefenwert kleiner als der entsprechende bisherige Wert im z-Puffer ist.

2.4 Das Kameramodell Eine Kamera wird idealisiert durch eine Lochkamera beschrieben, die durch Zentralprojektion eine dreidimensionale Szene auf eine zweidimensionale Bildebene abbildet. Eine Lochkamera hat keine Linse sondern eine unendlich kleine Lochblende, durch die die Lichtstrahlen der Szene auf die Bildebene fallen. Eine un¨ endlich kleine Offnung existiert nat¨urlich nur in der Theorie. Da schon sehr kleine

2.4. Das Kameramodell

15

L¨ocher zu Beugungsfehlern f¨uhren, und gr¨oßere Lochblenden keine scharfen Abbildungen mehr zulassen [Eve01], kommen in der Praxis Objektive aus einer oder mehreren Linsen zum Einsatz. Der wesentliche Unterschied zur Lochkamera besteht darin, dass eine Linse nur diejenigen Objektpunkte scharf auf die Bildebene abbildet, die sich in einer bestimmten Entfernung, der Objektweite, vor der Kamera befinden. Im Folgenden wird von einer digitalen Kamera mit einer Aufl¨osung von w × h Pixeln und einer idealer Linse ohne Abbildungsfehler ausgegangen. Dabei sei w die horizontale und h die vertikale Komponente der Aufl¨osung.

Innere Kameraparameter Ein Kamerasensor liefert im Allgemeinen Daten in einem eigenen diskreten Pi¨ xelkoordinatensystem, dessen Uberf¨ uhrung in Kamerakoordinaten nur von den inneren Kameraparametern abh¨angig ist [Woe01]. Dazu geh¨oren das Kamerazentrum, die Brennweite der Linse und die horizontale und vertikale Aufl¨osung des Kamerasensors, die in der so genannten Kamerakalibriermatrix K zusammengefasst werden. Im Folgenden wird ausf¨uhrlicher auf die einzelnen Parameter eingegangen. Eine Linse ist gekennzeichnet durch ihre Brennweite (engl. focal length) f , ¨ den Abstand des Linsenhauptpunktes zu ihrem Brennpunkt. Ublicherweise ist sie auf den Objektiven aufgedruckt und in Millimetern angegeben. Sie ist ein Maß ¨ f¨ur den Offnungswinkel der Kamera bzw. f¨ur den Maßstab des Objektivs. Kennt man die Breite Bx und H¨ohe By des Kamerasensors, l¨asst sich aus der Brennweite ¨ leicht der Offnungswinkel α bzw. β des Objektivs in horizontaler bzw. vertikaler Richtung bestimmen (siehe dazu auch die geometrische Darstellung in Abbildung 2.4): α = 2 cot−1

 2f  Bx

,

β = 2 cot−1

 2f  By

(2.3)

¨ Im Kontext dieser Arbeit sollen die Offnungswinkel berechenbar sein, ohne dass man die Sensorgr¨oßen kennt. Dazu wird im Folgenden von der klassischen

16

Kapitel 2. Grundlagen Objekt

Hauptebene f 1 β 2

F’

Brennebene

f

Brennpunkt

M F

optische Achse

Bild

Brennpunkt Linse Brennebene

Mittelpunkt

Abbildung 2.4: Das Linsenmodell der Kamera.

Definition der Brennweite abgewichen. Sei fx :=

α f 1 = cot , Bx 2 2

fy :=

β  f 1 = cot , By 2 2

(2.4)

dann bezeichnen fx und fy die neue Brennweite“ in horizontaler und vertikaler ” Richtung. F¨ur eine Kamera mit fixer Optik ist der Wert der Brennweiten konstant. Das Verh¨altnis s =

Bx By

wird Seitenverh¨altnis (engl. aspect ratio) genannt. Im

Folgenden wird von quadratischen Pixeln ausgegangen, d.h.

w h

=

Bx By

= s. Dann

gilt: fy = fx

Bx w = fx s = fx . By h

(2.5)

Gem¨aß Gleichung (2.4) k¨onnen die Brennweiten relativ einfach gemessen werden [Eve01]: Sei W die Breite eines beliebigen Objektes vor der Kamera, H sei dessen H¨ohe. Bestimmt man den Objektabstand Dx bzw. Dy so, dass das Objekt die komplette Breite bzw. H¨ohe des Kamerabildes gerade abdeckt, berechnen sich die Brennweiten durch: fx =

Dx , W

fy =

Dy H

(2.6)

Die Brennweiten und die Aufl¨osung der Kamera werden in einer Matrix K,

2.5. O PEN GL und JAVA 3D

17

der so genannten Kalibriermatrix, zusammengefasst:     fx 0 0 w 0 cx      , V =  0 fy = fx w 0 , K = T V, T =  0 h c y     h 0 0 1 0 0 1

(2.7)

mit (cx , cy ) Verschiebung des Ursprungs des Bildkoordinatensystems auf den Schnitt¨ punkt von Bildebene und optischer Achse. Ublicherweise ist cx = w und cy = h , 2

2

wenn das Bild zentral im Ursprung liegt.

¨ Außere Kameraparameter F¨ur die Verarbeitung von Kamerabildern sind zus¨atzlich zu ihren inneren Parametern ihre Lage und Orientierung bzw. Translation und Rotation im Raum, die a¨ ußeren Kameraparameter, notwendig. Im Gegensatz zu den inneren Parametern, die bei fixer Optik f¨ur jedes aufgenommene Bild gleich sind, ist bei den a¨ ußeren ¨ Parametern eine Anderung von Bild zu Bild u¨ blich4 . In dieser Arbeit wird die Translation der Kamera vernachl¨assigt, es wird von einem reinen Rotationsmodell ausgegangen. Dazu gibt eine Rotationsmatrix R die Orientierung der Kamera im Raum an. Sie beschreibt die Transformation der Einheitsvektoren des Weltkoordinatensystems in die Basisvektoren des rotierten Kamerakoordinatensystems. Oft muss R−1 , die Inverse von R, benutzt werden, um zwischen den Koordinatensystemen zu transformieren. Da es sich bei einer Rotationsmatrix um eine orthogonale Matrix handelt, gilt: R−1 = RT .

2.5

(2.8)

O PEN GL und JAVA 3D

Ein direkter Vergleich von O PEN GL und JAVA 3D l¨auft auf einen Vergleich von unterschiedlichen Abstraktionsebenen hinaus. O PEN GL ist eine so genannte low” 4

In der Tat ist der Prozess der Sch¨atzung dieser a¨ ußeren Parameter f¨ur die einzelnen Bilder die

Hauptaufgabe bei der Berechnung von Panoramen.

18

Kapitel 2. Grundlagen

level“-API, die im Vergleich zu abstrakteren APIs unmittelbarere und unbeschr¨anktere Kontrollm¨oglichkeiten der Szenenvisualisierung bietet. Daf¨ur stellt JAVA 3D als high-level“-API dem Benutzer neben einem abstrakten in Klassen gekapsel” ten Visualisierungskonzept ein hierarchisches Szenenmodell, den so genannten Szenengraphen“, zur Verf¨ugung. ” JAVA 3D ist eine Sammlung von Klassen, die, wie der Name schon sagt, die Programmiersprache JAVA um die F¨ahigkeit der Darstellung von und Interaktion mit dreidimensionalen Grafiken erweitert. Generell bietet JAVA 3D den gleichen Funktionsumfang wie eine direkte O PEN GL-Implementierung, eingebettet in das Klassenkonzept; tats¨achlich heißen die Funktionen sogar sehr a¨ hnlich. Allerdings nimmt man den Nachteil in Kauf, die Kontrolle u¨ ber die genaue Visualisierungsreihenfolge zu verlieren. JAVA 3D baut auf einer w¨ahlbaren low-level-API auf, zum Zeitpunkt der Erstellung dieser Arbeit sind die Alternativen O PEN GL und D IRECT X, grunds¨atzlich ist jede beliebige andere low-level-Schnittstelle denkbar. Da die Funktionen von JAVA 3D aber sehr stark an O PEN GL angelehnt sind, kann eine davon stark abweichende low-level-API einen großen Konvertierungsaufwand der Formate zur Laufzeit bedeuten, und damit die Nutzung ineffizient werden. Im Vergleich zu JAVA 3D kann f¨ur O PEN GL jede beliebige Programmiersprache benutzt werden, f¨ur die API-Definitionen zur Verf¨ugung stehen. Dies ist sicher das Hauptargument f¨ur eine direkte Nutzung von O PEN GL5 .

5

So hat sich z.B. das Garbage-Collecting von

JAVA

f¨ur die Menge und Gr¨oße der im Soft-

wareprojekt dieser Arbeit gleichzeitig verwendeten Texturen als ungeeignet herausgestellt; der Speicherbedarf ist enorm und durch Kapselung in den JAVA 3D-Klassen nicht transparent und dadurch unkontrollierbar.

Kapitel 3 Berechnung und Darstellung von Panoramen ¨ Dieses Kapitel wird sich mit der Erzeugung von Ubersichtsbildern (Panoramen) durch geeignetes Zusammensetzen von Einzelbildern besch¨aftigen. Abschnitt 3.1 stellt das verwendete Verfahren zur Ausrichtung (Registrierung) der Einzelbilder vor, und Abschnitt 3.2 beschreibt die Darstellung des Panoramas im Hinblick auf Nutzung der 3D-Hardware-Schnittstellen O PEN GL und JA VA 3D.

Die hier vorgestellte Technik erzeugt im Gegensatz zu anderen verf¨ugba-

ren Verfahren abstandstreue“ Panoramen, d.h. die Einzelbilder werden nicht un” terschiedlich skaliert oder geschert, sondern in Originalgr¨oße und -form dargestellt. Ein zweidimensionales Panorama ist eine Projektion einer dreidimensionalen Szene auf eine zweidimensionale Panoramaoberfl¨ache, in der Literatur oft auch Mannigfaltigkeit“ genannt. Die Projektion kann mit speziellen Aufnahmeger¨aten ” wie einer Fischaugenlinse durchgef¨uhrt werden. Ein Einsatz dieser Spezialger¨ate l¨asst sich zugunsten von Standardkameras vermeiden, indem man durch Ausrichtung u¨ berlappender Bilder einer aufgenommenen Bildsequenz eine panoramische Projektion erzeugt. Meist sind diese Panoramen so groß, dass nur ein kleiner Ausschnitt von ihnen in Originalgr¨oße auf einem Bildschirm dargestellt werden kann. Bei einem weiten 19

20

Kapitel 3. Berechnung und Darstellung von Panoramen

Blickwinkel kommt noch das Projektionsproblem hinzu, da das Panorama dann nicht mehr auf einer Ebene darstellbar ist und eine andere Projektionsfl¨ache gesucht werden muss. Eine Verkleinerung auf Bildschirmgr¨oße kommt nur f¨ur eine ¨ grobe Ubersicht in Frage, eine genaue Aussage etwa u¨ ber die Qualit¨at des Panoramas l¨asst sich so nicht treffen. Eine Alternative ist, dem Betrachter die Auswahl des Ausschnittes zu erlauben, und ihm damit die M¨oglichkeit zur Exploration1 der Szene zu geben. Im Laufe der letzten Jahre sind Grafikkarten mit hardwareseitiger 3D-Unterst¨utzung immer performanter und gleichzeitig erschwinglicher geworden. Das dr¨angt die Idee auf, die interaktive Darstellung von Panoramen durch Nutzung der Hardware zu beschleunigen und echtzeitf¨ahig zu machen. Das Verfahren der Panoramaerzeugung f¨uhrt zu den drei Grundproblemen • Aufnahme der Bilder • Registrierung der Einzelbilder • Abbildung auf die Panoramaoberfl¨ache Der n¨achste Abschnitt wird das f¨ur die Registrierung der Einzelbilder benutzte Verfahren Rotational Mosaicing“ vorstellen. Es erwartet als einzigen Kamerapa” rameter die Brennweite und liefert f¨ur Rotationen und leichte Translationen der Kamera gute Registrierungen bzw. Panoramen. Ein weiterer Abschnitt wird das Problem der Darstellung mit Hardwareunterst¨utzung vorstellen und im Detail der eingeschlagene L¨osungsweg erl¨autert. Die Voraussetzung f¨ur die Darstellung von Panoramen ist die korrekte Sch¨atzung von Transformationen f¨ur jedes Bild, so dass sie aneinander ausgerichtet werden k¨onnen. Dieser Schritt wird als Registrierung bezeichnet. Im ersten Schritt, bei der so genannten lokalen“ Transformation werden die Abbildungsparame” ter, etwa Rotation und Translation, zwischen den einzelnen Bildpaaren berechnet. Daraus wird jedem Bild eine globale Transformation zugeordnet, um sie dann aneinander ausgerichtet auf einer Projektionsfl¨ache, z.B. auf eine Ebene oder eine 1

Mit Exploration wird die interaktive Erforschung einer virtuellen Szene bezeichnet.

3.1. Rotational Mosaicing

21

Kugelschale, abzubilden [Eve01]. Diese Abbildung erzeugt das eigentliche Panorama und wird ausf¨uhrlich in Abschnitt 3.2 behandelt.

3.1

Rotational Mosaicing

Das Zusammensetzen eines Bildes aus einer Sequenz von Einzelbildern wird als Mosaicing (aus dem Englischen: mosaicing) bezeichnet. In diesem Abschnitt wird das Verfahren Rotational Mosaicing“ vorgestellt, das die n¨otigen Daten f¨ur die ” Panoramadarstellung liefert. In [S¨ul01] werden die drei Verfahren General Ma” nifold Mosaicing“, Topology Inference with Local to Global Alignment“ und ” Rotational Mosaicing“ zum Erstellen von Panoramen verglichen, und schließlich ” wird sich f¨ur Rotational Mosaicing entschieden. Rotational Mosaicing ben¨otigt f¨ur die Registrierung die Brennweite der Kamera, ansonsten werden von allen drei Verfahren unkalibrierte Aufnahmen verarbeitet. Da General Manifold Mosaicing keine Registrierung durchf¨uhrt, sondern vielmehr eine Registrierung voraussetzt, kommt dieses Verfahren hier nicht in Frage. Rotational Mosaicing besitzt gegen¨uber Topology Inference den Vorteil, Abbildungsfehler wie Linsenverzerrungen kompensieren zu k¨onnen [S¨ul01]. Das von Shum und Szeliski in [SS97] beschriebene Verfahren erm¨oglicht die Erzeugung von Panoramen aus mit der Hand aufgenommenen Bildsequenzen ohne Kalibrierung der Kamera. M¨oglichst freie Bewegungen, bei denen auch kleinere Parallaxen auftreten k¨onnen, sollen verarbeitet werden. Es werden keine zylindrischen oder sph¨arischen Koordinaten verwendet, sondern jedem Bild eine Transformation zugeordnet, die die lokale Lage des Bildes beschreibt. Durch Akkumulation der lokalen Transformation werden f¨ur alle Bilder globale Transformationen berechnet. F¨ur l¨angere Sequenzen m¨ussen kumulierte Fehlregistrierungen behandelt werden, etwa um bei 360◦ Panoramen die eventuell entstehende L¨ucke zwischen dem ersten und dem letzten Bild auszugleichen. Dazu m¨ussen die lokalen Fehler gleichm¨aßig verteilt oder reduziert werden. Das Verfahren teilt sich auf in die vier Schritte [SS97]: 1. Sch¨atzung der Brennweite der Kamera 2. Registrierung von Bildpaaren

22

Kapitel 3. Berechnung und Darstellung von Panoramen 3. global konsistente Ausrichtung

4. Reduktion von lokalen Fehlregistrierungen

Die Brennweite wird f¨ur das Mapping des Mosaiks auf die Projektionsfl¨ache ben¨otigt. Ist die Brennweite unbekannt, wird sie im ersten Schritt gesch¨atzt oder gemessen. Das Verfahren der Brennweitensch¨atzung ist in [S¨ul01] beschrieben, stellte sich aber als sehr st¨oranf¨allig heraus, daher wird es hier nicht weiter behandelt.

3.1.1 Registrierung In der Registrierungsphase werden je zwei Bilder anhand ihres Intensit¨atsverlaufes aneinander ausgerichtet. Dies wird durch Anwendung eines Bewegungsmodells und die Sch¨atzung der erforderlichen Parameter realisiert. Als Ergebnis wird jedem Bild seine Transformation innerhalb des gew¨ahlten Modells zugeordnet. Das Problem der Bildregistrierung wird zun¨achst im eindimensionalen Fall mit dem Spezialfall der horizontalen Translation beschrieben. Ausgehend von zwei Intensit¨atsfunktionen I0 und I1 von Bildpunkten x und N betrachteten Abtastpunkten p1 , . . . , pN wird eine Verschiebung h bestimmt, so dass die Differenz der Intensit¨aten m¨oglichst gering wird:

min{E(h)} h

mit E(h) =

N X

(I1 (pj + h) − I0 (pj ))2

(3.1)

j=1

Durch die Verwendung des quadratischen Fehlers statt des absoluten Fehlers wird erreicht, dass gr¨oßere Abweichungen die Optimierung st¨arker beeinflussen als kleine. Mit der linearen Approximation der Intensit¨atsfunktion im Bereich um den Punkt pj I1 (pj + h) ∼ I1 (pj ) + h∇I1 (pj )

(3.2)

3.1. Rotational Mosaicing

23

ergibt sich aus 3.1 min {E(h)}

h∈Rn

N X

mit E(h) ∼

(I1 (pj ) + h∇I1 (pj ) − I0 (pj ))2

j=1 N X

=

(3.3) (h∇I1 (pj ) + ej )2

j=1

wobei ej = I1 (pj ) − I0 (pj ) und ∇I1 = ∂I1 /∂x ist. Durch Anwendung der Taylorreihenentwicklung und Abbruch nach dem linearen Glied ergibt sich die Normalengleichung N X

T

∇I1 (pj ) ∇I1 (pj )h = −

j=1

N X

∇I1 (pj )T ej .

(3.4)

j=1

Diese minimiert den Fehler aus (3.1), wenn nicht alle Ableitungen der Funktion I1 Null sind. Wenn alle Ableitungen Null sind, dann sind die Grauwerte konstant, d.h. die Fl¨ache ist homogen und kann nicht registriert werden.

3.1.2

Iterative Sch¨atzung

Die Bewegungssch¨atzung nach Gleichung (3.4) ist nach einmaliger Berechnung aufgrund des Abbrechens nach dem linearen Glied noch recht ungenau. Deshalb wird das Verfahren iterativ solange angewendet, bis eine definierte Anzahl an Iterationen erreicht ist oder das Inkrement einen Schwellwert unterschreitet. Mit I˜1,n (pj ) = I1 (pj + hn ), die um hn verschobene Intensit¨atsfunktion I1 , muss nun in jedem k-ten Iterationsschritt Ek (hk ) =

N X

(I˜1, k−1 (pj + hk ) − I0 (pj ))2

(3.5)

j=1

minimiert werden.

3.1.3

Rotationsmodell

Ein Rotationsmodell als Bewegungsmodell hat den Vorteil, dass nur drei Parameter f¨ur die Rotation der X-, Y- und Z-Achse gesch¨atzt werden m¨ussen. Dadurch wird das Verfahren stabiler und konvergiert schneller. Verwendet wird ein

24

Kapitel 3. Berechnung und Darstellung von Panoramen

Kameramodell bestehend aus einer oder mehreren Linsen und einem Sensorfeld, gekennzeichnet durch die horizontale und vertikale Gr¨oße des Bildes w und h, sowie die Brennweite f := fx in horizontaler Richtung. Ohne Einschr¨ankung der Allgemeinheit kann angenommen werden, dass die Kamera im Ursprung positioniert ist. Dann ist die Beziehung zwischen Raumkoordinaten eines Punktes p und Bildkoordinaten des Bildpunktes x: x = KRT p = T V RT p,

(3.6)

mit  K = T V,

w 0 cx





f

0

    , V = 0 f w T = 0 h c y    h 0 0 1 0 0

 0  0 , 1

(3.7)

und damit 

1  wf

K −1 =  0 0

0 1 wf

0

cx − wf



 cy  − wf ,

(3.8)

1

K ist die Kalibrierungsmatrix der Kamera zusammengesetzt aus der Brennweite V und T mit (cx , cy ) als Verschiebung des Ursprungs des Bildkoordinatensystems auf den Schnittpunkt von Bildebene und optischer Achse, u¨ blicherweise cx =

w 2

und cy = h2 , wenn das Bild zentral im Ursprung liegt. R ist die Rotationsmatrix der Kamera im Raum. Die Zuordnung der Bilder k, l durch Rotation der Kamera ist beschrieben durch: M ∼ Tk Vk Rk Rl−1 Vl−1 Tl−1 = Tk Vk Rkl Vl−1 Tl−1 .

(3.9)

Unter der Annahme, dass die Aufl¨osung und Ursprungsverschiebung der Kamera konstant sind (dies ist im Allgemeinen gegeben), gilt Tk Tl−1 = I. Damit kann jede Kamerabewegung durch Vk Rkl Vl−1 , die Brennweite und die Rotation beschrieben werden. Zur Bestimmung der Rotation muss in diesem Modell die Brennweite bekannt sein. Im Folgenden wird angenommen, dass die Brennweite bei allen Bildern gleich ist, d.h. Vk = Vl =: V .

3.1. Rotational Mosaicing

25

Um die Rotation zu berechnen, wird eine inkrementelle Akualisierung der Rotationsmatrix Rk auf Basis der Winkelgeschwindigkeit Ω = (ωx , ωy , ωz ) durchgef¨uhrt: Rkl ← Rot(Ω)Rkl bzw. M ← Vk Rot(Ω)Rkl Vl−1 ,

(3.10)

wobei Rot(Ω) die Rotationsmatrix f¨ur Ω ist. Unter der Annahme, dass die Aktualisierungswinkel klein sind, kann der Kreuzproduktoperator X(Ω)   0 −ωz ωy    X(Ω) =  ω 0 −ω z x   −ωy ωx 0

(3.11)

zur Approximation der Rotationswinkel verwendet werden. Dann ist die Aktualisierungsvorschrift Rkl ≈ (I + X(Ω))Rkl bzw. M ≈ Vk (I + X(Ω))Rkl Vl−1 .

(3.12)

M ≈ V (I + X(Ω))Rkl V −1 = V Rkl V −1 + V X(Ω)Rkl = M + DΩ M = (I + DΩ )M, mit

  DΩ = V X(Ω)V −1 =  

(3.13)

0

−ωi,z

ωi,z

0

−ωi,y /fl ωi,x /fl

fk ωi,y



 −fk ωi,x  

(3.14)

0

In euklidischen Koordinaten ist die Aktualisierung x0 ∼ (I + DΩi )x 1 − ωi,z y + fk ωi,y −ωi,y /fl + ωi,x /fl + 1 ωi,z x + 1 + fk ωi,x y0 = . −ωi,y /fl + ωi,x /fl + 1

x0 =

(3.15) (3.16)

Mit partieller Ableitung nach Ω erh¨alt man die Jakobimatrix ∂x0 JΩ = = ∂Ω

−xy/fl −fk − y 2 /fl

fk + x2 /fl −y xy/fl

x

!T .

(3.17)

26

Kapitel 3. Berechnung und Darstellung von Panoramen

Dann kann der Rotationsvektor (ωx , ωy , ωz ) durch L¨osen der Normalengleichung N X

T Jj,Ωi gj gjT Jj,Ω d i i

j=1

=−

N X

Jj,Ωi gj ej

(3.18)

j=1

gesch¨atzt werden.

3.1.4

Realisierung des Rotational Mosaicing

Dieser Abschnitt wurde von [Eve01] u¨ bernommen, er fasst die Realisierung des Rotational Mosaicings zusammen. Die lokale Registrierung, also die paarweise Ausrichtung der Bilder, erfolgt hierarchisch auf einer so genannten Aufl¨osungspyramide, die f¨ur jedes Bild konstruiert wird. Die Ebene 0 der Pyramide, die unterste“ Stufe, ist das urspr¨ungliche ” Bild, die Ebene 1 ist ein gegl¨attetes, unterabgetastetes Bild der Ebene 0, analog werden alle weiteren Ebenen berechnet. Die Ausrichtung wird im ersten Schritt auf der gr¨obsten Ebene ermittelt. Wenn diese hinreichend gut ist, d.h. ein bestimmter Schwellwert bei einer Iteration unterschritten wird, wird die Ausrichtung auf der n¨achst feineren Ebene berechnet, bis letztlich die Urbilder ausgerichtet sind. Dieser hierarchische Ansatz verbessert die Effizienz der Registrierung bei gleicher Qualit¨at erheblich, die Laufzeiteinsparung liegt in der Regel bei etwa 50%. Experimentell wurde ermittelt, dass eine Pyramide der H¨ohe 3 oder 4 die besten und schnellsten Resultate liefert. F¨ur die initiale Bewegungssch¨atzung als Startwert der lokalen Registrierung wurden drei verschiedene Verfahren implementiert: Blockmatching, regularisiertes Blockmatching und Phasenkorrelation. Die Phasenkorrelation wird bestimmt, indem die Bilder mittels einer 2D-FFT in den Frequenzraum transformiert werden und dort die Phasenverschiebung berechnet wird, die gleichzeitig die Verschiebung im Raum angibt. Das Verfahren hat gegen¨uber dem Blockmatching den Vorteil, nahezu beliebig große Verschiebungen effizient zu erkennen. Sollen mit Blockmatching große Verschiebungen bestimmt werden, so m¨ussen entweder die Suchbereiche entsprechend groß gew¨ahlt werden, was zu entsprechenden Laufzeiteinbußen f¨uhrt, oder die Pyramidenh¨ohe stark erh¨oht werden, wobei die

3.2. Darstellung des Panoramas

27

Gr¨oße des Suchbereichs auf oberster Ebene dann gleich bleibt. Das wiederum ist nicht ohne weiteres m¨oglich, da die wiederholte Tiefpassfilterung und Unterabtastung hochfrequente Anteile wie z.B. Ecken und Kanten entfernt, aber gerade diese Bildanteile f¨ur das Blockmatching ben¨otigt werden. F¨ur die weitere lokale Registrierung kommt eine blockweise inkrementelle Bewegungssch¨atzung zum Einsatz. Ausgehend von der im Initialisierungsschritt bestimmten Rotationsmatrix R0 wird das zu vergleichende Bild um R0 rotiert. Dann wird blockweise eine Bewegung in Form eines Vektors d mit drei Rotationen gesch¨atzt, die erforderlich ist, um die u¨ berlappenden Bildteile zu Deckung zu bringen. Aus d wird eine differentielle Rotationsmatrix berechnet und R0 damit korrigiert. Diese korrigierte Rotation R1 des Bildes dient nun als Initialisierung f¨ur die n¨achste Iteration. Das Verfahren l¨auft als erstes auf der h¨ochsten bzw. am gr¨obsten aufgel¨osten Pyramidenstufe. Als Abbruchkriterium wird entweder eine maximale Iterationenazahl oder die Konvergenz des Verfahrens verwendet. Konvergenz wird angenommen, wenn das gesch¨atzte Update d einen Schwellwert unterschreitet. Danach wird das Verfahren auf der n¨achst feineren Pyramidenstufe mit dem Startwert, der in der vorherigen Ebene berechnet wurde, ausgef¨uhrt. Ein Iterationsschwellwert von 8 bis 12 und ein Konvergenzkriterium von 10−3 f¨ur die Norm von D haben sich als sinnvoll erwiesen.

3.2

Darstellung des Panoramas

Dieser Abschnitt zeigt, wie man ein m¨oglichst u¨ bergangsfreies Panorama aus einer Sequenz von Einzelbildern mit durch das Rotational Mosaicing gegebenen Orientierungsdaten unter Nutzung von 3D-Hardware-Beschleunigung darstellt. Wenn das Panorama einen gr¨oßeren Winkel aufspannt, ist zudem eine Explorationsm¨oglichkeit n¨otig, um es vollst¨andig erfassen zu k¨onnen. Analog zum Rotational Mosaicing wird davon ausgegangen, dass sich die Kamera im Ursprung befindet und die Bilder nur durch Rotationen der Kamera (und evtl. kleinen Translationen) entstanden sind. Entsprechend den Anforderungen der Hardware bzw. von O PEN GL und JAVA 3D wird eine dreidimensionale Struktur als Projektionsfl¨ache

28

Kapitel 3. Berechnung und Darstellung von Panoramen

aufgebaut. Sie dient als Texturtr¨ager und wird mit den Bildern der Bildsequenz gef¨ullt. Dazu werden die Einzelbilder als Texturen definiert und entsprechende Texturkoordinaten zugewiesen. Die nat¨urliche Wahl so einer Projektionsfl¨ache ist wegen der Beschr¨ankung auf Rotationen eine Kugelschale, aber auch andere Formen wie Zylinder oder W¨urfel sind vorstellbar (und wurden auch implementiert). Bei beliebigen Rotationen und Translationen m¨ussten eine andere, in der Regel unregelm¨aßig geformte, Projektionsfl¨ache berechnet werden, die die optischen Zentren aller Bilder durchl¨auft. Abbildung 3.1 veranschaulicht die F¨alle.

(a)

(b)

Abbildung 3.1: Beispiele f¨ur Projektionsfl¨achen: (a) Kugel bei Rotationen ohne Translation, (b) allgemeine Form bei freier Kombination von Rotationen und Translationen.

3.2.1

Aufbau eines Texturtr¨agers

Um einen Texturtr¨ager als Projektionsfl¨ache aufzubauen, muss zun¨achst die Gr¨oße der Bilder in Pixeln und die Brennweite f der Kamera, die die Bilder aufgenommen hat, bekannt sein. Aus f kann dann der Abstand der Projektionsfl¨ache zur virtuellen Kamera bzw. der Radius der Kugel im virtuellen Universum berechnet werden. Rotational Mosaicing setzt als Kameraparameter f voraus. Da das Verfahren, das in [S¨ul01] f¨ur die Sch¨atzung der Brennweite herangezogen wurde, keine guten Ergebnisse lieferte, muss f gemessen werden. Im Folgenden m¨ogen w und h die Breite bzw. H¨ohe des Bildes in Pixeln angeben, und f die Brennweite in x-Ausrichtung bezeichnen. Dann l¨asst sich die Kalibriermatrix K bzw. K −1 gem¨aß (3.7) berechnen. Rotational Mosaicing liefert zugleich eine Rotationsmatrix R = Rzγ Ryβ Rxα , die

3.2. Darstellung des Panoramas

29

die Bewegung des jeweiligen Bildes zum Ursprungsbild mit R0 = I der Sequenz darstellt. Dann ist {0..w−1} × {0..h−1} −→ R3 :

pB = (pB1 , pB2 ) 7→ RK −1

 pB  1

pB2 1

(3.19)

=: pR eine Abbildung von Bildkoordinaten pB in Raumkoordinaten pR .

1

f 1/

Abbildung 3.2: Aufbau eines Rasters und Transformation in ein virtuelles Universum

Nun w¨urde es gen¨ugen, die vier Eckpunkte jedes Bildes in Raumkoordinaten zu u¨ berf¨uhren, um Bilder zu erhalten, die alle tangential an einer Kugel mit Radius 1 ausgerichtet sind (s. Abb. 3.2). Ber¨ucksichtigt man aber, dass die Bilder am Schluss auf einer einzigen beliebig geformten Projektionsfl¨ache (Mannigfaltigkeit) angeordnet werden sollen, dann muss jedes Bild in ein gen¨ugend feines Raster unterteilt, und auf jeden dieser Rasterpunkte diese Transformation angewandt werden. Das Ergebnis ist eine Menge von Raumpunkten, die entsprechend der gegebenen Projektionsfl¨ache angepasst werden k¨onnen. 3.2.1.1

Projektionsfl¨achen / Geometrien

Jeder Raumpunkt pR , auf den abgebildet wurde, kann als Strahl vom Ursprung angesehen werden. Dann kann durch Anpassung der L¨ange dieser Strahlen eine beliebige Projektionsfl¨ache bzw. Geometrie erzeugt werden (s. Abb. 3.3). So entsteht

30

Kapitel 3. Berechnung und Darstellung von Panoramen

etwa bei Normalisierung von kpR k eine Kugelschale. Nur geringf¨ugig schwieriger lassen sich so auch andere Geometrien wie Zylinder oder W¨urfel modellieren. Im Allgemeinen muss daf¨ur der Schnittpunkt der Strahlen mit der Geometrie berechnet werden. Die Art der Projektionsfl¨ache ist bei dieser Methode nicht vom Betrachter zu erkennen, solange er sich im Koordinatenursprung befindet. Erst, wenn er es verl¨asst, sind Unterschiede durch die verschiedenen Geometrien sichtbar.

Abbildung 3.3: Modellierung der Projektionsfl¨ache

Um Projektionsfl¨achen zu konstruieren, ist man nat¨urlich nicht darauf beschr¨ankt, die L¨angen der Strahlen zu ver¨andern. Ver¨andert man etwa auch die Richtung der Vektoren, kann man die Darstellung frei ver¨andern. Eine Anwendung daf¨ur l¨asst sich schnell finden: die Projektion eines Weitwinkelpanoramas (> 180◦ ) auf einer Ebene. Das kann etwa durch eine direkte Abbildung der sph¨arischen Koordinaten der Kugel auf die Bildkoordinaten in der Ebene realisiert werden (in der Literatur auch spherical mapping oder latitude-longitude projection genannt). Setzt man pα =

1 2f tan−1

1 2f

,

pβ =

h 2f w tan−1

h 2f w

,

(3.20)

mit w Breite und h H¨ohe der Bilder in Pixeln, dann geben pα und pβ die Pixel/Winkel Relation wieder. F¨ur einen Vektor p0 = (x, y, z) ∈ R3 , mit kp0 k = 1 und y 6= 1 k¨onnen nun die Winkel in x- und y-Richtung α bzw. β bestimmt wer-

3.2. Darstellung des Panoramas

31

den: α = tan−1 β = tan−1

x z y √ , x2 + z 2

(3.21) (3.22)

Dann ist (pα α, pβ β) der entsprechende Punkt auf der Ebene. Die bei diesem Verfahren entstehende Projektionsfl¨ache hat immer die gleiche Gr¨oße: Sie ist 2πpα breit und πpβ hoch. Leider treten naturgem¨aß bei Projektionen der Polbereiche der Kugel starke Verzerrungen auf. Allgemein sind die Pole kritische Bereiche bei sph¨arischen Projektionen und sollten nach M¨oglichkeit nicht mit Bildinhalten besetzt sein. Dies betrifft auch die Alternativen zur Verwendung der sph¨arischen Koordinaten, z.B. die stereografische Projektion oder die Mercatorprojektion.

3.2.2

Texturzuweisung

Bisher ist zum Aufbau des virtuellen Universums an Bildinformationen nur die Bilddimension verwendet worden. Um die eigentlichen Bildinhalte der aufgenommenen Sequenz u¨ ber die berechnete Geometrie zu legen, m¨ussen sie als Texturen definiert und entsprechende Texturkoordinaten tx und ty ∈ [0, 1] den transformierten Rasterpunkten, in die die Bilder in 3.2.1 eingeteilt und die mittels der Funktion (3.19) abgebildet wurden, zugewiesen werden. Bei der Berechnung der Texturkoordinaten muss ber¨ucksichtigt werden, dass die Breite und H¨ohe von Texturen durch Hardwareeinschr¨ankungen (und damit auch Einschr¨ankungen f¨ur O PEN GL und JAVA 3D) jeweils eine 2er-Potenz sein m¨ussen. Handelt es sich etwa um Bilder, die in der gebr¨auchlichen PAL-Aufl¨osung 720 × 576 aufgenommen wurden, m¨ussen sie erst auf eine Dimension von 1024 × 1024 erweitert werden, bevor sie als Texturen nutzbar sind. Der Inhalt des entstehenden Texturenrandes spielt dabei keine Rolle, denn er ist durch entsprechende Wahl der Texturkoordinaten nicht sichtbar. Die Texturkoordinaten tx und ty k¨onnen f¨ur einen Rasterpunkt pi mit den Bildkoordinaten px und py folgendermaßen berechnet werden: tx =

px , dlog 2 2 we

ty =

py dlog 2 2 he

(3.23)

32

Kapitel 3. Berechnung und Darstellung von Panoramen

(a)

(b)

(c) Abbildung 3.4: Beispiele f¨ur Geometrien: (a) Kugel, (b) W¨urfel, (c) sph¨arische Projektion durch sph¨arische Koordinaten

In Abbildung 3.5 wird dieser Sachverhalt anschaulich dargestellt.

3.2.3

¨ Uberlappungsbereiche

Das Verfahren Rotational Mosaicing, das f¨ur die Generierung bzw. Sch¨atzung der Orientierungen und Position der Bilder zueinander gew¨ahlt wurde, setzt f¨ur eine erfolgreiche Berechnung zwingend voraus, dass zwischen jeweils zwei benach¨ ¨ barten Bildern gen¨ugend große Uberlappungsbereiche vorhanden sind. Ublich sind sogar Bereiche, die Teil von mehr als drei Bildern sind. Da diese alle auf einer einzigen Projektionsfl¨ache im virtuellen Universum liegen und z.B. bei einer Kugel alle Punkte im gleichen Abstand zum Betrachter aufgebaut wurden, entscheidet bei ausgeschaltetem z-Puffer nur die Reihenfolge der Darstellungsaufrufe

3.2. Darstellung des Panoramas

33 w

h 2dlog2 he

2dlog2 we Abbildung 3.5: Texturenrand durch Erweiterung auf 2er-Potenz-Gr¨oße.

dar¨uber, welches Bild f¨ur welchen Punkt auf der Projektionsfl¨ache gew¨ahlt wird. Bei eingeschaltetem z-Puffer ist das Ergebnis nicht mehr so einfach vorherzusagen. Minimale Unterschiede der Tiefenwerte bzw. eine unzureichende Aufl¨osung des z-Puffers k¨onnen zu einer unregelm¨aßig abwechselnde Darstellung f¨uhren. Die Unkontrollierbarkeit von außen macht dies zu einem unerw¨unschten, da in der Regel sehr auff¨alligen Effekt. Eine einfache M¨oglichkeit, dies zu umgehen, w¨are, jedes Bild in ausreichender unterschiedlicher Entfernung vom Betrachter aufzubauen, wie in Abbildung 3.6 dargestellt.

Abbildung 3.6: Anordnung der Bilder in verschiedenen Entfernungen vom Ursprung.

Dies hat aber mehrere Nachteile: a) Die Projektionsfl¨ache ist nicht mehr zusammenh¨angend und l¨asst bei geeigneter Betrachterposition L¨ucken erkennen, ¨ und b) die Uberg¨ ange zwischen den Bildern sind abrupt und tauchen genau am Rand auf, bei dem eventuelle Linsenverzerrungen am gr¨oßten sind. Damit sind ¨ die Uberg¨ ange sehr auff¨allig und widersprechen der Zielvorgabe. Im Folgenden ¨ werden zwei Verfahren vorgestellt, die diese Uberg¨ ange gl¨atten bzw. verhindern sollen:

34

Kapitel 3. Berechnung und Darstellung von Panoramen

Mittelwertfilter Die Bilder werden transparent u¨ bereinander gelegt; dadurch ent¨ steht ein etwas unsch¨arferes Bild, daf¨ur aber mit weicheren Uberg¨ angen. Radialfilter F¨ur jeden Bildpunkt p in gemeinsamen Bildbereichen wird entschieden, welches Bild daf¨ur gew¨ahlt wird. Dazu wird f¨ur jedes Bild bestimmt, wie groß der Abstand von p zum Bildzentrum ist, und das mit dem geringsten Abstand gew¨ahlt. Um diese Verfahren anwenden zu k¨onnen, ist es als Grundlage zun¨achst erforder¨ lich, die Uberlappungsbereiche zu berechnen. 3.2.3.1

¨ Berechnung der Uberlappungsbereiche

Im Folgenden wird von einer Sequenz von N Bildern B1 , . . . , BN ausgegangen, alle mit einer Breite von w und einer H¨ohe von h Pixeln. F¨ur ein Bild Bi gibt Ri die zugeh¨orige Kamera-Rotationsmatrix an, die durch Rotational Mosaicing berechnet wurden. K sei wie in (3.7) definiert. Um f¨ur zwei Bilder Bi und Bj den gemeinsamen Bereich im Bild Bi zu bestimmen, m¨ussen f¨ur die vier Eckpunkte von Bild Bj die Koordinaten in Bezug auf Bild Bi berechnet werden:  fij : (0, 0), (w−1, 0), (0, h−1), (w−1, h−1) −→ R3 , xj = (xj1 , xj2 ) 7→

KRi RjT K −1

 xj  1

xj2 1

=: xi (3.24)

Sei xi = (xi1 , xi2 , xi3 )T das Ergebnis der Abbildung fij . Dann ist xi mit norx

x

miertem xi3 , also ( xii1 , xii2 ) =: x0i (f¨ur xi3 6= 0), der zu Eckpunkt xj von Bild Bj 3

3

geh¨orende Punkt auf Bild Bi . Die abgebildeten Eckpunkte von Bj auf Bi ergeben zusammen ein Viereck, ¨ dessen Schnittfl¨ache mit Bi den Uberlappungsbereich innerhalb Bi bildet.

3.2.4

Mittelwertfilter

Eine M¨oglichkeit, harte Bild¨uberg¨ange im Panorama zu verhindern, ist, die Bilder transparent u¨ bereinander zu legen und dadurch den Mittelwert zu bilden und Kan-

3.2. Darstellung des Panoramas

35

ten zu gl¨atten. Dabei wird der Nachteil der im Allgemeinen unsch¨arferen Bilder (Blurring) und der m¨oglichen auftretenden Ghosting-Artefakte bei sich bewegenden Objekten in Kauf genommen. Um die Mittelwerte zu berechnen, muss f¨ur jeden Bildpunkt im Panorama die Anzahl Bilder ermittelt werden, in deren Bereich dieser Punkt liegt. Das ist gleich bedeutend damit, f¨ur jedes Bild alle Bildpunkte daraufhin zu untersuchen, bei wie ¨ vielen Uberlappungsbereichen mit den anderen Bildern dieser Punkt enthalten ist. Dazu berechne f¨ur jeden Punkt pi = (pi1 , pi2 ) aus Bild Bi pj = (pj1 , pj2 ), mit pj1 =

p0j

1 p0j 3

, pj2 =

p0j

(3.25)

2

p0j

3

f¨ur p0j3 6= 0 und (p0j1 , p0j2 , p0j3 )T

=

KRj RiT K −1

 pi  1

pi2 1

.

(3.26)

¨ Wenn pj1 < w und pj2 < h, dann ist pi im Uberlappungsbereich von Bi und Bj enthalten. F¨uhrt man nun dieses Verfahren f¨ur alle Bilder Bj , mit j 6= i, aus, dann kann man f¨ur den Punkt pi und sukzessive f¨ur alle Punkte aller Bilder die Anzahl si (pi ) der gemeinsamen Bilder bestimmen. Es gibt mindestens zwei M¨oglichkeiten, aus diesen Daten ein gemitteltes Panorama zu erzeugen: 1. Manipulation der Bildinhalte: die Grauwerte der Pixel werden jeweils durch die f¨ur sie wie oben ermittelte Anzahl der gemeinsamen Bilder geteilt. Zu beachten ist dabei, nicht direkt mit drei 8-Bit-Werten zu rechnen, sondern die Bilder in Fließkomma-Werte zu konvertieren, um starke Rundungsfehler zu vermeiden. Alternativ ist die folgende Methode m¨oglich: 2. Skalierung der Bildwerte durch eine Alphamap mit Alphawerten αi f¨ur jedes Bild Bi : αi (pi ) =

1 , si (pi )

f¨ur alle pi ∈ Bi

(3.27)

Sei IP die Grauwertsfunktion des zusammengesetzten Panoramabildes und Ii die ¨ Grauwertsfunktion f¨ur Bild Bi . Bei Uberlagerung der Bilder im Panorama gilt

36

Kapitel 3. Berechnung und Darstellung von Panoramen

dann f¨ur jeden Panoramapunkt p ∈ R3 mit dazugeh¨origer Bildermenge S(p): X X 1 1 Ii (KRi p), (3.28) IP (p) = Ii (KRi p) = |S(p)| |S(p)| Bi ∈S(p)

Bi ∈S(p)

was genau dem Mittelwert entspricht. Analog kann diese Methode f¨ur die RGBWerte bei Farbbildern durchgef¨uhrt werden. ¨ Leider lassen sich bei dieser Methode die Uberlappungsbereiche nicht subpixelgenau berechnen, da entweder direkt auf den Bildern oder auf einer Alphamap, die die gleiche Gr¨oße besitzt, und damit auf Pixelebene gearbeitet wird. Diese Quantisierung verursacht bei der Darstellung schmale R¨ander bzw. L¨ucken, da dort subpixelgenau gerechnet wird (s. Abb. 3.7). Dies schr¨ankt die Anwendbarkeit des Mittelwertfilters in der Praxis ein.

Abbildung 3.7: Mittelwertfilter. Oben: R¨ander bzw. L¨ucken durch Quantisierungsfehler. Unten: auftretende Ghosting-Artefakte durch sich bewegende Elemente

3.2.5 Radialfilter Im Gegensatz zum Mittelwertfilter versucht der Radialfilter nicht, mehrere Bilder ¨ durch Uberlagerung gleichzeitig darzustellen, sondern im Gegenteil jedem Bildpunkt im Panorama genau ein Bild zuzuordnen. Das Kriterium, das u¨ ber die Wahl des Bildes entscheidet, soll im Folgenden erl¨autert werden. Nat¨urlicherweise sollte das Bild gew¨ahlt werden, das bei dem jeweiligen Bildpunkt den aufgenommenen Gegebenheiten am N¨achsten kommt. Bei der u¨ blichen

3.2. Darstellung des Panoramas

37

radialen Linsenverzerrung (d.h. Kissen- oder Tonnenverzerrung) der Kamera wird der Fehler zum Rand des Bildes hin immer gr¨oßer. Ein weiterer Effekt, der besonders bei Mosaiken auff¨allt, ist ein Intensit¨atsabfall von der Bildmitte zu den R¨andern hin. Besonders auff¨allig ist dieser als Vignettierung bezeichnete Effekt bei Mosaiken deshalb, da dort Bildkanten direkt in der Mitte anderer Bilder liegen k¨onnen. Insgesamt ist der Abstand des Panoramapunktes zum jeweiligen Bildzentrum also ein sinnvolles G¨utekriterium: je kleiner der Abstand, desto besser. Es wird daher das Bild mit dem geringsten Abstand gew¨ahlt. Da es bei O PEN GL und erst recht bei JAVA 3D aus Gr¨unden der Performanz keinen Sinn macht, Backward-Mapping zu betreiben – denn dann k¨onnte man gleich ganz auf Hardwarebeschleunigung verzichten und die Szene per Software darstellen – , kann nicht der Weg beschritten werden, f¨ur jeden Punkt p des Panoramas das Bild mit dem geringsten Abstand zu w¨ahlen und darzustellen. Stattdessen wird f¨ur jeden Punkt jedes Bildes der korrespondierende Punkt auf den anderen Bildern berechnet und ermittelt, ob es ein Bild gibt, bei dem der korrespondierende Punkt einen kleineren Abstand zu seinem Bildzentrum hat. F¨ur ein Bild Bi berechne f¨ur alle Bj 6= Bi die Schnittbereiche. F¨ur alle Punkte pi = (pi1 , pi2 ) in der Schnittfl¨ache2 mit Bj innerhalb Bi berechne wie beim Mittelwertfilter durch Anwendung der Formeln (3.25) und (3.26) die korrespondierenden Punkte pj = (pj1 , pj2 ) in Bj . Durch einen Vergleich der Distanz di zum Bildzentrum von Bi di =

q

p2i1 + p2i2

(3.29)

mit der Distanz dj zum Bildzentrum von Bj dj =

q

p2j1 + p2j2

(3.30)

kann f¨ur alle Punkte aus Bi bestimmt werden, welche im Panorama angezeigt werden sollen: Hat ein anderes Bild f¨ur den jeweiligen Punkt einen kleineren Abstand zum Bildzentrum, d.h. es existiert f¨ur diesen Punkt ein j mit dj < di , soll der Punkt von Bi nicht angezeigt werden. 2

¨ s. Abschnitt 3.2.3.1 zur Berechnung der Schnittfl¨ache bzw. des Uberlappungsbereichs

38

Kapitel 3. Berechnung und Darstellung von Panoramen Eine Implementierung dieses Filters kann durch jeweils eine Alphamap f¨ur

jedes Bild realisiert werden, indem diese mit einer Null f¨ur die Punkte, die nicht dargestellt werden sollen, und mit einer Eins f¨ur die anderen Punkte gef¨ullt werden. Hier gilt leider der gleiche Nachteil wie beim Mittelwertfilter: Die genauen Pixelgrenzen im Panorama k¨onnen nicht genau auf die einzelnen Bilder umgerechnet werden. Unter Umst¨anden entstehen dadurch bei Anwendung der Alphamaps und geeigneten Betrachterpositionen st¨orende L¨ucken im Panorama (s. Abb. 3.8). Dies kann dadurch verhindert werden, dass die Grenzen der AlphamapBereiche, die mit einer Eins gef¨ullt sind, um einen bestimmten Skalierungsfaktor vergr¨oßert. Dies ist umso einfacher, da diese Bereiche durch ihre Konstruktion zusammenh¨angend sind. Es kann also einfach die Alphamaps Zeile f¨ur Zeile durchgegangen werden, die linke und rechte Grenze des 1er-Bereichs bestimmt und die R¨ander unter Anwendung des Skalierungsfaktors korrigiert und mit Eins aufgef¨ullt werden. Der Unterschied zwischen einer Panoramaberechnung mit und ohne Alphamapkorrektur ist in Abbildung 3.8 zu sehen.

(a)

(b)

Abbildung 3.8: Radialfilter: (a) ohne Skalierungsfaktor der Alphamaps, (b) mit Skalierungsfaktor = 1.1

3.2. Darstellung des Panoramas

3.2.6

39

Optimierung des Speicherbedarfs des Radialfilters

Ein Panorama, das unter Nutzung einer Textur f¨ur jedes Bild der Sequenz dargestellt wird, ben¨otigt viel Texturspeicher, da Texturen immer in Dimension einer 2er-Potenz vorliegen m¨ussen. 30 24-Bit PAL-Bilder 720 × 576 verbrauchen dadurch inakzeptable 90 MBytes an Texturspeicher. Zum Vergleich: Die Bilder sind im Original zusammen etwa 35.6 MBytes groß. Durch Beschneiden der Bilder auf ihre tats¨achlich genutzten Anteile l¨asst sich viel Speicher sparen: F¨ur eine Darstellung des Panoramas werden ja nur die Teile der Bilder ben¨otigt, die in den Alphamaps mit einer Eins gekennzeichnet wurden. Bei einem Zurechtschneiden der Bilder gilt es Folgendes zu beachten: Sei bx der minimale linke Abstand des auszuschneidenden Bereichs in Pixeln, by der minimale obere Abstand, w0 die neue Breite des Bildes und h0 die neue H¨ohe des Bildes. Dann gilt f¨ur das verkleinerte Bild eine neue Brennweite f0 = f ∗

w , w0

(3.31)

und damit w0 f 0 = w0 (f ∗

w ) w0

= wf,

h0 fy0 = h0 (f 0 ∗

w0 ) h0

= h0 (f ∗

w w0 ) w 0 h0

(3.32) = wf,

0

mit fy0 = f 0 ∗ wh0 neue Brennweite in y-Richtung. Die neue Kalibriermatrix K 0 der Kamera lautet 

wf

 K0 =   0 0

0

c0x



 wf c0y  , 0 1



1  wf

(K 0 )−1 =  0 0

mit einer neuen Hauptpunktverschiebung c0x =

w 2

0 1 wf

0

0

cx − wf



 c0 − wfy   1

− bx und c0y =

h 2

− by .

(3.33)

Kapitel 4 Interaktiver Ausgleich von Linsenverzerrungen Beim Linsenkameramodell in Abschnitt 2.4 wurde eine idealisierte Linse ohne Linsenverzeichnungen angenommen. Reale Kameralinsen produzieren geometrische Verzerrungen, so dass von der idealen Zentralprojektion abgewichen wird. Das Ergebnis sind beispielsweise tonnen- oder kissenf¨ormige Verzeichnungen von Quadraten. Bei Algorithmen, die mit den verzerrten Bildern arbeiten, m¨ussen diese Verzeichnungen mit zus¨atzlichem Aufwand ber¨ucksichtigt bzw. herausgerechnet werden. Diese Arbeit kann erheblich erleichtert werden, wenn man die Verzerrungsfunktion genau kennt. Alternativ k¨onnten gleich die Bilder in einem ersten Schritt entzerrt werden. Dieses Kapitel besch¨aftigt sich mit dem Ausgleich dieser Linsenverzerrungen unter Nutzung von 3D-Hardware-Beschleunigung. Eine Anwendung besteht darin, direkt entzerrte Bilder zu erzeugen, eine andere darin, die Parameter der Verzerrungsfunktion interaktiv zu bestimmen bzw. zu sch¨atzen. Abschnitt 4.1 nimmt eine mathematische Formalisierung der Linsenverzerrungen vor, Abschnitt 4.2 wird eine Invertierung der vereinfachten Verzerrungsfunktion vorstellen, und Abschnitt 4.3 beschreibt die Darstellung im Hinblick auf Nutzung der 3D-Hardware-Schnittstelle O PEN GL. 41

42

Kapitel 4. Interaktiver Ausgleich von Linsenverzerrungen

4.1

Berechnung von Linsenverzerrungen

Die Linsen sind zylindersymmetrisch, d.h. ein konzentrischer Kreis wird als Kreis mit einem verf¨alschten Radius abgebildet. Diese Verf¨alschung wird radiale Verzeichnung genannt und kann bei handels¨ublichen Kameras im Randbereich einige Pixel betragen. F¨ur einen Punkt p = (x, y) ∈ R2 kann sie ausgedr¨uckt werden durch 0

0

0



p = (x , y ) = p ∗ 1 +

n X

ki kpk

2i



(4.1)

i=1

f¨ur ein geeignetes n ∈ N. Allgemein kann aber angenommen werden, dass ein Polynom zweiten Grades (n = 1) bzw. vierten Grades (n = 2) ausreicht, um die radialen Linsenverzerrungen mit vernachl¨assigbarem Fehler zu modellieren [Tsa87]. Dadurch gewinnt man die vereinfachte Form p0 = (x0 , y 0 ) = p ∗ (1 + kkpk2 ).

(4.2)

Positive k bedeuten kissen- und negative k tonnenf¨ormige Verzerrungen. Bei Weitwinkellinsen sind tonnenf¨ormige Verzeichnungen u¨ blich, daher spielt diese Art von Verzerrung in der Praxis eine gr¨oßere Rolle. Die beiden verschiedenen Effekte der radialen Verzerrung sind in Abbildung 4.1 dargestellt.

(a)

(b)

Abbildung 4.1: Radiale Verzeichnung. Das gestrichelte Rechteck stellt das ideale unverzerrte Bild dar. Die Formen mit durchgezogenen Linien sind Beispiele f¨ur eine (a) tonnenf¨ormige Verzerrung, und (b) kissenf¨ormige Verzerrung.

Die Berechnung der Inversen dieser Funktion (4.2) ist trotz der Vereinfachung nicht direkt allgemein l¨osbar, sondern kann nur f¨ur diskrete Punkte direkt erfolgen.

4.2. Berechnung der einfachen radialen Entzerrungsfunktion

43

Wie man im Abschnitt 4.3 sehen wird, ist die Berechnung einer Inversen nicht unbedingt notwendig, um Bilder zu entzerren.

4.2

Berechnung der einfachen radialen Entzerrungsfunktion

Wie bereits erw¨ahnt, wird sich dieser Abschnitt mit der Berechnung der entzerrten Koordinaten der durch Linsenverzeichnungen nach (4.2) entstandenen Bildpunkte besch¨aftigen. Es wird keine allgemeine Inverse diese Funktion aufgestellt, sondern f¨ur bekanntes k und f¨ur konkrete Bildpunkte die Position vor ihrer Verzerrung berechnet. Sei also (x0 , y 0 ) 6= (0, 0) der zu entzerrende Bildpunkt, k sei bekannt und fest, und x und y seien die zu ermittelnden neuen Koordinaten. Gleichung (4.2) l¨asst sich f¨ur die x-Komponente als x0 = x ∗ (1 + k(x2 + y 2 )) formulieren. Mit α =

y0 x0

entsteht eine allgemeine kubische Gleichung1 :

(1 + α2 )kx3 + x − x0 = ax3 + x + d = 0 wegen

x y

=

x0 y0

(4.3)

(4.4)

und mit a = (1 + α2 )k, d = −x0 .

Dies ist ein bekanntes und relativ leicht l¨osbares Problem: Definieren wir p = 3a,

q = 27a2 d,

D = 4p3 + q 2 ,

(4.5) (4.6)

dann bezeichnet D die so genannte Diskriminante der Gleichung. Gilt D ≥ 0, dann hat die kubische Gleichung eine reelle und zwei komplexe L¨osungen, im Fall D < 0 drei reelle L¨osungen. Im Allgemeinen interessiert hier nur eine reelle L¨osung mit sgn(x) = sgn(x0 ). F¨ur den Fall D ≥ 0 heißt die reelle L¨osung x q q √ √ 1 3 1 3 −4q + 4 D + −4q − 4 D 2 2 x = Fx (x0 , y 0 ) := (4.7) 3a 1

Im Fall x0 = 0 setze α =

x0 y0

und ersetze in der folgenden Gleichung x0 durch y 0 und x durch y.

44

Kapitel 4. Interaktiver Ausgleich von Linsenverzerrungen

F¨ur den Fall D < 0 heißt die relevante reelle L¨osung x √ (2 −p) cos( ϕ3 ) −q x= , mit cos(ϕ) = p 3a 2 −p3

(4.8)

In beiden F¨allen errechnet sich dann y durch2 y = Fy (x0 , y 0 ) := αx

4.3

(4.9)

Visueller Ausgleich von Linsenverzerrungen

Um Bilder mit 3D-Hardware-Beschleunigung darzustellen, m¨ussen sie als Texturen auf einem Texturtr¨ager innerhalb eines virtuellen Universums definiert werden. In diesem Kapitel spielt die Brennweite f der verwendeten Kamera keine Rolle. Um trotzdem die Gleichungen aus Abschnitt 3.2 anwenden zu k¨onnen, sei o.B.d.A. f = 1. Die Bilder seien w Pixel breit und h Pixel hoch. Mittels Abbildung (3.19) kann dann ein Raster aufgespannt und auf eine Ebene im Raum projiziert werden. Diese projizierte Fl¨ache hat einen Abstand von z = 1 in z-Richtung vom Betrachter, die Breite

1 f

= 1, die H¨ohe

h wf

=

h , w

und hat ihr Zentrum auf

der optischen Achse des Betrachters. Es gibt nun zwei M¨oglichkeiten, die Mittel der Hardware-Beschleunigung auszunutzen, um einen Ausgleich der Bilder durchzuf¨uhren: 1. Anwendung der Entzerrungsfunktion, d.h. der Inversen von (4.2), auf die Position der Rasterpunkte im Texturtr¨ager 2. Anwendung der Verzerrungsfunktion auf die Texturkoordinaten der Rasterpunkte im Texturtr¨ager Beide Varianten implementieren eine Approximation einer nichtlinearen Texturprojektion. Approximation deshalb, da die 3D-Hardware bzw. O PEN GL zwischen den korrekten neuen Rasterpunkten bzw. den Texturkoordinaten der Rasterpunkte linear interpoliert. Es entstehen also Fehler, a¨ hnlich der perspektivischen Korrektur bei der allgemeinen Texturprojektion, die ja auch nur eine Approximation der 2

Im Fall x0 = 0 m¨ussen x und y in der Gleichung vertauscht werden.

4.3. Visueller Ausgleich von Linsenverzerrungen

45

korrekten perspektivischen Projektion darstellt. W¨ahlt man das Raster aber fein genug, und ist |k| innerhalb des gew¨ohnlichen Rahmens (d.h. |k| < 10−6 ), dann sind die Fehler vernachl¨assigbar klein. Beim zweiten Verfahren kann auf eine Entzerrungsfunktion verzichtet werden, allerdings bringt es andere Nachteile mit sich: Je nach Art der Verzerrung, d.h. tonnen- oder kissenf¨ormig, muss das Raster eingeschr¨ankt oder erweitert werden. Eine direkte Berechnung dieser neuen Gr¨oße f¨allt jedoch wegen der fehlenden Entzerrungsfunktion aus. Stattdessen m¨ussen die begrenzenden Rasterpunkte mit maximalen bzw. minimalen modifizierten Texturkoordinaten ermittelt werden. Zudem sind die auftretenden Bildr¨ander je nach Feinheit des Rasters starkem Aliasing unterworfen, denn entweder kann einem Rasterpunkt eine g¨ultige Texturkoordinate zugewiesen werden, oder nicht. Letzteres betrifft dann alle interpolierten Werte zu seinen benachbarten Rasterpunkten, die dann auch entfernt werden. Wegen dieser Nachteile wurde von einer Implementierung der TexturkoordinatenAnpassung Abstand genommen und statt dessen die erste Methode, die Verschiebung der Rasterpunkte, implementiert. Daher wird sich auch im Folgenden darauf beschr¨ankt. Der Prozess der Rasteranpassung ist in Abbildung 4.2 veranschaulicht. Das Verfahren ist offenbar nur anwendbar, wenn eine entsprechende Entzerrungsfunktion – wohlgemerkt muss diese nicht stetig sein – f¨ur die einzelnen Rasterpunkte zur Verf¨ugung steht. Sei also p0 = (x0 , y 0 ) die Position eines Rasterpunktes auf dem Texturtr¨ager. Seine neue entzerrte Position kann dann gem¨aß Gleichungen (4.7), (4.8) und (4.9) bestimmt werden. Um das entzerrte Bild passend, d.h. ohne R¨ander, darzustellen, muss der korrekte Blickwinkel (field of view) des Betrachters ermittelt werden. Dazu berechne zun¨achst die neue maximale Breite w0 f¨ur ein gegebenes k, so dass keine R¨ander entstehen3 :  2Fx ( w , 0) falls k < 0 2 0 w = 2F ( w , h ) sonst x 2 2

3

Die maximale Breite h0 kann analog durch die Funktion Fy bestimmt werden.

(4.10)

46

Kapitel 4. Interaktiver Ausgleich von Linsenverzerrungen

(a)

(b)

(c)

Abbildung 4.2: Prozess des Entzerrens: (a) Originalbild, (b) Berechnung der neuen Rasterpunkte, (c) Texturierung

Daraus kann der Blickwinkel θ wie folgt berechnet werden: θ = 2 tan−1 (

w0 ) 2w

(4.11)

Kapitel 5 Ergebnisse und Diskussion Dieses Kapitel zeigt einige Beispiele von Panoramen, die unter Nutzung der im Rahmen dieser Arbeit entwickelten Software entstanden sind. Die anschließende Diskussion begr¨undet, warum O PEN GL bzw. C++ gegen¨uber JAVA 3D als Basis f¨ur die Implementierung bevorzugt wurde, und vergleicht die beiden Filter Radialund Mittelwertfilter.

5.1

¨ Panoramen Beispiele fur

Dieser Abschnitt zeigt drei Beispielpanoramen, die durch das Programm IMV (Interactive Mosaic Viewer), das im Rahmen der Arbeit entstanden ist, visualisiert wurden. Die Berechnung der Bildpositionen erfolgte durch ImageMosaicing [S¨ul01]. Da eine Darstellung der dreidimensionalen Projektionsfl¨achen wie Kugel- oder Zylinderschale als Pr¨asentation ungeeignet ist, wird im Folgenden f¨ur die Beispiele die in IMV implementierte sph¨arische Projektion unter Nutzung des Radialfilters abgebildet. Abbildung 5.1 zeigt einen Teil der Kieler Innenstadt, aufgenommen vom CAP Kiel mit Blick auf die Kieler F¨orde. Deutlich sind hier st¨orende Helligkeitsunterschiede einzelner Bilder zu erkennen. Idealerweise sollte im Vorfeld ein Helligkeitsabgleich stattfinden. Prinzipbedingt sind einige Fahrzeuge auf diesem Bild 47

48

Kapitel 5. Ergebnisse und Diskussion

abgeschnitten, hier hat der Radialfilter das Bild gewechselt. Abbildung 5.2 stellt einen Ausschnitt dieses Panoramas dar. Ein Ausschnitt des Kieler Universit¨atsgel¨andes ist auf Abbildung 5.3 zu sehen. Bis auf die u¨ blichen Helligkeitsunterschiede ist ein nahezu perfektes Ergebnis entstanden. ¨ Schließlich zeigt Abbildung 5.4 eine Ubersicht einer H¨alfte des Diplomandenraums des Instituts.

5.2

Diskussion

Die Auswahl an m¨oglichen Sprachen f¨ur die Implementierung der in Kapitel 3 vorgestellten Verfahren ist groß. Zun¨achst wurde JAVA 3D ausgew¨ahlt, da es die Technik der 3D-Programmierung elegant durch sein Klassenkonzept abstrahiert bzw. kapselt, und trotzdem durch das Prinzip der 3D-Hardware-Beschleunigung eine gute Performanz erzielen kann. Dazu setzt JAVA 3D auf einer 3D-Schnittstelle wie O PEN GL oder D IRECT 3D auf. Die n¨otigen zeitaufw¨andigen Berechnungnen, die f¨ur eine Nutzung des Radialbzw. Mittelwertfilter im Vorfeld angestellt werden m¨ussen, d.h. die Berechnung der Relevanzbereiche bzw. der Alphamaps, sind von JAVA bedingt durch die Natur der Interpretersprache nur f¨ur sehr wenige Bilder in akzeptabler Zeit zu bew¨altigen. In der Praxis ist man darauf angewiesen, die Relevanzbereiche bzw. Alphamaps durch effizientere Programmiersprachen wie C++ berechnen zu lassen und diese in JAVA zu verwenden. Neben dem erheblichen Zeitaufwand durch JAVA spricht ein weiteres Argument gegen dessen Nutzung: der Speicherbedarf. Abbildung 5.5 zeigt einen direkten Vergleich des Speicheraufwands des JAVA 3D-Plugins SpherePart3D und des Radialfilters von IMV, dem direkt in O PEN GL implementierten Programm, ohne eine Zurechtschneidung der Bilder. Man erkennt, dass beide Kurven linear ansteigen, die von JAVA 3D allerdings mit etwa zweifachem Anstieg. Dazu ein Erkl¨arungsversuch: JAVA 3D setzt auf einer low-level-API auf, in diesem Fall O PEN GL. Es ist anzunehmen, dass Texturen nicht nur in der low-level-API, d.h.

5.2. Diskussion

49

Abbildung 5.1: Kieler Innenstadt, 24 Bilder.

Abbildung 5.2: Ausschnitt von Abbildung 5.1, 12 Bilder.

Abbildung 5.3: Kieler Universit¨atsgel¨ande, S¨udwestseite, 17 Bilder.

50

Kapitel 5. Ergebnisse und Diskussion

Abbildung 5.4: Diplomandenraum, 14 Bilder.

O PEN GL, gehalten werden, sondern zus¨atzlich innerhalb JAVA 3D. Bei vielen Bildern bzw. Texturen f¨ullt auch der durch die Zurechtschneidung der Bilder gem¨aß den Relevanzbereichen stark verminderte Speicherbedarf des Radialfilters in IMV den Texturspeicher einer Grafikkarte. So verbraucht etwa ein 26-Bilder-Panorama schon 21 MB. Dies ist f¨ur manche Grafikkarten schon mehr, als in ihren Texturspeicher passt. Die Folge ist eine einbrechende Performanz der Darstellung. Eine L¨osung, bei der man allerdings leichte Abstriche der Bildqualit¨at in Kauf nimmt, stellt die Texturkompression bzw. -dekompression in Hardware dar, die von den meisten Grafikkarten unterst¨utzt wird. Da diese immer in einem konstanten Faktor 1:6 komprimiert, wird z.B. aus einem Speicheraufwand von 21MB 3.5MB. Leider unterst¨utzt zum Zeitpunkt der Erstellung dieser Arbeit JAVA 3D keine Texturkompression, und es ist auch keine Unterst¨utzung angek¨undigt. Die genannten Argumente haben dazu gef¨uhrt, dass JAVA 3D nur als PrototypSprache f¨ur den Panorama-Betrachter verwendet wurde. Das Hauptprogramm wurde in C++ programmiert und nutzt direkt O PEN GL.

5.2. Diskussion

51

250

Speicher/MB

200

150

100

50

0

0

5

10

Speicheraufwand IMV

15 Anzahl Bilder

20

25

30

Speicheraufwand Java3D-Plugin

Abbildung 5.5: Vergleich des Speicheraufwands des Radialfilters von IMV ohne Zurechtschneidung der Bilder und des JAVA 3D-Plugins.

5.2.1

Vergleich der Filter

Beide Filter, der Mittelwertfilter und der Radialfilter, haben ihre Vor- und Nachteile. Der Radialfilter stellt ein scharfes Bild dar und kann vom Speicherbedarf her im Vergleich zum Mittelwertfilter stark optimiert werden. Sich bewegende Objekte werden vom Mittelwertfilter naturgem¨aß sehr unscharf abgebildet. Der Radialfilter stellt sie dagegen scharf, aber oft nur abgeschnitten und kleinere Objekte manchmal gar nicht im Panorama dar. Der Zeitaufwand der Berechnung ist beim Radialfilter kleiner, da er beim Berechnen der Punktdistanzen abbrechen kann, sobald ein anderes Bild einen kleineren Punktabstand hat. Der Mittelwertfilter muss immer f¨ur alle Punkte alle benachbarten Bilder durchgehen. Wie man in Abbildung 5.6 erkennen kann, ist der Zeitaufwand dennoch auch f¨ur den Mittelwertfilter ab einer Bilderanzahl von ca. 5 nahezu linear, da bei der Berechnung nur sich u¨ berlappende Bilder ber¨ucksichtigt werden. Leider liefert der Mittelwertfilter in seiner jetzigen Form kein perfektes Bild: Schon kleine Unterschiede von einem ¨ Pixel zwischen der Berechnung der Uberlappungsbereiche und der tats¨achlichen Darstellung von O PEN GL bzw. JAVA 3D sind durch L¨ucken im Panorama zu er-

52

Kapitel 5. Ergebnisse und Diskussion

kennen und st¨oren das Gesamtbild. Abbildung 5.7 zeigt einen direkten Vergleich der Visualisierung durch Mittelwert- und Radialfilter. Deutlich kann man die kleinen Registrierungsfehler von ImageMosaicing im Mittelwertfilter erkennen. Der Radialfilter hingegen vermittelt trotz der Fehler noch einen guten Gesamteindruck.

5.2. Diskussion

53

16 14 12

Zeit/s

10 8 6 4 2 0

0

5

10

15 Anzahl Bilder

20

25

30

Zeitaufwand IMV Radialfilter Alphamap-Berechnung Zeitaufwand IMV Mittelwertfilter Alphamap-Berechnung

Abbildung 5.6: Entwicklung des Zeitaufwands f¨ur die Berechnung der Relevanzbereiche bzw. der Alphamaps durch den Radial- bzw. Mittelwertfilter. Gerechnet wurde auf einem AMD Duron 800MHz mit 512MB RAM, Implementierungsgrundlage ist IMV, ein im Rahmen der Arbeit entwickeltes Programm.

(a)

(b)

Abbildung 5.7: Direkter Vergleich der Filter. (a) Mittelwertfilter, (b) Radialfilter.

Kapitel 6 Zusammenfassung Im Zuge dieser Arbeit wurden Verfahren entwickelt, um die Darstellung von abstandstreuen Panoramen und den Ausgleich von Linsenverzerrungen als approximierte nichtlineare Texturprojektionen zu visualisieren. Der Schwerpunkt lag dabei auf der Effizienz bzw. Performanz der Darstellung durch eine Nutzung von 3D-Hardware-Beschleunigung, die eine Interaktion in Echtzeit m¨oglich macht. Es wurde das verwendete Verfahren Rotational Mosaicing zur Berechnung der Positionen der einzelnen Bilder innerhalb des Panoramas vorgestellt. F¨ur die Darstellung des Panoramas wurden zwei Techniken (Filter), Radial- und Mittel¨ wertfilter, zur Verbindung bzw. Uberlagerung der einzelnen Bilder realisiert. Die Technik zur Nutzung der Hardware-Beschleunigung wurde auf den Ausgleich von Linsenverzerrungen angewandt. Dazu wurde zun¨achst die Umkehrfunktion der radialen Verzerrungsfunktion entwickelt, die dann auf die Elemente des aufspannenden Bildtr¨agers angewandt werden, und damit ein entzerrtes Bild entsteht. Unter Verwendung von C++ und O PEN GL sind die Referenzimplementierungen Interactive Mosaic Viewer (IMV) und Interactive Undistorter (IU) entstanden. Mittels JAVA 3D entstand ein erster Prototyp des MosaicViewers als Plugin f¨ur das Visualisierungstool IVT von J. L. Gonz´alez V´azquez [V´az01]. Dabei hat sich JAVA 3D hinsichtlich des Speicherbedarfs f¨ur die verwendete Menge und Gr¨oße von Texturen als ungeeignet herausgestellt (s. Kapitel 55

56 Ergebnisse).

Kapitel 6. Zusammenfassung

Anhang A Implementierung Zur Umsetzung der in Kapitel 3 und Kapitel 4 beschriebenen Verfahren wurden zwei Programme entwickelt, deren Strukturen und wichtigsten Klassen im Folgenden zusammengefasst vorgestellt werden.

A.1

Das IVT-Plugin SpherePart3D

Die Klasse SpherePart3D wurde als Plugin f¨ur das JAVA 3D-Tool IVT (Interactive Visualization Tool) von Jos´e Luis Gonz´alez V´azquez [V´az01] konzipiert. Es stellt ein Panorama auf einer Projektionsfl¨ache frei w¨ahlbarer Form durch eine passende Zusammensetzung von Einzelbildern dar. Dabei wird dem Betrachter erm¨oglicht, eine interaktive Exploration des Panoramas bzw. der Szene durchzuf¨uhren. Grundlage der Darstellung bilden die Orientierungsdaten der einzelnen Bilder, die vom Programm ImageMosaicing von Michael S¨ulzer [S¨ul01] geliefert werden. Abbildung A.2 zeigt die Klassenstruktur des Plugins. Leider hat sich JAVA 3D hinsichtlich des Speicherbedarfs f¨ur die verwendete Menge von Texturen als ungeeignet herausgestellt (s. Kapitel Ergebnisse), daher ist das entstandene Plugin nur als Prototyp f¨ur das eigentliche Programm IMV zur PanoramaBetrachtung anzusehen. Die wesentlichen Funktionen k¨onnen zu folgenden Schritten zusammengefasst werden: 57

58

Kapitel A. Implementierung 1. Einlesen der Bilder und Orientierungsdaten 2. Einlesen der Relevanzdaten f¨ur jedes Bild: f¨ur jedes Bild wird die Dimension und Lage des Streifens angegeben, der im Panorama von diesem Bild zu sehen sein soll. Diese Daten wurden in der ersten Phase des Projektes von ImageMosaicing geliefert, in der zweiten Phase von IMV. 3. Konstruktion eines Texturtr¨agers f¨ur jedes Bild entsprechend der gew¨ahlten Geometrie/Form und Zuweisung der Texturkoordinaten; entsprechende Erweiterung des JAVA 3D-Szenengraphen 4. Festlegung der Szenenparameter wie etwa Betrachterposition und -orientierung oder Darstellungswinkel

Abbildung A.1: Screenshot des IVT-Plugins.

A.2

Interactive Mosaic Viewer (IMV)

Unter Nutzung der vom Programm ImageMosaicing von Michael S¨ulzer [S¨ul01] gelieferten Orientierungsdaten in Form von Rotationsmatrizen f¨ur jedes Bild stellt

A.2. Interactive Mosaic Viewer (IMV)

SpherePart3D

erzeugt und kontrolliert

59

SpherePart

Inhalt

Parameter für BoundingPart

SphereBP

Geometrie / Form

CylinderBP

CuboidBP

Abbildung A.2: Klassenstruktur des IVT-Plugins.

das Tool IMV eine Sequenz von Bildern als Panorama innerhalb eines virtuellen dreidimensionalen Raums dar. Es wurde in C++ programmiert und benutzt O PEN GL als Visualisierungsschnittstelle. Das Klassenkonzept von IMV ist dem des IVT-Plugins sehr a¨ hnlich. Eine wesentliche Erweiterung stellt die Abstraktionsebene Filter“ dar, die die Kombi” nation der einzelnen Bilder abstrahiert. Dabei l¨asst sich das im IVT-Plugin verwendete Verfahren als ein spezieller Filter auffassen, der so genannte Radialfilter (s. Abschnitt 3.2.3). Ein weiterer implementierter Filter ist der Mittelwertfilter, ¨ der den Mittelwert der Bilder durch transparente Uberlagerung erzeugt. Der zu verwendende Filter l¨asst sich als Parameter u¨ ber die Kommandozeile ausw¨ahlen. Es folgt eine Zusammenfassung der wichtigsten Schritte: 1. Einlesen der Bilder und Orientierungsdaten 2. je nach Filter: • Radialfilter (a) Berechnung der relevanten Bereiche f¨ur jedes Bild (b) Ausschneiden der relevanten Bereiche • Mittelwertfilter (a) f¨ur jeden Punkt des Panoramas Berechnung der Anzahl Bilder, die sich u¨ berlappen

60

Kapitel A. Implementierung (b) Erstellung von Alphamaps f¨ur jedes Bild/Textur, d.h. eine entsprechende Gewichtung der einzelnen Texel, so dass ein korrekter Mittelwert gebildet wird 3. Konstruktion eines Texturtr¨agers f¨ur jedes Bild entsprechend der gew¨ahlten Geometrie/Form und Zuweisung der Texturkoordinaten 4. Festlegung der Szenenparameter wie etwa Betrachterposition und -orientierung oder Darstellungswinkel P1

R1 ImageMosaicing

Pn

Rn

IMV

Abbildung A.3: Parameter f¨ur IMV: Bilder P1 bis Pn und Rotationsmatrizen R1 bis Rn .

A.3 Interactive Undistorter (IU) Das Programm IU stellt das Bild einer Kamera durch O PEN GL in Echtzeit verbzw. entzerrt dar. Dazu wird ein Raster aufgebaut, das interaktiv durch Wahl des Faktors der radialen Verzerrung gedehnt bzw. gestaucht wird. Bei korrekter Sch¨atzung des Faktors ist ein entzerrtes Bild das Ergebnis. Das Grabbing der Kamerabilder erfolgt u¨ ber Klassen, die von den Klassen v4lsource und v4lpicture von Jan-Friso Evers [Eve01] abgeleitet sind.

Literaturverzeichnis [BN76]

B LINN , JAMES F. and M ARTIN E. N EWELL: Texture and Reflection in Computer Generated Images. CACM, 19(10):542–547, October 1976.

[Cat74]

C ATMULL , E DWARD E.: A Subdivision Algorithm for Computer Display of Curved Surfaces. PhD thesis, Dept. of CS, U. of Utah, December 1974.

[Eve01]

E VERS , JAN -F RISO: Entwicklung einer orientierungssensitiven Kamera zur Erstellung von Panoramabildern. Diplomarbeit, ChristianAlbrechts-Universit¨at zu Kiel, 2001.

[FvDH91] F OLEY, J. D., A.

VAN

DAM, and J. F. H UGHES: Computer Graph-

ics, Principles and Practice. Addison-Wesley Systems Programming Series. Addison-Wesley, 2nd edition, 1991. [HM91]

H ECKBERT, PAUL S. and H ENRY P. M ORETON: Interpolation for Polygon Texture Mapping and Shading.

In State of the Art in

Computer Graphics: Visualization and Modeling, pages 101–111. Springer-Verlag, 1991. [SS97]

S HUM , H. Y. and R. S ZELISKI: Panoramic image mosaics. Technical report, Microsoft Research, 1997.

[S¨ul01]

¨ S ULZER , M ICHAEL: Image Mosaicing. Albrechts-Universit¨at zu Kiel, 2001. 61

Diplomarbeit, Christian-

62 [Tsa87]

LITERATURVERZEICHNIS T SAI , R. Y.: A versatile camera calibration technique for highaccuracy 3D machine vision metrology using off-the-shelf TV cameras and lenses. In IEEE Journal of Robotics and Automation, volume RA-3, No. 4, pages 323–344, August 1987.

[V´az01]

´ ´ V AZQUEZ , J OS E´ L UIS G ONZ ALEZ : Visualisierung raum-zeitlicher Daten unter Java 3D. Diplomarbeit, Christian-Albrechts-Universit¨at zu Kiel, 2001.

[WNDS99] W OO , M ASON, JACKIE N EIDER, T OM DAVIS, and DAVE S HREINER: OpenGL Programming Guide.

Addison-Wesley, 3rd

edition, 1999. [Woe01]

W OETZEL , JAN: Projektive 3D-Rekonstruktion durch Bildfolgenanalyse monokularer Kameras mit adaptierbarer Korrespondenzsuche. Diplomarbeit, Christian-Albrechts-Universit¨at zu Kiel, 2001.

Danksagungen Diese Diplomarbeit wurde am Lehrstuhl Multimediale Systeme zur Informationsverarbeitung der Christian-Albrechts-Universit¨at zu Kiel angefertigt. Ich danke allen Mitarbeitern des Lehrstuhls f¨ur die Hilfsbereitschaft und das gute Arbeitsklima. Bei meinem Betreuer Herrn Dipl.-Ing. Jan-Friso Evers-Senne bedanke ich mich besonders f¨ur die gute fachliche Betreuung und die hervorragende Unterst¨utzung. Ich danke Herrn Prof. Dr.-Ing. Reinhard Koch f¨ur das Angebot des interessanten Themas und die vielen Anregungen zu dieser Arbeit. Weiterhin bedanke ich mich bei meiner Freundin Annie f¨ur ihr großes Verst¨andnis, die Motivierung und Aufmunterung. Meinem Bruder Dirk danke ich f¨ur die Ablenkung. Ein großer Dank gilt meinen Eltern Helmut und Renate f¨ur die umfassende Unterst¨utzung in jeglichem Sinne.

Erkl¨arung

Ich versichere, dass ich die vorliegende Arbeit selbstst¨andig verfasst und ausschließlich die angegebenen Hilfsmittel und Quellen verwendet habe.

Kiel, im Juni 2002