PCL Developers blog

Nizar Sallem

project:Leica Geosystems Code Sprint

About me

Currently, I am a PhD student at the LAAS-CNRS in Toulouse, FRANCE.

The aim of my research is to develop and integrate a vision platform for robotics manipulator. It is a transversal project that covers all the processiong pipeline from data acquisition to object model reconstruction.

Recent status updates

Experimenting with half
Saturday, September 21, 2013

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:

X Y Z intensity
0.004745 1.044357 -2.114578 0.006226
0.004745 1.046707 -2.112625 0.006714
0.004745 1.049637 -2.111862 0.006409
0 0 0 0.500000
0.004776 1.057053 -2.113419 0.006088
0.004776 1.060349 -2.113327 0.006683
0.004807 1.064133 -2.114212 0.007370
0.004807 1.068130 -2.115555 0.007156
0.004807 1.072067 -2.116714 0.006760
0.004837 1.075150 -2.116165 0.006790

Using half precision float:

X Y Z intensity
0.00474167 1.04395 -2.11328 0.00622559
0.00474167 1.0459 -2.11133 0.00671387
0.00474167 1.04883 -2.11133 0.00640869
0 0 0 0.5
0.00477219 1.05664 -2.11328 0.00608444
0.00477219 1.05957 -2.11328 0.00667953
0.00480652 1.06348 -2.11328 0.00737
0.00480652 1.06738 -2.11523 0.00715256
0.00480652 1.07129 -2.11523 0.00675964
0.00483322 1.07422 -2.11523 0.00678635

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.

Enhencing LZF + JP2K reading/writing time
Friday, September 20, 2013

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
indoor.ptx 10997760 208685.6 16995.2
outdoor.ptx 8062080 134010.5 X

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.

Performance analysis
Friday, September 06, 2013

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
indoor.ptx 480M 210M 169M 134M
outdoor.ptx 212M 124M 57M X

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
indoor.ptx 10997760 293994.1 1371.2 7123.7 19347.5
outdoor.ptx 8062080 134010.5 726.1 2765.3 X

Encoding times are reported to the graph below for a better visualization.

Improved compression and writing speed
Thursday, August 29, 2013

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.

Leica proper data structures
Thursday, May 02, 2013

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
    1. ascii
    2. binary
    3. 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:

  1. image_offset
  2. image_encoding
  3. image_step

Finally, adapted point types:

  1. PointXYZI without extra padding;
  2. PointXYZIRGB specific to leica contains both color and intensity data.