E57-Punktwolke: Was das Format speichert

Zusammenfassung: Was ist eine E57-Punktwolke?

Eine E57-Punktwolke bezeichnet üblicherweise die Scanmessungen selbst, während eine E57-Datei der Container ist, der diese Messungen samt zugehörigen Metadaten enthält. [1] In der aktuellen ASTM-Terminologie ist „E57-Datei“ die Kurzbezeichnung für das ASTM-E57-3D-Dateiformat, das in ASTM E2807-11(2026) definiert ist. [1]

In der Praxis ist das E57-Dateiformat ein neutrales Austauschformat für 3D-Bilddaten, kein Scannermodell, kein CAD-Volumenkörper-Format und keine Hersteller-Projektdatei. [1] Der Standard besagt, dass eine E57-Datei 3D-Punktdaten, Punktattribute wie Farbe und Intensität sowie 2D-Bilder speichern kann, wobei eine Kombination aus Binärdaten und XML mit einem Erweiterungsmechanismus für künftige Anforderungen verwendet wird. [1] Was das Format speichern kann, ist nicht dasselbe wie das, was jeder Exporter oder Importer bewahrt, und das Designpapier beschreibt E57 als Austauschformat statt als Arbeitsprojektformat. [1] [3]

Auf einen Blick

• Was es ist: ein herstellerneutrales Austauschformat für 3D-Bilddaten. [1]
• Was es enthalten kann: Punkte, Attribute wie Farbe oder Intensität, Metadaten und optionale 2D-Bilder. [1]
• Was es nicht garantiert: Scannergenauigkeit, vollständige Felderhaltung oder identisches Verhalten in verschiedener Software. [3]
• Bester erster Validierungsschritt: Öffnen Sie die Datei lokal, prüfen Sie sichtbare Scans und Attribute und testen Sie sie dann vor der Übergabe im Zielwerkzeug. [6] [11]

Historischer Hintergrund des E57-Dateiformats

Das ASTM-Komitee E57 für 3D-Bildgebungssysteme wurde 2006 eingerichtet, um Standardterminologie, Prüfmethoden, Best Practices und Spezifikationen für die Dateninteroperabilität von 3D-Bildgebungssystemen zu entwickeln. [2] Das von Daniel Huber im Januar 2011 veröffentlichte Designpapier beschrieb die Ziele, Struktur und den Kontext der frühen Implementierung des Formats. [3] Dieses Papier bleibt historisch wichtig, ist jedoch nicht der aktuell maßgebliche Standard. Es verweist auch darauf, dass das Format kürzlich als ASTM E2761 genehmigt worden sei, was heute nur noch als historischer Kontext betrachtet werden sollte. [3] Zum 5. Juni 2026 nennt die aktive ASTM-Shopseite als aktuell maßgebliche Spezifikation ASTM E2807-11(2026). [1]

Was eine E57-Datei ist und was nicht

E57 ist ein Austauschformat für 3D-Bilddaten. [1] Es ist kein Scannertyp, kein CAD-Volumenkörperformat, nicht primär ein Mesh-Format und keine Projektdatei im selben Sinn wie Software-Ökosysteme, die interne Indizes, Caches, Regionen, Anmerkungen und Anwendungszustände verwalten. [3] Das Designpapier stellt ausdrücklich klar, dass E57 weder als Arbeitsdatenformat noch als Projektformat gedacht ist und dass abgeleitete modellierte Objekte nicht enthalten sein sollten. [3]

Diese Unterscheidung ist wichtig, weil Nutzer oft erwarten, dass eine gemeinsam genutzte .e57 sich wie das Quellprojekt verhält. Die ReCap-Dokumentation von Autodesk trennt neutrale Exporte wie E57, PTS und PCG von Autodesk-zentrierten RCP/RCS-Projektstrukturen, bei denen RCP auf indizierte Punkt-Wolkendaten verweist, statt als neutraler Container zu dienen. [7] Die SCENE-Dokumentation von FARO zieht eine ähnliche Grenze aus einer anderen Perspektive: Ihr E57-Hinweis besagt, dass das Format für Scanpunkte und nicht für Objekte gedacht ist. [10]

