PTS-Datei: Was das Punktwolkenformat bedeutet

Zusammenfassung: Was eine PTS-Datei ist

In diesem Artikel bezeichnet eine PTS-Datei das Punktwolkenformat .pts: eine Klartext-/ASCII-Austauschdatei für 3D-Punkte, kein Mesh, Oberflächenmodell oder CAD-Volumenkörper. [1] [11]

In der Praxis ist PTS eher als weit verbreitete Konvention denn als einzelne starre Spezifikation zu verstehen. Eine dokumentierte Konvention verwendet eine Punktanzahl in der ersten Zeile, gefolgt von sieben Werten pro Punkt, doch Importverhalten, Spaltenreihenfolge und Attributverarbeitung unterscheiden sich je nach Software. Autodesk ReCap beschreibt rohe .pts-Dateien zudem als unstrukturierte Punktwolke; dies ist ein Grund dafür, weshalb PTS üblicherweise weniger Scan-Kontext und Metadaten als E57 enthält. [1] [4] [14]

Was in einer PTS-Punktwolkendatei enthalten ist (und warum das „Schema“ variiert)

Eine verbreitete Konvention ist einfach: Die erste Zeile speichert eine Punktanzahl, und jede folgende Zeile speichert einen Punkt. nanoCAD dokumentiert genau dieses Layout für eine PTS-Konvention, und die Kommandozeilenoption -ADD_PTS_COUNT von CloudCompare zeigt, dass manche Werkzeuge die Punktanzahl der ersten Zeile beim Speichern von ASCII-Wolken zur Kompatibilität aktiv hinzufügen. [1] [10]

Nach diesem Header besteht das verbreitete Layout aus XYZ plus optionalen Attributen, häufig Intensität und RGB, doch dieses Layout ist nicht zwingend. Der ASCII-Parser von Leica Cyclone 3DR ist bewusst flexibel: Er kann X, Y, Z, I, R, G und B aus einer Menge von Zahlen dekodieren, zusätzliche Werte ignorieren oder Dateien akzeptieren, in denen einige Werte fehlen. Deshalb können zwei gültige PTS-Dateien dieselbe Erweiterung haben und dennoch unterschiedliche Importzuordnungen benötigen. [2] [7]

Ein kleines schematisches Beispiel sieht so aus:

3
1.000 2.000 3.000 120 255 240 230
1.010 2.005 3.020 118 254 239 229
1.025 2.010 3.040 121 253 238 228

Nur schematisch — reale Exporteure können Spalten weglassen oder hinzufügen oder eine andere Reihenfolge verwenden. [7]

Intensität und Farbe sind getrennte Attribute, und ihre numerischen Konventionen sind nicht universell. Im dokumentierten PTS-Importverhalten von nanoCAD wird RGB mit 0–255 pro Kanal erwartet und die importierte Intensität auf 0–65535 normalisiert. In der PTX-Exportdokumentation von Leica Cyclone liegt die PTX-Intensität bei 0–1, und dieselbe KB-Notiz besagt, dass von Cyclone exportierte PTS ganzzahlige Intensitätswerte von -2048 bis 2047 verwenden können. Diese Unterschiede sind der Grund, weshalb „PTS-Format“ besser als gemeinsame Konvention denn als eine feste Regel gelesen wird, der jedes Werkzeug folgt. [1] [2]

Strukturiert oder unstrukturiert: Was eine PTS-Datei üblicherweise nicht bewahrt

Autodesk ReCap beschreibt rohe .pts-Dateien ausdrücklich als unstrukturierte Punktwolke. In der Praxis bedeutet dies, dass die Datei zwar die Punkte selbst bewahren kann, jedoch Informationen zum Scan-Ursprung verliert, die manche nachgelagerten Operationen benötigen, etwa die Organisation pro Scan, den Scannerstandpunkt oder die für scanbewusste Segmentierung und ähnliche Workflows erforderliche Struktur. Die eigene Anmerkung von ReCap zum strukturierten E57-Export verdeutlicht den Kontrast durch den Hinweis auf Zeilen-/Spalteninformationen und Registrierungstransformationen. [3] [4]

