ASTM E2807-11(2019)e1

This international standard was developed in accordance with internationally recognized principles on standardization established in the Decision on Principles for the
Development of International Standards, Guides and Recommendations issued by the World Trade Organization Technical Barriers to Trade (TBT) Committee.
´1
Designation:E2807 −11 (Reapproved 2019)
Standard Specification for
3D Imaging Data Exchange, Version 1.0
This standard is issued under the fixed designation E2807; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision.Anumber in parentheses indicates the year of last reapproval.A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
ε NOTE—A spelling was corrected in Table 29 and Fig. 7 was updated editorially to reflect data in Table 43 in November
2022.
1. Scope mendations issued by the World Trade Organization Technical
Barriers to Trade (TBT) Committee.
1.1 This specification describes a data file exchange format
for three-dimensional (3D) imaging data, known as theASTM
2. Referenced Documents
E57 3D file format, Version 1.0. The term “E57 file” will be
2.1 ASTM Standards:
used as shorthand for “ASTM E57 3D file format” hereafter.
E2544Terminology for Three-Dimensional (3D) Imaging
1.2 An E57 file is capable of storing 3D point data, such as
Systems
that produced by a 3D imaging system, attributes associated
2.2 IEEE Standard:
with 3D point data, such as color or intensity, and 2D imagery,
754-1985IEEEStandardforBinaryFloating-PointArithme-
such as digital photographs obtained by a 3D imaging system.
tic
Furthermore, the standard defines an extension mechanism to
2.3 IETF Standard:
address future aspects of 3D imaging.
RFC 3720 Internet Small Computer Systems Interface
1.3 Thisspecificationdescribesalldatathatwillbestoredin
(iSCSI)
the file. The file is a combination of binary and eXtensible
2.4 W3C Standard:
Markup Language (XML) formats and is fully documented in
XML Schema Part 2:Datatypes Second Edition
this specification.
1.4 All quantities standardized in this specification are
3. Terminology
expressed in terms of SI units. No other units of measurement
3.1 Definitions—Terminologyusedinthisspecificationcon-
are included in this standard.
forms to the definitions included in Terminology E2544.
1.4.1 Discussion—Planar angles are specified in radians,
3.2 Definitions of Terms Specific to This Standard:
which are considered a supplementary SI unit.
3.2.1 backward compatibility, n—ability of a file reader to
1.5 This standard does not purport to address all of the
understandafilecreatedbyawriterofanolderversionofafile
safety concerns, if any, associated with its use. It is the
format standard.
responsibility of the user of this standard to establish appro-
3.2.2 byte, n—grouping of 8 bits, also known as an octet.
priate safety, health, and environmental practices and deter-
mine the applicability of regulatory limitations prior to use.
3.2.3 camel case, n—naming convention in which com-
1.6 This standard does not purport to address legal poundwordsarejoinedwithoutspaceswitheachword’sinitial
concerns, if any, associated with its use. It is the responsibility
letter capitalized within the component and the first letter is
of the user of this standard to comply with appropriate either upper or lowercase.
regulatory limitations prior to use.
3.2.4 camera image, n—regular, rectangular grid of values
1.7 This international standard was developed in accor-
that stores data from a 2D imaging system, such as a camera.
dance with internationally recognized principles on standard-
ization established in the Decision on Principles for the
Development of International Standards, Guides and Recom-
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
Standards volume information, refer to the standard’s Document Summary page on
the ASTM website.
1 3
This specification is under the jurisdiction of ASTM Committee E57 on 3D For referenced IEEE standards, visit http://grouper.ieee.org/groups/754.
Imaging Systems and is the direct responsibility of Subcommittee E57.11 on Data For referenced Internet Engineering Task Force (IETF) standards, visit the
Interoperability. IETF website, www.ietf.org.
Current edition approved March 1, 2019. Published March 2019. Originally String representations (the lexical space) of the numeric datatypes are docu-
approved in 2011. Last previous edition approved in 2011 as E2807–11. DOI: mented in the W3C standard: “XML Schema Part 2: Datatypes Second Edition”,
10.1520/E2807-11R19E01. 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 States
´1
E2807−11 (2019)
3.2.5 camera projection model, n—mathematical formula 4.8 PNG—Portable network graphics
usedtoconvertbetween3Dcoordinatesandpixelsinacamera
4.9 URI—Uniform resource identifier
image.
4.10 UTC—Coordinated universal time
3.2.6 file offset, n—see physical file offset.
4.11 UTF—Unicode Transformation Format
3.2.7 file-level coordinate system, n—coordinate system
4.12 W3C—WorldWide Web Consortium
common to all 2D and 3D data sets in a given E57 file.
4.13 XML—eXtensible Markup Language
3.2.8 forward compatibility, n—ability of a file reader to
read a file that conforms to a newer version of a format
specification than it was designed to read, specifically having 5. Notation and Mathematical Concepts
the capability to understand those aspects of the file that were
5.1 The following notation and established mathematical
defined in the version it was designed to read, while ignoring
concepts are used in this specification.
those portions that were defined in later versions of the format
5.2 Intervals:
specification.
5.2.1 A closed interval is denoted [a, b], where a ≤ b.A
3.2.9 logical length, n—number of bytes used to describe
closed interval includes the endpoints a and b and all numbers
someentityinanE57file,notincludingCRCchecksumbytes.
inbetween.Anopenintervalisdenoted(a, b),where a≤ b.An
3.2.10 physical file offset, n—numberofbytesprecedingthe
open interval includes the numbers between the endpoints a
specified byte location in an E57 file, counting payload bytes
and b, but does not include the endpoints themselves. The
and checksums.
half-open intervals (a, b] and [a, b) do not include the a and b
3.2.10.1 Discussion—This term is also known as the file
endpoints, respectively.
offset.
5.3 Cartesian Coordinate System:
3.2.11 physical length, n—number of bytes used to describe
5.3.1 Points in Cartesian coordinates are represented by an
some entity in an E57 file, including CRC checksum bytes.
ordered triplet (x, y, z), where x, y, and z are coordinates along
the X, Y, and Z axes, respectively. The coordinate system is
3.2.12 record, n—single collection in a sequence of
right-handed.
identically-typed collections of elements.
3.2.13 rigid body transform, n—type of coordinate trans- 5.4 Cylindrical Coordinate System:
form that preserves distances between all pairs of points that
5.4.1 Points in cylindrical coordinates are represented by an
furthermore does not admit a reflection. ordered triplet (ρ, θ, z), where ρ is the radial distance (in
3.2.13.1 Discussion—A rigid body transform can be used, meters), θ is the azimuth angle (in radians), and z is the height
for example, to convert points from the local coordinates of a (in meters).
3D data set (for example, a single laser scan) to a common 5.4.1.1 The azimuth angle is measured as the counterclock-
coordinate system shared by multiple 3D data sets (for wiserotationofthepositive X-axisaboutthepositive Z-axisof
example, a set of laser scans).
a Cartesian reference frame.
5.4.2 The following restrictions on cylindrical coordinates
3.2.14 XML namespace, n—method for qualifying element
are applied:
names in XML to prevent the ambiguity of multiple elements
with the same name.
ρ$0 (1)
3.2.14.1 Discussion—XML namespaces are used in an E57
2π,θ# π (2)
file to support the definition of extensions.
5.4.3 The conversion from Cartesian to cylindrical coordi-
3.2.15 XML whitespace, n—sequence of one or more of the
nates is accomplished through the formulas (note that the z
following Unicode characters: the space character (20
coordinate is the same in both systems):
hexadecimal), the carriage return (0D hexadecimal), line feed
2 2
(0A hexadecimal), or tab (09 hexadecimal).
ρ 5 = x 1y (3)
~ !
3.2.16 zero padding, n—one or more zero-valued bytes
θ 5 atan2 y,x (4)
~ !
appended to the end of a sequence of bytes.
5.4.3.1 The function “atan2(y, x)” is defined as the function
returning the arc tangent of y/x, in the range (–π,+π] radians.
4. Acronyms
The signs of the arguments are used to determine the quadrant
4.1 ASCII—American Standard Code for Information Inter-
of the result.
change
5.4.3.2 In degenerate cases, the following convention is
observed:
4.2 CRC—Cyclic redundancy check
If x = y = 0, then θ=0.
4.3 GUID—Globally unique identifier
5.4.4 Conversely, cylindrical coordinates can be converted
4.4 IEEE—Institute of Electrical and Electronics Engineers
to Cartesian coordinates using the formulas:
4.5 IETF—Internet Engineering Task Force
x 5 ρ cos θ (5)
~ !
4.6 iSCSI—Internet small computer system interface
y 5 ρ sin~θ! (6)
4.7 JPEG—Joint Photographic Experts Group 5.5 Spherical Coordinate System:
´1
E2807−11 (2019)
5.5.1 Points in spherical coordinates are represented by an 5.6.5 Discussion—Unitquaternionsareusedinthisstandard
orderedtriplet(r,θ,φ),where ristherange(inmeters),θisthe to represent rotations in rigid body transforms.
azimuth angle (in radians), and φ is the elevation angle (in
5.7 Rigid Body Transforms:
radians).
5.7.1 A rigid body transform converts points from one
5.5.2 Thefollowingrestrictionsonsphericalcoordinatesare
coordinate reference frame to another, preserving distances
applied:
between pairs of points and, furthermore, not admitting a
r$0 (7)
reflection. A rigid body transform can be represented as a
3 × 3 rotation matrix R and a translation 3-vector t.
2π,θ# π (8)
5.7.2 A3D point is transformed from the source coordinate
π π
2 # φ# (9)
system to the destination coordinate system by first applying
2 2
the rotation and then the translation. More formally, the
5.5.3 The conversion from spherical to Cartesian coordi-
transformation operation T(.) of a point p is defined as:
nates is accomplished through the formulas:
p' 5 T~p! 5 Rp1t (18)
x 5 r cos φ cos θ (10)
~ ! ~ !
The rotation matrix R can be computed from a unit quater-
y 5 r cos φ sin θ (11)
~ ! ~ !
nion q using Eq 17.
z 5 r sin φ (12)
~ !
5.7.3 Discussion—Rigid body transforms are used in this
standard to support the transformation of data represented in a
5.5.4 Conversely, in non-degenerate cases, Cartesian coor-
local coordinate system, such as the coordinate system of a
dinates can be converted to spherical coordinates via the
sensor used to acquire a 3D data set, to a common file-level
formulas:
coordinate system shared by all 3D data sets.
2 2 2
r 5 =~x 1y 1z ! (13)
5.8 Trees:
θ 5 atan2~y,x! (14)
5.8.1 A tree is data structure that represents an acyclic
z
graph.Atree consists of nodes, which store some information,
φ 5 arcsin (15)
S D
r
and edges (also known as arcs) that connect the nodes. The
single topmost node is called the root node.Anode may have
5.5.4.1 In degenerate cases, the following conventions are
zero or more nodes connected below it, which are called child
observed:
nodes. Each node, except the root node, has exactly one node
If x = y = 0, then θ=0;
connectedaboveit,whichiscalledtheparentnode.Nodeswith
If x = y = z = 0, then both θ = 0 and φ=0.
no children are called leaf nodes. A descendant is a direct or
5.5.5 Discussion—Theelevationismeasuredwithrespectto
indirect child of a given node.
the XY-plane, with positive elevations towards the positive
5.8.2 Discussion—Trees are used in this standard to de-
Z-axis. The azimuth is measured as the counterclockwise
scribe the structure of XML data, as well as index data in
rotation of the positive X-axis about the positive Z-axis. This
binary sections.
definition of azimuth follows typical engineering usage. Note
5.9 XML Elements and Attributes:
thatthisdiffersfromtraditionaluseinnavigationorsurveying.
5.9.1 AnXMLelementisthefundamentalbuildingblockof
5.6 Quaternions:
an XML file. An element consists of a start tag, optional
5.6.1 A quaternion is a generalized complex number. A
attributes, optional child elements, optional child text, and an
quaternion, q,isrepresentedbyanorderedfour-tuple(w,x,y,z),
end tag. Element names in an E57 file are case sensitive.
where q= w+ xi+ yj+ zk.Thecoordinate wdefinesthescalar
Element names in this specification are written in camel case
part of the quaternion, and the coordinates (x, y, z) define the
with a lowercase initial character. Type names in this specifi-
vector part.
cation are written in camel case with an upper case initial
5.6.2 The norm of a quaternion, || q ||, is defined as:
character.
2 2 2 2
5.9.2 Discussion—See Fig. 1 for an excerpt of XML that
|| q || 5 =w 1x 1y 1z .
illustrates the parts of an XML element.
5.6.3 Aunit quaternion, q, has the further restriction that its
5.9.3 XML elements that have child elements form a tree,
norm || q||=1.
with each element being a node.
5.6.4 Rotationofapointpbyaunitquaternion qisgivenby
5.9.4 A pathname is a string that specifies the sequence of
the matrix formula:
elements names that are encountered when traversing from a
p' 5 Rp (16)
given origin element to a destination element in an XML tree.
In this standard, pathnames are only defined for destination
where:
elements that are descendants of the origin element.Arelative
2 2 2 2
w 1x 2 y 2 z 2 xy 2 wz 2 xz1wy
~ ! ~ !
pathname is formed by concatenating the sequence of element
2 2 2 2
2 xy1wz w 1y 2 x 2 z 2 yz 2 wx
R 5 ~ ! ~ !
names traversed using the forward slash (“/”) as a separator.
F G
2 2 2 2
2 xz 2 wy 2 yz1wx w 1z 2 x 2 y
~ ! ~ !
Eachsuccessiveelementinthesequenceshallbeachildofthe
(17) previous element. Note that the element name of the origin
´1
E2807−11 (2019)
FIG. 1XML Elements and Attributes
element does not appear in the pathname. An absolute path- standard are logical sequences. The physical sequence repre-
name has an origin that is the root element of the tree, and is sentation of a logical sequence may have an intervening
formedbyprependingaforwardslashtotherelativepathname. checksum if the logical sequence crosses a page boundary.
5.9.5 Discussion—As an example, consider a hypothetical Page boundaries occur every 1020 bytes of logical data.
E57 file consisting of a root element named e57Root which
6.3 An E57 file shall be composed of two or more sections
contains a child element named data3D, which contains a
in the following order:
child element named0, which contains a child element named
6.3.1 File header section (required, see Section 7),
pose, which contains a child element namedtranslation
6.3.2 Binary sections (optional, see Section 9), and
, which contains a child element named x. Then the absolute
6.3.3 XML section (required, see Section 8).
pathname of the x element is “/data3D/0/pose/
translation/x”, and the relative pathname of the x
6.4 Binary portions (including the header and binary sec-
elementrelativetotheposeelementis“translation/x”.
tions) of an E57 file are encoded using the little-endian byte
order.
6. General File Structure
6.1 E57 files shall use the filename extension “.e57” (note
7. File Header Section
lowercase e).
7.1 The file header section begins at file offset 0.
6.2 This specification defines a binary file format composed
7.2 The file header section is 48 bytes in length, with the
of a sequence of pages.
6.2.1 Each page shall be composed of 1020 bytes of data format given in Table 1.
(knownasthepayload)followedbya32-bitcyclicredundancy
check (CRC) checksum computed on the preceding payload. 8. XML Section
6.2.2 The length of an E57 file shall be an integral multiple
8.1 TheXMLsectionofthefiledescribesthedatahierarchy.
of 1024 bytes. Any unused bytes in the payload of the final
ThedatahierarchycontainsasetofXMLelementsinaspecific
page in a file shall be filled with 0 values.
format, and arbitrary XML is not allowed. The elements are
6.2.3 The CRC checksum shall be computed on the 1020
built upon a set of fundamental data types: Integer,
bytes of data using the iSCSI polynomial CRC32C (CRC
ScaledInteger, Float, String, Structure, Blob,Vector, and Com-
32-bit Castagnioli) as documented in IETF RFC 3720, Section
pressedVector. Additional composite data types are defined in
12.1 (http://tools.ietf.org/html/rfc3720).
the standard or can be defined by an extension to the standard.
6.2.4 Discussion—Sequences of data without the CRC
checksum bytes are known as logical sequences, while se- 8.2 The XML section of the E57 file contains a single
quences of data with the CRC checksum bytes included are well-formed XML 1.0 document using UTF-8 encoding.
known as physical sequences. All sequences of characters (in However, arbitrary XML is not allowed. The elements in the
XML section) or bytes (in binary sections) described in this XMLsection shall be E57 elements, which are XMLelements
TABLE 1 Format of the E57 File Header Section
Bytes Field name Data type Description
1-8 fileSignature 8-bit characters The file type signature. Shall contain the ASCII characters “ASTM-E57”.
9-12 versionMajor Unsigned 32-bit integer The file format major version number. The value shall be 1.
13-16 versionMinor Unsigned 32-bit integer The file format minor version number. The value shall be 0.
17-24 fileLength Unsigned 64-bit integer The physical length of the file, in bytes. Note that this length includes CRC bytes
and any zero padding as described in 6.2.2. Shall be in the open interval (0, 2 ).
25-32 xmlOffset Unsigned 64-bit integer The physical file offset, in bytes, to the beginning of the XML section of the file. As
defined in 3.2.10, this value includes CRC bytes. Shall be in the open interval (0,
2 ).
33-40 xmlLength Unsigned 64-bit integer The logical length, in bytes, of the XML section of the file, excluding CRC bytes and
zero padding. Shall be in the open interval (0, 2 ).
41-48 pageSize Unsigned 64-bit integer The size a page, in bytes, as defined in 6.2. The value shall be 1024.
´1
E2807−11 (2019)
of a specific format, as will be described in 8.3. Furthermore, leading and trailing XML whitespace. The raw value is
the elements shall follow particular grammatical rules, which restricted to be in the closed interval [minimum, maximum].
are described in 8.4. If raw value is unspecified, the default raw value is 0. The
scaled value (SV) is computed from the raw value (RV) using
8.3 E57 Element Data Types:
the formula
8.3.1 The E57 file format supports eight fundamental E57
SV 5 r r r RV 3r scale 1r offset (19)
elementdatatypes—fiveterminaltypesandthreenon-terminal ~ ~ ~ ! ~ ! ~ !!
types. Non-terminal types are composed of other non-terminal
where the (r) function means rounding to the nearest
or terminal types to an arbitrary, but finite, level of nesting.
representable double precision (53-bit mantissa) IEEE 754-
Terminal types shall not contain any child E57 elements. The
1985 floating-point number using the “Round To Nearest”
terminal types are Integer, ScaledInteger, Float, String, and
rounding mode (as described in IEEE 754-1985), and the ‘×’
Blob. The non-terminal types are Structure, Vector, and Com-
and ‘+’ operators are considered to be infinitely precise.
pressedVector. Every element in an E57 file shall be one of
8.3.4 Float Type:
these types. Some or all of the data associated with an E57
8.3.4.1 Float type E57 elements (Float hereafter) are used
element may be encoded in a binary section.
forstoringfloatingpointvalues.TheXMLattributesforaFloat
8.3.1.1 The data type of an E57 element is indicated by the
are listed in Table 4.
typeXMLattribute,whichisrequired.Dependingonthedata
8.3.4.2 The value of a Float is represented as child text of
type, there may be other XML attributes that are required or
the XML element. This child text shall be zero or one
optional, and there may be restrictions on child elements.
occurrence of the xsd:float representation (if precision is
8.3.1.2 String representations of the numeric data types are
single)orxsd:double(ifprecisionisdouble),withoptional
documented in theW3C standard “XMLSchema Part 2: Data
leading and trailing XML whitespace. If no value is specified,
types Second Edition.”The following XMLbuilt-in data types
the default value of the Float is 0. The number represented is
from that standard are referenced below: xsd:integer, xsd:float,
the nearest representable single precision (or double precision
xsd:double. Instances of xsd:float and xsd:double shall not use
if precision is double) IEEE 754-1985 floating point
the special values: -0 (negative zero), +INF (positive infinity),
number (including denormals, but excluding NaNs, +INF,
-INF (negative infinity), and NaN (not a number).
-INF, and -0) to the text representation.
8.3.1.3 The rules for each E57 element data type are
8.3.5 String Type:
detailedinfollowingsections.TheorderoftheXMLattributes
8.3.5.1 String type E57 elements (String hereafter) are used
is not important.
for storing text. The XML attributes for a String are listed in
8.3.2 Integer Type:
Table 5.
8.3.2.1 Integer type E57 elements (Integer hereafter) are
used for storing integer values. The XML attributes for an 8.3.5.2 ThevalueofaStringshallbeencodedinUTF-8and
Integer are listed in Table 2. shallberepresentedaschildtextoftheXMLelement.Because
8.3.2.2 ThevalueofanIntegerisrepresentedaschildtextof the content of a String may include any combination of
the XML element. This child text shall be zero or one characters, the XML child text shall appear inside a Character
occurrence of the xsd:integer representation, with optional
data (CDATA) section. If the character sequence “]]>” appears
leading and trailing XML whitespace. If no value is specified, in the String value, the characters shall be split across two or
the default value of the Integer is 0. more CDATAsections such that each “]]>” in the String value
8.3.2.3 The value of the Integer is restricted to be in the is split into “]]” and “>” in adjacent CDATA sections. There
range [minimum, maximum]. shall be no XML whitespace before the first CDATA section,
8.3.3 ScaledInteger Type: between CDATA sections, or after the last CDATA section.
8.3.3.1 For efficiency, it is possible to store numbers with
8.3.6 Blob Type:
fractional parts using a ScaledInteger type E57 element
8.3.6.1 BlobtypeE57elements(Blobhereafter)areusedfor
(ScaledInteger hereafter). A ScaledInteger stores an integer
storingopaqueblocksofbinarydatathatwillbeinterpretedby
“raw value,” and the actual floating point “scaled value” is
the reader.The XMLattributes for a Blob are listed in Table 6.
computed from the raw value by applying a scaling and offset.
8.3.6.2 ABlob is divided into two parts within an E57 file,
The XML attributes for a ScaledInteger are listed in Table 3.
an XML portion, documented here, and a binary section. The
8.3.3.2 The rawValue of a ScaledInteger is encoded as child
XML portion indicates the size and location of the binary
text of the XML element. The child text shall be zero or one
sectionoftheBlob.Thebinarysection,describedin9.2,stores
occurrence of the xsd:integer representation, with optional
the actual data content.
8.3.6.3 ABlob shall not contain any child elements or child
See “http://www.w3.org/TR/xmlschema-2/ text.
TABLE 2 Attributes for an Integer Type E57 Element
Attribute Required/ Default
Format Description
Name Optional Value
type required n/a string Shall be “Integer”.
63 63 63
minimum optional –2 xsd:integer The smallest value that can be encoded. Shall be in the interval [-2 ,2 -1].
63 63
maximum optional 2 – 1 xsd:integer The largest value that can be encoded. Shall be in the interval [minimum, 2 -1].
´1
E2807−11 (2019)
TABLE 3 Attributes for a ScaledInteger Type E57 Element
Attribute Required/ Default
Format Description
Name Optional Value
type required n/a string Shall be “ScaledInteger”.
minimum optional –2 xsd:integer The smallest rawValue that can be encoded. Shall
63 63
be in the interval [-2 ,2 -1].
maximum optional 2 – 1 xsd:integer The largest rawValue that can be encoded. Shall
be in the interval [minimum, 2 -1].
scale optional 1.0 xsd:double The scale value for the ScaledInteger. Shall be
non-zero.
offset optional 0.0 xsd:double The offset value for the ScaledInteger.
TABLE 4 Attributes for a Float Type E57 Element
Attribute Required/
Default Value Format Description
Name Optional
type required n/a string Shall be “Float”.
precision optional double string Shall be either “single” for 32 bit IEEE 754-1985 floating
point values, or “double” for 64 bit IEEE 754-1985 floating
point values.
minimum optional -3.402823466e+38 if precision is single, or xsd:double The smallest value that can be encoded. Shall be in the
-1.7976931348623158e+308 if precision is interval [-3.402823466e+38, 3.402823466e+38] if precision
double. is single, or [-1.7976931348623158e+308,
1.7976931348623158e+308] if precision is double.
maximum optional 3.402823466e+38 if precision is single, or xsd:double The largest value that can be encoded. Shall be in the in-
1.7976931348623158e+308 if precision is terval [minimum, 3.402823466e+38] if precision is single, or
double. [minimum, 1.7976931348623158e+308] if precision is
double.
TABLE 5 Attributes for a String Type E57 Element
Attribute Required/
Default Value Format Description
Name Optional
type required n/a string Shall be “String”.
TABLE 6 Attributes of a Blob Type E57 Element
Attribute Required/ Default
Format Description
Name Optional Value
type required n/a string Shall be “Blob”.
fileOffset required n/a xsd:integer The physical file offset of the start of the associated binary Blob section in the
E57 file. Shall be in the interval [0, 2 ).
length required n/a xsd:integer The logical length of the associated binary Blob section, in bytes. Shall be in
the interval (0, 2 ).
8.3.6.4 Discussion—TheformatoftheBlob’sdatacontentis 8.3.8 Vector Type:
not defined in this specification. A Blob may be used, for 8.3.8.1 Vector-type E57 elements (Vector hereafter) are
example,toembedanimagefromacamerawithinanE57file. used for storing ordered lists of items, known as records.
8.3.7 Structure Type: Vectors are intended to store identical or substantially identi-
8.3.7.1 Structure-type E57 elements (Structure hereafter) cally typed records. The XMLattributes for a Vector are listed
are used to represent unordered groups of potentially hetero- in Table 8.
geneous E57 elements. The XMLattributes for a Structure are 8.3.8.2 AVector shall have zero or more child elements, all
listed in Table 7. of which shall use the tag name vectorChild.
8.3.7.2 A Structure shall contain zero or more child E57 8.3.8.3 If the allowHeterogeneousChildren flag is
elements of any type.The names of the child elements shall be set to 0, then all the child elements shall have identical
unique within the Structure. structure in terms of number of children, element names,
8.3.7.3 A Structure shall not contain any child text. element types, attributes, and descendant elements recursively
TABLE 7 Attributes for a Structure Type E57 Element
Attribute Required/
Default Value Format Description
Name Optional
type required n/a string Shall be “Structure”.
´1
E2807−11 (2019)
TABLE 8 Attributes for a Vector Type E57 Element
Required/ Default
Attribute Name Format Description
Optional Value
type required n/a string Shall be “Vector”.
allowHeterogeneousChildren optional 1 xsd:integer Indicates whether the child elements may have different structure.
Set to 1 to enable, set to 0 to disable. Shall be either 0 or 1.
(that is, identical except for values), and the Vector is consid- (3)The codecs child element is a heterogeneous vector
ered to be homogeneous. If the allowHeterogeneous- of Codec Structures. Each Codec Structure specifies how a set
Childrenflagissetto1,thenthetypesofthechildelements of E57 elements within a record will be compressed in the
are unconstrained, and the Vector is considered to be hetero- associated binary section. The child elements for a Codec
geneous. Structure are listed in Table 11.
8.3.8.4 A Vector shall not contain any child text.
(a)The inputs child element is a Vector of Strings.
8.3.8.5 The element names of the child E57 elements of a Each string is a relative path name of an element in the
Vector shall be string representations of integers beginning
prototype Structure that the codec will compress. The
with“0”forthefirstdefinedchildelementandincrementingby relative pathnames shall be specified with respect to the
one for each subsequently defined child element. prototype element.
8.3.9 CompressedVector Type: (b)The bitPackCodec child element is a Structure
8.3.9.1 CompressedVector-type E57 elements (Com- with no child elements. Defining this empty Structure specifies
pressedVector hereafter) are used for storing ordered lists of thatalltheelementsdescribedbytheinputselementshallbe
identically typed items, known as records, in a compressed encoded in the binary section using the bitPackCodec. Opera-
binary format. The XML attributes for a CompressedVector- tion of the bitPackCodec is described in 9.7.
type E57 element are listed in Table 9. (4) Each terminal element in the prototype shall be listed
8.3.9.2 ACompressedVectorisdividedintotwopartswithin atmostonceasaninputtoacodec.Ifaterminalelementinthe
an E57 file, an XML portion, documented here, and a binary prototype is not listed as an input to a codec, it is implied that
section. The XML portion describes the format of the records the element is compressed by the bitPackCodec.
usingaprototypestructure,specifieswhatcompressionscheme
8.4 XML Data Hierarchy:
is used for the data, and indicates the size and location of the
8.4.1 The XML section of an E57 file shall follow a
binary section of the CompressedVector. The binary section,
particularformat.Asetofdatatypesisdefinedbythisstandard
described in 9.3, stores the actual data content.
to support the storage of 3D point data and 2D imagery in a
8.3.9.3 The child elements for a CompressedVector are
common, file-level coordinate system. These data types are
listed in Table 10. A CompressedVector shall not contain any
defined in the following sub-sections. They are constructed
child text.
from the eight fundamental data types defined in 8.3.
(1)The prototype child element specifies the structure
8.4.1.1 Discussion—An example instance of an XML data
ofthedatathatwillbestoredintheCompressedVector,aswell
hierarchy is shown in Fig. 2. A more extensive example, in
as the possible range of values that the data may take. The
XML format, is given in Appendix X1.
prototype shall be any E57 element type (with potential
sub-children) except Blob and CompressedVector. The values
8.4.2 E57Root:
of the prototype elements and sub-elements are ignored,
8.4.2.1 An E57Root Structure stores the top-level informa-
and need not be specified.
tion for the XMLsection of the file.The child elements for the
(2) Discussion—Theprototype child element describes
E57Root Structure are listed in Table 12.
the abstract requirements of a representation of the data
8.4.2.2 The root element of the XML tree shall be an
contents. The abstract requirements, in combination with an
instance of an E57Root Structure with the element name
encoding technique (provided by the codecs child element),
e57Root.
specify the format of the contents of the binary section of the
8.4.2.3 The E57 XML namespace shall be declared as the
file. The prototype will typically be a Structure with a
default namespace in the E57Root element as:
single level of child elements.Aprototype with more than
xmlns=9http://www.astm.org/COMMIT/E57/2010-e57-v1.09
one level of child elements is allowed, but not recommended.
TABLE 9 Attributes for a CompressedVector Type E57 Element
Attribute Required/ Default
Format Description
Name Optional Value
type required n/a string Shall be “CompressedVector”.
fileOffset required n/a xsd:integer The physical file offset of the start of the CompressedVector binary section in
the E57 file (an integer). Shall be in the interval (0, 2 ).
recordCount required n/a xsd:integer The number of records in the compressed binary block (an integer). Shall be
in the interval [0, 2 ).
´1
E2807−11 (2019)
TABLE 10 Child Elements for a CompressedVector Type E57 Element
Element Required/
Type Description
Name Optional
prototype Structure, Integer, Float, ScaledInteger, String, or Vector required Specifies the fields of the CompressedVector records and
their range limits.
codecs Vector of Codec Structures optional A heterogeneous Vector specifying the compression
method to be used for fields within the
CompressedVector.
TABLE 11 Child Elements for the Codec Structure
Required/
Element Name Type Description
A
Optional
inputs Vector of Strings required A Vector listing the relative path names of elements in the prototype that this codec will
compress.
bitPackCodec Structure optional* Specifies that the bitPackCodec will be used for compressing the data.
A
Optional fields with an asterisk have additional constraints. See text for details.
NOTE 1—For clarity, not all elements of the hierarchy are shown. Stacked boxes indicate Vectors or Compressed Vectors of elements.
FIG. 2An Example XML Data Hierarchy Instance
TABLE 12 Child Elements for the E57Root Structure
Required/
Element Name Type Description
Optional
formatName String required Shall contain the string “ASTM E57 3D Imaging Data File”.
guid Guid String required A globally unique identification (GUID) String for the current version of the file
(see 8.4.22).
versionMajor Integer required The major version number of the file format. Shall be 1.
versionMinor Integer required The minor version number of the file format. Shall be 0.
e57LibraryVersion String optional The version identifier for the E57 file format library that wrote the file.
creationDateTime DateTime Structure optional Date and time that the file was created.
data3D Vector of Data3D Structures optional A heterogeneous Vector of Data3D Structures for storing 3D imaging data.
images2D Vector of Image2D Structures optional A heterogeneous Vector of Image2D Structures for storing 2D images from a
camera or similar device.
coordinateMetadata CoordinateMetadata String optional Information describing the Coordinate Reference System to be used for the
file.
No other default namespaces shall be declared in child
xmlns:=99
elements of the E57Root element.
where is the namespace prefix and
8.4.2.4 All XML namespaces (with the exception of the
is a uniform resource identifier (URI). No XML namespaces
default namespace) shall be declared in the E57Root element
shall be declared in child elements of the E57Root element.
as an XML attribute in the following format:
´1
E2807−11 (2019)
8.4.2.5 Discussion—Thee57LibraryVersion String is the file-level coordinate system, the pose child element shall
determined by the developer of the low-level software or be omitted, and the identity transform shall be implied for the
library that writes E57 files, not by high-level applications that pose.
use the E57 file writing software/library. (1)Points shall be stored in the local coordinate system
8.4.3 Data3D: relative to the sensor when possible.
8.4.3.1 A Data3D Structure represents a collection of 3D (2) Discussion—This statement implies that storing the
points and any associated attributes, as well as metadata about points in the file-level coordinate system and discarding the
the collection of points. The child elements for the Data3D posetransformisprohibitedifthepointsareknowninthelocal
Structure are listed in Table 13. coordinate system, since this practice results in loss of infor-
8.4.3.2 The 3D points shall be stored either in a local mation.
coordinate system relative to the sensor or in a file-level 8.4.3.3 The originalGuids child element identifies the
coordinate system common to all the 3D data sets in an E57 dataset(orsets)fromwhichthedataoriginated(thatis,notthe
file. If the points are stored using the local coordinate system, most recent version, but the first version). If the original-
the pose child element shall be present and shall store the Guidselementispresent,thestringsstoredintheVectorshall
transform that, when applied to the 3D points, will place them contain the GUIDs that identify the source of the data in the
inthefile-levelcoordinatesystem.Ifthepointsarestoredusing Data3Dobject.TheabsenceoftheoriginalGuidselement
TABLE 13 Child Elements for the Data3D Structure
Required/
Element Name Type Description
A
Optional
guid Guid String required A globally unique identifier for the current version of the
Data3D object (see 8.4.22).
points CompressedVector of PointRecord Structures required A compressed vector of PointRecord Structures referring to
the binary data that actually stores the point data.
pose RigidBodyTransform Structure optional A rigid body transform that transforms data stored in the
local coordinate system of the points to the file-level
coordinate system.
originalGuids Vector of Guid Strings optional A Vector of globally unique identifiers identifying the data
set (or sets) from which the points in this Data3D
originated.
pointGroupingSchemes PointGroupingSchemes Structure optional The defined schemes that group points in different ways.
name String optional A user-defined name for the Data3D.
description String optional A user-defined description of the Data3D.
cartesianBounds CartesianBounds Structure optional* The bounding region (in Cartesian coordinates) of all the
points in this Data3D (in the local coordinate system of the
points).
sphericalBounds SphericalBounds Structure optional* The bounding region (in spherical coordinates) of all the
points in this Data3D (in the local coordinate system of the
points).
indexBounds IndexBounds Structure optional* The bounds of the row, column, and return number of all
the points in this Data3D.
intensityLimits IntensityLimits Structure optional* The limits for the value of signal intensity that the sensor is
capable of producing.
colorLimits ColorLimits Structure optional* The limits for the value of red, green, and blue color that
the sensor is capable of producing.
acquisitionStart DateTime Structure optional The start date and time that the data was acquired.
acquisitionEnd DateTime Structure optional The end date and time that the data was acquired.
sensorVendor String optional The name of the manufacturer for the sensor used to
collect the points in this Data3D.
sensorModel String optional The model name or number for the sensor.
sensorSerialNumber String optional The serial number for the sensor.
sensorHardwareVersion String optional The version identifier for the sensor hardware at the time of
data collection.
sensorSoftwareVersion String optional The version identifier for the software used for the data
collection.
sensorFirmwareVersion String optional The version identifier for the firmware installed in the sensor
at the time of data collection.
temperature Float optional The ambient temperature, measured at the sensor, at the
time of data collection (in degrees Celsius). Shall be$
−273.15° (absolute zero).
relativeHumidity Float optional The percentage relative humidity, measured at the sensor,
at the time of data collection. Shall be in the interval [0,
100].
atmosphericPressure Float optional The atmospheric pressure, measured at the sensor, at the
time of data collection (in Pascals). Shall be positive.
A
Optional fields with an asterisk have additional constraints. See text for details.
´1
E2807−11 (2019)
shall indicate that the Data3D object has not been modified defined and within the indexBounds element, the re-
from its original version. In this case, the original version shall turnMinimum and returnMaximum shall be defined.
be indicated by the guid element. 8.4.3.7 If theintensity element is defined for the points
8.4.3.4 If the points stored in the pointRecord element in the pointRecord, and if the minimum and maximum
are represented in Cartesian coordinates (that is, if intensity values that can be produced by the device that
cartesianX, cartesianY, and cartesianZ are obtained the intensity measurements are known, then the
defined), then the cartesianBounds element shall be intensityLimits element shall be defined.
defined. 8.4.3.8 If the colorRed, colorGreen, and color-
8.4.3.5 If the points in the pointRecord element are Blue elements are defined for the points in the
represented in spherical coordinates (that is, if pointRecord, and if the minimum and maximum color
sphericalRange, sphericalElevation, and values that can be produced by the device that obtained the
sphericalAzimuth are defined), then the spherical- color measurements are known, then the colorLimits
Bounds element shall be defined. element shall be defined.
8.4.3.6 If the rowIndex element is defined for the points 8.4.4 PointRecord:
inthepointRecord,thentheindexBoundselementshall 8.4.4.1 A PointRecord Structure stores the information for
be defined and within the indexBounds element, the row- an individual point measurement from a 3D imaging system.
Minimum and rowMaximum shall be defined. If the col- The child elements for the PointRecord Structure are listed in
umnIndex element is defined for the points in the Table 14.
pointRecord, then the indexBounds element shall be 8.4.4.2 One or more of the following elements shall be
defined and within the indexBounds element, the colum- defined:cartesianX,sphericalRange. If any elements
nMinimum and columnMaximum shall be defined. If the intheset{cartesianX,cartesianY,cartesianZ}are
returnIndex element is defined for the points in the defined, then all elements in that set shall be defined. If any
pointRecord, then the indexBounds element shall be elements in the set {sphericalRange,
TABLE 14 Child Elements for the PointRecord Structure
Required/
Element Name Type Description
A
Optional
cartesianX Float/ScaledInteger/Integer optional* The X coordinate (in meters) of the point in Cartesian coordinates.
cartesianY Float/ScaledInteger/Integer optional* The Y coordinate (in meters) of the point in Cartesian coordinates.
cartesianZ Float/ScaledInteger/Integer optional* The Z coordinate (in meters) of the point in Cartesian coordinates.
sphericalRange Float/ScaledInteger/Integer optional* The range (in meters) of points in spherical coordinates. Shall be
non-negative.
sphericalAzimuth Float/ScaledInteger optional* Azimuth angle (in radians) of point in spherical coordinates (see 5.5
for restrictions on values).
sphericalElevation Float/ScaledInteger optional* Elevation angle (in radians) of point in spherical coordinates (see
5.5 for restrictions on values).
rowIndex Integer optional The row number of point (zero-based). This is useful for data that is
stored in a regular grid. Shall be in the interval [0, 2 ).
columnIndex Integer optional The column number of point (zero-based). This is useful for data
that is stored in a regular grid. Shall be in the interval [0, 2 ).
returnCount Integer optional* Only for multi-return sensors. The total number of returns for the
pulse that this corresponds to. Shall be in the interval (0, 2 ).
returnIndex Integer optional* Only for multi-return sensors. The number of this return (zero
based). That is, 0 is the first return, 1 is the second, and so on.
Shall be in the interval [0, returnCount).
timeStamp Float/ScaledInteger/Integer optional The time (in seconds) since the start time for the data, which is
given by acquisitionStart in the parent Data3D Structure. Shall be
non-negative.
intensity Float/ScaledInteger/Integer optional Point response intensity. Unit is unspecified.
colorRed Float/ScaledInteger/Integer optional* Red color coefficient. Unit is unspecified.
colorGreen Float/ScaledInteger/Integer optional* Green color coefficient. Unit is unspecified.
colorBlue Float/ScaledInteger/Integer optional* Blue color coefficient. Unit is unspecified.
cartesianInvalidState Integer optional Indicates whether the Cartesian coordinate vector or its magnitude
is meaningful. Shall be in the interval [0, 2].
sphericalInvalidState Integer
...