Hello everyone
I've read some interesting topics about the best pointcloud formats, but it's hard to navigate as none seem to be unanimous. Some tips for finding the format that offers the most compromise would be welcome.
With my company, we are developing a 3D viewer to display and manipulate pointclouds from a lidar. Point clouds will be up to 100M points. We are looking for a good compromise between several criteria:
- a free format to use
- point reading speed (possible parallelization?)
- the existence of library or C ++ tool to read and write files
- storage size
And ideally which also meets the following optional criteria:
- a format that can be displayed on software like CloudCompare, pix4D, geoslam
- the possibility of describing an octree structure
- the existence of a library to read pointclouds in Java / Kotlin
I know that no single format will be perfect for all of these criteria At the moment we are considering using the .las, .laz, COPC, .e57, .ply formats but there are certainly others to consider. Which format do you think offers the best compromises?
Thanks for your help
Looking for a good pointcloud format
- smacl
- Global Moderator
- Posts: 1409
- Joined: Tue Jan 25, 2011 5:12 pm
- 13
- Full Name: Shane MacLaughlin
- Company Details: Atlas Computers Ltd
- Company Position Title: Managing Director
- Country: Ireland
- Linkedin Profile: Yes
- Location: Ireland
- Has thanked: 627 times
- Been thanked: 657 times
- Contact:
Re: Looking for a good pointcloud format
Depends on whether you're looking for a point cloud storage format or a point cloud data transfer format. Also whether you are OK with unstructured data or need to preserve and use structure. LAS,LAZ, E57, and PTS are data transfer formats primarily and not great as a native format as they don't support spatial queries. COPC will be a better option here but will take some work to support structure. E57 is flexible and supports structure and images but for data transfer purposes. PCL is another one to look at but hasn't seen much development in years. Parallelization is typically one you'll have to figure out for yourself and is usually workable for octree access but not so easy for octree building.
-
- I have made <0 posts
- Posts: 5
- Joined: Mon Nov 22, 2021 1:07 pm
- 2
- Full Name: Julien Chaize
- Company Details: Flyability
- Company Position Title: Indoor drone exploration
- Country: Switzerland
- Linkedin Profile: Yes
- Has thanked: 2 times
Re: Looking for a good pointcloud format
COPC seems quite good but asks to develop yourself all the tools to read and write the pointclouds with the octree in addition to being particularly long to load. e57 seemed to me to be the right option but as of this I found this format is not standardized and it does not allow defining octree structures ? I didn't really consider PCL maybe I should, is it really adapted to store 100M points ? Potree seems to be another good option but can't be read by other visualization software.smacl wrote: ↑Tue Nov 23, 2021 8:54 am Depends on whether you're looking for a point cloud storage format or a point cloud data transfer format. Also whether you are OK with unstructured data or need to preserve and use structure. LAS,LAZ, E57, and PTS are data transfer formats primarily and not great as a native format as they don't support spatial queries. COPC will be a better option here but will take some work to support structure. E57 is flexible and supports structure and images but for data transfer purposes. PCL is another one to look at but hasn't seen much development in years. Parallelization is typically one you'll have to figure out for yourself and is usually workable for octree access but not so easy for octree building.
- smacl
- Global Moderator
- Posts: 1409
- Joined: Tue Jan 25, 2011 5:12 pm
- 13
- Full Name: Shane MacLaughlin
- Company Details: Atlas Computers Ltd
- Company Position Title: Managing Director
- Country: Ireland
- Linkedin Profile: Yes
- Location: Ireland
- Has thanked: 627 times
- Been thanked: 657 times
- Contact:
Re: Looking for a good pointcloud format
The E57 reference implementation in C++ hasn't seen much development in a long time and is not the easiest to work with. E.g. you often need to get into quaternion transforms to get a structured pointcloud into a unified coordinate system. It is also slow, I ended up rewriting chunks of it for the SCC implementation when I first started using it. LASLIB is probably a better option if you don't need images or structure, easier to implement, supports compact data via LAZ and gives you a pathway to COPC via Las 1.4. The new Portree looks nice but I haven't played with it much yet. It is all open source so could be a good starting point for your own development. The new writer is fast and the viewer is great.
-
- I have made <0 posts
- Posts: 5
- Joined: Mon Nov 22, 2021 1:07 pm
- 2
- Full Name: Julien Chaize
- Company Details: Flyability
- Company Position Title: Indoor drone exploration
- Country: Switzerland
- Linkedin Profile: Yes
- Has thanked: 2 times
Re: Looking for a good pointcloud format
If you just want to store and load pointlouds, why not use PLY rather than LAS / LAZ / E57 when it seems to offer a very good size / speed / compatibility ratio? The new potree seems very good (save time by not implementing our own octree algorithm and storing it), in that case would it be a good solution to provide customers with Potree for the use of our viewer and a second LAZ type format for example so that the cloud points can be opened with other software (and which would make it possible to generate the potree)?
-
- V.I.P Member
- Posts: 916
- Joined: Tue May 11, 2021 5:36 pm
- 2
- Full Name: Adam Berta
- Company Details: InnoScan 3D Hungary Kft
- Company Position Title: unknown
- Country: Hungary
- Linkedin Profile: No
- Has thanked: 51 times
- Been thanked: 297 times
- Contact:
Re: Looking for a good pointcloud format
we are giving to our customers a potree viewer as a viewer (with images and "high res" point cloud) and a secondary fileformat based on their request, rcp,e57 ,laz or what they need and what resolution they need.julienchz wrote: ↑Tue Nov 23, 2021 1:38 pm If you just want to store and load pointlouds, why not use PLY rather than LAS / LAZ / E57 when it seems to offer a very good size / speed / compatibility ratio? The new potree seems very good (save time by not implementing our own octree algorithm and storing it), in that case would it be a good solution to provide customers with Potree for the use of our viewer and a second LAZ type format for example so that the cloud points can be opened with other software (and which would make it possible to generate the potree)?
-
- I have made <0 posts
- Posts: 1
- Joined: Mon Feb 21, 2022 1:57 pm
- 2
- Full Name: Rishab Sain
- Company Details: sevenmentor
- Company Position Title: sevenmentor
- Country: India
- Skype Name: rishab
- Linkedin Profile: No