点云序列压缩格式对比

在工作中有存储点云数据的需求,因此对不同格式的点云压缩率做了比较。

目录

在自动驾驶数据中,点云几乎总是单个传感器数据量最大的一部分,原因是它经常由数十万个点构成,而每个点的精度要求又都很高,造成了单帧点云的数据量就很大,因此一个好的点云压缩算法,尤其是能处理点云序列的算法对节省存储和传输开销是很有用的。

测试对象

本文主要对比几种不同数据格式压缩点云序列的压缩率和速度,涉及的格式如下:

  • tar:最基本的文件打包格式之一,配合强大的压缩算法(本文使用LZMA)即可以获得有效的点云压缩。
  • npz:Numpy所使用的数据打包格式,其本质上就是特殊格式的zip文件。
  • pcd:这个格式是,在点云处理领域很常用的库 —— PCL,所使用的点云格式。它也支持对二进制存储的点云进行压缩。
  • laz:LAS数据这个数据格式是美国摄影测量Photogrammetry遥感Remote Sensing学会发布的,算是一个行业标准,它定义了几种标准的点云字段列表。而LAZ是LAS的开源替代,并且支持了点云的压缩。
  • drc:这个格式是Google的Draco几何压缩库所使用的格式,也被应用与GLTF等文件格式中。它的主要使用对象是网格Mesh数据,但也支持点云的无损和有损压缩。

目前据我所知,没有针对时序点云设计的存储和压缩格式。有一些格式支持深度图的压缩,但是点云并不是总能无损地转变成深度图,因此在本文对比中没有考虑。

时序点云压缩目前没有有效的算法,这可能是在两帧点云的点中进行匹配并不是一个简单的问题,因此delta encoding等手段并不能方便地应用于点云数据。

测试使用的数据是从Carla仿真器中采集的连100帧点云数据,这些数据原始的存储格式是numpy的npy格式(该格式没有任何数据压缩),总大小接近100M。原始点云包含三百万个点,其坐标范围为:[67.726, 123.920, -4.946] ~ [264.771, 318.595, 17.516]

测试结果

测试结果如下表:

压缩时间(s)压缩后大小(M)压缩率
tar.xz (基线)12.59516.25217.22
numpy npz4.25426.37427.94
las + tar.xz4.87710.08510.68
draco (q=14) + tar.xz6.0048.7019.22
draco (q=10) + tar.xz4.3145.0325.33
pcl + tar.xz19.43423.67325.08
las aggregated0.4059.95310.54
draco (q=14) aggregated37.7128.8139.34
draco (q=10) aggregated38.1275.5355.86
las aggregated (w/pose)0.3789.86210.45
draco (q=14) aggregated w/pose38.2767.2057.63
draco (q=10) aggregated w/pose38.9664.2454.50

其中aggregated表示多帧点云是通过直接叠加到一起进行压缩,aggregated w/pose表示多帧点云经过运动补偿变换后叠加在一起进行压缩。可以看到压缩率最好的格式是draco + 适当量化 + 运动补偿,而兼顾速度与压缩率的格式是laz + 运动补偿。这个试验结果也说明,把多帧点云转移到同一个坐标系中其实是一个有效的手段,因为对于静态场景来说,在同一个世界坐标系中不同帧的点云对静态物体的采样应该是很接近的,这就给提高压缩率带来了可能。

此外在进行代码开发的过程中还有一点其他体会:LAZ格式对点云压缩的支持较好,对一些常用的点属性有清晰的定义和支持,但是它对自定义的点属性支持不够灵活,并且不支持有损压缩;Draco格式虽然是针对网格数据设计的,但是它支持自定义的点属性,并且它使用量化技术对浮点数进行压缩,能够有效地进一步降低点云压缩后的大小。由于传感器本身的噪声,对点云数据进行一定程度的有损压缩实际上是完全可以接受的,但是如果有损压缩的点云会被用于机器学习的模型,那么量化带来的一些数据上的噪声规律是有可能对模型性能产生一定影响的,需要留意。

Draco量化

另外,由于Draco对数值进行了量化Quantization,那么我们也来分析一下量化带来的精度损失。我统计了使用Draco库在不同压缩Compression水平Level和量化位数q(指浮点数量化到大概剩下多少bit)的设置下,所得到的点云的体积以及质量损失。其变化关系如后三图所示,其中需要指出的是在我的测试中,将压缩水平设置为1和5最后的到的点云质量非常接近,在图中几乎无法分辨。

压缩率与压缩设置的关系

从这张雅座率与压缩设置的关系图中可看出,在不同的压缩水平下,压缩后点云的体积都基本与量化位数成正比,并且趋势很一致。而区别点在于,在量化位数较高时,压缩水平为0(无损)和10的误差比压缩水平为1或5要低;而在量化位数较低时,压缩水平为0则显著比其他压缩水平得到的点云要大。

压缩前后产生的点云误差均值与量化程度的关系

上面是一张压缩误差均值与量化程度的关系图,其中不同颜色的折线段是不同量化程度下的压缩前后点云相对误差的均值(注意图中q越小,量化程度越大),而对应颜色的阴影区域则代表范围。

从图中中可以看出,无损压缩(压缩水平为0)的点云误差显著低于有损压缩,这是意料之内的。但是令我比较惊讶的是,无损压缩的点云同样会受到量化比特数的影响,也就是说在无损压缩的过程中同样有量化操作的发生。不过可以看到,即使是q=5的情况下,无损压缩后点云的平均误差也是显著低于有损压缩的。另外对于有损压缩来说,虽然不同的压缩方式在压缩误差上是有区别的,但是他们都是在同一个数量级下,因此在上图中差别并不明显。

压缩前后产生的点云误差95分位与量化程度的关系

之前那张图是在对数坐标系下进行比较的,难以看出压缩水平设置对最后点云误差的影响。上面这张图则是一张线性尺度的压缩误差分位值与量化程度的关系图。这张图中折线代表的是压缩前后点云误差的最大值与最小值。这张图则直接反映出有损压缩模式下,各个压缩级别实际上出来的点云质量是相似的。


对时序点云压缩的探索就告一段落了,本次试验实际上是去年年中做的,但是这个文章过了一年才写出来也是很拖沓了。。但,还是希望能看到学界或者业界有针对时序点云的压缩格式设计,这对无人驾驶和机器人相关的数据集都是很有价值的。本文所用相关代码请参见我的Github仓库

使用 Hugo 构建
主题 StackedJimmy 设计,Jacob 修改