Import trajectory file with time data

[HeddwynB]

Hi there,

I am working on data collected using the FARO Orbis in the Amazon. I am hoping to voxelise the data using AMAPvox to obtain forest structural information. As such, I want to use CC to clip the transect out of the whole point cloud. I need to also clip the trajectory file (traj.txt output by FARO Connect) to the exact same limits as the point cloud.

On importing the traj.txt file, clipping and exporting both I am finding that the time values in the trajectory file have been rounded up to the nearest integer, i.e. from 1724180873.92625 to 1724180873.00000 because, in order for them to be imported, I am classifying these time values as scalar field type on import.

In order for the time values to correspond to the point cloud times they have to be time matched, so rounding the time unmatches them. Is there a way that I can import the trajectory file to CC, including the time data, retaining the time data exactly as it is? I have tried some of the other options from the drop-down menu in the ascii file import window (where it is possible to choose attribute type for each column of the data), however none of these seem to allow to just import the data rather than use it. I had tried to import them as labels but labels aren't exported so that didn't work.

Thanks
Heddwyn

[daniel]

Interesting!

The issue is actually that the scale of the scalar values is too large to be represented accurately on 32bits... Which is the default internal format that CC uses to save memory. CC is able to automatically shift all the scalar values when they are too big, but only for some specific file formats and known scalar fields currently (such as the 'GPS time' scalar field of LAS files).

I don't think the ASCII/txt file loader is able to do that (especially since it doesn't know anything about the scalar fields the user tries to load)... But maybe it should! Or we could also use 64bits values as the memory is less a constraint these days...

Would it work for you if the values were temporarily shifted while the points are loaded in CloudCompare? (and then they will be fully restored when you save the cloud section later).

[HeddwynB]

That would work fine- as long as the specific rows in the txt file contain the same time value on exporting as they did on import, it's no problem if they change in between. The time values are only needed for the subsequent steps in order to identify scanner location for each recorded point, but that's why they can't be rounded to an integer (because they need to match).

I saw on another thread a suggestion to multiply on import for intensity values to avoid rounding- could that work for this, but by dividing instead so that values are manageable?

Thanks

[daniel]

Good point, but it's more shifting AND scaling that might be necessary (just as what is necessary for coordinates with the Global Shift & Scale values, or with LAS files with te LAS scale and LAS offset values).

I'll see what can be done in the next version.

[daniel]

In case it's not too late, you can test this new version of CloudCompare: https://www.cloudcompare.org/release/Cl ... up_x64.exe

It automatically shifts the values (silently) so you should be able to load all your time values without messing with them.

Can you test it and confirm that it works on your side? (mind that it's a test version, very fresh, and that the Python plugin doesn't work with it for instance, just in case).

[daniel]

Warning, there was a big bug in the 17th Nov version. Here's a patched version: https://www.cloudcompare.org/release/Cl ... up_x64.exe

(waiting for a more stable 2.14.alpha version to be accessible via the official website)