Designation: E2807 − 11Standard Specification for3D Imaging Data Exchange, Version 1.01This standard is issued under the fixed designation E2807; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon (´) indicates an editorial change since the last revision or reapproval.1. Scope1.1 This specification describes a data file exchange formatfor three-dimensional (3D) imaging data, known as the ASTME57 3D file format, Version 1.0. The term “E57 file” will beused as shorthand for “ASTM E57 3D file format” hereafter.1.2 An E57 file is capable of storing 3D point data, such asthat produced by a 3D imaging system, attributes associatedwith 3D point data, such as color or intensity, and 2D imagery,such as digital photographs obtained by a 3D imaging system.Furthermore, the standard defines an extension mechanism toaddress future aspects of 3D imaging.1.3 This specification describes all data that will be stored inthe file. The file is a combination of binary and eXtensibleMarkup Language (XML) formats and is fully documented inthis specification.1.4 All quantities standardized in this specification areexpressed in terms of SI units. No other units of measurementare included in this standard.1.4.1 Discussion—Planar angles are specified in radians,which are considered a supplementary SI unit.1.5 This standard does not purport to address all of thesafety concerns, if any, associated with its use. It is theresponsibility of the user of this standard to establish appro-priate safety and health practices and determine the applica-bility of regulatory limitations prior to use.1.6 This standard does not purport to address legalconcerns, if any, associated with its use. It is the responsibilityof the user of this standard to comply with appropriateregulatory limitations prior to use.2. Referenced Documents2.1 ASTM Standards:2E2544 Terminology for Three-Dimensional (3D) ImagingSystems2.2 IEEE Standard:3754-1985 IEEE Standard for Binary Floating-PointArithme-tic2.3 IETF Standard:4RFC 3720 Internet Small Computer Systems Interface(iSCSI)2.4 W3C Standard:5XML Schema Part 2: Datatypes Second Edition3. Terminology3.1 Definitions—Terminology used in this specification con-forms to the definitions included in Terminology E2544.3.2 Definitions of Terms Specific to This Standard:3.2.1 backward compatibility, n—ability of a file reader tounderstand a file created by a writer of an older version of a fileformat standard.3.2.2 byte, n—grouping of 8 bits, also known as an octet.3.2.3 camel case, n—naming convention in which com-pound words are joined without spaces with each word’s initialletter capitalized within the component and the first letter iseither upper or lowercase.3.2.4 camera image, n—regular, rectangular grid of valuesthat stores data from a 2D imaging system, such as a camera.3.2.5 camera projection model, n—mathematical formulaused to convert between 3D coordinates and pixels in a cameraimage.3.2.6 file offset, n—see physical file offset.3.2.7 file-level coordinate system, n—coordinate systemcommon to all 2D and 3D data sets in a given E57 file.3.2.8 forward compatibility, n—ability of a file reader toread a file that conforms to a newer version of a formatspecification than it was designed to read, specifically havingthe capability to understand those aspects of the file that weredefined in the version it was designed to read, while ignoringthose portions that were defined in later versions of the formatspecification.1This specification is under the jurisdiction of ASTM Committee E57 on 3DImaging Systems and is the direct responsibility of Subcommittee E57.04 on DataInteroperability.Current edition approved Feb. 1, 2011. Published March 2011.2For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at

