Leica Geosystems is sponsoring the development of open source efficient compression mechanisms for organized and unorganized 3D point cloud data. The ultimate goal is to achieve as much compression as possible, and process a few million points per second on a standard laptop. In addition different lossy vs lossless compression techniques will be analyzed and compared.
For a complete list of all the present and past PCL code sprints please visit http://www.pointclouds.org/blog.
Click on any of the links below to find out more about our team of PCL developers that are participating in the sprint:
Today I started experimenting with half (http://half.sourceforge.net/) a C++ header-only library to provide an IEEE 754 conformant 16-bit half-precision.
The mixed results are that I ended up with fairly lighter binary files (50% lighter as expected) but there is a loss of precision when I convert it back to ASSCII.
The file outdoor.ptx when encoded to binary is just 62M vs 124M.
The conversion back to ASCII is not so great though (because of rounding probably). I am exposing 10 lines from the orginal ASCII file and the one generated after converting back the binary file.
Original ASCII file:
Using half precision float:
As you can notice there are differences starting at 6th decimal position. It could be worth trying to use different rounding options to see if it helps.
Through the usage of OpenMP parallelism instructions I achieved better results for ASCII reading and LZF + J2K PTX file encoding. Here I show the improved results.
Experimental protocol is very similar to the one used earlier : 10 runs in a row of leica_ascii2binary tool with LZF + JP2K encoding option. Each time we measure the ASCII file reading time and the writing.
|File||Nb of points||ASCII||LZF + JP2K|
Compared ASCII reading times with and without OpenMP for both files are shown on the figure below. You can notice the 10 seconds gap achieved through usage of OpenMP.
Compared LZF + J2K encoding times with and without OpenMP are shown next. From the graphics you can notice the gain of almost 3 seconds during the encoding.
This part of the project is purely analytical where I compare compression rate/speed of several compression methods.
Below are compression rates on the test dataset. Tests were run on a personal laptop powered by a i7 CPU M 620 @ 2.67GHz. To be fair, I only compare loseless compression rates.
|File||ASCII||binary||LZF||LZF + JP2K|
For PTX files with RGB data the joint LZF + JP2K compression is the most efficient.
The image below summarizes graphically files size with reference to encoding used.
Main issue though is that the JP2K compression is not fast: it takes almost 12s on my laptop to perform for the indoor.ptx dataset but I believe it is acceptable given the gain in file size. I tested the conversion time taken by the image_to_j2k command line tool to convert the ASCII PGM image generated by copying the RGB data into a J2K image and it is roughly the same amount of time needed to perform the conversion. This indicates that its an OpenJPEG intrinsic issue.
The table below lists ASCII reading times and then writing speed for the given dataset. Times indicated are the average reading/writing speed for 10 runs expressed in ms.
Tests were run by invoking command line tool leica_ascii2binary each time with the appropriate flag:
- 0 binary conversion;
- 1 binary LZF compression;
- 2 binary LZF + JP2K compression.
|File||Nb of points||ASCII||binary||LZF||LZF + JP2K|
Encoding times are reported to the graph below for a better visualization.
I implemented two compression methods :
- LZF mainly a rewrite from PCDWriter::writeBinaryCompressed method
- JP2K + LZF method which uses LZF to compress XYZ and intensity information while JP2K is used to compress RGB data.
This choice is motivated by the need of a comparison basis and also by the fact that RGB data won’t be compressed efficiently by LZF since it is a dictionary based algorithm.
As for JP2K, it is an improvement of JPEG it is a wavelet based compression algorithm which claims higher compression rates with almost no data loss.
The implementation I am using is the one provided by OpenJPEG. As version 1.3 seems to be the most common I picked it to run the tests.
I spent the few past weeks trying to improve the data read/write speed by using leica centric point types which lead to better results.
In the next weeks I will be essentially running tests and trying to enhance compression performances.
For now loseless compression ratio is 0.27 using LZF + JP2K, ASCII data reading is 0.021 ms/point while LZF + JP2K data writing speed is 0.001 ms/point.
Basically the approach fits a set of geometric primitives approximating the input point cloud. Although higher order proxies such as spheres or cylinders could be considered we focus here on planes. First, most man made environments are essentially piecewise planar. Second, curved objects allow piecewise linear approximations at the cost of a higher number of proxies.
Principles of our approach : i) Estimation of an oriented plane is done via a weighted PCA incorporating closeness of points and and local complexity using curvature information obtained from the eigenvalues of the PCA. We define an input point to be inlier whenever its distance is less then some threshold, it is visible on the positive side of the plane and the angle between the line of sight and the normal is bounded by some threshold. ii) A proxy consists of an oriented 3D plane and a connected subset of inliers encoding the spatial extent. Here two methods will be tested. First a RANSAC based approach and second a region growing approach.
Currently I am implementing the region growing extraction. First results and images will be reported next week.
We expect a very high compression with the proposed approach. Since a single plane can approximate a high number of points. Of course the compression is lossy and one cannot expect recovering the original point cloud. I further believe that the integration of colour information can be done without to much overhead.
The reading speed is slower than the aim of the project. My aim is to speed it up by using proper data types.
First, we propose a new file structure for PTX where the coordinates can be separated from the image data. Header contains three extra fields:
- data_type: indicates whether it is
- binary compressed
- image_offset: if image data is to be separated from the coordinates than it starts at position in the file. image_offset should be set to -1 if no RGB data is stored.
- image_encoding: indicates how the image is stored # bgr8 indicates a binary pixel map # jp2k indicates a JPEG2000 compressed data image
Second, leica::PointCloud class inherits from pcl::PointCloud with an additional transformation matrix.
Third, sensor_msgs::PTXCloudData inherits from sensor_msgs::PointCloud2 with extra fields:
Finally, adapted point types:
- PointXYZI without extra padding;
- PointXYZIRGB specific to leica contains both color and intensity data.
Created class PTXReader to read content of leica PTX ASCII file and store data into a PCL cloud. Reader is pushed into https://github.com/nizar-sallem/pcl leica branch.