E57 Issues from CC

[Charlesw]

For years now, we have noticed there is some level irregularity to the E57 files produced by CloudCompare.

Until recently, the irregularities were minor and did not affect our usage of the E57 files. We are now getting much heavier into automated processes across different programs and noticed that the irregularities are now causing issues with compatibility.

Some of the "irregularities" I mention are losing the ability to utilize "bubble" views or scanner positions after saving an E57 from CloudCompare.

I want to clarify that as far as a typical point cloud goes, the E57 files do work and keep their coloring and data points, but the 360 images do not seem to be fully compatible with the standard. We are having issues specifically with keeping the bubble views on scanner positions.

This "irregularity" can be reproduced by taking a scan such as an FLS or RTC scan, exporting as an E57 from either FARO Scene or Register360 or Cyclone. Call this "baseline.e57". We can then bring "baseline.e57" into CC and immediately save it out as a new e57, call it "cc.e57".

Then cache each of the two files individually in Recap. "basleine.e57" will continue to have each scans respective position with the bubble view imagery, while the "cc.e57" file will not.

This can also be confirmed by dumping the e57 xml data for each file as well and manually comparing the xml files of each. There are multiple differences in the files after being save by CC, however the biggest one causing concern is the loss of scanner position and respective image data.

Any thoughts on how to resolve or things we can try on our end to fix would be greatly appreciated. We have tried versions from 2.9 to current and still have this issue regardless of the version of CC. I am active and happy to help troubleshoot or provide any information that is helpful to the troubleshooting process.

Respectfully,

[WargodHernandez]

Looking at how the e57 format works in CC this isn't surprising.

from E57Filter.cpp from CC
The function essentially works on point cloud entities and does not look for any metadata that was originally imported. The file importer saves this metadata as tree structure items basically just a generic objects that are given names which relay the information in the file like

Code: Select all

rowMaximum [INTEGER: 1073]

to indicate an e57 node named rowMaximum with type INTEGER and a value of 1073.

But during save the system isn't looking for additional tree objects to save which aren't clouds, so it would never find any of that meta data. as a result all meta data that can not be obtained by the cloud cannot be saved, and is faked instead
example of creating fake meta data:

Code: Select all

// Save a dummy string for coordinate system.
/// Really should be a valid WKT string identifying the coordinate reference system (CRS).
root.set("coordinateMetadata", e57::StringNode(imf, "")); // Sets an empty string
		
// Create creationDateTime structure
/// Path name: "/creationDateTime
e57::StructureNode creationDateTime = e57::StructureNode(imf);
creationDateTime.set("dateTimeValue", e57::FloatNode(imf, 0.0)); //Just sets creation datetime to 0
creationDateTime.set("isAtomicClockReferenced", e57::IntegerNode(imf,0));
root.set("creationDateTime", creationDateTime);

In essence the e57 support is minimal.
If someone was willing to take on the work, I think it could be improved by storing the metadata as actual metadata (rather than tree objects) on the CC object during load and then saving it back out when saving.