search

PointCloudLibrary / pcl

Point Cloud Library (PCL)
https://pointclouds.org/
Other
9.93k stars 4.61k forks source link

PCD format: does it support offsets and scaling? #2335

Closed jgrn307 closed 6 years ago

jgrn307 commented 6 years ago

We're having some issues with overflow/precision in PCD files, and were wondering if the PCD format supports offsets or scaling factors applied to the xyz coordinates? PDAL's PCD writers allow for e.g. subtract_minimum and scale_x, scale_y, scale_z (https://pdal.io/stages/writers.pcd.html#writers-pcd) but it appears there is no way to store this info in the PCD file, no? If not, is this something there is a plan to implement down the road?

Although a LAStools post, this is a relevant read that concerns these issues (and proposes possible fixes, but only if the PCD format can retain the info): https://groups.google.com/forum/#!topic/lastools/oK81EEr7W3Y

taketwo commented 6 years ago

it appears there is no way to store this info in the PCD file, no? If not, is this something there is a plan to implement down the road?

If I understand correctly, offset/scaling is needed when the serializing high precision values into low precision values. In PCL, however, point clouds are always represented using single-precision floats, both during processing in memory and when stored in PCDs. Therefore, there is no reason to have offset/scaling in PCD format. Even if we had it, PCL would not be able to meaningfully load such a file, because after applying offset/scaling the values will overflow PCL's single-precision coordinates.

jgrn307 commented 6 years ago

We ran into an issue using a PCL-based algorithm "treeseg": https://github.com/apburt/treeseg that was solved by the offset issue.

We have a point cloud that basically represents ~ 30m x 30m and need about .0001m precision for our work (terrestrial laser scanner). However, we are using CA Teale Albers projection -- this is in meter units, but in our are (California) the coordinates are very large numbers (even though the total range of our data is only 30m).

When we pruned the min x,y,z, all of the PCL algorithms started working as expected. However, we need our final outputs in "true" coordinates, which requires adding-back the coordinates. The las format has support for these offset/scaling factors -- even if most of your algorithms don't "natively" support these factors, by keeping them in the header, they could be used down the line. For now, we have to store the offset is a separate file.

I think it would be a worthy addition!

taketwo commented 6 years ago

I understand your use-case but I think that PCD is simply not the right file format for you. Why not keeping your data in LAS files?

I think it would be a worthy addition!

As I wrote, PCL works with single-precision and stores single-precision. Offset/scaling are not supported by any of PCL algorithms, why would we make this a part of our native storage format?

That being said, PCD format supports comments in the header (lines starting with #). You may use that to store any additional information that you need in your application.

jgrn307 commented 6 years ago

Hi: sorry I'm not being clear -- the algorithm we are using is heavily PCL-based, so I was assuming we need to stick to PCD format for going from one step to another. Is there an easy read-to-PCL cloud from las available?

The comments in the header, tho, may be the right solution -- is there support in PCDWriter for add a comment line when writing out a cloud?

taketwo commented 6 years ago

Is there an easy read-to-PCL cloud from las available?

I don't work with LAS files, but here is the first link which I goodled with "las pcd": https://github.com/murtiad/las2pcd.

is there support in PCDWriter for add a comment line when writing out a cloud?

No, but you can use something like sed to update the file after it was written.