 上周在一篇共享的开源的方案中我们介绍了理论的研究部分，处于好奇，本人决定亲自测试一下该开源的方案，虽然了解PCL的同学应该都知道，该开源库中也有关于点云的压缩和解压的研究，效果也很好。在之前的博客中，我们有过介绍，将来如果有机会更加可以继续深入解析其中的理论以及代码部分，这里我们首先来学习一下这一优秀的开源代码。首先介绍一下这篇文章《Real-Time Spatio-Temporal LiDAR Point Cloud Compression》 本文提出了一个新的系统，可以有效地压缩一系列点云。利用点云帧序列中的空间和时间冗余的思想。首先在点云序列中识别关键帧，然后通过迭代平面拟合对关键帧进行空间编码。然后我们利用连续点云在物理空间中有大量重叠的事实，因此空间编码的数据可以（重新）用于对时间流进行编码。利用空间编码数据进行时间编码，不仅提高了压缩率，而且避免了冗余计算，大大提高了压缩速度。实验表明，我们的压缩系统达到了40×90的压缩率，明显高于MPEG的LiDAR点云压缩标准，同时保持了较高的端到端应用精度。同时，我们的压缩系统的压缩速度与目前激光雷达的点云生成速率相匹配，并优于现有的压缩系统，实现了实时点云传输。 具体文章可查看： github地址: https://github.com/horizon-research/Real-Time-Spatio-Temporal-LiDAR-Point-Cloud-Compression由于在测试时，编译有点小问题，所以这里对源代码进行了一些重构，在代码结构上进行了CMake重构，将头文件和源文件进行了部分修改。 整理后的代码地址： https://github.com/yaoli1992/LiDAR-Point-Cloud-Compression 测试内容介绍 原始的代码给出了data 和src两个文件，其中data是给的测试数据，代码是在src中，并且使用的Makefile编译。  根据文件的命名，可以一目了然的知道每一个文件是什么作用，代码上看起来是比较简单明了的，这里面也给出了六个测试代码，分别是对单帧点云数据和多帧的点云数据的压缩和解压以及完整的测试，具体如下： * 'pcc_encoder'：对单帧点云进行编码的编码器。 * 'pcc-decoder'：解码单帧点云的解码器。 * 'pcc_test'：这是一个完整的测试代码。 * 'pcc_stream_encoder'：对多帧的点云数据流进行编码的编码器。 * 'pcc_stream_decoder'：解码多帧的点云数据流解码器。 * 'pcc_stream_test'：这是多帧数据流完整的测试。 使用了opencv4和boost库函数，如果你的电脑端正好有这两个库，那么你就直接make吧，可以直接编译和使用，但是由于本人的电脑只有opencv3.4以及boost1.58，修改后在编译的时候仍然没有成功，所以我决定将代码重新构建一下，使用cmake进行编译，并且为了测试压缩前后点云数据的质量，我已经引入了点云库PCL，对点云进行一些转换和可视化， 同时将代码的公共部分编译成一个.so的动态链接库，这样我们就可以很好的整合这些代码了，这里可以先看一下，本人在构建完成后的文件夹有哪些，如图：  每个文件夹的说明如下： build:主要是我们的编译文件，以及生成的可执行文件。 data:是原始的数据文件，这里没有做改变 include:主要存放原始文件中的头文件 lib:文件主要是保存在接下来的编译中生成的.so动态链接库 src:主要用于存放原始文件的实现函数，主要是.cpp文件。 pcl_test：是我临时增加的一个基于点云库的bin文件转到pcd文件 test:主要是实验单帧和多帧点云数据压缩和解压的测试代码。 CmakeLists.txt：增加cmake文件。 重新构建的代码刚刚分享在了我的github地址上，所以有需要的直接下载后，使用cmake的方式编译代码即可， 编译完成后生成动态链接库，以及可执行的二进制文件  接下来我们就可以根据提供的数据和生成的二进制文件进行一些测试，在测试之前，可以根据我提供的pcl_test文件生成一个pcl_bin2pcd的可执行文件，并使使用pcl_viewer进行可视化查看原始数据和原始点的数量以及加载这些点云需要的时长。如图所示：  为了更好的对比压缩前后点云数据所占空间的大小，这里我们首先查看一下点云的属性，查看其大小：  然后我们使用，编译生成的可执行文件进行点云压缩处理 ./pcc_encoder --path ../data --file 0000000000.bin -p 0.18 -y 0.45 -f binary -l 4 -t 0.5 --out frame.tar.gz 命令行来对0000000000.bin进行压缩。解压后生成一个frame.tar.gz，我们查看此时这一帧点云数据的大小。  对比一下文件大小可以看出压缩后的点云确实很小啊，从2M压缩到了50.6KB，节省了空间，但是会不会影响我们的点云质量呢？这里我们再解压出来看看。使用命令 ./pcc_decoder -p 0.18 -y 0.45 -f binary -l 4 --file frame.tar.gz 此时解压出来的bin文件的大小，如图所示：  解压后从大小上好像比之前的小了一些，那说明是有一些损失，这里我们直接使用工具将其转化后可视化的结果大致查看一下结果如下  总结 从点的个数和点云的加载时间上也减少了不少，有损失，但是可视化出来的结果，看不出有什么影响点云质量。同时在作者的论文中也从三个方面，提出了三个评估指标来验证这里的压缩是没有影响到点云的质量。分别从以下三个方面的应用验证了压缩的有效性：
使用三个评估指标：未压缩点云的压缩率、FPS的压缩速度和应用程序结果的精确度。 所谓前人栽树，后人乘凉，再次感谢作者开源了代码。 资源 三维点云论文及相关应用分享 【点云论文速读】基于激光雷达的里程计及3D点云地图中的定位方法 3D-MiniNet: 从点云中学习2D表示以实现快速有效的3D LIDAR语义分割（2020） PCL中outofcore模块---基于核外八叉树的大规模点云的显示 更多文章可查看：点云学习历史文章大汇总 SLAM及AR相关分享 |
|
|
