E57 erklärt: das "PDF der Punktwolken"
Stellen Sie sich vor, Sie fotografieren einen Raum — doch statt eines flachen Bildes erfassen Sie die genaue Position von einer Million winziger Punkte, die jede Wand, jeden Stuhl und jede Kaffeetasse bedecken. Wenn Sie einen Laser schnell genug rotieren lassen und messen, wie weit alles entfernt ist, erhalten Sie eine Punktwolke: ein 3D-"Foto" aus vermessenen Punkten. Dieser leicht verständliche Überblick zeigt ohne Fachjargon, was tatsächlich in einer E57-Datei steckt — und welchen cleveren Kniff unsere eigene Software dabei nutzt.
Warum überhaupt ein spezielles Format?
Ein normales Foto ist lediglich ein Raster aus farbigen Pixeln — ganz einfach. Ein 3D-Scan ist komplexer. Für jeden seiner Millionen Punkte sollen die Position im Raum (drei Werte: X, Y, Z), die Farbe, die Stärke des reflektierten Lasersignals (die Intensität — vergleichbar mit einem schwarz-weißen "Laserfoto") und häufig auch die gleichzeitig vom Scanner aufgenommenen Panoramafotos gespeichert werden.
Stellen Sie sich nun vor, eine Person scannt mit einem Faro-Scanner, ein Kollege verwendet einen Leica-Scanner und der Kunde öffnet das Ergebnis in Autodesk-Software. Drei Geräte, drei Programme — und alle müssen dieselbe Datei auch noch Jahre später lesen können, ohne einen Hersteller um einen geheimen Decoder bitten zu müssen. Genau dieses Problem löst E57. Es ist ein offener, herstellerneutraler Standard (veröffentlicht als ASTM E2807 und basierend auf der quelloffenen Bibliothek libE57). E57 wird als das "PDF der Punktwolken" bezeichnet: eine portable Datei, die von allen einheitlich gelesen werden kann.
Die Grundidee: eine Textkarte mit binärer Muskelkraft
Im Kern ist eine E57-Datei ein Hybrid aus zwei grundverschiedenen Bestandteilen: einem kleinen XML-Abschnitt — menschenlesbarem Klartext, der als Inhaltsverzeichnis dient — und großen Blöcken mit Binärdaten, in denen Millionen von Rohwerten kompakt und schnell zugänglich gespeichert sind.
Warum die Karte ans Ende setzen? Weil ein Scanner beim Schreiben der Datei noch nicht weiß, wie groß alles sein wird, also zuerst die Rohdaten streamt und erst am Ende eine saubere Zusammenfassung schreibt. Der Vorteil ist enorm: Um einen Scan aus einer 20-Gigabyte-Datei herauszuholen, liest die Software den winzigen Header, springt zur XML-Karte, findet die Zeile "Scan #3 liegt bei Byte 4.812.000.000" und springt direkt dorthin.
Unauffälliges Sicherheitsnetz: Die gesamte Datei ist in 1.024 Byte große "Seiten" unterteilt. Die letzten 4 Byte jeder Seite sind für eine Prüfsumme reserviert — einen Fingerabdruck, anhand dessen die Software erkennt, ob die Datei beschädigt wurde.
Alles hängt an einer Wurzel
Öffnen Sie diese XML-Karte, und Sie finden einen Baum — ganz ähnlich wie die Ordnerstruktur auf Ihrem Computer. Es gibt ein einziges root, und zwei Zweige erledigen den Großteil der Arbeit: data3D, eine nummerierte Liste von Scans, und images2D, eine nummerierte Liste von Fotos (meist die 360°-Panoramen, die der Scanner aufgenommen hat).
Zwei Arten, einen Punkt zu speichern
Ein Laserscanner arbeitet nicht direkt mit X, Y und Z. Er steht an einem festen Punkt und rotiert. Für jeden Punkt kennt er drei Werte: die Entfernung (wie weit der Strahl zurückgelegt hat), den Azimut (den horizontalen Winkel nach links oder rechts) und die Elevation (den vertikalen Winkel nach oben oder unten). Das sind sphärische Koordinaten — die Muttersprache des Scanners. Die meisten Programme bevorzugen jedoch einfache kartesische X-, Y- und Z-Koordinaten. E57 kann beide Varianten speichern; die Umrechnung erfolgt mit etwas Trigonometrie.
Drei Arten eingebetteter Fotos
Die Fotos in images2D sind keine Links zu Dateien in irgendeinem Ordner — die eigentliche JPEG- oder PNG-Datei steckt direkt in der E57-Datei. Und es gibt mehr als eine Art eingebetteter Fotos. E57 bettet jedes Foto in eine "Darstellung" ein, die der Software angibt, inwieweit sie sich auf die Bildgeometrie verlassen kann. Der Unterschied läuft auf eine einzige Frage hinaus: Wie vollständig ist die Kamera beschrieben?
sphericalRepresentation— ein vollständiges 360° × 180°-Panorama, also das vertraute gestreckte equirektangulare 2:1-Bild. Da die Projektion bekannt ist, entspricht jedes Pixel einer exakten Richtung und lässt sich perfekt an der Punktwolke ausrichten. Dies ist der wichtigste Pfad in unserer Verarbeitung: Wir lesen das Bild ein, bringen die Bildfläche auf ein sauberes 2:1-Verhältnis und übergeben es an den Panorama-Viewer.pinholeRepresentation— ein gewöhnliches Objektivfoto, beschrieben durch das klassische Lochkameramodell (Brennweite, Sensorgröße, optisches Zentrum). Damit kann die Software ebenfalls die Richtung jedes Pixels bestimmen, allerdings nur innerhalb eines kleineren Sichtfelds. In der Praxis arbeitet vor allem Leica so: Eine fertige Cubemap — die sechs nach außen gerichteten, flachen Würfelflächen — wird direkt in die E57-Datei geschrieben. Unser Verarbeitungspfad für Würfelflächen fügt genau diese Flächen zu einem vollständigen Panorama zusammen. Dies ist einer der einfachsten Fälle, um wieder ein sauberes 360°-Bild zu erzeugen.visualReferenceRepresentation— ein Foto ganz ohne Kameramodell, ausdrücklich "nur für das menschliche Auge". Damit kann man nicht messen und es nicht auf die Punktwolke projizieren; es ist nur eine Referenzaufnahme. Unser Importer speichert solche Fotos als angehängte Kommentare, statt sie in 3D zu platzieren.
Hier liegt der Haken. sphericalRepresentation ist die beliebte Wahl, lässt sich aber überraschend leicht falsch umsetzen — genau deshalb kann derselbe Scan in verschiedenen Programmen unterschiedlich aussehen.
- Blinde Bereiche werden abgeschnitten. Jeder Scanner hat einen Bereich, den er nicht erfassen kann — typischerweise direkt unter sich, wo sein eigenes Stativ steht. Manche Exportprogramme beschneiden das Panorama dort einfach, sodass eine Lücke oder eine nicht standardmäßige Höhe entsteht.
- Nicht quadratische Pixel. Ein sauberes Panorama hat quadratische Pixel (
pixelWidth=pixelHeight). Bei manchen Dateien ist das nicht der Fall, sodass das Bild gestreckt wirkt, bis es neu skaliert wird. - Die falsche Richtung ist “vorwärts”. Die mit einem Panorama gespeicherte Rotation gibt an, welche Richtung in der Bildmitte liegt, und es gibt keine allgemeingültige Festlegung, was “vorwärts” überhaupt bedeutet — manche Exportprogramme richten sie nach Norden aus, andere nach Osten. Ein kleiner Fehler an dieser Stelle dreht die gesamte Ansicht.
- Bearbeitungstools können Daten verlieren. Wird eine E57-Datei beispielsweise mit CloudCompare geöffnet und wieder gespeichert, kann die Aufnahmeposition von
pinholeRepresentation-Bildern verloren gehen — die Fotos bleiben erhalten, wissen aber nicht mehr, wo sie aufgenommen wurden.
Das Ergebnis: In der Praxis wird dieselbe E57-Datei von verschiedenen Programmen oft unterschiedlich dargestellt. Unser Importer versucht, häufige Eigenheiten auszugleichen: Er skaliert nicht quadratische Pixel neu, korrigiert die Ausrichtung des Panoramas und vereinheitlicht die Bildfläche auf das 2:1-Format. So sieht eine Tour unabhängig vom Programm, mit dem die Datei erstellt wurde, korrekt aus.
Wenn das Panorama direkt in die Punktwolke eingebrannt ist
Darin steckt eine der elegantesten — und am wenigsten beachteten — Ideen des gesamten Formats. Neben Panoramen, die als separate Bilder gespeichert sind, kann ein Panorama auch in der Punktwolke selbst verborgen sein. Ein Laserscanner sendet seine Strahlen nicht wahllos aus — er tastet Zeile für Zeile und Spalte für Spalte ein regelmäßiges Winkelraster ab, ähnlich wie ein alter Fernseher beim Bildaufbau. E57 kann diese Reihenfolge bewahren: Jedem Punkt werden ein rowIndex und ein columnIndex zugewiesen, die angeben, aus welcher Rasterzelle er stammt. Ein so gespeicherter Scan wird als strukturiert bezeichnet.
Der Vorteil: Wenn die Punkte in einem Raster liegen, ist die Punktwolke bereits ein Bild. Liest man sie Zeile für Zeile, landet jeder Punkt auf einem Pixel — das Panorama erscheint ganz ohne clevere Neuprojektion. Die Datei speichert die Rastergröße sogar unter indexBounds (columnMaximum, rowMaximum), sodass die Software die Auflösung im Voraus kennt — unser Synthesizer übernimmt die Ausgabebreite direkt aus columnMaximum + 1.
Aber ein Raster muss ein perfektes Rechteck sein, und die reale Welt ist es nicht. Was geschieht in Richtungen, in denen der Strahl in den offenen Himmel ging und nichts zurückkam? Die pragmatische Antwort lautet: Diese Zellen werden mit fiktiven Punkten gefüllt — sehr oft mit einer Entfernung von genau 0, also "Strahl gesendet, nichts getroffen". Sie vervollständigen das Rechteck, stellen aber keine echte Geometrie dar und müssen daher von sorgfältig arbeitender Software ausgesondert werden. Unsere Software markiert jeden Punkt mit der Entfernung 0, setzt ihn auf eine fiktive große Entfernung, damit die Rasterberechnung weiter funktioniert, und behandelt diese fiktiven Himmelspunkte beim Erzeugen der Tiefenkarte oder beim Exportieren der Punktwolke niemals als reale Flächen.
Einen Scan wieder in ein Foto verwandeln, in dem Sie stehen können
Nicht jeder Scan liegt bereits in einem fertigen Raster vor — manche bestehen nur aus einer losen, unstrukturierten Ansammlung von Punkten. Die gute Nachricht: Das Panorama lässt sich trotzdem wiederherstellen, und hier setzt unsere eigene Arbeit an. Denn ein Scan ist im Grunde "eine vollständige Kugel aus Punkten, die von einem einzigen Standpunkt aus anhand ihrer Winkel erfasst wurden" — man kann ihn also zu einem flachen Panorama abwickeln.
Jeder Punkt wird anhand seiner Winkelposition einem Pixel des vertrauten, gestreckten equirektangularen 2:1-Panoramas zugeordnet: von links nach rechts über die Bildbreite und von oben nach unten über die Bildhöhe. Die Tiefenkarte ist dabei die entscheidende Zutat: Für jedes Pixel ist eine Entfernung hinterlegt, sodass ein flach wirkendes Panorama messbar und begehbar wird. Klicken Sie zwei Punkte auf einer Wand an, kennt die Software den tatsächlichen Abstand, weil die zugrunde liegenden 3D-Daten erhalten geblieben sind.
Warum ist E57 also wichtig?
Weil es der neutrale Treffpunkt ist. Ein Vermesser scannt eine Brücke mit der Hardware eines Herstellers, ein Ingenieur öffnet die Scandaten in einer anderen Software, und ein Architekt archiviert sie für die nächsten zwanzig Jahre — dabei können sich alle drei auf dieselbe E57-Datei verlassen, ohne von einem Hersteller abhängig zu sein. Als offener Standard, den jeder implementieren kann, vereint E57 Farbe, Intensität, Geometrie, Panoramen und die überaus wichtigen Sensorpositionen in einer Datei.
Noch eine interessante Tatsache: Die in einer E57-Datei gespeicherte Aufnahmezeit wird als GPS-Zeit angegeben — in Sekunden seit dem 6. Januar 1980, dem Beginn der GPS-Zeit — und nicht anhand der üblichen Computer-Epoche von 1970. Wird dies falsch interpretiert, erscheint ein heute aufgenommener Scan so, als stamme er aus dem Jahr 2013.
Möchten Sie tiefer einsteigen?
- libE57.org — die maßgebliche Open-Source-Bibliothek und zentrale Anlaufstelle für das Format
- ASTM E2807 — der offizielle Standard
- libE57Format · Image2D — genaue Definitionen der sphärischen Darstellung, der Lochkameradarstellung und der visuellen Referenzdarstellung
- Paul Bourke’s E57 notes — eine kompakte technische Erläuterung des Headers und der Struktur