E57

The most common file format for storing and interchange of 3D laser scan data.
See early paper: The ASTM E57 File Format for 3D Imaging Data Exchange

In February 2011 E57 was approved as a ASTM standard (E2807).
See: Standard Specification for 3D Imaging Data Exchange, Version 1.0.
Quote: " This specification describes a data file exchange format for three-dimensional (3D) imaging data, known as the ASTM E57 3D file format, Version 1.0. In this specification, the term "E57 file" is used as a short version of "ASTM E57 3D file format". An E57 file is capable of storing 3D point data (those produced by 3D imaging systems), attributes associated with 3D point data (color and intensity), and 2D imagery (digital photographs obtained using a 3D imaging system). This specification describes all data that will be stored in the file, which is a combination of binary and eXtensible Markup Language (XML) formats. "

Broadly an E57 file consists of a 48 byte header, a series of data chunks, and finally an XML section. The whole file, including the header is split into 1024 byte "pages", 1020 bytes of data and 4 bytes at the end as a checksum. This chunk nature even applies to the otherwise text/readable XML section located after all the data chunks.

struct E57FileHeader {
    char        fileSignature[8];
    uint32_t    majorVersion;
    uint32_t    minorVersion;
    uint64_t    filePhysicalLength;
    uint64_t    xmlPhysicalOffset;
    uint64_t    xmlLogicalLength;
    uint64_t    pageSize;
}

In order to extract the XML section one simply reads from the start of the file in 1024 byte pages, once the file location reaches header.xmlPhysicalOffset save the remaining 1020 bytes of each 1024 page. There are of course other options, slightly more complicated but faster is to seek to header.xmlPhysicalOffset and determine which part of the 1024 page one is on, read the rest of that page and then continue to read 1024 bytes pages to the end of the file but only saving the first 1020 bytes of each. An example XML section is provided here: xml.zip. It seems normal that a E57 file is padded to integer multiple of the page size, 1024, so header.filePhysicalLength is always a multiple of 1024.

Navigable version