4. 点云数据格式详解:PCD、PLY、LAS、BIN 怎么选?

点云数据格式,说白了就是点云在硬盘上怎么「躺」着。你想想看,一个激光雷达扫一圈下来,少说几十万个点,每个点带着 XYZ 坐标、强度、时间戳、甚至 RGB 颜色。怎么存才又快又省空间?这就是格式要解决的问题。

我最早接触点云时,拿到一堆 .bin 文件,完全不知道里面是什么结构。后来踩了不少坑,才把主流格式摸清楚。今天咱们就把 PCD、PLY、LAS、BIN 这四种格式从头到尾拆一遍。

核心观点:没有「最好」的格式,只有「最合适」的场景。选格式前,先问自己三个问题——数据要给人看还是给机器读?要不要保留颜色?文件大小有没有限制?

点云文件格式知识体系 点云数据格式 PCD PLY LAS BIN PCD 特性 • 纯文本/二进制双模式 • 头部信息自描述 • PCL 原生格式 PLY 特性 • 支持顶点+面片 • 可含 RGB 颜色 • 3D 建模常用 LAS 特性 • 行业标准格式 • 支持分类/时间戳 • 航测/测绘专用 BIN 特性 • 纯二进制裸数据 • 无头部信息 • 加载速度最快 选择建议 可视化 → PCD/PLY | 测绘 → LAS | 高性能 → BIN

4.1 PCD 格式:PCL 的亲儿子

PCD 是 Point Cloud Library(PCL)的原生格式。我个人习惯在 PCL 项目里直接用 .pcd,省去格式转换的麻烦。

头部信息长这样:

# .PCD v0.7 - Point Cloud Data file format
VERSION 0.7
FIELDS x y z intensity
SIZE 4 4 4 4
TYPE F F F F
COUNT 1 1 1 1
WIDTH 100000
HEIGHT 1
VIEWPOINT 0 0 0 1 0 0 0
POINTS 100000
DATA ascii

头部字段不多,但每个都有讲究:

  • FIELDS:定义每个点的属性名称。常见的有 x, y, z, intensity, rgb, normal_x 等。
  • SIZE:每个字段占的字节数。float 是 4 字节,double 是 8 字节。
  • TYPE:数据类型。F 表示 float,I 表示 signed int,U 表示 unsigned int。
  • WIDTH / HEIGHT:如果 HEIGHT=1,说明是无序点云;否则是有序点云(像深度图那样)。
  • POINTS:总点数。WIDTH × HEIGHT 必须等于 POINTS。
  • DATA:数据存储模式。ascii 或 binary。

我的经验:调试阶段用 ascii 模式,肉眼能看数据对不对。正式部署一定要切 binary 模式,文件体积能缩小 60% 以上,加载速度也快得多。

4.2 PLY 格式:3D 建模界的通用语

PLY(Polygon File Format)最初由斯坦福大学设计,后来成了 3D 建模和计算机图形学的通用格式。它最大的特点是——不仅能存点,还能存三角面片。

头部示例:

ply
format ascii 1.0
comment Created by XYZ Scanner
element vertex 50000
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
element face 0
property list uchar int vertex_indices
end_header

PLY 头部有几个关键点:

  • element:定义数据块类型。vertex 是顶点,face 是面片。
  • property:每个元素的属性。支持 float, double, uchar, int 等类型。
  • property list:变长列表,常用于存储多边形顶点索引。
  • end_header:头部结束标记,后面就是纯数据了。

PLY 也支持 binary 模式,有 little endian 和 big endian 两种变体。我记得有一次从某设备导出的 PLY 文件,在 Windows 上读出来全是乱码——后来发现是字节序没对齐。

避坑指南:PLY 的 binary 模式有两种字节序。跨平台使用时,一定要检查文件头部的 format binary_little_endian 1.0 或 format binary_big_endian 1.0。我曾经因为没注意这个,浪费了整整一个下午。

4.3 LAS 格式:测绘行业的硬通货

LAS 是美国摄影测量与遥感学会(ASPRS)制定的标准格式。做航测、地形建模、林业调查的朋友,基本绕不开它。

