The ASTM E57 File Format for 3D Imaging Data Exchange

Transcription

1 The ASTM E57 File Format for 3D Imaging Data Exchange Image courtesy Intelisum, Inc. Daniel Huber The Robotics Institute Carnegie Mellon University Member of the ASTM E57 Committee on 3D Imaging Systems Sub-committee on Data Interoperability

2 What have we done? Over the past 5 years, we have developed an open standard for 3D imaging system data exchange. The E57 Format n n n Store and exchange: n n n 3D data (point clouds, range images) Associated images Meta-data to support downstream processing General purpose terrestrial, aerial, mobile Extendable Who is we? ASTM E57 Committee on 3D Imaging Systems, Sub-committee on Data Interoperability (E57.04) 2

3 What is Three Dimensional Imaging? Laser Scanners Triangulation 3

4 Uses of 3D Imaging: Modeling and Visualization 4

5 Uses of 3D Imaging: Robotics 5

6 Uses of 3D Imaging: Civil Engineering Quality assurance Infrastructure inspection Reverse engineering 6

7 How Do People Store 3D Data Today? Proprietary Formats n PTS n PTX n DXF Ad-Hoc Formats n PLY n homebrew Domain Specific Formats n LAS 7

8 What s the Problem with the Status Quo? Proprietary Formats n Data exchange combinatorial explosion n Loss of information when converting n Long-term stability Ad-Hoc Formats n Storage efficiency n Limited documentation n Variations in implementations n Limited use for data exchange Domain Specific Formats n Limited applicability across domains 8

9 How Does the E57 Format Address These Problems? Proprietary Formats n Data exchange combinatorial explosion n Loss of information when converting n Long-term stability Ad-Hoc Formats n Storage efficiency n Limited documentation n Variations in implementations n Limited use for data exchange Domain Specific Formats n Limited applicability across domains The E57 Format n Single, common format n Reduced need to convert n Standardized definition n Binary storage and data compression n Thorough, extensive documentation n Reference implementation n Widespread use n General purpose, with domainspecific extendibility 9

10 The Road to the E57 Standard Specify requirements Design the format Write standard Vote on standard Encourage adoption Develop qualification process Begin version 2 Specify requirements Develop supporting software Testing Develop additional tools 10

11 Guiding Principles n Reliable interoperability Data transferable between vendors n Open Freely available, well documented, unrestricted, and vendor neutral n Low barrier for adoption Development cost kept to a minimum n Minimalist design Keep design as simple as possible n Extensibility Allow new capabilities in the future without breaking core functionality 11

12 Information to Store in an E57 File n Unorganized point clouds or gridded data n Multiple return data n Multiple data sets (but in one coordinate system) n Associated images and pose information n Intended for data exchange and archiving n Not intended as a working format. n Limit meta-information and derived information Image courtesy Intelisum, Inc. 12

13 Secondary Goals n Support for internationalization n Support for extremely large file sizes n Self-describing e.g., should not require external lookup tables n Computer readable i.e., allow automatic verification of syntax n Speed and storage efficient smaller and faster than ASCII n Memory efficient Allow microcontroller implementation n LAS compatibility Superset of LAS functionality 13

14 Common file format types E57 Design Basics Fixed sized fields and records Flexible, self-documenting n Rigid, but compact and efficient n Flexible, but inefficient and more verbose E57 Format A hybrid of the two n Flexible, self-documenting framework n Fixed sized, user-defined records for large, repeating structures (e.g., point clouds) 14

15 E57 Hierarchical File Structure points points (PointRecord) points (PointRecord) (PointRecord) data3d (Data3D) bar bar pose (RigidBodyTransform) e57root (E57Root) pointgroupingschemes (PointGroupingSchemes) pose (RigidBodyTransform) groupingbyline (GroupingByLine) groups groups (LineGroupRecord) groups (LineGroupRecord) (LineGroupRecord) images2d (Image2D) bar bar visualreferencerepresentation (VisualReferenceRepresentation) sphericalrepresentation (SphericalRepresentation) 15

16 Parts of an E57 File Header Binary section (points) Binary section (points) Binary section (image) XML section 16

17 Header Binary section (points) Binary section (points) Logical data stream Error Checking Binary section (image) XML section 1020 byte logical block 4 byte checksum Physical data stream 17

18 XML Hierarchy The E57 Element Types Terminal types Integer Float ScaledInteger Non-terminal types Structure Vector CompressedVector String Blob 18

19 Example point record prototype: Point Data Storage 19

20 Binary Encoding Blobs n Opaque encoding n Images, user-defined data CompressedVectors n Point data storage, user-defined data n Data organized into chunks for semi-random access n Index packets, data packets n Data serialization using codecs (bit packing) 20

21 Image Storage n Images stored in blobs (jpg or png format) n Image distortion removed n Mask to handle non-rectangular images n Four camera models n Visual reference n Pinhole n Spherical n Cylindrical y image x image principal point imaging plane scene center of projection z y x focal length 21

22 Extensions n Extend format to add new capabilities Example: LAS extension n Define new element types Example las:edgeofflightline n Support backward and limited forward compatibility 22

23 Implementation The libe57 software n Reference implementation is critical to rapid adoption n Goals n Cross-platform n Open source n Foundation API Comprehensive n Simple API Easy to use, designed for common use cases 23

24 Ongoing Work n Finishing development and testing of libe57 n Working with companies to help with adoption of standard n Beginning to work on Version 2 of the standard n Advanced compression n Representing uncertainty n Mobile scanning n Improved representation of intensity 24

25 Supporting Partners n ASTM International n Bechtel Corporation n Carnahan-Proctor and Cross, Inc. n Carnegie Mellon University Robotics Institute n Course Six, Inc. n FARO Technologies Inc. n InteliSum, Inc. n Inovx, Inc. n Kubit, GmbH n Leica Geosystems n LiDAR News n Optech, Inc. n Pointools, Inc. n Quantapoint, Inc. n Riegl Laser Measurement Systems GmbH n Trimble Navigation Limited n University of California Davis n Zoller+Fröhlich GmbH and more every week 25

26 Summary E57 format A standard format for storing data from 3D imaging systems libe57 A free reference implementation of the E57 standard ( Interested in helping out? Contact me: Daniel Huber ([email protected]) 26

27 Comparison with LAS LAS E57 Domain Aerial sensing General purpose Point record fields Fixed several templates User-selectable Data field bit-resolution Fixed User-selectable Data geometry Lines Lines, Gridded, Unorganized Extensions No Yes Max data size 4.2E9 records 1.8E19 bytes 27