Es ist auch hilfreich, Koordinaten von der Bedeutung des Koordinatensystems zu trennen. Eine PTS-Datei kann gültige XYZ-Werte enthalten und dennoch wichtigen Kontext außerhalb der Datei lassen, etwa Einheiten, Projekt-CRS, Datum, Kontrollstrategie oder Registrierungsnotizen. Der CAD-Interop-Leitfaden charakterisiert PTS/PTX als ASCII ohne formalen Standard und merkt an, dass Georeferenzierung dort nicht nativ kodiert ist; Vermessungsberichte, Kontrolldateien und Projektdokumentation sind daher häufig ebenso wichtig wie die Punktzeilen selbst. [5] [11]

Eine Konvertierung kann Scan-Struktur oder Registrierungshistorie, die nie in die Übergabe geschrieben wurden, nicht wiederherstellen. Wenn der Export strukturierte Scans bereits zu einer unstrukturierten PTS abgeflacht hat, kann eine spätere Konvertierung zwar weiterhin Koordinaten und möglicherweise zugeordnete Attribute bewahren, aber fehlende Scan-Ursprünge, Zeilen-/Spaltenreihenfolge oder früheren Registrierungskontext nicht zuverlässig rekonstruieren. [3] [4]

PTS vs. PTX vs. E57 (plus XYZ und LAS/LAZ) — was wählen?

Für die meisten realen Workflows lautet die Frage eigentlich PTS vs. E57-Punktwolke, ergänzt um einen Sonderfall: PTX, wenn Pose pro Scan und Scan-Rasterstruktur wichtig sind. Die folgende Tabelle fasst dokumentiertes Verhalten aus den zitierten Quellen von Herstellern, Projekten und Normen zusammen. [1] [2] [4] [11] [12] [13] [14]

PTS ist die lockerste Option. Eine dokumentierte Konvention besteht aus einer Anzahl in der ersten Zeile plus X Y Z intensity R G B, doch in den zitierten Quellen wurde kein veröffentlichter formaler Standard für PTS im ASTM-/ISO-Stil verifiziert. [1] [11]

PTX ist der strukturierte ASCII-Zweig, der am engsten mit terrestrischen Scan-Exporten verbunden ist. Die PTX-Dokumentation von Leica Cyclone beschreibt Abschnitte pro Scan mit Anzahl der Spalten, Anzahl der Zeilen, registrierter Scannerposition und -achsen sowie einer 4×4-Transformationsmatrix. Im selben Cyclone-Kontext werden PTX-Koordinaten in Metern exportiert, PTX-Intensität verwendet 0–1, und PTX kann eine oder mehrere Scan-Wolken enthalten. [2]

E57 unterscheidet sich grundlegend. Das ASTM Committee E57 führt ASTM E2807 als Spezifikation für den Austausch von 3D-Bildgebungsdaten auf, libE57Format beschreibt E57 als Speicherung von Punktwolken plus zugehörigen Attributen und 2D-Bildern, und Hubers Übersicht erläutert, dass die Dateistruktur einen 48-Byte-Header, optionale Binärabschnitte und eine XML-Hierarchie statt einfacher ASCII-Punktzeilen verwendet. [12] [13] [14]

Die Wahl hängt daher vor allem davon ab, wie viel Bedeutung die Übergabe bewahren muss. Verwenden Sie PTS, wenn Lesbarkeit und schneller Austausch genügen, PTX, wenn Scan-Pose und Scan-Rasterkontext in einem ASCII-Workflow wichtig sind, und strukturiertes E57, wenn Sie einen stärker standardisierten Austauschcontainer wünschen, der umfangreicheren Kontext bewahren kann. LAS/LAZ und XYZ sind besser als Workflow-Ziele für bestimmte nachgelagerte Anforderungen zu verstehen, nicht als direkter Ersatz für strukturierte Scan-Historie. [2] [3] [4] [11]

So öffnen Sie PTS-Dateidaten (Viewer, CAD/BIM und CLI)

Da PTS Text ist, beginnt der sicherste Workflow mit einer Prüfung und wechselt erst zu einem Viewer, CAD-/BIM-Werkzeug oder einer CLI-Pipeline, wenn Sie wissen, was die Spalten bedeuten. [3] [5] [9]

Checkliste zum Öffnen

