Hi,
Thank you for the nice software. I'm comparing .asc format clouds, received from underground mine environment. I'm not sure whether I should do the cloud registration or not - the "C2C distance" results seem to be different depending on this (See Attached Fig1). Each scanning is performed from one station and already georeferenced according to the mine coordinate system.
The "C2C distance" results seem to vary also depending on which one of the two clouds is selected for "Reference" and which one as "Compared".
The apparent deformation seems to increase together with the distance from the scanner. I guess this due to the accuracy, which of course decreases the further the data is received (Fig2).
And finally - do you think it is possible to distinguish mm-scale deformations from a data received from one station only, such as in this case? The apparent C2C distances seem to be several cm's which is not likely to occur. So, I wonder where do the apparent distances come from? I guess this might originate from the registration issue mentioned above. Locally, I'm sure blind spots etc. have an effect as well.
As you've probably noticed I'm still quite a beginner with CloudCompare. Thank you for your help and time!
C2C distance - cloud registration
C2C distance - cloud registration
- Attachments
-
- Fig2.JPG (55.51 KiB) Viewed 20205 times
-
- Fig1.JPG (91.02 KiB) Viewed 20205 times
Re: C2C distance - cloud registration
Ah ah, a lot of questions!
About registration: it really depends on how much you trust the initial registration. Normally, it shouldn't do much harm to refine the registration with the ICP algorithm if you use the appropriate parameters. Especially the 'overlap' parameter that should be realistic (as the 2 clouds probably don't fully overlap). It's also better to use the widest and densest cloud as 'reference' (if the 2 clouds are different in this regard).
About distances computation: the C2C distances are quite crude so you won't be able to achieve mm-scale deformation detection with it. It's not super robust to the local cloud density (so it's probably also a factor of why you have larger distances far away from the scanner). To limit this effect, you have to use once again the densest cloud as reference, and also to use a 'local model'. The other issue with this algorithm is that it will always compute a distance for every point, potentially by pairing it with a far away point in the other cloud. You can limit this effect by setting a 'max distance', but once again this is not robust to holes in the clouds, etc.
To refine your analysis, I would definitely advise you to look at the M3C2 algorithm: https://www.cloudcompare.org/doc/wiki/i ... 2_(plugin)
It's a little bit more harder to tame, but much more powerful (with signed distances, a statistical approach, holes/non overlapping parts management, etc.). With a tunnel cloud, the biggest challenge might be to compute properly oriented normals. Don't hesitate to share some clouds with me (admin@cloudcompare.org) if you want me to look at them and to try to find how to use M3C2 on them.
About registration: it really depends on how much you trust the initial registration. Normally, it shouldn't do much harm to refine the registration with the ICP algorithm if you use the appropriate parameters. Especially the 'overlap' parameter that should be realistic (as the 2 clouds probably don't fully overlap). It's also better to use the widest and densest cloud as 'reference' (if the 2 clouds are different in this regard).
About distances computation: the C2C distances are quite crude so you won't be able to achieve mm-scale deformation detection with it. It's not super robust to the local cloud density (so it's probably also a factor of why you have larger distances far away from the scanner). To limit this effect, you have to use once again the densest cloud as reference, and also to use a 'local model'. The other issue with this algorithm is that it will always compute a distance for every point, potentially by pairing it with a far away point in the other cloud. You can limit this effect by setting a 'max distance', but once again this is not robust to holes in the clouds, etc.
To refine your analysis, I would definitely advise you to look at the M3C2 algorithm: https://www.cloudcompare.org/doc/wiki/i ... 2_(plugin)
It's a little bit more harder to tame, but much more powerful (with signed distances, a statistical approach, holes/non overlapping parts management, etc.). With a tunnel cloud, the biggest challenge might be to compute properly oriented normals. Don't hesitate to share some clouds with me (admin@cloudcompare.org) if you want me to look at them and to try to find how to use M3C2 on them.
Daniel, CloudCompare admin
Re: C2C distance - cloud registration
Thank You very much Daniel - I will have a look at the M3C2 algorithm. Kind Regards, Joonas