CloudCompare
CloudCompare copied to clipboard
Phantom points when importing .e57 files
Describe the bug I recently observed that when exporting scans out of Leica cyclone using the .e57 format, and then importing them into CC, the total amount of points at least doubles. After a bit of investigation, these additional points could be all found to be located at 0,0,0. My assumption is that Leica uses a raster form of encoding the points and sets all invalid points to 0 (sky etc). I am not sure if their approach is "correct" within .e57 standard, or if I should make them aware of the issue, or if CC is mishandling this expected form of encoding.
How to reproduce Example file: https://polybox.ethz.ch/index.php/s/vjWkFYEiM1ldjvR
Your environment
- CC Version (or git hash/tag): v2.11.0
- OS & Version: Windows 10
- Graphics card: NVIDIA Geforce RTX 2080 Ti
That's weird indeed. We do ignore the "invalid points" when they are properly declared (there's a dedicated "invalid point array" to flag them). And when testing again with the official E57 sample files (http://www.libe57.org/data.html) I confirm that CC properly ignores the invalid points.
And the format of the E57 file you provided is not structured/gridded. It's a plain set of points (you can see the file structure under the "File structure" group next to the loaded cloud(s)).
I believe in this case this is something else. Clearly it seems we read a point at (0, 0, 0) for every normal point. As we use a 3rd party library to read E57 files, it's not easy where this issue comes from... If Leica could explain it may make things easier for us to fix (if the issue comes from our side or on the 3rd party library we use).
When looking at the order of the data, an option would indeed be that the data should be gridded (with potential 'holes' = invalid points) but when it's saved, the structure is lost, the 'invalid' information is lost, and all points (valid or not) are indeed saved as plain 3D points... There are chunks of (0, 0, 0) points here and there.
Hi, thanks for the quick response. My current assumption is that it is a Leica issue. I tried exporting the same scan as a .ptx file and again big blocks of 0 0 0 0 entries appear. As far as I understand the .ptx file format, this can't be intended.
I will contact Leica and give you an update when I hear back from them.