Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/facontidavide/cloudini.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2025-09-19 |
Dev Status | DEVELOPED |
Released | UNRELEASED |
Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
Name | Version |
---|---|
cloudini_lib | 0.7.0 |
cloudini_ros | 0.7.0 |
README
Cloudini (pronounced with Italian accent) is a pointcloud compression library.
Its main focus is speed, but it still achieves very good compression ratios.
Its main use cases are:
-
To improve the storage of datasets containing pointcloud data (being a notable example rosbags).
-
Decrease the bandwidth used when streaming pointclouds over a network.
It works seamlessly with PCL and ROS, but the main library can be compiled and used independently, if needed.
What to expect
The compression ratio is hard to predict because it depends on the way the original data is encoded.
For example, ROS pointcloud messages are extremely inefficient, because they include some “padding” in the message that, in extreme cases, may reach up to 50%.
(Yes, you heard correctly, almost 50% of that 10 Gb rosbag is useless padding).
But, in general, you may expect considerably better compression and faster encoding/decoding than ZSTD or LZ4 alone.
These are two random examples using real-world data from LiDARs.
- Channels: XYZ, Intensity, no padding
[LZ4 only] ratio: 0.77 time (usec): 2165
[ZSTD only] ratio: 0.68 time (usec): 2967
[Cloudini-LZ4] ratio: 0.56 time (usec): 1254
[Cloudini-ZSTD] ratio: 0.51 time (usec): 1576
- Channels: XYZ, intensity, ring (int16), timestamp (double), with padding
[LZ4 only] ratio: 0.31 time (usec): 2866
[ZSTD only] ratio: 0.24 time (usec): 3423
[Cloudini-LZ4] ratio: 0.16 time (usec): 2210
[Cloudini-ZSTD] ratio: 0.14 time (usec): 2758
If you are a ROS user, you can test the compression ratio and speed yourself,
running the application rosbag_benchmark
on any rosbag containing a sensor_msgs::msg::PointCloud2
topic.
How to test it yourself
There is a pre-compiled Linux AppImage that can be downloaded in the release page
Alternatively, you can test the obtainable compression ratio in your browser here: https://cloudini.netlify.app/
NOTE: your data will not be uploaded to the cloud. The application runs 100% inside your browser.
How it works
The algorithm contains two steps:
The encoding is lossy for floating point channels (typically the X, Y, Z channels) and lossless for RGBA and integer channels.
Now, I know that when you read the word “lossy” you may think about grainy JPEGS images. Don’t.
The encoder applies a quantization using a resolution provided by the user.
Typical LiDARs have an accuracy/noise in the order of +/- 1 cm. Therefore, using a resolution of 1 mm (+/- 0.5 mm max quantization error) is usually a very conservative option.
It should also be noted that this two-step compression strategy has a negative overhead, i.e. it is actually faster than using LZ4 or ZSTD alone.
Compile instructions
Some dependencies are downloaded automatically using CPM. To avoid downloading them again when your rebuild your project, I suggest setting CPM_SOURCE_CACHE as described here.
To build the main library (cloudini_lib
)
cmake -B build/release -S cloudini_lib -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --parallel
ROS compilation
File truncated at 100 lines see the full file