Abstract
In computer vision, reconstructing 3D models from real world data is an important task with diverse possibilities for practical application. In this work, the approach of Schroers et al. (2012) and Zach et al. (2007) is followed in implementing a 3D reconstruction tool using range image integration for data from RGBD sensors and camera position data. To improve performance in terms of speed and memory footprint, dynamic octrees, which adapt to the movement of the object surface during reconstruction, are used. To further enhance the quality of the resulting meshes retrieved using the marching cubes algorithm (Lorensen and Cline, 1987), separate mesh recoloring and the mesh decimation algorithm described in Schroeder et al. (1992) are implemented as well.
November: closest signed distances und Fehlerbehebung
Das Paper, auf dem diese Arbeit basiert, schlägt vor, anstelle der traditionell gemessenen Entfernung eines Punktes von der Objektoberfläche (entlang der Geraden durch die Kamera und den Punkt) die Entfernung für mehr Genauigkeit zu berechnen. Dies ist das vorerst letzte Feature, das noch in die Software eingebaut wurde.
Gleichzeitig mussten noch mehrere Fehler gefunden werden, die nur in Spezialfällen auftraten. Zuerst musste die mesh reduction neu implementiert werden, da sie aufgrund anderer Änderungen in der Programmstruktur keine Knoten aus dem 3D-Modell mehr entfernte. Dabei zeigten sich mehrere andere Probleme in bestehendem Code, darunter auch verschiedene Speicherzugriffsfehler (buffer overflow und double free). Zudem stellte sich heraus, dass alte Codeüberbleibsel, die für die Farbglättung hinzugefügt wurden, die Propagierung der Farbe zu Punkten, die nicht über die ursprünglichen Daten eingefärbt werden konnten, verhinderten, da diese Punkte trotzdem als eingefärbt markiert waren.
Ein weiterer Fehler betrifft die Teile des Programmes, die ihre eigene Laufzeit messen. Sie erzeugten dabei falsche Messwerte, sodass z.B. nach drei Minuten Laufzeit für das Programm erst 20 Sekunden vergangen waren. Dies konnte allerdings auf einen Fehler des verwendeten Compilers und/oder der verwendeten C++-Bibliothek zurückgeführt werden und wird deshalb vorerst vernachlässigt.
Oktober: „Treppen-Bug“ und Aufteilen von Octrees
Bei manchen Objekten kann mit aktivierter Glättung auf real glatten Seiten eine regelmäßige Folge von Senkungen finden. Diese entstehen, da das Zusammenführen der Octrees nicht mehr rückgängig gemacht wird, wenn die Glättung die Objektkante in den zusammengeführten Octree schiebt. Wir haben diesen Fehler den „Treppen-Bug“ getauft, da bei höherer Glättung treppenartige Gebilde entstehen können.
Um diesen Fehler zu beheben, müssen zuvor zusammengefasste Octree-Blöcke wieder aufgeteilt werden, wenn sie der Kante zu nahe kommen. Dies war zuvor schon ohne großen Erfolg versucht worden, allerdings wurden die Probleme dabei von einem anderen Fehler als dem „Treppen-Bug“ verursacht.
Juni: Fehlerbehebung, Farbe, dynamische Octrees und „mesh reduction„
Da mit der Implementierung der Octrees sämtliche Algorithmen umgeschrieben werden mussten, kam es zu zahlreichen schwer identifizierbaren Fehlern. So lieferten die ersten Testläufe (wie in allen vorangegangenen Beispielen mit dem Akkuschauber) folgendes Bild, Schuld trägt der Fakt, dass Stellen, an denen in einer Aufnahme kein Objekt gefunden wurde, für diese Aufnahme vollständig ignoriert wurden, sodass diese Stellen fälschlicherweise als „innerhalb des Objekts“ galten, obwohl sie nur in einer von vielen Aufnahmen in oder hinter dem eigentlichen Objekt lagen.
Nach dem Beheben der Fehler erzeugt das Programm nun aber sehr detaillierte 3D-Modelle. Da das Glätten der Farben in den vorherigen Monaten fehlgeschlagen war, werden nun die Farben der einzelnen Punkte mit einem einfacheren Verfahren ermittelt: Für jeden Punkt wird überprüft, in welchen Aufnahmen er „gesehen“ wird, und dann der Mittelwert der Farben der Originalbilder an den passenden Stellen als Farbe genommen. Die Farben können so genauer wiedergegeben werden. Allerdings gibt es Stellen, an denen keine Farbdaten vorhanden sind, da sie nie von einer der Kameras gesehen wurden, momentan bleiben diese Punkte grau.
Um die Effizienz weiter zu verbessern, wurde die Implementierung noch erweitert: Wenn die Tiefenwerte, die intern repräsentieren, wo sich das Objekt befindet, in bestimmten benachbarten Regionen sehr ähnlich sind, können diese zu einer größeren Region zusammengefasst werden, sodass insgesamt weniger berechnet werden muss. Ändern sich die Werte in einer solchen Region zu sehr, kann diese aber auch wieder in mehrere kleine unterteilt werden. In der Visualisierung (insbesondere im Fenster links oben in den Bildern) ist gut zu sehen, wie die feine Unterteilung außerhalb und innerhalb des Objekts (nicht entlang des Randes des Objekts, an dem die Auflösung möglichst groß bleiben soll) sich auflöst und eine gröbere Struktur mit größeren Regionen zurückbleibt:
vor dem Zusammenfassen
nach dem Zusammenfassen
Bei hoher Detailgenauigkeit kann die Größe der Ausgabedateien schnell 40 MB erreichen. Um diese zu reduzieren, wurde zusätzlich anhand von Schroeder et al. (1992) ein „mesh reduction„-Algorithmus implementiert, der die Anzahl der einzelnen Dreiecke, aus denen das 3D-Modell aufgebaut ist, reduziert, ohne dass die Qualität zu sehr darunter leidet. Dies führt in Regionen, in denen sich die Dreiecke sehr ähneln (z.B. auf einer einfarbigen Fläche) zu einer Verringerung der Dreieckszahl, während die hohe Detailtiefe an Kanten und Ecken erhalten bleiben kann.
Um auch Stellen, für die von den Kameras keine Farbe geliefert wurde, einen realistischen Farbwert zu geben, wird die Farbe nun von bereits eingefärbten Punkten an nicht eingefärbte Punkte übertragen („color propagation„)
Mai: Octrees
Um Arbeitsspeicher und Laufzeit zu sparen, werden die Tiefen- und Bilddaten jetzt als Octrees gespeichert. So kann bei weniger Ressourcenverbrauch eine höhere Auflösung und Detailtiefe erzielt werden. Zusätzlich wurden neue Visualisierungsmethoden implementiert:
April: Anisotrope Glättung
Das Paper sieht vor, dass die Glättung auch an das Gefälle der Oberfläche angepasst wird (anisotropes Glätten). Allerdings stellte sich im Laufe des Monats heraus, dass dies kaum einen Einfluss auf die entstehenden Modelle hat, und der damit verbundene Geschwindigkeitseinbruch den Nutzen um ein Vielfaches überwog. Zusätzlich wurde der Code, der für die Farbglättung verantwortlich war, wegen zahlreicher Bugs entfernt.
März: Farbe
Anstelle des Markerboards werden nun vorberechnete Positionen im Raum verwendet, welche von der Software, die auch die Bild- und Tiefendaten vom Sensor ausliest, generiert werden. Außerdem werden die Daten nun bei der Glättung des 3D-Modells so gewichtet, dass häufig gesehene Stellen (für die die Daten deshalb genauer sind) weniger geglättet werden als selten gesehene. Gleichzeitig werden die erzeugten 3D-Modelle mit den Farben aus den Originalbildern eingefärbt:
Um Bereichen, die nur in wenigen oder gar keinem der Bilder vom Sensor gesehen wurden, eine realistische Farbe zu geben, soll nicht nur die Oberfläche geglättet werden, sondern es soll mit den Farben ebenso verfahren werden. Beim Versuch, dies zu implementieren, kommt es allerdings zu unerwarteten Ergebnissen:
Januar – Februar: Erste Implementierung
Im Laufe dieser Forschungsarbeit soll – dem Ansatz von Schroers et al. (2012) folgend – eine Software entwickelt werden, die aus Farbbildern mit zusätzlichen Tiefeninformationen dreidimensionale Modelle rekonstruieren soll. Nach dem ersten Treffen Mitte Januar habe ich bis Anfang Februar eine erste Implementierung in C++ fertigstellen können, die zwar schon 3D-Modelle erzeugte, aber noch nicht alle Ideen aus dem Paper berücksichtigte.
Das Bild zeigt ein Plastikmodell eines Hasen, das häufig für die 3D-Rekonstruktion verwendet wird, auf einem sogenannten Markerboard. Die Muster auf dem Brett dienen dazu, die Position der Kamera relativ zur Mitte des Bretts (durch den grünen Punkt markiert) zu bestimmen. Der rote Würfel markiert das Gebiet, das während der Rekonstruktion berücksichtigt wird. In den nachfolgenden Wochen wurden dann die gröbsten Fehler behoben, sodass einigermaßen ansehnliche Ergebnisse erzielt werden konnten.
Als erstes Objekt für die Rekonstruktion verwendete ich einen Akkuschrauber, von dem ca. 40 Bilder und Tiefendaten aus verschiedenen Perspektiven aufgenommen wurden. Die neu erzeugten 3D-Modelle werden dann als .ply-Dateien ausgegeben:
