4. 点云数据格式详解:PCD、PLY、LAS、BIN 怎么选?
点云数据格式,说白了就是点云在硬盘上怎么「躺」着。你想想看,一个激光雷达扫一圈下来,少说几十万个点,每个点带着 XYZ 坐标、强度、时间戳、甚至 RGB 颜色。怎么存才又快又省空间?这就是格式要解决的问题。
我最早接触点云时,拿到一堆 .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 如何选择合适的格式?
我总结了一个简单的决策流程,你照着走就行:
- 是不是做测绘? → 是 → 选 LAS。别犹豫,这是行业标准。
- 是不是用 PCL 开发? → 是 → 选 PCD。省去转换麻烦。
- 要不要存三角面片? → 是 → 选 PLY。它是唯一支持面片的格式。
- 对加载速度要求极高? → 是 → 选 BIN。但记得自己维护一份元数据。
- 以上都不是? → 选 PCD。通用性最好,工具支持最全。
最后提醒一句:不管你选什么格式,一定要在项目初期就定下来。我见过太多项目,中途换格式导致所有数据要重新转换,那叫一个痛苦。格式选型就像选地基——后面改起来,代价太大了。