Five formats cover almost everything you will meet in robotics and mapping. They differ less in what they can store than in which ecosystem expects them.
| Format | Origin | Typical use | Encoding | Attributes | Reads it |
|---|---|---|---|---|---|
| PCD | Point Cloud Library (PCL) | Robotics, SLAM output, ROS pipelines | ASCII, binary, binary compressed | Arbitrary named fields: intensity, ring, RGB, timestamp | PCL tools, CloudCompare, RViz, browser viewers |
| PLY | Stanford, general 3D | Handoff to graphics, meshing, 3D printing | ASCII and binary | Vertex properties including colour and normals, plus faces | Blender, MeshLab, CloudCompare, most 3D software |
| LAS | ASPRS, airborne lidar survey | Survey, GIS, aerial and mobile mapping | Binary only, versioned point record formats | Intensity, return number, classification, GPS time, optional RGB | QGIS, ArcGIS, PDAL, LAStools, CloudCompare |
| LAZ | LASzip compression of LAS | Same as LAS, when file size matters | Binary, lossless compression | Identical to LAS | Same tooling as LAS in most modern versions |
| E57 | ASTM E2807 standard | Terrestrial laser scanning, interoperability between vendors | Binary container with XML metadata | Multiple scans, per-scan pose, intensity, colour, imagery | CloudCompare, most TLS vendor software, libE57 |
The Point Cloud Library format. Its header declares fields, sizes and types, so an intensity or ring channel travels with the data instead of being implied. If your pipeline is ROS or PCL, this is the default and there is rarely a reason to fight it.
More on PCDA general 3D format that stores vertices with arbitrary properties and, optionally, faces. It is the pragmatic choice when the cloud leaves robotics and enters a graphics or meshing tool, because everything from Blender to MeshLab reads it.
The ASPRS standard for lidar survey data, with fixed point record formats covering intensity, return number, classification and GPS time. LAZ is the same content under lossless LASzip compression, which is why most GIS work ships LAZ.
Defined by ASTM E2807 as a vendor-neutral container for 3D imaging data. Its distinguishing feature is structure: multiple scans with their own poses, plus imagery and metadata, inside one file. Common in terrestrial laser scanning, rare in ROS.
LidarFlow runs return output.pcd and map.ply. For anything else, the free point cloud converter handles PCD, PLY, XYZ and CSV in the browser, and CloudCompare or PDAL cover the survey formats on the desktop.
Sources: the PCL PCD specification, the ASPRS LAS specification, and libE57 on ASTM E2807.
PCD is the Point Cloud Library format and declares a named field layout per point, which suits LiDAR attributes such as intensity or ring. PLY is a general 3D format from Stanford that stores vertices and optional faces, so mesh and graphics software reads it far more widely.
They hold the same data. LAZ is the losslessly compressed encoding of LAS, typically several times smaller on disk, and most survey and GIS software reads it directly. Use LAZ unless a specific tool in your chain only accepts LAS.
CloudCompare reads all of these, including PCD, PLY, LAS/LAZ and E57. Blender is happiest with PLY. QGIS works with LAS and LAZ through its point cloud support, not with PCD.
PCD and PLY from every run, plus the SLAM trajectory as a text file and a metadata file describing the run settings.