• Bewahren Sie die unveränderte originale PTS-Datei auf und führen Sie Tests an einer Arbeitskopie durch. [4] [11]
• Prüfen Sie vor dem Import die erste Zeile und die Spaltenanzahl pro Zeile. [1] [10]
• Bestätigen Sie Einheiten und CRS extern anhand von Projektnotizen, Kontroll- oder Vermessungslieferungen. [5] [11]
• Überprüfen Sie die Zuordnung von Farbe und Intensität, nicht nur XYZ. [1] [7]
• Prüfen Sie, ob die Wolke bereits registriert oder vereinheitlicht ist oder ob die Struktur einzelner Scans weiterhin wichtig ist. [2] [4]
• Speichern Sie erst dann eine Arbeitskopie in E57, LAZ, RCP/RCS oder einem anderen nachgelagerten Format, das Ihre Werkzeugkette erwartet. [3] [6] [11]

Autodesk ReCap ist ein üblicher CAD-/BIM-Weg, da seine Hilfe PTS sowohl als Import- als auch als Exportformat aufführt und dieselbe Seite den strukturierten E57-Export mit Zeilen-/Spalteninformationen und Registrierungstransformationen nennt. Leica Cyclone 3DR führt .pts und .ptx sowohl bei Unterstützung für Punktwolkenimport als auch -export auf, neben E57, LAS und LAZ. FARO SCENE führt PTS und PTX ebenfalls unter seinen Exportformaten auf, und die FILE-I/O-Tabelle von CloudCompare enthält .pts unter den ASCII-Punktwolkenformaten, die gelesen und geschrieben werden können. [3] [6] [8] [9]

Für CLI- und Stapelverarbeitung liest readers.pts von PDAL Leica-Cyclone-PTS-Dateien und leitet Dimensionen aus Textpunkten ab. PDAL dokumentiert außerdem die Optionen default_srs und override_srs, was hilft, wenn die Datei selbst nicht genügend Raumbezugskontext enthält. Die Kommandozeilenoption -ADD_PTS_COUNT von CloudCompare ist ein weiterer praktischer Hinweis darauf, dass die Punktanzahl in der ersten Zeile ein häufiges Kompatibilitätsmerkmal und keine universelle Garantie für jede ASCII-Punktwolkendatei ist. [5] [10]

Konvertierungsworkflow: PTS in E57, LAS/LAZ, PLY oder XYZ (zwei Fälle)

Betrachten Sie die Konvertierung in zwei Fällen: eine einzelne vereinheitlichte Wolke oder eine Scan-Menge, bei der strukturierter Scan-Kontext weiterhin wichtig ist. Diese Unterscheidung ist wichtiger als die Dateierweiterung allein. [3] [4]

Fall A — Konvertieren einer vereinheitlichten/unstrukturierten PTS (einzelne Wolke)

Wenn die Quelle bereits eine vereinheitlichte oder unstrukturierte Wolke ist, geht es bei der Konvertierung hauptsächlich darum, Koordinaten und alle korrekt zuordenbaren Attribute zu bewahren. Strukturiertes E57 ist üblicherweise das bessere Ziel für Archivierung oder plattformübergreifenden Austausch, LAS/LAZ kann die kompaktere nachgelagerte Wahl für Pipelines im Vermessungsstil sein, XYZ ist der minimalste ASCII-Weg, wenn nur Koordinaten zählen, und einige Punktwolkenwerkzeuge bieten zudem PLY als weiteres geometrieorientiertes Exportziel. Validieren Sie vor dem Speichern Einheiten, Punktanzahl und ob Intensität oder RGB tatsächlich in den Quellspalten vorhanden sind, statt sie vom Importer annehmen zu lassen. [3] [6] [9] [11]

Fall B — Konvertieren von Scan-Mengen, bei denen Scanpositionen/-struktur wichtig sind

Wenn Scanpositionen, Zeilen-/Spaltenreihenfolge oder Registrierungstransformationen wichtig sind, kann PTS bereits die falsche Übergabe sein. ReCap bezeichnet rohe .pts-Dateien als unstrukturiert, während die PTX-Dokumentation von Cyclone einen Header pro Scan mit Zeilen, Spalten, Scannerachsen und -position sowie einer 4×4-Transformationsmatrix beschreibt. Die Anmerkung von ReCap zum strukturierten E57-Export weist durch den Hinweis auf Zeilen-/Spalteninformationen und Registrierungstransformationen auf dieselbe Unterscheidung hin. In der eigenen Beschreibung von Cyclone ist PTX für gerasterte Scan-Wolken statt für ungeordnete vereinheitlichte Wolken gedacht. Sobald diese Beziehungen im PTS-Export fehlen, kann eine spätere Konvertierung sie nicht rekonstruieren. [2] [3] [4]

