第2章：点云数据格式解析——PCD、BIN、PLY、LAS，以及XYZI/XYZRGB结构
大家好，我是你们的老朋友。上一章我们聊了激光雷达的基本原理，知道了点云是怎么来的。但点云数据拿到手，打开一看——一堆数字，怎么读？怎么存？不同厂家给的文件后缀还不一样，.pcd、.bin、.ply、.las……
说实话，我刚开始接触这行的时候，也被这些格式搞得头大。有一次项目紧急，客户扔过来一个.bin文件，我直接用文本编辑器打开，满屏乱码，还以为文件坏了。后来才知道，二进制格式不能这么玩。嗯，今天咱们就把这些格式彻底捋清楚。
2.1 点云数据到底长什么样？
先别管格式，咱们先想一个问题：一个激光点，需要记录哪些信息？
- 位置（XYZ）：这是必须的。x、y、z三个坐标，告诉你这个点在哪。
- 强度（Intensity）：也就是反射回来的信号强弱。不同材质反射率不同，强度值能帮你区分路面、树木、车辆。
- 颜色（RGB）：有些激光雷达能同时采集颜色信息，或者通过相机融合得到。有颜色的话，点云看起来更直观。
- 其他属性：比如时间戳、回波次数、扫描线编号等。这些在高级应用中会用到。
所以，最基本的点云数据结构就是 XYZI（位置+强度）和 XYZRGB（位置+颜色）。
核心概念：点云本质上是一个 N×D 的矩阵，N 是点的数量，D 是每个点的维度（3、4 或更多）。
2.2 四大主流格式详解
2.2.1 PCD 格式（Point Cloud Data）
PCD 是 PCL（Point Cloud Library）库的亲儿子。我个人习惯用 PCL 做点云处理，所以 PCD 是我最常用的格式。
PCD 文件分为两部分：文件头 和 数据体。
文件头是纯文本，告诉你这个文件有多少点、每个点有哪些字段、数据是二进制还是 ASCII。举个例子：
# .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 就告诉你了，每个点有4个字段：x、y、z、强度。后面 SIZE 4 表示每个字段占4字节（float32）。
数据体可以是 ASCII 文本，也可以是二进制。ASCII 方便查看，但文件大、读写慢。二进制反之。
我的建议：开发调试阶段用 ASCII，方便肉眼检查。正式部署用二进制，速度快、省空间。
2.2.2 BIN 格式（二进制裸数据）
BIN 格式没有标准文件头，说白了就是一堆二进制数直接堆在一起。你想想看，如果你不知道每个点有几个字段、每个字段占多少字节，这文件根本没法读。
我曾经踩过一个坑：客户给的 .bin 文件，说是 XYZI 格式，每个字段4字节。我按这个解析，结果点云全是乱的。后来一问，人家用的是 double（8字节）存的坐标。嗯，从那以后我拿到 .bin 文件第一件事就是确认数据协议。
常见的 .bin 格式（比如 KITTI 数据集）是这样的：
// 每个点占 16 字节：4个float32，分别是 x, y, z, intensity
// 文件总字节数 / 16 = 点的数量
float x = *(float*)(data + i*16);
float y = *(float*)(data + i*16 + 4);
float z = *(float*)(data + i*16 + 8);
float intensity = *(float*)(data + i*16 + 12);
解析代码其实很简单，但前提是你得知道协议。没有协议，.bin 就是一堆乱码。
注意：BIN 格式没有自我描述能力。拿到 .bin 文件，一定要配套拿到数据格式说明，否则就是盲人摸象。
2.2.3 PLY 格式（Polygon File Format）
PLY 格式最早是为三维模型设计的，但后来也被广泛用于点云。它的特点是既能存点云，也能存网格（三角形面片）。
PLY 也有文件头和数据体。文件头比 PCD 更灵活，可以自定义字段。比如：
ply
format ascii 1.0
element vertex 50000
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
property float intensity
end_header
你看，这里既有颜色（RGB），又有强度（intensity）。这在 PCD 里需要自己定义，但 PLY 原生支持。
PLY 的缺点是文件体积偏大，尤其是 ASCII 格式。二进制 PLY 会好一些，但解析起来比 PCD 稍微复杂一点。
2.2.4 LAS 格式（LASer）
LAS 是测绘和地理信息领域的标准格式。如果你做自动驾驶，可能接触不多。但做高精地图、城市建模的朋友，一定很熟悉。
LAS 格式非常规范，有严格的公共文件头、变长记录和点数据记录。它支持的信息非常丰富：
- XYZ 坐标（通常用整数存储，配合缩放因子和偏移量）
- 强度
- 回波次数（第几次回波、总回波次数）
- 分类（地面、植被、建筑等）
- 颜色
- GPS 时间
LAS 格式的解析库很成熟，比如 libLAS、PDAL。我个人建议不要自己手写解析器，直接用现成的库，省心。
2.3 点云数据结构：XYZI vs XYZRGB
咱们用表格对比一下这两种最常见的结构：
| 结构 | 字段 | 典型应用场景 | 数据量（每点） |
|---|---|---|---|
| XYZI | x, y, z, intensity | 自动驾驶感知、障碍物检测 | 16 字节（4×float32） |
| XYZRGB | x, y, z, r, g, b | 视觉融合、三维重建、可视化 | 24 字节（3×float32 + 3×uint8） |
为什么自动驾驶常用 XYZI？因为强度信息对区分路面和车道线非常有用。而 XYZRGB 更多用于展示和建模，比如用相机给点云上色，看起来更真实。
当然，也有混合结构，比如 XYZIRGB，既有强度又有颜色。这种结构每点占 28 字节左右，数据量会大一些。
2.4 知识体系总览
下面这张图，是我自己梳理的点云格式知识体系。你看一眼，心里就有谱了。
2.5 实战建议
说了这么多，到底怎么选？我个人的经验是这样的：
- 做算法开发：用 PCD，配合 PCL 库，读写方便，生态好。
- 处理公开数据集：KITTI 用 .bin，nuScenes 用 .bin 或 .pcd，按官方说明来。
- 做三维建模或可视化：用 PLY，支持颜色，展示效果好。
- 做高精地图或测绘：用 LAS，行业标准，信息完整。
一个小技巧：如果你不确定文件是什么格式，用 file 命令（Linux/Mac）或者用十六进制编辑器打开看文件头。PCD 开头是 # .PCD，PLY 开头是 ply，LAS 开头有 LASF 标识。BIN 嘛……嗯，只能靠猜了。
好了，这一章的内容就到这里。格式这东西，说白了就是约定。你知道了约定，就能读懂数据。下一章咱们开始动手，用代码读写这些格式，到时候你就知道，其实没那么复杂。