Gigapan Timemachine

Dies ist ein Tutorial zur Installation und Inbetriebnahme eines Rendering-programms für Timemachines. Da neben der Computerwelt mein Herz auch für die Fotografie schlägt, ist dies ein Thema, das beide Welten miteinander verbindet. Zur Beschreibung, um was es sich genau handelt, verweise ich auf meinen Fotoblog (link: comming soon). Hier soll es lediglich um die technische Umsetzung gehen. In diesem Artikel behandele ich die Installation auf einem einzelnen PC. Für einen Cluster aus mehreren Rechnern werde ich ein extra Tutorial schreiben, da hierfür etwas mehr Aufwand von nöten ist.

Der Render-client ist für Windows, OSX und Linux verfügbar. Für den Windows-Client gibt es auch eine einfache GUI, in meinem Tutorial soll es sich aber um die Installation unter Ubuntu Linux 12.04 64 Bit gehen. Für weitere Informationen zu den anderen Betriebssystemen und weitere Informationen verweise ich auf das Wiki von gigapan.org.

Installation
Alle arbeiten werden in der shell ausgeführt, es werden root-Rechte mit sudo vorausgesetzt. Zuerst müssen ein paar Pakete installiert werden:

sudo apt-get install ia32-libs xvfb ruby1.8

Ia32-libs wird benötigt, da das Programm nur für 32 Bit kompiliert ist, xvfb stellt einen window-manager da, der auch auf Servern ohne Desktop einen Dummy-X-Server für den Stitcher zur Verfügung stellt. Solltet ihr eine neuere Version von Ruby nutzen, so müsst ihr trotzdem ruby1.8 installieren, da nur dieses mit dem Programm kompatibel ist. Als nächstes erstellen wir uns den Ordner „timemachine“ und laden in diesen das Programmpaket der Timemachine (tmc) herunter und entpacken es.

mkdir tmc

cd tmc

wget *link coming soon*

tar xvzf *dateiname*

Das Programm ist nun bereits lauffähig, es beinhaltet den Stitcher und einige Beispiele im Ordner ct-examples. Um die Funktionsfähigkeit des Programms zu testen, geht in den Ordner ct und gebt folgenden Befehl ein:

ruby1.8 ct.rb --selftest

Sämtliche Module werden getestet und (hoffentlich) mit „success“ bestätigt. Am Ende sollte „ct.rb self-test succeeded.“ zu lesen sein. Ist dies nicht der Fall, so fehlen eventuell Zugriffsrechte auf Programmteile. Um ein uneingeschränktes ausführen zu ermöglichen müsst Ihr zurück in den Hauptordner von tmc gehen und den folgenden Befehl eingeben, welcher sämtlichen Dateien in diesem Ordner vollen Zugriff ermöglicht:

chmod -R 777 ./

Nun sollte das Programm funktionieren.

Rendering

Es gibt verschiedene Arten, wie das Programm ausgeführt wird. So kann als Input wahlweise eine Bildserie aus einem einzelnen Blickwinkel, eine Bildserie bestehend aus Gigapans oder mehrere bereits fertig hochgeladene Panoramen von gigapan.org, verwendet werden. Die Einstellungen dafür werden über die Konfigurationsdatei „definition.tmc“ festgelegt.

Fall 1: Bildserie mit einem Bild

Die Ausführung des Programms gestaltet sich immer gleich:

ruby1.8 ct.rb Projektname.tmc Projektergebniss.timemachine

Projektname.tmc ist der Ordner, in den die Rohfotos und die definition.tmc kommen. Erstellt diesen Ordner auf eurer Festplatte unter einem beliebigen Namen (nur die Endung .tmc MUSS exakt so vorhanden sein, da sonst das Programm nicht arbeitet!), in meinem Beispiel wird er im selben Ordner liegen, in dem auch der Ordner tmc liegt. In diesem Projektordner erstellen wir nun einen Ordner „0100-original-images“, in den alle Bilder kopiert werden, die zu einer Timemachine gerendert werden sollen. Der Name des Ordners ist wichtig, da das Programm nur in einem Ordner mit diesem Namen nach den Bildern sucht (analog kann man in der definition.tmc für jedes Bild einen Pfad angeben, was aber sehr viel Aufwand bei vielen Bildern bedeutet). Erstellt nun in Projektname.tmc die Datei definition.tmc. Im folgenden seht ihr meine Beispiel-konfiguration, die Ihr so übernehmen könnt:

{
  "source":{
    "type": "images"
   },
   "videosets":[
         {
            "label": "Large",
            "type": "h.264",
            "size": "large",
            "quality": 26,
            "fps": 30
         }
  ]
}