Zu dokumentierende Konvertierungsrisiken

• Einheiten sind möglicherweise nicht kodiert oder offensichtlich, selbst wenn die Koordinaten selbst korrekt aussehen. [1] [11]
• CRS oder Georeferenzierung können außerhalb der Datei liegen, weshalb Metadaten in Begleitdateien wichtig sind. [5] [11]
• Der Intensitätsbereich kann zwischen Werkzeugen wechseln; nanoCAD dokumentiert beim Import eine Normalisierung auf 0–65535, während Cyclone PTX-Intensität als 0–1 dokumentiert und eine andere ganzzahlige Konvention für von Cyclone exportierte PTS nennt. [1] [2]
• RGB kann verloren gehen, wenn der Importer andere Spalten erwartet; der ASCII-Leser von Cyclone 3DR akzeptiert mehrere Spaltenzuordnungen und sowohl RGB-Tokenstile mit 0–255 als auch mit 0–1. [7]
• Registrierungs- oder Scannerpose-Metadaten können in PTS fehlen; die Warnung von ReCap zu unstrukturierten .pts-Dateien ist die zentrale Einschränkung. [4]
• Große ASCII-Dateien sind langsam und speicherintensiv; ein Branchenleitfaden nennt als anschauliche Größe etwa 1 GB für 10 Millionen Punkte und ungefähr 5–10× größer als E57 oder LAZ, doch diese Angabe hängt von Präzision, Leerraum und den geschriebenen Attributen ab. [11]

Häufige Probleme beim Import von PTS (und schnelle Lösungen)

Wenn die Wolke im falschen Maßstab importiert wird, sollten Sie zuerst Einheiten vermuten. Die von nanoCAD dokumentierte verbreitete PTS-Konvention beschreibt Punktzeilen und Attribute, jedoch kein universelles eingebettetes Einheitensystem, und der CAD-Interop-Leitfaden warnt, dass Georeferenzierung dort nicht nativ kodiert ist. Die schnelle Lösung besteht darin, eine bekannte Distanz oder einen Kontrollpunkt zu überprüfen und anschließend Einheiten und Raumbezug im Importer oder der Pipeline ausdrücklich festzulegen, statt Standardwerten zu vertrauen. Die SRS-Optionen von PDAL sind gerade deshalb hilfreich, weil dieser Kontext möglicherweise außerhalb der Datei bereitgestellt werden muss. [1] [5] [11]

Wenn Farbe fehlt oder offensichtlich falsch ist, sollten Sie die Spaltenzuordnung vermuten. Cyclone 3DR kann RGB je nach Formattoken als Ganzzahlen von 0–255 oder als Fließkommazahlen von 0–1 dekodieren, während nanoCAD für seinen PTS-Import eine RGB-Konvention von 0–255 dokumentiert. Wenn der Importer die falsche Spaltenreihenfolge errät, kann Farbe verschwinden, Kanäle verschieben oder als etwas völlig anderes interpretiert werden. Die Lösung besteht darin, die ersten Zeilen zu prüfen und die Felder manuell zuzuordnen, sofern die Software dies erlaubt. [1] [7]

Wenn Intensität ausgewaschen oder abgeschnitten wirkt, sollten Sie eher eine Bereichsabweichung als fehlerhafte Geometrie vermuten. nanoCAD normalisiert importierte Intensität auf 0–65535, Cyclone PTX verwendet 0–1, und die Cyclone-KB nennt eine andere ganzzahlige Konvention für von Cyclone exportierte PTS. Dieselben Punktwerte können daher in verschiedenen Viewern sehr unterschiedlich dargestellt werden. Wenn die Datei nicht importiert werden kann oder zu lange benötigt, bedenken Sie, dass rohes ASCII umfangreich ist: Die Angabe des CAD-Interop-Leitfadens von ~1 GB je 10 Millionen Punkte ist anschaulich, nicht universell, erklärt aber, warum sehr große PTS-Dateien langsamer zu analysieren sind als kompakte binäre Alternativen. [1] [2] [11]