头部结构(简化版):

File Signature:      LASF
File Source ID:      0
Global Encoding:     1
Project ID:          ...
Version Major:       1
Version Minor:       4
System Identifier:   Leica ALS80
Generating Software: ...
File Creation Day:   150
File Creation Year:  2024
Header Size:         375
Offset to point data: 375
Number of variable length records: 3
Point Data Format ID: 6
Point Data Record Length: 30
Number of point records: 2500000
Number of points by return: ...
X Scale Factor:       0.01
Y Scale Factor:       0.01
Z Scale Factor:       0.01
X Offset:            500000.00
Y Offset:            4000000.00
Z Offset:            100.00
Max X / Min X:       ...
Max Y / Min Y:       ...
Max Z / Min Z:       ...

LAS 头部信息非常丰富,我挑几个重点说:

  • Scale Factor + Offset:这是 LAS 的精髓。点云坐标用整数存储,通过缩放和平移转成真实地理坐标。既保证了精度,又压缩了存储空间。
  • Point Data Format ID:定义了每个点的字段结构。ID 0 只有 XYZ,ID 6 开始支持 RGB、NIR(近红外)、时间戳等。
  • Variable Length Records:可变长记录区,可以存波形信息、分类规则、元数据等。

为什么 LAS 这么「重」?因为它要承载的信息太多了。一个标准的 LAS 1.4 文件,头部就有 375 字节,再加上可变长记录、点数据记录,结构非常严谨。但也正因为严谨,它成了测绘行业的法定格式。

4.4 BIN 格式:简单粗暴,但快

BIN 格式其实没有「标准」。它就是一个二进制文件,里面按固定字节数连续存储每个点的数据。没有头部,没有元数据,就是裸数据。

常见的 BIN 结构:

// 每个点占 16 字节(4 个 float)
// 顺序:x, y, z, intensity
// 连续存储,无分隔符

Offset 0:     float x
Offset 4:     float y
Offset 8:     float z
Offset 12:    float intensity
Offset 16:    float x (下一个点)
...

BIN 格式的优缺点非常极端:

特性 说明
加载速度 极快。直接 mmap 映射到内存,零解析开销。
文件体积 最小。没有头部冗余,纯数据。
可读性 极差。没有头部,不知道里面存了什么。
跨平台 差。字节序、字段顺序全靠约定。

什么时候用 BIN?我一般在实时性要求极高的场景用 BIN——比如自动驾驶的在线感知模块,每秒要处理 10 帧点云,每帧 100 万个点。这时候用 PCD 或 LAS 解析开销太大,BIN 直接内存映射,延迟能控制在 1ms 以内。

4.5 四种格式横向对比

为了方便你选型,我整理了一张对比表:

维度 PCD PLY LAS BIN
头部信息 自描述,简洁 自描述,中等 自描述,丰富 无
支持颜色 是(RGB) 是(RGB) 是(RGB+NIR) 需约定
支持面片 否 是 否 否
地理坐标 需额外处理 需额外处理 原生支持 需额外处理
加载速度 中等 中等 较慢 极快
文件大小 中等 中等 较大 最小
主要场景 PCL 开发 3D 建模 测绘/航测 高性能系统

4.6 如何选择合适的格式?

我总结了一个简单的决策流程,你照着走就行:

  1. 是不是做测绘? → 是 → 选 LAS。别犹豫,这是行业标准。
  2. 是不是用 PCL 开发? → 是 → 选 PCD。省去转换麻烦。
  3. 要不要存三角面片? → 是 → 选 PLY。它是唯一支持面片的格式。
  4. 对加载速度要求极高? → 是 → 选 BIN。但记得自己维护一份元数据。
  5. 以上都不是? → 选 PCD。通用性最好,工具支持最全。

最后提醒一句:不管你选什么格式,一定要在项目初期就定下来。我见过太多项目,中途换格式导致所有数据要重新转换,那叫一个痛苦。格式选型就像选地基——后面改起来,代价太大了。