Pointcloud compression: crowd sourcing benchmark

1

Hi,

as everyone working with 3D LIDARs is aware of, the serialized sensor_msgs::PointCloud2 messages are very large. This affects:

  • the size of the rosbags.
  • the ability to visualize them remotely, for instance using RViz running on a different PC.
  • the time to load them insize a certain visualization tool.

People having this problem may start having a look here:

I am currently working (mostly for fun) on a different codec that preserves the number of points and their order (no voxelization).

Would you be interested to help me benchmarking this on a variety of rosbags?

Since these rosbag might contain sensitive information and I guess many people will not be happy sharing them, I will provide a precompiled App that you can run on your computer, and that will upload the results, such as encoding /decoding speed and compression ratio.

No personal information will be recorded.

What do you think?

11 Likes
2

Great initiative, count me in!

3

I would be happy to help with benchmarking!

4

Just out of curiosity: is this a hand-rolled codec or one found in research? Pointcloud compression is something i started thinking about recently, but I haven’t had time to look at the literature/state-of-the-art solutions.

5

Hand rolled. In my preliminary result I get a 0.35 compression (1/3 the original size).

I tried some “known” algorithms, but results were generally worse.
I guess those algorithm deal with generic datasets, whilst I am leveraging some specific characteristics of data generated by LIDARs.

2 Likes
6

Hello, I would love to help with benchmarking!

7

r2b_storage_sequence r2b_cafe_sequence

r2b_hallway_sequence r2b_hideaway_sequence

@facontidavide open source ROSBags w/ XT32 LIDAR available for compression testing.

Thanks

1 Like
8

I’d be willing to participate. We have a lot of various sonar->point cloud data as well stereo pair data. Do you think you could provide the source for your benchmarking app?

9

Hey, I’d like to help as well.
Would be especially interesting for us, because we stream pointclouds from a drone for live visualization.

10

Code and pre-compiled app can be found here:

Please report issues there and contact me if you are happy sharing the rosbag directly.

Please send your results to davide.faconti@gmail.com or sumit them as issues on Github itself :heart:

11

In the repo, you say it is lossy compression. But when the number and order of points is preserved, where is the loss? Precision of the floats?

12

In the repo, you say it is lossy compression. But when the number and order of points is preserved, where is the loss? Precision of the floats?

Correct: since commercial LIDARs have an accuracy/noise in the order of 1 cm. a quantization of 1mm should not affect significantly the results.

Note that the lossless is just a banal ZSTD compression, nothing interesting there, just a reference to compare it to “something”.

1 Like
15

That’s basically what Google Draco is doing, isn’t it? With configurable bits/channel.

16

EDITED: Draco uses a KDTree based algorithm to do the quantization. This will reorder the points.

There is a draco::POINT_CLOUD_SEQUENTIAL_ENCODING option, but it doesn’t seem to apply any compression (unless I am doing something wrong).

My focus is on preserving the number of points and the order, because some algorithms (including LOAM and derivatives) rely on that.

So, in short, the algorithm is different.

17

@facontidavide open source ROSBags w/ XT32 LIDAR available for compression testing.

Got these preliminary results:

Topic: /pandar_xt_32_0_lidar
  Count: 100
  Lossless Average time: 10215 usec
  Lossless Average ratio: 0.473528
  Lossy Average time: 7876 usec
  Lossy Average ratio: 0.196945
1 Like
18

I updated the code to include more compression options. Sample of the results using the BPearl:

Topic: /lidars/bpearl_back_left
Count: 908
[LZ4] ratio: 0.780 time (usec): 5490
[ZSTD] ratio: 0.646 time (usec): 9007
[Lossy + LZ4] ratio: 0.360 time (usec): 3066
[Lossy + ZSTD] ratio: 0.319 time (usec): 4863

Or data provide by @ggrigor

Topic: /pandar_xt_32_0_lidar
Count: 100
[LZ4] ratio: 0.529 time (usec): 6234
[ZSTD] ratio: 0.474 time (usec): 12846
[Lossy + LZ4] ratio: 0.230 time (usec): 7763
[Lossy + ZSTD] ratio: 0.197 time (usec): 10432

The results look very promising!
If anybody tries this out, please submit your results here:

19

Since Draco has been mentioned by a few people, yopu might want to look at the benchmark (notice compression time)

The original PCL point type is XYZI with zero padding. Draco quantization is 16 bits, while mine is 1mm (not sure how to compare them).

  [LZ4]          ratio: 0.79 time (usec): 3242
  [ZSTD]         ratio: 0.66 time (usec): 5229
  [Draco]        ratio: 0.29 time (usec): 35320

  [Lossy only]   ratio: 0.37 time (usec): 1420
  [Lossy + LZ4]  ratio: 0.36 time (usec): 1723
  [Lossy + ZSTD] ratio: 0.32 time (usec): 2385

Draco is great, but sloooow… good for long term storage but not for streaming over wifi (one of my intended uses).

2 Likes
20

Draco has a parameter for controlling the encoding speed (I guess at the expense of compression ratio).

21

I know, but it is not up to me to compare all the possible algorithms, against all possible rosbags, using all possible parameters :sweat_smile:

I released the code, people can play with it

22

@facontidavide This is how it all starts!

One day you are just messing around with different compression techniques and the next day you to run a website that benchmarks different hardware and software combos against different datasets and posts the results to a publicly visible leader board. :wink:

Maybe some sort of grand “ROS Leaderboard,” like the COCO leaderboard, is something that should exist. When we were writing the RMW reports I suggested that someone should make “Consumer Reports” but for ROS packages.

I might need a second intern for the summer. :melting_face:

2 Likes