Automatic offset limit

[macsurveyr]

Hi,

I have quite a few data sets that have UTM coordinates in the range that exceed 500000.00,4390000.00

When opening any file with coordinates in that range, CloudCompare offers to offset.

[17:19:11] [PLYFilter::loadFile] Cloud (vertices) has been recentered! Translation: (-506228.12,-4394878.00,-1641.74)

It appears that coordinates that exceed 4000000.00 and probably 1000000.00 exceed some limit and are truncated or rounded to the nearest 0.5 unit - in this case meters. Probably goes unnoticed for many data sets but for a building in those coordinates it is pretty obvious.

Thanks for all your wonderful work.

Tom

[daniel]

Indeed CloudCompare works with 32 bits floats which have a relatively limited accuracy (this is why if we detect coordinates above 1000000 we warn the user).

What bugs me is that we precisely do this to avoid losing 'short scale' accuracy ... So you shouldn't get this round off effect. Moreover the PLY format handles double precision (64 bits) so it should also be ok.

What is the software that has generated the PLY file? Can you send me a sample file so I can investigate this effect more deeply? (cloudcompare [at] danielgm.net)

[macsurveyr]

Daniel,

Here is a sparse cloud of the building. No faces, but it does show the issue.

https://www.dropbox.com/s/tqggizeqawzls ... sparse.ply

Let me know if you need anything else.

Tom

[daniel]

That was quick : this ply file has been saved with 'float' (32 bits) coordinates (you can read the header with any text editor).

So if the coordinates are this big, it means that they are already 'implicitly' truncated (due to the lack of resolution of the float representation). CC saves ply files with 'double' (64 bits) coordinates if a large shift must be applied (typically the inverse of the one applied on input).

But of course if the file is already truncated when loaded, there's nothing CC can do ... Which software generated this file? It should use 'double' precision instead of 'float' when exporting PLY files.

[macsurveyr]

That also was quick. The PLY file was made by PhotoScan and I have already reported it as a bug.

Thank you for your expertise.

Tom

[macsurveyr]

Hmmm,

On second thought. Should 1,000,000 actually exceed the float data type?

I will check an ascii version of the PLY and see if the coordinates themselves are being truncated or rounded, but if not, shouldn't the property float support 2^32 values?

Tom

[daniel]

Indeed you can put very large numbers in a float (up to 3.4*10^38) but they have a 'relative' resolution (the bigger the number is, the less accurate its float representation will be).

For more information take look at http://en.wikipedia.org/wiki/Floating_point.

To simplify this, your number will be decomposed as m*2^e where e is coded on 7 bits and m on 23 bits (other bits are reserved for sign, etc.).

• If you have a number between 0 and 1, then e = 0 and you have 23 bits to represent exactly your number (i.e. ~0.0000001 accuracy).
• If you have a number between 1.05 and 2 million, then e = 21 and you have 23 bits to represent a portion of 2^21 = 2097152. So the smallest interval between two consecutive digits is about 0,25!

This is why when you represent coordinates above 1 million with only 32 bits floats, you have a maximum resolution of about 0.1 meters, and this decreases rapidly (0.25 for 2M, 0.5 for 4M, etc.). This is just a quick example, these are not the exact numbers but you've got the idea.

[macsurveyr]

Daniel,

Here are two links to PLY files.

https://www.dropbox.com/s/dhqtb1vhtrgbv ... binary.ply
https://www.dropbox.com/s/tqggizeqawzls ... sparse.ply

They are supposed have identical data - the first one is a binary PLY file and the second is an ascii version of the exact same file.

Open them in CloudCompare and apply offset to all. The ascii version imports just fine and the binary does not.

Tom

[daniel]

That's logical as the ASCII version has no such limit as 32 or 64 bits coding. Digits are written in a human readable way (you can edit the file with any text editor). So if PhotScan can output ASCII PLY files then you can use this format instead of the 32 bits binary one (however the ASCII version is much bigger).

CloudCompare will always take the most information he can from any PLY file. But if this PLY file is saved with 32 bits float values (your "binary' version here), then your dataset is already 'corrupted'. If you want a 'working' binary PLY file, then you need a file saved with 64 bits double values.