Summary: What Is an E57 Point Cloud?
An E57 point cloud usually means the scan measurements themselves, while an E57 file is the container that carries those measurements plus related metadata. [1] In current ASTM wording, “E57 file” is shorthand for the ASTM E57 3D file format defined by ASTM E2807-11(2026). [1]
In practice, the E57 file format is a neutral exchange format for 3D imaging data, not a scanner model, CAD solid format, or vendor project file. [1] The standard says an E57 file can store 3D point data, point attributes such as color and intensity, and 2D imagery, using a combination of binary data and XML with an extension mechanism for future needs. [1] What the format can store is not the same as what every exporter or importer preserves, and the design paper frames E57 as an exchange format rather than a working project format. [1] [3]
At a glance
- What it is: a vendor-neutral exchange container for 3D imaging data. [1]
- What it can contain: points, attributes such as color or intensity, metadata, and optional 2D images. [1]
- What it does not guarantee: scanner accuracy, full field preservation, or identical behavior across software. [3]
- Best first validation step: open the file locally, inspect visible scans and attributes, and then test it in the target tool before delivery. [6] [11]
Historical Background of the E57 File Format
ASTM Committee E57 on 3D Imaging Systems was established in 2006 to develop standard terminology, test methods, best practices, and data interoperability specifications for 3D imaging systems. [2] Daniel Huber’s design paper, published in January 2011, described the format’s goals, structure, and early implementation context. [3] That paper remains historically important, but it is not the current controlling standard. It also refers to the format being recently approved as ASTM E2761, which should now be treated as historical context only. [3] As of June 5, 2026, the active ASTM store page identifies the current controlling specification as ASTM E2807-11(2026). [1]
What an E57 File Is and Is Not
E57 is an exchange format for 3D imaging data. [1] It is not a scanner type, not a CAD solid format, not primarily a mesh format, and not a project file in the same sense as software ecosystems that maintain internal indexes, caches, regions, annotations, and application state. [3] The design paper is explicit that E57 is not intended to be a working data format or project format, and that derived modeled objects should not be included. [3]
That distinction matters because users often expect a shared .e57 to behave like the source project. Autodesk’s ReCap documentation separates neutral exports such as E57, PTS, and PCG from Autodesk-centered RCP/RCS project structures, where RCP references indexed point-cloud data rather than serving as a neutral container. [7] FARO’s SCENE documentation draws a similar boundary from another angle: its E57 note says the format is for scan points, not objects. [10]
E57 File Format: Technical Principles (Conceptual Anatomy, Not a Parser Guide)
At a conceptual level, E57 uses a hybrid design. [3] The hierarchy is XML-based so the structure is self-describing and extensible, while heavy payloads such as points and images are stored efficiently in binary form. [3] Huber’s paper describes this as a compromise between flexible, self-documenting structures and the practical need for faster I/O and smaller storage than plain-text point dumps. [3]
The high-level anatomy is simple: an E57 file is divided into a header, optional binary sections, and an XML section. [3] A few byte-level facts are well supported without turning this into a parser guide: the header is 48 bytes, binary pages are 1024 bytes with 1020 bytes of payload plus a 32-bit CRC, binary sections use little-endian byte order, and the XML section is a single XML 1.0 document using UTF-8 encoding. [3] [4]
This matters in workflows because E57 is not “just XYZ with a different extension.” [3] The format can bundle multiple 3D datasets, optional images, structured metadata, and error-checkable binary payloads in one exchange container. [3] [4] That is why an E57 handoff can preserve more context than a bare text export, but also why two tools can both “open E57” and still disagree about which parts they keep. [3] [4]
Core pieces of an E57 file
- Header: a 48-byte file header with critical file-level information. [3] [4]
- Page-based binary with CRC: binary data is page-based, with 1020 bytes of payload and a 32-bit CRC per 1024-byte page. [3] [4]
- XML 1.0 UTF-8 hierarchy: the required XML section is a single XML 1.0 document encoded in UTF-8. [4]
- Data3D: the main container for 3D datasets such as scans or point sets. [3] [4]
- Images2D: the optional container for associated 2D imagery. [3] [4]
- CoordinateMetadata: an optional string for standardized CRS context. [3] [4]
- CompressedVector: a core non-terminal type used to store ordered records in compressed binary form. [3] [4]
Data3D, Images2D, and Metadata (What the Schema Is Trying to Express)
Within the hierarchy, Data3D is where a scan-like 3D dataset lives. [3] Each Data3D contains point data in a CompressedVector, and public descriptions commonly refer to the logical per-point structure as PointRecord. [3] [4] The format is flexible: it can represent Cartesian or spherical coordinates, and a given record may include fields such as RGB color, intensity, row and column indices, return information, or time stamps. [3] Not every file contains every field, and some software may additionally expose normals or related derived fields in its own data model, so field presence is something to verify, not assume. [5] [6]
Images2D is the parallel container for optional imagery associated with scans. [3] The public design paper describes four image representations: Visual Reference, Pinhole, Spherical, and Cylindrical. [3] Images are stored as JPEG or PNG blobs, and the model is meant to preserve a meaningful relationship between pixels and the scan’s coordinate system when that relationship exists. [3] [4] If images disappear after import, the usual reason is not that E57 cannot store them, but that the exporter omitted them, the association was incomplete, or the receiving tool supports only a subset of the image representations. [3] [6]
What Is Stored in an E57 Scan Data Format? (And What’s Optional)
At the capability level, an E57 scan data format can store geometry, point attributes, metadata, and optional imagery in one container. [1]
The practical question is less “what can E57 store?” than “what did this file and toolchain preserve?” [1] [3] A file may contain multiple Data3D datasets, file-level metadata, scan-level pose information, optional CRS context, and images, yet an importer may flatten scans, drop images, ignore CRS text, or keep only attributes common to all internal clouds. [3] [4] That is why E57 deliverables should always be evaluated as format capability versus software support. [1] [3]
Check these deliverable fields before accepting an E57 point cloud file
- Point count per scan, if the tool exposes it. [5]
- Structured vs unstructured export. [8] [9]
- RGB present or absent. [1] [3]
- Intensity present or absent. [1] [3]
- Normals present or absent. [5] [6]
- Images embedded, linked, or absent. [3] [4]
- Coordinate system notes and CRS metadata present or absent. [3] [4]
- Scan poses or registration transforms present or absent. [3] [8]
- Export settings that can change data, such as unified cloud export, decimation, or clipping behavior. [8] [9]
Where E57 data can live (and what’s commonly lost)
| Level | Examples | Standard capability | Common interoperability pitfall |
|---|---|---|---|
| File/root-level | E57Root, coordinateMetadata. [3] [4] |
Can hold multiple 3D datasets, 2D images, and optional CRS context. [3] [4] | Importers may load points but ignore file-level CRS text or image associations. [3] [4] |
| Scan/Data3D-level | Pose, acquisition time, bounds, grouping, per-scan metadata. [3] [5] | Designed to keep dataset-level context with each scan. [3] | Unified or flattened imports may hide scan boundaries and reduce scan-specific context. [3] [11] |
| Point-record level | Coordinates, color, intensity, returns, timestamps, row/column-like structure. [1] [3] | Flexible per-point fields inside compressed records. [3] [4] | Receivers often keep only fields they understand or only fields shared across internal clouds. [6] [11] |
| Software-derived fields | Computed normals, decimated clouds, UI-normalized intensity. [5] [6] | These may exist in workflows, but they are not universal promises of an E57 handoff. [3] [5] | Users may mistake application behavior for portable format behavior. [3] [5] |
Most “missing field” complaints happen when expectations cross those levels. [3] A sender may know the source project contains panoramas, per-scan structure, and poses, while the receiver only verifies that the points opened. [6] [8] For delivery, the only safe test is whether the required information survives in the target application. [11]
Structured vs Unstructured E57 Point Cloud Data (Schema First, Software Second)
In E57 discussions, structured or gridded data refers first to how the point set is organized, not to a branding term from one software package. [3] Huber’s design paper describes E57 as being able to represent unordered point clouds as well as data organized into rows and columns, which is the schema-level basis for scan-grid-like datasets. [3] That organization can matter for scanner-position workflows, panorama alignment, and line- or column-aware processing. [3]
By contrast, unstructured or unorganized data behaves more like a plain list of points in space. [3] The coordinates may still be valid, but when a tool flattens a structured scan into an unstructured export, it can lose row/column organization, image relationships, or other station-like cues that downstream tools use for navigation and display. [3] This is why a point cloud can look “complete” in one program yet lose pano or scan-station behavior in another. [3]
Software behavior comes second. Autodesk says ReCap can export structured E57 with individual scans, row/column info, and registration transforms, but also warns that this export does not apply project deletions or clips. [8] Leica says tripod-based Setups export as structured with scan grid and panoramas, while unstructured sources export without a scan grid. [9] So “structured” is meaningful, but it does not guarantee that every target program will recreate a scan-station or panorama experience. [8] [9]
Coordinate Frames, Poses, and CRS Metadata (Avoiding the #1 Deliverables Mistake)
E57 was designed so that multiple datasets in one file can still be represented in a common file-level coordinate system. [3] In practical terms, a scan may exist in local sensor coordinates while an optional pose or rigid transform tells software how that scan sits in the wider file-level frame. [3] This is the bridge between “individual scan space” and “registered project space.” [3]
CRS information is a separate but related layer. [3] The root can carry optional CoordinateMetadata as a standardized CRS string in an OGC/WKT context, while the ASTM scope also states that standardized quantities use SI units and planar angles are in radians. [1] [4] Vendor exporters may document their own conventions on top of that; Autodesk ReCap, for example, states that its E57 exports use Cartesian meters and angles in radians. [5] Even when a file is called “georeferenced,” that can still be ambiguous if one tool reads pose transforms but ignores CRS text, or vice versa. [3] [4]
Warning: Georeferencing can be present as transforms and/or CRS metadata, but not all software reads or writes those parts consistently. [4] Always validate coordinates, orientation, and CRS behavior in the target tool before delivery. [4]
How to Open an E57 Point Cloud File (Viewer, BIM, Conversion, or Code?)
How to open an E57 point cloud file depends on your goal: visual inspection, project import, conversion, or programmatic processing. [6] [11] There is no single path that works for every E57 deliverable. [3]
In broad terms, neutral viewers are best for first-pass inspection, vendor ecosystems are best for checking project-specific behavior, and libraries or data tools are best for batch or code workflows. [17] [18] Autodesk ReCap documents both import and export behavior for E57, Leica documents how its exports preserve structured and unstructured setups, FARO documents E57 import/export as scan-point exchange, and PDAL documents a narrower reader intended for Cartesian point-cloud workflows. [5] [6] [9] [10] [11]
The important checks are not just “did it open?” but “what opened?” [3] Confirm whether a multi-scan file stayed multi-scan, whether panoramas or images came across, whether structured information survived, whether attributes such as RGB or intensity remain, and whether the target tool silently flattened or filtered anything. [6] [8] [11]
Avoid uploading confidential scan data to browser-based converters by default; prefer local or enterprise tools for sensitive, regulated, or very large datasets.
- Duplicate the original E57 and preserve the untouched source file.
- Open the copy locally in a neutral viewer such as CloudCompare for first inspection. [17]
- Confirm scan count or visible multi-scan structure, then check bounding box and obvious unit or axis problems.
- Check which attributes imported, including RGB, intensity, normals, and images where relevant. [5] [6]
- Validate the same file in the target application, such as ReCap, Cyclone, SCENE, or a downstream BIM pipeline. [6] [9] [10]
- Only then convert or export, documenting decimation, transforms, and dropped attributes. [8] [9]
Documented E57 support by tool (feature-level, not marketing)
| Tool | Reads | Writes | Images/panoramas | Structured/gridded handling | Notable documented limitation / note |
|---|---|---|---|---|---|
| CloudCompare | E57 read documented. [17] | E57 write documented. [17] | Calibrated pictures are documented in E57 I/O. [17] | No reliable figure found in the cited docs. | Official file I/O page lists multi-cloud support and E57 features such as normals, RGB, and intensity. [17] |
| Autodesk ReCap | E57 import documented. [6] [8] | E57 export documented. [5] [8] | Imports only E57_SPHERICAL panoramas; JPEG and PNG accepted. [6] |
Structured E57 export includes row/column info and registration transforms. [8] | Structured export does not apply deletions or clips created in the project. [8] |
| Leica Cyclone REGISTER 360 PLUS | No reliable figure found in the cited page. | E57 export as one file or separate files documented. [9] | Structured tripod-based exports include panoramas. [9] | Tripod-based Setups export as structured; unstructured sources export without scan grid. [9] | Separate-files export is recommended in some cases to avoid very large structured files. [9] |
| FARO SCENE | E57 import documented for scan points. [10] | E57 export documented for scan points. [10] | No reliable figure found in the cited page. | No reliable figure found in the cited page. | FARO says E57 is for scan points, not objects. [10] |
| PDAL | Reads Cartesian E57. [11] | No reliable figure found in the cited page. | Not documented as an image workflow in the cited reader page. [11] | Reads multiple internal clouds as one and only keeps dimensions present in all clouds. [11] | Spherical point clouds are not supported by the documented reader. [11] |
| libE57Format | Library read support documented. [18] | Library write support documented. [18] | README notes that E57 files can store 2D images. [18] | No reliable figure found for end-user structured behavior because this is a library, not a viewer. | Best thought of as a C++ E57 I/O library for Linux, macOS, and Windows. [18] |
A practical rule follows from that table: first validate the content class you care about. [3] If the job depends on scan-grid preservation, panoramas, spherical data, or scan-level metadata, you need exporter and importer documentation that explicitly covers those features, not just a checkmark next to “E57.” [6] [8] [9] [11]
E57 vs Other Scan Data Formats (LAS/LAZ/COPC, PTX/PTS, PLY, RCP/RCS)
No point-cloud format is best for every workflow. [1] E57 is strongest when you need neutral terrestrial scan exchange with richer context than simple XYZ-style text files. [1] LAS/LAZ and COPC are stronger when the job is geospatial LiDAR delivery, tiling, seeking, and large-scale spatial access. [12] [13] [14] RCP/RCS is strongest when the working environment is Autodesk-centered and indexed around Autodesk’s own project/cache behavior rather than neutral interchange. [7]
The table below reads left to right: “best fit” is the workflow, “commonly preserves” is the usual strength, and “main caution” is what tends to surprise people during exchange. [1] [7]
| Format | Best fit | Commonly preserves | Main caution |
|---|---|---|---|
| E57 | Terrestrial scan exchange across vendors and tools. [1] | Multi-scan containers, optional attributes, optional images, optional CRS context. [1] [3] | Feature support varies by importer and exporter. [1] [3] |
| LAS | Geospatial LiDAR deliverables. [12] | Standard LiDAR point records in an open community standard. [12] | Not centered on scan-station or panorama workflows. [12] |
| LAZ | LAS with lossless compression. [13] | LAS structure plus compressed point data. [13] | Requires LAZ-capable tooling; random access is chunk-granular. [13] |
| COPC (.copc.laz) | Cloud or range-readable spatial access. [14] | LAZ 1.4 organized in a clustered octree with VLR/EVLR metadata for seeking and subsetting. [14] | Geospatial access is the goal, not scan-project exchange. [14] |
| PTX | Legacy scanner exchange, often for structured station-style exports. [9] | XYZ, intensity, and registration transformation information in Leica’s documented workflow. [9] | Often heavier exchange behavior, and metadata consistency is tool-dependent. [9] |
| PTS/XYZ | Simple point exchange. [9] | Coordinates and, depending on writer, limited extra attributes. [9] | Weak structure and weak context make coordinate mistakes easy. [9] |
| PLY | Research, single-object mesh interchange, or point/mesh handoff. [19] | A single object with points and optional properties such as color; point-cloud use is possible. [19] | Not a scan-project container, and semantics vary by writer-defined properties. [19] |
| RCP/RCS | Autodesk workflows. [7] | Indexed project/cache behavior for Autodesk products. [7] | Not a neutral exchange container, and portability depends on referenced indexed files. [7] |
For geospatial deliverables, the contrast is especially concrete. [15] The current USGS Lidar Base Specification page for 2025 rev. A says point deliverables shall be in LAS 1.4-R15 using PDRF 6, 7, 8, 9, or 10, which is one reason LAS/LAZ dominates many national mapping and 3DEP-style workflows. [15]
A short market-direction note: OGC announced publication of the LAZ 1.4 Community Standard on September 3, 2026, defining lossless compression for LAS 1.4 with chunked storage, while COPC 1.0 builds cloud-optimized seeking and subsetting on top of LAZ 1.4 octree organization. [13] [14] Those are different goals from E57’s role as a rich, scan-oriented exchange container. [1] [14]
Performance Metrics and Data Quality (What E57 Does Not Guarantee)
E57 does not define scanner accuracy, precision, resolution, or point density by itself. [3] It can carry measured values and related metadata, but the quality of those values still comes from the instrument, calibration, acquisition method, registration workflow, and later processing. [3]
File size and performance are similarly situational. [3] Structured exports can be larger because they may include scan-grid information and panoramic images, while decimation, clipping policy, image inclusion, and which attributes are present can all change the result. [8] [9] E57 also uses compressed binary structures internally, but there is no reliable universal figure for E57 compression, import speed, or size relative to LAS, LAZ, PTX, or PTS across real projects. [3]
E57 can encode measured values and metadata, but scanner accuracy, registration residuals, calibration state, and decimation choices are external to the file format. [3]
Applications of E57 Point Cloud Files (When It’s a Good Fit)
Because E57 is built for exchanging 3D point data, attributes, and optional imagery, it fits well wherever scan data must move between capture, review, and downstream analysis tools. [1] [2] That commonly includes as-built documentation, survey and construction handoff, industrial plant documentation, manufacturing-related 3D measurement workflows, and cultural heritage recording. [2] In BIM coordination or reverse-engineering contexts, its value usually comes from carrying enough scan context to survive handoff better than bare text formats. [1] [3]
The useful deliverable is not the .e57 extension by itself. [3] A good handoff is one whose scans, attributes, coordinate context, and images survive in the receiving workflow. [1] [3]
Limitations and Interoperability Risks (Why Fields Disappear)
E57’s strength is flexibility, but flexibility creates optionality. [1] [3] The format can store many kinds of data, yet any given file may omit some of them, and any given tool may preserve only a subset. [1] [3] That is why two people can both be “using E57” and still see different scans, fields, or images after exchange. [3]
The documented examples are instructive. PDAL’s E57 reader supports Cartesian point clouds, reads multiple internal clouds as one, keeps only dimensions present in all clouds, and does not support spherical point clouds. [11] FARO’s SCENE says E57 is for scan points, not objects. [10] Autodesk ReCap says its panorama import supports only the E57_SPHERICAL representation, with JPEG or PNG images. [6]
So a successful import is only a starting point. [3] You still need to confirm whether images, scan grids, poses, normals, timestamps, and attribute ranges made the trip. [5] [6] [11]
Warning: “Opened successfully” does not prove preservation of images, scan grids, poses, normals, timestamps, or all attributes. [6] [11] Validate the file in the destination workflow before you sign off on delivery. [6] [11]
Conclusion: When to Use the E57 Point Cloud Format
Use the E57 point cloud format when you need a neutral, scan-oriented exchange container that can carry more context than plain XYZ-style text, but do not mistake that capability for a guarantee that every tool will preserve every field. [1] [3] It is usually the right choice for cross-vendor terrestrial scan handoff, while LAS/LAZ or COPC fit many geospatial deliverables better and RCP/RCS fits Autodesk-centered project workflows better. [7] [12] [14] Before delivery, work through the field checklist and the comparison table, then verify the result in the destination application. [6] [8] [11]
E57 Point Cloud FAQ
What is an E57 point cloud (and how is it different from an E57 file)?
An E57 point cloud is the scan data itself, while an E57 file is the container that can hold that data along with attributes, metadata, and optional imagery. [1] The current ASTM shorthand treats “E57 file” as the ASTM E57 3D file format defined by ASTM E2807-11(2026), so the file is the package and the point cloud is one kind of payload inside it. [1]
What is stored in an E57 scan data format—and what is optional?
The format can store 3D point data, attributes such as color or intensity, and 2D imagery. [1] It can also represent multiple 3D datasets, optional images, pose information, and optional coordinate metadata for CRS context. [3] [4] But all of those should be treated as “may be present,” because a specific exporter may omit them and a specific importer may ignore them. [3]
Why does my E57 point cloud look different after importing into another program?
Because “the format can store it” is not the same as “this tool preserved it.” [1] [3] Some programs flatten multiple scans, some ignore certain images, some only support specific panorama representations, and some only keep dimensions common to all embedded clouds. [6] [11] If appearance or behavior changed, compare the source export settings against the destination tool’s documented limits. [8] [9]
How do I open an E57 point cloud file safely (without risky web converters)?
Make a copy of the original file, inspect that copy locally in a neutral viewer or desktop tool, verify visible scans and attributes, and then test the same file in the target application before converting anything. [17] [6] [11] Browser-based converters can be convenient, but they are not a safe default for confidential, regulated, or very large scan datasets.
Does the E57 file format guarantee scanner accuracy, registration quality, or point density?
No. [3] E57 can encode measured values and metadata, but scanner accuracy, registration residuals, calibration state, and decimation are external to the file format. [3] The extension tells you the container, not whether the capture was good, the registration was tight, or the density is suitable for a given task. [3]
Expert: What does “structured” mean in E57—does it guarantee scan-station/panorama navigation?
Structured means the data preserves scan-grid-like organization such as row and column context, rather than being just an unordered point list. [3] That can help downstream station or panorama workflows, but it is not a universal guarantee. [3] Autodesk and Leica both document structured E57 behavior in their own export workflows, yet the target application still has to support and reconstruct that information properly. [8] [9]
Expert: How should I think about coordinate frames, pose transforms, and optional CRS metadata in E57 deliverables?
Think in layers. A scan may be local to the sensor, a pose transform may place it into a file-level common frame, and optional CoordinateMetadata may describe the larger CRS context in standardized text. [3] [4] Those layers are related but not interchangeable, so “georeferenced” can still be ambiguous unless you verify both coordinates and CRS behavior in the receiving software. [4]
Sources
- ASTM International — E2807 Standard Specification for 3D Imaging Data Exchange, Version 1.0 (ASTM E2807-11(2026)). https://store.astm.org/standards/e2807
- NIST — ASTM E57 – 3D Imaging Systems. https://www.nist.gov/publications/astm-e57-3d-imaging-systems
- 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
- Library of Congress — ASTEM E57 3D file format (E57). https://www.loc.gov/preservation/digital/formats/fdd/fdd000563.shtml
- 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
- 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
- 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
- Autodesk ReCap Help — Supported File Formats. https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
- Leica Geosystems RCDOCS — Third-Party File Export (Cyclone REGISTER 360 PLUS). https://rcdocs.leica-geosystems.com/docs/cyclone-register-360-third-party-file-export
- FARO Knowledge Base — Export Formats Supported by SCENE. https://knowledge.faro.com/Software/FARO_SCENE/SCENE/Export_Formats_Supported_by_SCENE
- PDAL Documentation — readers.e57. https://pdal.org/en/stable/stages/readers.e57.html
- OGC — LAS Specification – Open Format for LiDAR Point Cloud Data. https://www.ogc.org/standards/LAS/
- 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/
- COPC — Cloud Optimized Point Cloud Specification – 1.0. https://copc.io/copc-specification-1.0.pdf
- 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
- IANA — Media Types registry. https://www.iana.org/assignments/media-types
- CloudCompare Wiki — FILE I/O. https://www.cloudcompare.org/doc/wiki/index.php/FILE_I/O
- libE57Format — GitHub repository README. https://github.com/asmaloney/libE57Format
- Library of Congress — Polygon File Format (PLY) Family. https://wwws.loc.gov/preservation/digital/formats/fdd/fdd000501.shtml