Der eigentlich wichtige Parameter hier ist die fps-Anzahl, die festlegt, wie schnell euer Video später abgespielt wird. Da die definition.tmc sehr umfangreich sein kann, verweise ich an dieser Stelle wieder auf das Wiki von gigapan.org mit ausführlicheren Erklärungen für alle Modi. Desweiteren gibt es im tmc-Ordner ein Beispiel zum testen unter tmc-1.0.8.3-linux/ct-examples/patp10_1x1.tmc

Nun ist alles vorbereitet und wir können uns an das rendern machen. Geht dazu wieder in den ct-Ordner und führt folgenden Befehl aus:

ruby1.8 /home/user/timemachine/tmc-1.0.8.3-linux/ct/ct.rb /home/user/timemachine/Projektname.tmc/definition.tmc /home/user/timemachine/Projektergebniss.timemachine

oder kurz (wenn ihr im ct-Ordner seid)

ruby1.8 ct.rb ../../Projektname.tmc/defintion.tmc ../../Projektergebniss.timemachine

Nun wird es eine weile dauern, bis der Rendering-Prozess fertig ist. Am Ende dieses Artikels habe ich ein paar Zeiten meiner ersten Timemachines zum abschätzen aufgeschrieben. Habt ihr mehr als einen CPU-Kern in eurem Rechner, könnt ihr den Parameter -j gefolgt von einer Zahl für die Anzahl der verfügbaren CPU-Kerne angeben, wie -j 4 für einen Quadcore-Prozessor. Gebt aber niemals eine größere Zahl an, als Kerne verfügbar sind, da die Ausführung sonst langsamer wird.

Wenn das Programm durchgelaufen ist, seht ihr eine kurze Zusammenfassung der benötigten Zeit. Geht nun in den Ordner Projektergebniss.timemachine. Für eine Veröffentlichung dieses Projekts auf einem Webserver müsst ihr diesen Ordner komplett dorthin kopieren. Darin befindet sich die Datei view.html, welche euch beim aufrufen die fertige Timemachine abspielt. Entwickelt wurde das Programm für die Browser Google Chrome und MS Internet Explorer 11, jedoch habe ich es auch schon mit der neusten Firefox-Version öffnen können.

Fall 2: Stitching

Handelt es sich bei dem Rohmaterial nicht um eine einfache Bilderfolge, sondern mehrere Bilder, welche erst noch jeweils zu einem Panorama zusammengeführt werden müssen, werden ein paar kleine Änderungen im Gegensatz zum Fall 1 nötig. Die erste Änderung ist der Ordnername der Rohbilder, welcher nun den Namen „0100-unstitched“ bekommt. In diesen werden wieder alle Bilder der Panoramen kopiert. Und jetzt müssen die Bilder leider noch in Unterordner (alle Bilder eines Panoramas in einen Ordner) sortiert werden, denn leider kann das Stitching-Tool das noch nicht selbst. Hierzu habe ich mit Hilfe eines Freundes ein einfaches Bash-Script geschrieben, welches diese Aufgabe übernimmt. Den dazugehörigen Artikel finden ihr hier.

Sind die Bilder erfolgreich einsortiert, muss zuletzt noch die definition.tmc angepasst werden.

{
  "source":{
    "type":"stitch",
    "align_to": "[(i-1)/10*10]",
    "align_to_comment": "Align each gigapan to a master selected every 10 gigapans",
    "cols": 3,
    "rows": 2,
    "stitcher_args": "--no-vignette-correction --equalize-exposure-using-exif --adjust-exposure 0.5 --xvfb"
   },
   "videosets":[
         {
            "label": "Large",
            "type": "h.264",
            "size": "large",
            "quality": 26,
            "fps": 30
         }
  ]
}

Wichtig hier ist, dass an der Stelle type „stitch“ steht, damit vor dem eigentlichen Renderprozess die Panoramen zusammengesetzt werden. Ebenfalls wichtig ist der Wert „align_to“. Mit dessen Hilfe werden die Bilder aneinander ausgerichtet, damit es später nicht zu zu starken Verwackelungen kommt, wenn die Rohbilder nicht exakt deckungsgleich sind. In diesem Beispiel wird alle 10 Frames ein Masterbild genutzt, an dem die folgenden 9 ausgerichtet werden. Weitere Möglichkeiten findet Ihr auf der Entwicklerseite.

Ist alles eingestellt, starten wir den Renderer wie im Fall 1 mit

ruby ct.rb Projektname.tmc Projektergebnis.timemachine

