Exporting different formats results in different coordinates

[c3kkos]

I have a small slice taken out from a bigger point cloud ("X" tool) -nothing strange or exotic-

exporting ("SAVE") the object in .e57 AND .pts results in a different placement once the two files are opened again (regardless the SW used to open it. even Cloudcompare itself shows this behaviour, hence, the issue IS in the data)

i'll attach 2 images showing that.

The PTS position IS the correct one.

Having scalar fields, having global shifts and/or normals or other "extra" data does not affect this.

.pts is created with only the x,y,z values, comma separated. Values are in millimeters. here's a line:

37401.24218750,-4620.99169922,1456.31518555

[daniel]

Can you test again with version the 2.14.beta version?

We have fixed a few things with regard to E57 files export, especially when the sensor pose is not 'direct' but has a mirrored axis.

[c3kkos]

Done, no luck.

The .e57 is not aligned and it is also scaled down by 0.001.
Since .e57 is in binary format it is not possible for me to check where the scale is applied, either in the file's data or at import time

[daniel]

Can you share the PTS file with me then? (admin@cloudcompare.org)

[c3kkos]

Sure!

I'll send ASAP. Thank you.

[daniel]

So the cloud is interesting because it has large coordinates but also a quite large scale / extents. I realized that while the 'Global Shift & Scale' dialog was letting the user define a 'global scale', this value was never stored nor applied by the code in charge of loading files!

For now, I disabled the 'global scale' field, so as to avoid confusion. And when I load the PTS files and save them as E57 files, I end up with the same coordinates. Can you test on your side? (with the new 2.14.beta version online).

I still wonder how the scale of the cloud ended to be different for your E57 files, but I'll wait for your test results first.

[c3kkos]

Ok, i'll test it quickly.

Can i use the link in homepage?

https://www.cloudcompare.org/release/Cl ... bin_x64.7z

? is it updated?

[daniel]

Normally both the archive and the installer versions should be up-to-date.

[c3kkos]

Ah! Again this error!

I think there's something CC "remembers" at .7z package creation (maybe the recents files list)

since i work onto a corporate notebook with limited permissions, if CC fires up trying to "probe" some paths i don't have permission to look into, i find myself in this deadlock situation

please note: the previous 2.14 .7z runs OK. I had this issue months ago, then it disappeared, and showed once again now

[daniel]

Can you try after moving it to something like C:/Temp ?