There are hundreds of available file formats for 3D modelling. This creates a headache where interoperability is concerned. Different scanners produce raw data in multiple formats. Different processing software is capable of accepting some of these file types, and each piece of software has different exporting capabilities.
There are a few big players like Faro, Leica and Trimble that produce both software and hardware. Others are designed for use with third-party tech. Autodesk, for example, produces no hardware but is a significant developer of point cloud software. On the other hand, most Leica hardware is only directly compatible with Leica software products. Although there is significant overlap, the market is saturated with proprietary scanners and software systems that don’t all play well together.
Users need to be careful when conducting and commissioning point cloud surveys to make sure that they receive and create files that will be compatible with their goals and purposes. With a little bit of planning, however, these issues can be overcome.
Most software systems are capable of receiving a large number of file formats and have flexible export options. There are a number of common file types that have wide interoperable utility. The ability to secure data using these formats will ensure your ability to use a number of different types of software for processing without having to resort to third-party file converters.
This article will break down the main file types and pull apart some of the true distinctions in point cloud file formats from proprietary copies.
Point cloud file types: distinctions and differences
The largest difference between point cloud file types is the use of ASCII and binary. ASCII (American Standard Code for Information Interchange) is rooted in binary (as all computer languages are) but conveys information using text. Standard ASCII represents each character as a 7-bit binary number. However, the characters are the focal point of the data. Common point cloud ASCII file types are XYZ, OBJ (with some proprietary binary exceptions), PTX (Leica) and ASC.
Binary systems store data directly in binary code. Common point cloud binary formats include FLS (Faro), PCD (point cloud library), and LAS. Several other regularly used file types are capable of both ASCII and binary formats. These include PLY, FBX. E57 store data in both binary and ASCII, pulling many of the benefits of both together in a single file type.
Each line of text within an ASCII file represents a laser return record as (x, y, z) spatial coordinates. Additional information such as colour and intensity can be included in some formats. The main benefit of ASCII files is a degree of universality in accessibility provided by the standardised text abstraction used to convey the data. ASCII files, for example, can be opened in text editors. This is one reason that ASCII file types are recommended for long-term archiving.
However, the day to day utility of this type of access is minimal, and using text to convey data comes with costs. The files are larger, contain less metadata and must be read line by line — decreasing read speeds. Binary file formats are more compact and can carry more information. It is possible to include file signatures, software information and metadata within each coordinate. It also takes less time to process and visualise binary files because they can be spatially indexed, allowing them to be read in parts rather than sequentially. However, there are greater restrictions on how binary files can be accessed.
Common point cloud file formats in detail
OBJ: first developed by Wavefront technologies, the format has been adopted by a wide range of 3D graphics applications. These include Bentley Systems, RealityCapture and Trimble. It is a simple data format that only represents 3D geometry, normals, colour and texture. It is commonly ASCII, however there are some proprietary binary versions of OBJ.
PLY: known as the polygon file format or Stanford triangle format, PLY was inspired by OBJ and purpose-built to store 3D data. PLY uses lists of nominally flat polygons to represent objects. The goal was to add extensibility capabilities and the ability to store a greater number of physical elements. The result is a file format capable of representing colour, transparency, surface normals, texture, coordinates and data confidence values. There are two versions of this file, one in ASCII and the other binary.
XYZ: is a non-standardised set of files based on Cartesian coordinates (‘x’ ‘y’ and ‘z’). XYZ is an archetypal ASCII file type, conveying data in lines of text. There are no unit standardisations for XYZ files. Although there is wide compatibility across programs for this type of file, the lack of standardisation surrounding units and specifications makes it a fundamentally faulty method of data transfer unless additional information is supplied.
PCG, RCS, RCP: are all file formats developed by Autodesk to specifically meet the demands of their software suite. RCS and RCP are newer. Autodesk products, however, are often able to convert some open formats, such as PTS into PCG files.
E57: is a vendor-neutral file format for point cloud storage. It can also be used to store images and metadata produced by laser scanners and other 3D imaging systems. It is compact and widely used. It also utilises binary code in tandem with ASCII, providing much of the accessibility of ASCII and the speed of binary. E57 can represent normals, colours and scalar field intensity.
Import/Export capabilities of common point cloud software
Bentley, Pointools:
Import: POD, OBJ, SHP, DXF, DWG, ESRI, E57, ZFS, LAZ, LAS, FLS, FWS, XYZ, PTS, PTX, PTZ, TXT, LWO, CL3, BIN, RSP, 3DD
Export: POD, PTS, XYZ
Capturing Reality, RealityCapture, :
Import: PTX, E57
Export: OBJ, PLY, XYZ, DSM
Leica, Cyclone:
Import: XYZ, PTS, PTX, LAS, E57, ZFS, DP
Export: XYZ, PTS, PTX, E57, DXF, PCI/CWF, DBX, Land XML
Faro, Scene
Import: XYZ, CVS, COR
Export: PTC, PTX, PST, XYZ, DXF, IGES, VRML, E57
Trimble, Realworks
Import: XYZ, E57, LAS, LAZ, ZFS, RSP, FLS, DP, PTX, PTS
Export: E57, ASC, LAS 1.2, LAS 1.4, LAZ, POD, PTS, PTX, TZF, BSF, KMZ, DWGM DXF, DGN, FBX, OBJ
Autodesk, ReCap:
Import: ASC, CL3, CLR, E57, FLS, FWS, ISPROJ, LAS, PCG, PTG, PTS, PTX, RDS, TXT, XYB, XYZ, ZFS, ZFPRJ, DXF, DWG
Export: RCS, RCP, PCG, PTS, E57, DXF, DWG
In addition to the listed file types, most of these systems are also capable of exporting common raster files such as JPEG or GeoTIFF. By using additional software or making edits within advanced settings, most are further capable of an even greater diversity of exports and import capabilities. This list should not be looked at as a complete catalogue of the capabilities of these software. It is an account of the file formats that they are easily capable of using or delivering.
Summary: Interoperability remains an issue, but the daunting number of file types is misleading
There are far more file extensions than there are true differences between file types. Many are simply versions of proprietary file systems that are optimised in one way or another for a particular software version. However, that does not mean that other file types will not function perfectly well as import or export formats for that software.
E57 and LAS, for example, are both file types that provide broad interoperability through enabling complex data storage in an open and standard format. Unless using Autodesk, PLY is perhaps the most common and versatile format for exporting processed point clouds if concerned about accessing them across other systems. However, if only working with one type of processing software, there is no need to stray from the proprietary versions designed for that system. The Autodesk formats (RCS and RCP), for example, are great for what they were built to do. Autodesk files can then be exported to more commonly usable formats on an as needed basis.
Binary file formats built for the purpose of storing point cloud data will most likely be superior to repurposed file types and ASCII formats. This should not, however, dissuade you from using ASCII for its greater universality and long-term storage capabilities. But, because reformatting a binary file as ASCII will likely cause a loss of organisational data, it can be advisable to keep binary and proprietary files on hand as well — only creating an ASCII copy as a future-proofed backup.
What is truly important is your ability to access your files when they are needed. This means looking at the particular requirements of the software and/or hardware that you intend on using. Think about point cloud processing and then think about specific 3D modelling software. Ideally, you should look for versatility and purpose-built efficiency. If you can find software capable of importing a large number of file types with a number of export options, you are unlikely to find yourself stuck and incapable of accessing data or extracting data for use in another system.
Third-party software can be sought out to aid in file conversions. However, this always brings a risk of data corruption. When stuck for a decision, we would recommend prioritising E57 and PLY, with a node to the simplicity of XYZ file formats and their utility for long-term storage. From an interoperability perspective these file types are hard to beat.
Tags: point clouds