[email protected] For Annual Book of ASTMStandards volume information, refer to the standard’s Document Summary page onthe ASTM website.3For referenced IEEE standards, visit http://grouper.ieee.org/groups/754.4For referenced Internet Engineering Task Force (IETF) standards, visit theIETF website, www.ietf.org.5String representations (the lexical space) of the numeric datatypes are docu-mented in the W3C standard: “XML Schema Part 2: Datatypes Second Edition”,available on the website http://www.w3.org/TR/xmlschema-2/.Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States13.2.9 logical length, n—number of bytes used to describesome entity in an E57 file, not including CRC checksum bytes.3.2.10 physical file offset, n—number of bytes preceding thespecified byte location in an E57 file, counting payload bytesand checksums.3.2.10.1 Discussion—This term is also known as the fileoffset.3.2.11 physical length, n—number of bytes used to describesome entity in an E57 file, including CRC checksum bytes.3.2.12 record, n—single collection in a sequence ofidentically-typed collections of elements.3.2.13 rigid body transform, n—type of coordinate trans-form that preserves distances between all pairs of points thatfurthermore does not admit a reflection.3.2.13.1 Discussion—A rigid body transform can be used,for example, to convert points from the local coordinates of a3D data set (for example, a single laser scan) to a commoncoordinate system shared by multiple 3D data sets (forexample, a set of laser scans).3.2.14 XML namespace, n—method for qualifying elementnames in XML to prevent the ambiguity of multiple elementswith the same name.3.2.14.1 Discussion—XML namespaces are used in an E57file to support the definition of extensions.3.2.15 XML whitespace, n—sequence of one or more of thefollowing Unicode characters: the space character (20hexadecimal), the carriage return (0D hexadecimal), line feed(0A hexadecimal), or tab (09 hexadecimal).3.2.16 zero padding, n—one or more zero-valued bytesappended to the end of a sequence of bytes.4. Acronyms4.1 ASCII—American Standard Code for Information Inter-change4.2 CRC—Cyclic redundancy check4.3 GUID—Globally unique identifier4.4 IEEE—Institute of Electrical and Electronics Engineers4.5 IETF—Internet Engineering Task Force4.6 iSCSI—Internet small computer system interface4.7 JPEG—Joint Photographic Experts Group4.8 PNG—Portable network graphics4.9 URI—Uniform resource identifier4.10 UTC—Coordinated universal time4.11 UTF—Unicode Transformation Format4.12 W3C—WorldWide Web Consortium4.13 XML—eXtensible Markup Language5. Notation and Mathematical Concepts5.1 The following notation and established mathematicalconcepts are used in this specification.5.2 Intervals:5.2.1 A closed interval is denoted [a, b], where a ≤ b.Aclosed interval includes the endpoints a and b and all numbersin between.An open interval is denoted (a, b), where a ≤ b.Anopen interval includes the numbers between the endpoints aand b, but does not include the endpoints themselves. Thehalf-open intervals (a, b] and [a, b) do not include the a and bendpoints, respectively.5.3 Cartesian Coordinate System:5.3.1 Points in Cartesian coordinates are represented by anordered triplet (x, y, z), where x, y and z are coordinates alongthe X, Y, and Z axes, respectively. The coordinate system isright-handed.5.4 Cylindrical Coordinate System:5.4.1 Points in cylindrical coordinates are represented by anordered triplet (ρ, θ, z), where ρ is the radial distance (inmeters), θ is the azimuth angle (in radians), and z is the height(in meters).5.4.1.1 The azimuth angle is measured as the counterclock-wise rotation of the positive X-axis about the positive Z-axis ofa Cartesian reference frame.5.4.2 The following restrictions on cylindrical coordinatesare applied:ρ$0 (1)2π,θ # π (2)5.4.3 The conversion from Cartesian to cylindrical coordi-nates is accomplished through the formulas (note that the zcoordinate is the same in both systems):ρ 5 =~x21y2! (3)θ 5 atan2~y,x! (4)5.4.3.1 The function “atan2(y, x)” is defined as the functionreturning the arc tangent of y/x, in the range (–π,+π] radians.The signs of the arguments are used to determine the quadrantof the result.5.4.3.2 In degenerate cases, the following convention isobserved:If x = y = 0, then θ =0.5.4.4 Conversely, cylindrical coordinates can be convertedto Cartesian coordinates using the formulas:x 5 ρ cos~θ! (5)y 5 ρ sin~θ! (6)5.5 Spherical Coordinate System:5.5.1 Points in spherical coordinates are represented by anordered triplet (r, θ, φ), where r is the range (in meters), θ is theazimuth angle (in radians), and φ is the elevation angle (inradians).5.5.2 The following restrictions on spherical coordinates areapplied:r $0 (7)2π,θ # π (8)2π2#φ#π2(9)5.5.3 The conversion from spherical to Cartesian coordi-nates is accomplished through the formulas:E2807 − 112x 5 r cos~φ!cos~θ! (10)y 5 r cos~φ!sin~θ! (11)z 5 r sin~φ! (12)5.5.4 Conversely, in non-degenerate cases, Cartesian coor-dinates can be converted to spherical coordinates via theformulas:r 5 =~x21y21z2! (13)θ 5 atan2~y,x! (14)φ 5 arcsinSzrD(15)5.5.4.1 In degenerate cases, the following conventions areobserved:If x = y = 0, then θ =0;If x = y = z = 0, then both θ = 0 and φ =0.5.5.5 Discussion—The elevation is measured with respect tothe XY-plane, with positive elevations towards the positiveZ-axis. The azimuth is measured as the counterclockwiserotation of the positive X-axis about the positive Z-axis. Thisdefinition of azimuth follows typical engineering usage. Notethat this differs from traditional use in navigation or surveying.5.6 Quaternions:5.6.1 A quaternion is a generalized complex number. Aquaternion, q, is represented by an ordered four-tuple (w,x,y,z ),where q = w + xi + yj + zk. The coordinate w defines the scalarpart of the quaternion, and the coordinates (x, y, z) define thevector part.5.6.2 The norm of a quaternion, || q ||, is defined as:|| q || 5 =w21x21y21z2.5.6.3 A unit quaternion, q, has the further restriction that itsnorm || q ||=1.5.6.4 Rotation of a point p by a unit quaternion q is given bythe matrix formula:p 5 Rp (16)where:R 5Fw21x22 y22 z22~xy1wz!2~xz 2 wy!2~xy 2 wz!w21y22 x22 z22~yz1wx!2~xz1wy!2~yz 2 wx!w21z22 x22 y2G(17)5.6.5 Discussion—Unit quaternions are used in this standardto represent rotations in rigid body transforms.5.7 Rigid Body Transforms:5.7.1 A rigid body transform converts points from onecoordinate reference frame to another, preserving distancesbetween pairs of points and, furthermore, not admitting areflection. A rigid body transform can be represented as a3 × 3 rotation matrix R and a translation 3-vector t.5.7.2 A 3D point is transformed from the source coordinatesystem to the destination coordinate system by first applyingthe rotation and then the translation. More formally, thetransformation operation T(.) of a point p is defined as:p 5 T~p! 5 Rp1t (18)The rotation matrix R can be computed from a unit quater-nion q using Eq 17.5.7.3 Discussion—Rigid body transforms are used in thisstandard to support the transformation of data represented in alocal coordinate system, such as the coordinate system of asensor used to acquire a 3D data set, to a common file-levelcoordinate system shared by all 3D data sets.5.8 Trees:5.8.1 A tree is data structure that represents an acyclicgraph. A tree consists of nodes, which store some information,and edges (also known as arcs) that connect the nodes. Thesingle topmost node is called the root node. A node may havezero or more nodes connected below it, which are called childnodes. Each node, except the root node, has exactly one nodeconnected above it, which is called the parent node. Nodes withno children are called leaf nodes. A descendant is a direct orindirect child of a given node.5.8.2 Discussion—Trees are used in this standard to de-scribe the structure of XML data, as well as index data inbinary sections.5.9 XML Elements and Attributes :5.9.1 An XMLelement is the fundamental building block ofan XML file. An element consists of a start tag, optionalattributes, optional child elements, optional child text, and anend tag. Element names in an E57 file are case sensitive.Element names in this specification are written in camel casewith a lowercase initial character. Type names in this specifi-cation are written in camel case with an upper case initialcharacter.5.9.2 Discussion—See Fig. 1 for an excerpt of XML thatillustrates the parts of an XML element.5.9.3 XML elements that have child elements form a tree,with each element being a node.FIG. 1 XML Elements and AttributesE2807 − 1135.9.4 A pathname is a string that specifies the sequence ofelements names that are encountered when traversing from agiven origin element to a destination element in an XML tree.In this standard, pathnames are only defined for destinationelements that are descendants of the origin element. A relativepathname is formed by concatenating the sequence of elementnames traversed using the forward slash (“/”) as a separator.Each successive element in the sequence shall be a child of theprevious element. Note that the element name of the originelement does not appear in the pathname. An absolute path-name has an origin that is the root element of the tree, and isformed by prepending a forward slash to the relative pathname.5.9.5 Discussion—As an example, consider a hypotheticalE57 file consisting of a root element named e57Root whichcontains a child element named data3D, which contains achild element named 0, which contains a child element namedpose, which contains a child element named translation, which contains a child element named x. Then the absolutepathname of the x element is “/data3D/0/pose/translation/x”, and the relative pathname of the xelement relative to theposeelement is“translation/x”.6. General File Structure6.1 E57 files shall use the filename extension “.e57” (notelowercase e).6.2 This specification defines a binary file format composedof a sequence of pages.6.2.1 Each page shall be composed of 1020 bytes of data(known as the payload) followed by a 32-bit cyclic redundancycheck (CRC) checksum computed on the preceding payload.6.2.2 The length of an E57 file shall be an integral multipleof 1024 bytes. Any unused bytes in the payload of the finalpage in a file shall be filled with 0 values.6.2.3 The CRC checksum shall be computed on the 1020bytes of data using the iSCSI polynomial CRC32C (CRC32-bit Castagnioli) as documented in IETF RFC 3720, Section12.1 (http://tools.ietf.org/html/rfc3720).6.2.4 Discussion—Sequences of data without the CRCchecksum bytes are known as logical sequences, while se-quences of data with the CRC checksum bytes included areknown as physical sequences. All sequences of characters (inXML section) or bytes (in binary sections) described in thisstandard are logical sequences. The physical sequence repre-sentation of a logical sequence may have an interveningchecksum if the logical sequ