E57-Dateiformat: Technische Prinzipien (konzeptionelle Anatomie, keine Parser-Anleitung)

Auf konzeptioneller Ebene verwendet E57 ein hybrides Design. [3] Die Hierarchie basiert auf XML, sodass die Struktur selbstbeschreibend und erweiterbar ist, während umfangreiche Nutzdaten wie Punkte und Bilder effizient binär gespeichert werden. [3] Hubers Papier beschreibt dies als Kompromiss zwischen flexiblen, selbstdokumentierenden Strukturen und dem praktischen Bedarf an schnellerem I/O sowie geringerem Speicherbedarf als bei Klartext-Punktdumps. [3]

Die übergeordnete Anatomie ist einfach: Eine E57-Datei gliedert sich in einen Header, optionale Binärabschnitte und einen XML-Abschnitt. [3] Einige Fakten auf Byte-Ebene sind gut belegt, ohne daraus eine Parser-Anleitung zu machen: Der Header umfasst 48 Bytes, Binärseiten umfassen 1024 Bytes mit 1020 Bytes Nutzdaten plus einer 32-Bit-CRC, Binärabschnitte verwenden die Byte-Reihenfolge Little-Endian, und der XML-Abschnitt ist ein einzelnes XML-1.0-Dokument mit UTF-8-Kodierung. [3] [4]

Das ist für Workflows relevant, weil E57 nicht „nur XYZ mit einer anderen Erweiterung“ ist. [3] Das Format kann mehrere 3D-Datensätze, optionale Bilder, strukturierte Metadaten und per Fehlerprüfung kontrollierbare binäre Nutzdaten in einem Austauschcontainer bündeln. [3] [4] Deshalb kann eine E57-Übergabe mehr Kontext als ein bloßer Textexport bewahren, aber auch deshalb können zwei Werkzeuge beide „E57 öffnen“ und dennoch darin voneinander abweichen, welche Teile sie behalten. [3] [4]

Kernbestandteile einer E57-Datei

• Header: ein 48-Byte-Dateiheader mit kritischen Informationen auf Dateiebene. [3] [4]
• Seitenbasierte Binärdaten mit CRC: Binärdaten sind seitenbasiert, mit 1020 Bytes Nutzdaten und einer 32-Bit-CRC je 1024-Byte-Seite. [3] [4]
• XML-1.0-UTF-8-Hierarchie: Der erforderliche XML-Abschnitt ist ein einzelnes XML-1.0-Dokument, das in UTF-8 kodiert ist. [4]
• Data3D: der Hauptcontainer für 3D-Datensätze wie Scans oder Punktsätze. [3] [4]
• Images2D: der optionale Container für zugehörige 2D-Bilder. [3] [4]
• CoordinateMetadata: eine optionale Zeichenfolge für standardisierten CRS-Kontext. [3] [4]
• CompressedVector: ein zentraler nichtterminaler Typ zum Speichern geordneter Datensätze in komprimierter Binärform. [3] [4]

Data3D, Images2D und Metadaten (was das Schema ausdrücken soll)

Innerhalb der Hierarchie befindet sich in Data3D ein scanähnlicher 3D-Datensatz. [3] Jedes Data3D enthält Punktdaten in einem CompressedVector, und öffentliche Beschreibungen bezeichnen die logische Struktur pro Punkt üblicherweise als PointRecord. [3] [4] Das Format ist flexibel: Es kann kartesische oder sphärische Koordinaten darstellen, und ein bestimmter Datensatz kann Felder wie RGB-Farbe, Intensität, Zeilen- und Spaltenindizes, Rückgabeinformationen oder Zeitstempel enthalten. [3] Nicht jede Datei enthält jedes Feld, und manche Software kann zusätzlich Normalen oder verwandte abgeleitete Felder in ihrem eigenen Datenmodell bereitstellen; das Vorhandensein von Feldern muss daher geprüft und darf nicht vorausgesetzt werden. [5] [6]

