0

I'm using a simple encode and decode application for sending point cloud data as a stream using TCP. My issue can actually be reproduced just using the code from the following link:

https://pcl.readthedocs.io/en/latest/compression.html

Before encoding, I check the input with:

std::cout << "Input time (us) = " << cloud->header.stamp << std::endl;

After the decode portion, I add:

std::cout << "Output time (us) = " << output->header.stamp << std::endl;

Instead of using openNI for the incoming point cloud, I am using an Ouster tof635 lidar sensor and placing the points into a point cloud pointer to be used in the callback. I have no issues with this part.

I get a valid integer value for the cloud in the callback, but the output time after decoding is always zero. My suspicion is that the decode only copies the actual point cloud data from the stream and does not copy the header data at all.

My question is:
"Is there a function already existing in PCL that provides a way to get the header from the encoded stream (if the header is encoded at all), or will I likely need to write my own deserializing algorithm to pull the time stamp from the header of the encoded point cloud?"

I don't actually have an issue with the code I have written, but I am more looking for an answer about some insight into how to use the PCL OctreePointCloudCompression class. I see in the OctreePointCloudCompression file, there is a read and write frame header class members that are protected. This would lead me to believe these should be capturing the headers. Is it because "cloudOut" is a new point cloud and only the point data is copied to it?

Muhammad Mohsin Khan
  • 1,444
  • 7
  • 16
  • 23
notARobot
  • 61
  • 7
  • If decoded cloudOut->header.stamp is zero then it likely wasn't compressed. It is unlikely that it was compressed but was skipped when decoding back. – Öö Tiib Jan 11 '22 at 17:08
  • @ÖöTiib I'm assuming you meant to say it is unlikely it was not compressed and just skipped. Is there a way to ensure it is not skipped or will I need to encode the time stamp separate myself, send, and decode separately as well when received? – notARobot Jan 12 '22 at 14:06
  • No I meant it is unlikely it was compressed. It is most logical to keep whatever meta-information that can be needed for identifying in separate records outside of compressed data. It does not make sense to decode whole pile of data to find out some timestamp of it ... or the like ... for to figure if we want to process it more closely or not. – Öö Tiib Jan 12 '22 at 14:16

0 Answers0