Warum PTS in modernen Workflows weiterhin auftaucht (und wann es sinnvoll ist)

PTS bleibt bestehen, weil es transparent ist und weiterhin umfassend als ASCII-Austauschformat unterstützt wird. PDAL verfügt über ein dediziertes readers.pts, CloudCompare liest und schreibt .pts als ASCII-Punkt-wolkendaten, Leica Cyclone 3DR führt Unterstützung für Import und Export von .pts auf, und FARO SCENE führt PTS/PTX unter seinen Exportformaten auf. Das macht PTS als Format zum Debuggen, für Übergaben oder zum „Öffnen und Prüfen“ nützlich, selbst wenn es nicht das beste Langzeitarchiv ist. [5] [6] [8] [9]

Der umfassendere Trend bei Austausch und Archivierung weist jedoch in Richtung E57. Das ASTM Committee E57 führt E2807 als Datenaustauschstandard auf, libE57Format beschreibt E57 als Speicherung von Punktwolken plus Attributen und 2D-Bildern, und Hubers Übersicht erläutert das hybride XML-/Binärdesign, das stärker selbstbeschreibend und speichereffizienter als flaches ASCII ist. In den zitierten Quellen wurde kein verlässliches Ursprungsjahr für PTS verifiziert. [12] [13] [14]

Wann eine PTS-Datei verwendet und wann sie konvertiert werden sollte

Verwenden Sie eine PTS-Datei, wenn das Ziel schnelle Prüfung oder einfacher Austausch ist, Sender und Empfänger sich bereits über das Spaltenlayout einig sind und Einheiten oder CRS an anderer Stelle im Projekt dokumentiert sind. Das ist der Wohlfühlbereich des Formats: temporäre Übergaben, Fehlerbehebung und Lieferungen einzelner Wolken, bei denen lesbarer Text wichtiger ist als eingebettete Struktur. [1] [4] [5] [11]

Konvertieren Sie früher, wenn Sie strukturierteres, standardisierteres oder kompakteres Verhalten benötigen. Strukturiertes E57 ist die sicherere Wahl, wenn Zeilen-/Spalteninformationen und Registrierungstransformationen wichtig sind, PTX bleibt relevant, wenn Scan-Pose im Cyclone-Stil in einem ASCII-Workflow erhalten bleiben muss, und LAS/LAZ kann das bessere nachgelagerte Ziel sein, wenn die empfangende Pipeline kompakte Daten im Vermessungsstil bevorzugt. Die praktische Regel ist einfach: Behalten Sie PTS aus Bequemlichkeit, erwarten Sie jedoch nicht, dass es Bedeutung bewahrt, die von Anfang an nie kodiert wurde. [2] [3] [6] [11] [12] [14]

FAQ

Was ist das PTS-Punktwolkendateiformat?

Das PTS-Punktwolkendateiformat ist eine Klartext-/ASCII-Methode, um 3D-Punkte zeilenweise zu speichern. Eine dokumentierte Konvention verwendet eine Punktanzahl in der ersten Zeile, gefolgt von Punktzeilen mit XYZ, Intensität und RGB, doch die ASCII-Dokumentation von Cyclone 3DR zeigt, dass reale Importer fehlende, zusätzliche oder neu zugeordnete Spalten akzeptieren können. [1] [7]

Wie öffne ich PTS-Dateidaten?

Die sicherste Methode besteht darin, zuerst den Text zu prüfen und ihn dann in ein Punktwolkenwerkzeug zu laden, das ASCII-Zuordnung versteht. ReCap führt PTS für Import/Export auf, PDAL bietet readers.pts, und CloudCompare liest und schreibt .pts als ASCII-Punktwolkenformat. [3] [5] [9]

PTS vs. E57-Punktwolke: Welches sollte ich für Austausch/Archivierung verwenden?

Verwenden Sie PTS, wenn Sie hauptsächlich eine lesbare, schnell übertragbare Textwolke benötigen. Verwenden Sie E57, wenn Sie ein stärker standardisiertes Austausch- oder Archivformat brauchen: Autodesk dokumentiert strukturierten E57-Export mit Zeilen-/Spalteninformationen und Registrierungstransformationen, ASTM verankert E57 mit E2807, und die E57-Dokumentation beschreibt Unterstützung für Punktdaten, Attribute und 2D-Bilder in einer hybriden XML-/Binärdatei. [3] [12] [13] [14]