Images2D ist der parallele Container für optionale, mit Scans verknüpfte Bilddaten. [3] Das öffentliche Designpapier beschreibt vier Bildrepräsentationen: Visual Reference, Pinhole, Spherical und Cylindrical. [3] Bilder werden als JPEG- oder PNG-Blobs gespeichert, und das Modell soll eine sinnvolle Beziehung zwischen Pixeln und dem Koordinatensystem des Scans bewahren, sofern diese Beziehung existiert. [3] [4] Wenn Bilder nach dem Import verschwinden, liegt der Grund gewöhnlich nicht darin, dass E57 sie nicht speichern kann, sondern darin, dass der Exporter sie ausgelassen hat, die Zuordnung unvollständig war oder das empfangende Werkzeug nur einen Teil der Bildrepräsentationen unterstützt. [3] [6]

Was wird in einem E57-Scandatenformat gespeichert? (Und was ist optional?)

Auf Ebene der Fähigkeiten kann ein E57-Scandatenformat Geometrie, Punktattribute, Metadaten und optionale Bilddaten in einem Container speichern. [1]

Die praktische Frage lautet weniger „Was kann E57 speichern?“ als „Was haben diese Datei und diese Werkzeugkette bewahrt?“ [1] [3] Eine Datei kann mehrere Data3D-Datensätze, Metadaten auf Dateiebene, Pose-Informationen auf Scanebene, optionalen CRS-Kontext und Bilder enthalten, doch ein Importer kann Scans zusammenführen, Bilder verwerfen, CRS-Text ignorieren oder nur Attribute behalten, die allen internen Wolken gemeinsam sind. [3] [4] Deshalb sollten E57-Lieferdateien stets unter dem Gesichtspunkt Formatfähigkeit versus Softwareunterstützung bewertet werden. [1] [3]

Prüfen Sie diese Lieferfelder, bevor Sie eine E57-Punktwolkendatei akzeptieren

• Punktanzahl pro Scan, sofern das Werkzeug sie anzeigt. [5]
• Strukturierter gegenüber unstrukturiertem Export. [8] [9]
• RGB vorhanden oder nicht vorhanden. [1] [3]
• Intensität vorhanden oder nicht vorhanden. [1] [3]
• Normalen vorhanden oder nicht vorhanden. [5] [6]
• Bilder eingebettet, verknüpft oder nicht vorhanden. [3] [4]
• Hinweise zum Koordinatensystem und CRS-Metadaten vorhanden oder nicht vorhanden. [3] [4]
• Scanposen oder Registrierungs-Transformationen vorhanden oder nicht vorhanden. [3] [8]
• Exporteinstellungen, die Daten verändern können, etwa der Export einer vereinheitlichten Wolke, Dezimierung oder Clipping-Verhalten. [8] [9]

Wo E57-Daten liegen können (und was häufig verloren geht)

Die meisten Beschwerden über „fehlende Felder“ entstehen, wenn Erwartungen diese Ebenen überschreiten. [3] Ein Absender weiß möglicherweise, dass das Quellprojekt Panoramen, Struktur pro Scan und Posen enthält, während der Empfänger nur prüft, ob die Punkte geöffnet wurden. [6] [8] Für die Lieferung ist der einzige sichere Test, ob die erforderlichen Informationen in der Zielanwendung erhalten bleiben. [11]

Strukturierte versus unstrukturierte E57-Punktwolkendaten (zuerst Schema, dann Software)

In E57-Diskussionen beziehen sich strukturierte oder gerasterte Daten zunächst darauf, wie der Punktsatz organisiert ist, und nicht auf einen Markenbegriff eines bestimmten Softwarepakets. [3] Hubers Designpapier beschreibt, dass E57 ungeordnete Punktwolken ebenso wie in Zeilen und Spalten organisierte Daten darstellen kann; dies ist die Schema-Grundlage für scanrasterähnliche Datensätze. [3] Diese Organisation kann für Workflows mit Scannerpositionen, Panoramaausrichtung und zeilen- oder spaltenbewusste Verarbeitung wichtig sein. [3]

Dagegen verhalten sich unstrukturierte oder unorganisierte Daten eher wie eine einfache Liste von Punkten im Raum. [3] Die Koordinaten können weiterhin gültig sein, aber wenn ein Werkzeug einen strukturierten Scan zu einem unstrukturierten Export abflacht, kann es die Zeilen-/Spaltenorganisation, Bildbeziehungen oder andere stationsähnliche Hinweise verlieren, die nachgelagerte Werkzeuge für Navigation und Anzeige nutzen. [3] Deshalb kann eine Punktwolke in einem Programm „vollständig“ wirken und dennoch in einem anderen Pano- oder Scan-Station-Verhalten verlieren. [3]