Am Ende der Berechnung erhaltet Ihr wieder eine fertige Timemachine.

Statistiken

Zum Abschluss möchte ich noch eine kleine Übersicht über meine bisherigen Berechnungen geben, damit der Zeitaufwand für die Berechnung abgeschätzt werden kann und Ihr ein Gefühl bekommt.. denn es sind zum Teil mehrere Stunden dafür nötig. Das erste Beispiel ist eine Berechnung 104 Panoramen mit 2×3 Bildern je 18 Megapixel. Mit einem Desktop-PC mit 4 Kernen auf 3,3 GHz waren insgesamt 8h 25min 13s nötig. Dabei wurde eine Ausgabedatei von 11,7 GB Größe erstellt, das gesamte Projekt hat 23,6 GB Platz auf der Festplatte belegt. Mit Hilfe eines Servers mit 8 Kernen und HT bei 2,27 GHz hat sich die Zeit auf ca. 3,7 Stunden vergeringert, da das Programm sehr gut parallelisierbar ist. Durch die Verwendung eines zweiten (baugleichen) Servers zum berechnen wurde die Zeit weiter auf 2h 54m 57s reduziert, was einem Geschwindigkeitszuwachs von rund 27% durch den zweiten Server entspricht. Grund hierfür ist eine Limitierung der Parallelisierung beim Stitching.

Das zweite Beispiel ist eine Reihe aus 802 Einzelbildern je 18 Megapixel. Diese Berechnung habe ich gleich auf dem Server mit seinen insgesamt 16 x 2,27 GHz ausgeführt, welche 2,2 GB für die Ausgabedatei in 2h 35m 25s erzeugte und insgesamt 23 GB Platz auf der Festplatte (mit temporären Daten) verbraucht. Durch den zweiten Server mit weiteren 16 Kernen verkürzte sich die Berechnungszeit auf  1h 31m 30s, was sogar knapp 70% Beschleunigung entspricht.

Im letzten Beispiel habe ich eine sehr große Anzahl an Bildern (17000) mit recht niedriger Auflösung (FullHD) berechnet. Dies ist eigentlich kaum sinnvoll, da die Auflösung der Rohbilder bereits unter der von hochauflösenden Bildschirmen ist, sollte aber der Vollständigkeit wegen ebenfalls berechnet werden. Hier zeigt sich, dass die vielen Rohdaten die Festplatte stark beanspruchen und die CPU kaum genutzt wird. So benötigten beide Server Stunden. Die genaue Zeit für die Einzelberechnung habe ich leider nicht notiert, jedoch lag diese nur unwesentlich unter dieser Zeit.

Wie man sieht werden meistens Prozessor und Festplatte stark belastet, letztere sowohl vom gesamten Speichervolumen, als auch von den vielen parallelen Zugriffen, vor denen selbst mein Raid 5 aus 4 Server-Platten mit 15K Umdrehungen/Minute in die Knie gegangen ist. Eine wirkliche Beschleunigung des Prozesses könnte durch eine SSD erfolgen. Desweiteren würde ich aus meiner Erfahrung heraus lieber einen Server mit 4-8 Kernen bevorzugen, der eine möglichst hohe Taktrate hat, als viele Kerne mit niedrigerem Takt, was die nicht parallelisierbaren Bereiche im Programm beschleunigen würde.

Wie in den Statistiken bereits zu lesen war, habe ich mehrere Computer parallel an einer Timemachine arbeiten lassen. Dies ist mit ein wenig Mehraufwand ebenfalls möglich und kann gerade größere Projekte gut beschleunigen. Da die Erklärung dafür jedoch den Rahmen dieses bereits langen Artikels gänzlich sprengen würde, wird in näherer Zukunft dafür ein weiterer Artikel erscheinen. Bis dahin viel Spass mit meiner Anleitung, meldet Euch bei mir, wenn etwas nicht läuft, ich versuche gerne zu helfen. Timemachines sind ebenfalls gern gesehen 😉 Falls Ihr Verbesserungsvorschläge oder Kritik an dem Programm habt, könnt Ihr euch auch bei den Entwicklern der Software direkt unter [email protected] melden, Sie sind sehr hilfsbereit und geduldig. An dieser Stelle abschließend noch einen dickes Danke an Paul und Saman vom Gigapan-Team, welche mir geduldig geholfen haben! Nebenbei ist so auch die Linux-Version auf den aktuellsten Stand gebracht und vereinfacht worden.

Stay Tuned – Støertebeker

Veröffentlicht unter Allgemein, Installationen, Linux, Tutorials

Schreibe einen Kommentar