E57 erklärt: das "PDF der Punktwolken"
Stellen Sie sich vor, Sie fotografieren einen Raum — aber statt eines flachen Bildes erfassen Sie die genaue Position von einer Million winziger Punkte, die jede Wand, jeden Stuhl und jede Kaffeetasse bedecken. Lassen Sie einen Laser schnell genug rotieren und messen Sie, wie weit alles entfernt ist, und genau das erhalten Sie: eine Punktwolke, ein 3D-"Foto" aus gemessenen Punkten. Dies ist eine freundliche, verständliche Tour durch das, was tatsächlich in einer E57-Datei steckt — und einen cleveren Trick, den unsere Software damit macht.
Warum überhaupt ein spezielles Format?
Ein normales Foto ist nur ein Raster aus farbigen Pixeln — einfach. Ein 3D-Scan ist komplizierter. Für jeden seiner Millionen Punkte möchten Sie speichern, wo er sich im Raum befindet (drei Zahlen: X, Y, Z), welche Farbe er hat, wie stark der Laser zurückgeworfen wurde (seine Intensität — denken Sie an ein schwarz-weißes "Laserfoto") und oft die Panoramafotos, die der Scanner gleichzeitig aufgenommen hat.
Stellen Sie sich nun vor, eine Person scannt mit einem Faro, eine Kollegin mit einem Leica, und der Kunde öffnet das Ergebnis in Autodesk-Software. Drei Geräte, drei Programme — und alle müssen dieselbe Datei noch Jahre später lesen können, ohne beim Hersteller um einen geheimen Decoder zu betteln. Genau dieses Problem löst E57. Es ist ein offener, herstellerneutraler Standard (veröffentlicht als ASTM E2807 und auf der Open-Source-Bibliothek libE57 aufgebaut). Man nennt ihn das "PDF der Punktwolken": eine portable Datei, die jeder lesen kann.
Die Grundidee: eine Textkarte mit binärer Muskelkraft
Im Kern ist eine E57-Datei ein Hybrid aus zwei sehr unterschiedlichen Dingen, die zusammengefügt sind: einem kleinen Stück XML — einfachem, für Menschen lesbarem Text, der als Inhaltsverzeichnis dient — und großen Blöcken binärer Daten, die die rohen Millionen Zahlen enthalten und kompakt für Geschwindigkeit 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 1024-Byte-"Seiten" unterteilt, und jede Seite reserviert ihre letzten 4 Bytes für eine Prüfsumme — einen Fingerabdruck, mit dem 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 — genau wie Ordner 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 aufzuschreiben
Ein Laserscanner denkt nicht wirklich in X, Y, Z. Er steht an einem Ort und dreht sich, und für jeden Punkt kennt er drei Dinge: Reichweite (wie weit der Strahl gelaufen ist), Azimut (wie weit herum, links-rechts) und Elevation (wie weit nach oben oder unten). Das sind sphärische Koordinaten — die Muttersprache des Scanners. Die meiste Software bevorzugt jedoch einfaches kartesisches X, Y, Z. E57 speichert beides problemlos, und die Umrechnung ist etwas schnelle Trigonometrie.
Drei Arten eingebetteter Fotos
Die Fotos in images2D sind keine Links zu Dateien in einem Ordner — das eigentliche JPEG oder PNG steckt direkt im E57. Und es gibt mehr als eine Art eingebetteter Fotos. E57 verpackt jedes davon in eine "Repräsentation", die der Software sagt, wie sehr sie dem Bild geometrisch vertrauen kann. Der Unterschied läuft auf eine einzige Frage hinaus: wie vollständig ist die Kamera beschrieben?
sphericalRepresentation— ein vollständiges 360° × 180°-Panorama, das vertraute gestreckte 2:1-equirectangulare Bild. Da die Projektion bekannt ist, entspricht jedes Pixel einer exakten Richtung, sodass es perfekt mit der Punktwolke übereinstimmt. Das ist der Hauptweg in unserer Pipeline: Wir lesen es, bringen die Leinwand auf ein sauberes 2:1 und geben es an den Panorama-Viewer weiter.pinholeRepresentation— ein normales Objektivfoto, beschrieben durch das klassische Pinhole-Kameramodell (Brennweite, Sensorgröße, optisches Zentrum). Das reicht der Software, um auch die Richtung jedes Pixels zu kennen, nur eben in einem engeren Blickfeld. In der Praxis funktioniert Leica meist genau so: Es schreibt ein fertiges Cubemap — die sechs flachen Würfelflächen nach außen gerichtet — direkt in die E57, und unser Würfelflächen-Pfad setzt genau diese zu einem vollständigen Panorama zusammen. Das ist einer der einfachsten Fälle, um daraus wieder ein sauberes 360°-Bild zu machen.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 behält diese 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 leicht falsch umsetzen — genau deshalb kann derselbe Scan in verschiedenen Programmen unterschiedlich aussehen.
- Blinde Zonen werden abgeschnitten. Jeder Scanner hat einen Bereich, den er nicht sehen kann — klassisch direkt nach unten, wo sein eigenes Stativ steht. Manche Exporter schneiden das Panorama dort einfach ab und lassen eine Lücke oder eine unübliche Höhe zurück.
- Rechteckige Pixel. Ein sauberes Panorama hat quadratische Pixel (
pixelWidth=pixelHeight); manche Dateien haben das nicht, sodass das Bild gestreckt wirkt, bis es neu skaliert wird. - Die falsche Richtung ist „vorwärts“. Die mit einem Panorama gespeicherte Rotation sagt, welche Richtung in der Bildmitte liegt, und es gibt keine einheitliche Einigung darauf, was „vorwärts“ überhaupt bedeutet — manche Exporter richten sie nach Norden, andere nach Osten. Ein kleiner Fehler hier dreht die gesamte Ansicht.
- Bearbeitungstools können Daten verlieren. Beim Hin- und Zurückspeichern einer E57-Datei über CloudCompare kann zum Beispiel die Aufnahmeposition von
pinholeRepresentation-Bildern verloren gehen — die Fotos bleiben erhalten, wissen aber nicht mehr, wo sie aufgenommen wurden.
Unterm Strich: In der Praxis zeigt verschiedene Software dieselbe E57-Datei oft unterschiedlich. Unser Importer versucht, die üblichen Eigenheiten auszugleichen — rechteckige Pixel zu quadratischen zu machen, die Panoramaausrichtung zu korrigieren und die 2:1-Leinwand zu standardisieren — damit eine Tour richtig aussieht, egal mit welchem Tool die Datei geschrieben wurde.
Wenn das Panorama direkt in die Punktwolke eingebrannt ist
Hier ist eine der elegantesten — und am wenigsten gewürdigten — Ideen des gesamten Formats. Neben als separate Bilder gespeicherten Panoramen kann ein Panorama auch im Punktwolke selbst verborgen sein. Ein Laserscanner feuert nicht zufällig — er tastet ein ordentliches Raster von Winkeln ab, Zeile für Zeile, Spalte für Spalte, wie ein alter Fernseher, der einen Bildschirm zeichnet. E57 kann diese Reihenfolge bewahren: Jeder Punkt erhält einen rowIndex und einen columnIndex, die angeben, aus welcher Rasterzelle er stammt. Ein so gespeicherter Scan wird strukturiert genannt.
Der Vorteil: Wenn die Punkte auf einem Raster liegen, ist die Wolke 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 in ihren 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 ist mit Richtungen, in denen der Strahl in den offenen Himmel schoss und nichts zurückkam? Die pragmatische Antwort lautet: Diese Zellen mit fiktiven Punkten füllen — sehr oft mit einer Entfernung von genau 0, also "Strahl gesendet, nichts getroffen". Sie halten das Rechteck intakt, sind aber keine echte Geometrie, also muss ein aufmerksamer Leser sie beiseite lassen. Unsere Software markiert jeden Punkt mit Nullentfernung, legt ihn in einer Dummy-Ferne ab, damit die Rastermathematik weiter funktioniert, und behandelt diese Phantom-Himmelspunkte beim Erzeugen der Tiefenkarte oder beim Export der Punktwolke niemals als reale Flächen.
Einen Scan wieder in ein Foto verwandeln, in das man hineingehen kann
Nicht jeder Scan kommt auf einem fertigen Raster an — manche sind nur ein loses, unstrukturiertes Bündel von Punkten. Die gute Nachricht: Das Panorama lässt sich trotzdem wiederherstellen, und genau hier trifft das Format auf unsere eigene Arbeit. Denn ein Scan ist im Grunde "eine vollständige Kugel aus Punkten, gemessen als Winkel um einen einzigen Punkt" — man kann ihn also zu einem flachen Panorama entfalten.
Notiere den Winkel jedes Punkts, lasse links-rechts über die Bildbreite und oben-unten über die Bildhöhe laufen, und jeder Punkt landet auf einem Pixel — das vertraute gestreckte 2:1-equirectangulare Panorama. Die Tiefenkarte ist die Zauberzutat: Mit einer Entfernung hinter jedem Pixel wird ein flach wirkendes Panorama messbar und begehbar — klicke zwei Punkte an einer Wand an, und die Software kennt den echten Abstand, weil sie die 3D-Daten darunter nie vergessen hat.
Warum ist E57 also wichtig?
Weil es der neutrale Treffpunkt ist. Ein Vermesser scannt eine Brücke mit einer Hardware-Marke, ein Ingenieur öffnet sie in anderer Software, und ein Architekt archiviert sie für die nächsten zwanzig Jahre — und E57 ist die eine Datei, auf die sich alle drei verlassen können, ohne dass ein Hersteller die Schlüssel in der Hand hält. Es hält Farbe, Intensität, Geometrie, Panoramen und die überaus wichtigen Sensorpositionen an einem Ort zusammen, als offenen Standard, den jeder implementieren kann.
Noch eine letzte Kuriosität: Die Erfassungszeit in einer E57-Datei wird in GPS-Zeit gezählt — Sekunden seit dem 6. Januar 1980, dem Moment, in dem die Uhren der GPS-Satelliten eingeschaltet wurden — und nicht ab der üblichen Computer-Epoche von 1970. Wer das verwechselt, liest einen heute aufgenommenen Scan so, als wäre er 2013 entstanden.
Möchten Sie tiefer einsteigen?
- libE57.org — die maßgebliche Open-Source-Bibliothek und die Heimat des Formats.
- ASTM E2807 — der offizielle Standard.
- libE57Format · Image2D — exakte Definitionen der sphärischen, Lochkamera- und visuellen Referenzdarstellungen.
- Paul Bourke’s E57 notes — eine knappe technische Aufschlüsselung von Header und Struktur.