Das Softwareverhalten kommt an zweiter Stelle. Autodesk sagt, dass ReCap strukturiertes E57 mit einzelnen Scans, Zeilen-/Spalteninformationen und Registrierungs-Transformationen exportieren kann, warnt jedoch auch, dass dieser Export keine im Projekt vorgenommenen Löschungen oder Zuschnitte anwendet. [8] Leica gibt an, dass stativbasierte Setups strukturiert mit Scanraster und Panoramen exportiert werden, während unstrukturierte Quellen ohne Scanraster exportiert werden. [9] „Strukturiert“ ist also aussagekräftig, garantiert jedoch nicht, dass jedes Zielprogramm ein Scan-Station- oder Panorama-Erlebnis wiederherstellt. [8] [9]

Koordinatenrahmen, Posen und CRS-Metadaten (den #1-Fehler bei Lieferdateien vermeiden)

E57 wurde so konzipiert, dass mehrere Datensätze in einer Datei dennoch in einem gemeinsamen Koordinatensystem auf Dateiebene dargestellt werden können. [3] Praktisch kann ein Scan in lokalen Sensor-Koordinaten vorliegen, während eine optionale Pose oder starre Transformation der Software mitteilt, wie dieser Scan im übergeordneten Rahmen auf Dateiebene positioniert ist. [3] Dies ist die Brücke zwischen „Raum eines einzelnen Scans“ und „registriertem Projektraum“. [3]

CRS-Informationen sind eine separate, aber verwandte Ebene. [3] Der Root kann optionale CoordinateMetadata als standardisierte CRS-Zeichenfolge in einem OGC/WKT-Kontext enthalten, während der ASTM-Geltungsbereich auch festlegt, dass standardisierte Größen SI-Einheiten verwenden und ebene Winkel in Radiant angegeben werden. [1] [4] Hersteller-Exporter können darüber hinaus eigene Konventionen dokumentieren; Autodesk ReCap erklärt beispielsweise, dass seine E57-Exporte kartesische Meter und Winkel in Radiant verwenden. [5] Selbst wenn eine Datei als „georeferenziert“ bezeichnet wird, kann dies weiterhin mehrdeutig sein, wenn ein Werkzeug Pose-Transformationen liest, aber CRS-Text ignoriert, oder umgekehrt. [3] [4]

Warnung: Georeferenzierung kann als Transformationen und/oder CRS-Metadaten vorhanden sein, aber nicht jede Software liest oder schreibt diese Teile konsistent. [4] Validieren Sie Koordinaten, Orientierung und CRS-Verhalten vor der Lieferung immer im Zielwerkzeug. [4]

So öffnen Sie eine E57-Punktwolkendatei (Viewer, BIM, Konvertierung oder Code?)

Wie Sie eine E57-Punktwolkendatei öffnen, hängt von Ihrem Ziel ab: visuelle Prüfung, Projektimport, Konvertierung oder programmatische Verarbeitung. [6] [11] Es gibt keinen einzelnen Weg, der für jede E57-Lieferdatei funktioniert. [3]

Allgemein sind neutrale Viewer am besten für eine erste Prüfung geeignet, Hersteller-Ökosysteme für die Überprüfung projektspezifischen Verhaltens und Bibliotheken oder Datenwerkzeuge für Batch- oder Code-Workflows. [17] [18] Autodesk ReCap dokumentiert sowohl Import- als auch Exportverhalten für E57, Leica dokumentiert, wie seine Exporte strukturierte und unstrukturierte Setups bewahren, FARO dokumentiert E57-Import/-Export als Scanpunkt-Austausch, und PDAL dokumentiert einen enger gefassten Reader für kartesische Punktwolken-Workflows. [5] [6] [9] [10] [11]

Die wichtigen Prüfungen lauten nicht nur „Wurde sie geöffnet?“, sondern „Was wurde geöffnet?“ [3] Bestätigen Sie, ob eine Mehrscan-Datei eine Mehrscan-Datei blieb, ob Panoramen oder Bilder übernommen wurden, ob strukturierte Informationen erhalten blieben, ob Attribute wie RGB oder Intensität verbleiben und ob das Zielwerkzeug etwas stillschweigend abgeflacht oder gefiltert hat. [6] [8] [11]

Laden Sie vertrauliche Scandaten standardmäßig nicht zu browserbasierten Konvertern hoch; bevorzugen Sie für sensible, regulierte oder sehr große Datensätze lokale oder Unternehmenswerkzeuge.

1. Duplizieren Sie die ursprüngliche E57 und bewahren Sie die unveränderte Quelldatei auf.
2. Öffnen Sie die Kopie lokal in einem neutralen Viewer wie CloudCompare zur ersten Prüfung. [17]
3. Bestätigen Sie die Scananzahl oder die sichtbare Mehrscan-Struktur und prüfen Sie dann die Bounding Box sowie offensichtliche Einheiten- oder Achsenprobleme.
4. Prüfen Sie, welche Attribute importiert wurden, einschließlich RGB, Intensität, Normalen und gegebenenfalls Bilder. [5] [6]
5. Validieren Sie dieselbe Datei in der Zielanwendung, etwa ReCap, Cyclone, SCENE oder einer nachgelagerten BIM-Pipeline. [6] [9] [10]
6. Konvertieren oder exportieren Sie erst dann und dokumentieren Sie Dezimierung, Transformationen und verworfene Attribute. [8] [9]

Dokumentierte E57-Unterstützung nach Werkzeug (auf Funktionsebene, nicht Marketing)

Aus dieser Tabelle folgt eine praktische Regel: Validieren Sie zuerst die Inhaltsklasse, die für Sie wichtig ist. [3] Wenn die Aufgabe von der Bewahrung des Scanrasters, von Panoramen, sphärischen Daten oder Metadaten auf Scanebene abhängt, benötigen Sie Exporter- und Importer-Dokumentation, die diese Funktionen ausdrücklich abdeckt, und nicht nur ein Häkchen neben „E57“. [6] [8] [9] [11]

E57 gegenüber anderen Scandatenformaten (LAS/LAZ/COPC, PTX/PTS, PLY, RCP/RCS)

Kein Punktwolkenformat ist für jeden Workflow das beste. [1] E57 ist am stärksten, wenn Sie neutralen terrestrischen Scanaustausch mit mehr Kontext als einfache XYZ-Textdateien benötigen. [1] LAS/LAZ und COPC sind stärker geeignet, wenn es um georäumliche LiDAR-Lieferdaten, Kachelung, Suchen und großskaligen räumlichen Zugriff geht. [12] [13] [14] RCP/RCS ist am stärksten, wenn die Arbeitsumgebung Autodesk-zentriert ist und auf dem eigenen Projekt-/Cache-Verhalten von Autodesk statt auf neutralem Datenaustausch basiert. [7]

Die Tabelle unten wird von links nach rechts gelesen: „Beste Eignung“ bezeichnet den Workflow, „Üblicherweise bewahrt“ die typische Stärke und „Wichtigste Vorsicht“ das, was Menschen beim Austausch häufig überrascht. [1] [7]

Bei georäumlichen Lieferdaten ist der Kontrast besonders konkret. [15] Die aktuelle Seite der USGS Lidar Base Specification für 2025 rev. A besagt, dass Punkt-Lieferdaten in LAS 1.4-R15 mit PDRF 6, 7, 8, 9, oder 10 vorliegen müssen; dies ist ein Grund, warum LAS/LAZ viele nationale Kartierungs- und 3DEP-ähnliche Workflows dominiert. [15]

Ein kurzer Hinweis zur Marktentwicklung: OGC kündigte die Veröffentlichung des LAZ 1.4 Community Standard am 3. September 2026 an, der verlustfreie Komprimierung für LAS 1.4 mit Chunk-basierter Speicherung definiert, während COPC 1.0 Cloud-optimiertes Suchen und Teilmengenbildung auf der Oktree-Organisation von LAZ 1.4 aufbaut. [13] [14] Das sind andere Ziele als die Rolle von E57 als umfangreicher, scanorientierter Austauschcontainer. [1] [14]

Leistungsmetriken und Datenqualität (was E57 nicht garantiert)

E57 definiert für sich genommen keine Scanner-Genauigkeit, Präzision, Auflösung oder Punktdichte. [3] Es kann Messwerte und zugehörige Metadaten enthalten, doch die Qualität dieser Werte hängt weiterhin vom Instrument, der Kalibrierung, der Erfassungsmethode, dem Registrierungsworkflow und der späteren Verarbeitung ab. [3]

Dateigröße und Leistung sind ebenfalls situationsabhängig. [3] Strukturierte Exporte können größer sein, weil sie Scanrasterinformationen und Panoramabilder enthalten können, während Dezimierung, Clipping-Richtlinien, die Einbeziehung von Bildern und vorhandene Attribute das Ergebnis verändern können. [8] [9] E57 verwendet intern auch komprimierte Binärstrukturen, aber es gibt keine verlässliche universelle Angabe für E57-Komprimierung, Importgeschwindigkeit oder Größe im Vergleich zu LAS, LAZ, PTX oder PTS über reale Projekte hinweg. [3]

E57 kann Messwerte und Metadaten kodieren, doch Scannergenauigkeit, Registrierungsresiduen, Kalibrierzustand und Dezimierungsentscheidungen liegen außerhalb des Dateiformats. [3]

Anwendungen von E57-Punktwolkendateien (wann sie gut passen)

Da E57 für den Austausch von 3D-Punktdaten, Attributen und optionalen Bilddaten entwickelt wurde, eignet es sich gut überall dort, wo Scandaten zwischen Erfassung, Prüfung und nachgelagerten Analysewerkzeugen übertragen werden müssen. [1] [2] Dazu gehören üblicherweise Bestandsdokumentation, Übergaben in Vermessung und Bauwesen, Dokumentation industrieller Anlagen, fertigungsbezogene 3D-Messworkflows und die Erfassung von Kulturerbe. [2] In BIM-Koordinierungs- oder Reverse-Engineering-Kontexten liegt sein Wert in der Regel darin, ausreichend Scan-Kontext mitzuführen, um eine Übergabe besser zu überstehen als reine Textformate. [1] [3]

Die nützliche Lieferdatei ist nicht allein die Erweiterung .e57. [3] Eine gute Übergabe ist eine, deren Scans, Attribute, Koordinatenkontext und Bilder im empfangenden Workflow erhalten bleiben. [1] [3]

Einschränkungen und Interoperabilitätsrisiken (warum Felder verschwinden)

Die Stärke von E57 ist seine Flexibilität, doch Flexibilität schafft Optionalität. [1] [3] Das Format kann viele Datenarten speichern, doch jede einzelne Datei kann einige davon auslassen und jedes einzelne Werkzeug kann nur eine Teilmenge bewahren. [1] [3] Deshalb können zwei Personen beide „E57 verwenden“ und nach dem Austausch dennoch unterschiedliche Scans, Felder oder Bilder sehen. [3]

Die dokumentierten Beispiele sind aufschlussreich. Der E57-Reader von PDAL unterstützt kartesische Punktwolken, liest mehrere interne Wolken als eine, behält nur Dimensionen, die in allen Wolken vorhanden sind, und unterstützt keine sphärischen Punktwolken. [11] SCENE von FARO erklärt, E57 sei für Scanpunkte, nicht für Objekte. [10] Autodesk ReCap erklärt, dass sein Panoramaimport nur die Repräsentation E57_SPHERICAL mit JPEG- oder PNG-Bildern unterstützt. [6]

Ein erfolgreicher Import ist also nur ein Ausgangspunkt. [3] Sie müssen weiterhin bestätigen, ob Bilder, Scanraster, Posen, Normalen, Zeitstempel und Attributbereiche die Übertragung überstanden haben. [5] [6] [11]

Warnung: „Erfolgreich geöffnet“ beweist nicht, dass Bilder, Scanraster, Posen, Normalen, Zeitstempel oder alle Attribute erhalten geblieben sind. [6] [11] Validieren Sie die Datei im Zielworkflow, bevor Sie die Lieferung freigeben. [6] [11]

Fazit: Wann das E57-Punktwolkenformat eingesetzt werden sollte

Verwenden Sie das Format E57-Punktwolke, wenn Sie einen neutralen, scanorientierten Austauschcontainer benötigen, der mehr Kontext als XYZ-Text im einfachen Stil transportieren kann; verwechseln Sie diese Fähigkeit jedoch nicht mit einer Garantie, dass jedes Werkzeug jedes Feld bewahrt. [1] [3] Es ist meist die richtige Wahl für herstellerübergreifende terrestrische Scanübergaben, während LAS/LAZ oder COPC für viele georäumliche Lieferdateien besser passen und RCP/RCS besser für Autodesk-zentrierte Projektworkflows geeignet ist. [7] [12] [14] Arbeiten Sie vor der Lieferung die Feld-Checkliste und die Vergleichstabelle durch und prüfen Sie das Ergebnis dann in der Zielanwendung. [6] [8] [11]

E57-Punktwolken-FAQ

Was ist eine E57-Punktwolke (und wie unterscheidet sie sich von einer E57-Datei)?

Eine E57-Punktwolke sind die Scandaten selbst, während eine E57-Datei der Container ist, der diese Daten zusammen mit Attributen, Metadaten und optionalen Bilddaten enthalten kann. [1] Die aktuelle ASTM-Kurzbezeichnung behandelt „E57-Datei“ als das ASTM-E57-3D-Dateiformat, das in ASTM E2807-11(2026) definiert ist; die Datei ist somit das Paket und die Punktwolke eine Art von Nutzdaten darin. [1]

Was wird in einem E57-Scandatenformat gespeichert – und was ist optional?

Das Format kann 3D-Punktdaten, Attribute wie Farbe oder Intensität und 2D-Bilder speichern. [1] Es kann außerdem mehrere 3D-Datensätze, optionale Bilder, Pose-Informationen und optionale Koordinatenmetadaten für den CRS-Kontext darstellen. [3] [4] All dies sollte jedoch als „kann vorhanden sein“ behandelt werden, da ein bestimmter Exporter diese Inhalte auslassen und ein bestimmter Importer sie ignorieren kann. [3]

Warum sieht meine E57-Punktwolke nach dem Import in ein anderes Programm anders aus?

Weil „das Format kann es speichern“ nicht dasselbe ist wie „dieses Werkzeug hat es bewahrt“. [1] [3] Manche Programme führen mehrere Scans zusammen, manche ignorieren bestimmte Bilder, manche unterstützen nur bestimmte Panoramarepräsentationen und manche behalten nur Dimensionen, die allen eingebetteten Wolken gemeinsam sind. [6] [11] Wenn sich Aussehen oder Verhalten verändert haben, vergleichen Sie die Exporteinstellungen der Quelle mit den dokumentierten Grenzen des Zielwerkzeugs. [8] [9]

Wie öffne ich eine E57-Punktwolkendatei sicher (ohne riskante Web-Konverter)?

Erstellen Sie eine Kopie der Originaldatei, prüfen Sie diese Kopie lokal in einem neutralen Viewer oder Desktopwerkzeug, verifizieren Sie sichtbare Scans und Attribute und testen Sie anschließend dieselbe Datei in der Zielanwendung, bevor Sie etwas konvertieren. [17] [6] [11] Browserbasierte Konverter können bequem sein, sind aber keine sichere Standardwahl für vertrauliche, regulierte oder sehr große Scan-Datensätze.

Garantiert das E57-Dateiformat Scannergenauigkeit, Registrierungsqualität oder Punktdichte?

Nein. [3] E57 kann Messwerte und Metadaten kodieren, doch Scannergenauigkeit, Registrierungsresiduen, Kalibrierzustand und Dezimierung liegen außerhalb des Dateiformats. [3] Die Erweiterung sagt Ihnen, welcher Container verwendet wird, nicht, ob die Erfassung gut war, die Registrierung präzise ist oder die Dichte für eine bestimmte Aufgabe geeignet ist. [3]

Experte: Was bedeutet „strukturiert“ in E57 – garantiert es Scan-Station-/Panorama-Navigation?

Strukturiert bedeutet, dass die Daten eine scanrasterähnliche Organisation wie Zeilen- und Spaltenkontext bewahren, statt nur eine ungeordnete Punktliste zu sein. [3] Das kann nachgelagerten Stations- oder Panorama-Workflows helfen, ist aber keine universelle Garantie. [3] Autodesk und Leica dokumentieren beide strukturiertes E57-Verhalten in ihren eigenen Exportworkflows, doch die Zielanwendung muss diese Informationen weiterhin korrekt unterstützen und rekonstruieren. [8] [9]

Experte: Wie sollte ich über Koordinatenrahmen, Pose-Transformationen und optionale CRS-Metadaten in E57-Lieferdateien nachdenken?

Denken Sie in Ebenen. Ein Scan kann lokal zum Sensor sein, eine Pose-Transformation kann ihn in einem gemeinsamen Rahmen auf Dateiebene platzieren und optionale CoordinateMetadata können den übergeordneten CRS-Kontext in standardisiertem Text beschreiben. [3] [4] Diese Ebenen hängen zusammen, sind aber nicht austauschbar; daher kann „georeferenziert“ weiterhin mehrdeutig sein, wenn Sie nicht sowohl Koordinaten als auch CRS-Verhalten in der empfangenden Software überprüfen. [4]

Quellen

1. ASTM International — E2807 Standard Specification for 3D Imaging Data Exchange, Version 1.0 (ASTM E2807-11(2026)). https://store.astm.org/standards/e2807
2. NIST — ASTM E57 – 3D Imaging Systems. https://www.nist.gov/publications/astm-e57-3d-imaging-systems
3. Daniel Huber, Carnegie Mellon University — The ASTM E57 File Format for 3D Imaging Data Exchange. https://publications.ri.cmu.edu/storage/publications/pub_files/2011/1/2011-huber-e57-v3.pdf
4. Library of Congress — ASTEM E57 3D file format (E57). https://www.loc.gov/preservation/digital/formats/fdd/fdd000563.shtml
5. Autodesk ReCap Help — E57 Export Support – Technical Specification. https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Saving_Exporting_Your_Project/export_e57_technical_specifications.html
6. Autodesk ReCap Help — E57 Import Support – Technical Specification. https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Creating_Scan_Projects/Importing_Scans/E57_Panorama_Images/import_e57_support.html
7. Autodesk ReCap Help — About Scan and Photogrammetry Files and Projects. https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Getting_Started/Supported_File_Formats/scan_photogrammetry.html
8. Autodesk ReCap Help — Supported File Formats. https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
9. Leica Geosystems RCDOCS — Third-Party File Export (Cyclone REGISTER 360 PLUS). https://rcdocs.leica-geosystems.com/docs/cyclone-register-360-third-party-file-export
10. FARO Knowledge Base — Export Formats Supported by SCENE. https://knowledge.faro.com/Software/FARO_SCENE/SCENE/Export_Formats_Supported_by_SCENE
11. PDAL Documentation — readers.e57. https://pdal.org/en/stable/stages/readers.e57.html
12. OGC — LAS Specification – Open Format for LiDAR Point Cloud Data. https://www.ogc.org/standards/LAS/
13. OGC — OGC Announces Publication of the LAZ 1.4 Community Standard. https://www.ogc.org/announcement/ogc-announces-publication-of-the-laz-1-4-community-standard/
14. COPC — Cloud Optimized Point Cloud Specification – 1.0. https://copc.io/copc-specification-1.0.pdf
15. USGS — Lidar Base Specification: Data Processing and Handling Requirements. https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-data-processing-and-handling-requirements
16. IANA — Media Types registry. https://www.iana.org/assignments/media-types
17. CloudCompare Wiki — FILE I/O. https://www.cloudcompare.org/doc/wiki/index.php/FILE_I/O
18. libE57Format — GitHub repository README. https://github.com/asmaloney/libE57Format
19. Library of Congress — Polygon File Format (PLY) Family. https://wwws.loc.gov/preservation/digital/formats/fdd/fdd000501.shtml