Warum wird meine PTS im falschen Maßstab importiert?

Üblicherweise, weil Einheiten oder Raumbezug angenommen statt überprüft wurden. Die verbreitete PTS-Zeilenkonvention löst Maßstab oder CRS nicht selbst, und die dokumentierten SRS-Optionen von PDAL erinnern daran, dass dieser Kontext möglicherweise extern angewendet werden muss. Prüfen Sie eine bekannte Distanz, bestätigen Sie die Projekteinstellungen für Einheiten und das vorgesehene Koordinatensystem, bevor Sie erneut konvertieren. [1] [5] [11]

Experte: Warum behandeln manche Werkzeuge PTS als „unstrukturiert“, und was verliere ich gegenüber PTX/strukturiertem E57?

Weil PTS häufig nur ein flacher Punkt-Dump ist. ReCap bezeichnet rohe .pts-Dateien ausdrücklich als unstrukturiert, während die PTX-Dokumentation von Cyclone Zeilen, Spalten, Scannerpose und Transformationen pro Scan beschreibt und die Anmerkung von ReCap zu strukturiertem E57 Zeilen-/Spalteninformationen plus Registrierungstransformationen nennt. Was bei abgeflachtem PTS üblicherweise verloren geht, sind Scan-Ursprungskontext, Scan-Rasterreihenfolge und Teile der Registrierungsbedeutung. [2] [3] [4]

Experte: Warum sieht Intensität nach der Konvertierung falsch aus?

Weil Intensitätskonventionen zwischen Werkzeugen unterschiedlich sind. nanoCAD dokumentiert eine Normalisierung beim Import auf 0–65535, Cyclone dokumentiert PTX-Intensität als 0–1, und dieselbe Cyclone-KB nennt eine andere ganzzahlige Konvention für von Cyclone exportierte PTS. Wenn der Viewer den falschen Bereich annimmt, kann die Darstellung abgeschnitten, flach oder inkonsistent wirken, selbst wenn die Koordinaten in Ordnung sind. [1] [2]

Quellen

1. Hilfe zu nanoCAD-Punktwolkendatenformaten — https://nanocad.com/learning/online-help/nanocad-platform/point-clouds-data-formats/
2. Leica Cyclone PTX-Dateiformat-KB-PDF — https://nexus.hexagon.com/community/cfs-filesystemfile/__key/communityserver-discussions-components-files/735/PTX-File-Format.pdf?_=638615963512586589
3. Unterstützte Dateiformate von Autodesk ReCap — https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
4. Technischer Support von Autodesk ReCap: Geometrie kann nicht aus segmentierten Punktwolken erstellt werden — https://help.autodesk.com/view/RECAP/ENU/?caas=caas/sfdcarticles/sfdcarticles/Creating-geometry-from-segmented-Point-Clouds.html
5. PDAL-Dokumentation zu readers.pts — https://pdal.io/en/stable/stages/readers.pts.html
6. Technische Spezifikationen von Leica Cyclone 3DR — https://rcdocs.leica-geosystems.com/docs/technical-specifications-cyclone-3dr-technical-specifications
7. Dokumentation zur ASCII-Analyse von Leica Cyclone 3DR Script SCloud — https://cyclone3dr.leica-geosystems.com/help/2025.0/Script/class_s_cloud.html
8. Unterstützte Exportformate von FARO SCENE — https://knowledge.faro.com/Software/FARO_SCENE/SCENE/Export_Formats_Supported_by_SCENE
9. CloudCompare-FILE-I/O-Wiki — https://www.cloudcompare.org/doc/wiki/index.php/FILE_I/O
10. CloudCompare-Wiki zum Kommandozeilenmodus — https://cloudcompare.org/doc/wiki/index.php/Command_line_mode
11. CAD-Interop-Leitfaden zum PTS/PTX-Format — https://www.cadinterop.com/en/formats/cloud-point/pts-ptx.html
12. Faktenblatt des ASTM Committee E57 — https://mcsdocs.astm.org/committee-documents/E57_Fact_Sheet_2019.pdf
13. Projektdokumentation von libE57Format — https://github.com/asmaloney/libE57Format
14. Daniel Huber, „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