compare clouds for deformation-analysis

[kayillerwhale]

Hey,
i've got a problem with the following situation: for my bachelor-thesis i scanned a wall of a river 1 time per hour from the same position. starting at 6 o'clock in the morning with 22 degrees Celsius , i ended up at 13 o'clock with a temperature of 35 degrees. i need to check if there are any possible deformations in the wall related to the temperature. as a reference i also scanned a (fixed) house facade which is located behind the wall. the idea is, that there shouldn't be any distances/deformations when comparing 2 pointclouds (let's take the biggest timeframe: 6h & 13h) of the house facade. regarding the other case there might be some deformations when comparing 2 clouds of the riverwall. my question is: is that possible via cloudcompare?
i tried some attempts but never got a logical result. i don't need to register the 2 clouds right? when i load both clouds of the house facade or the riverwall they are nearly congruent. if i'd register them i would eliminate the deformations because cloudcompare would adjust the compared cloud to the reference cloud. am i right? sorry for my bad english. i hope you get what i mean ;)
thx for every help!

[Elbruno]

Hello,

To register them in CC try to use rotation only in Z axis and disable Scale Factor. This will avoid distance alterations.

Are you considering the scanner accuracy? Some may have a standard deviation greater than the expansion of the objects. So the phenomenon that you are watching may go unnoticed.

Att

[daniel]

Indeed, if you are sure that you scanner hasn't moved, then you shouldn't need to register your clouds. If you do it nevertheless, then you won't miss the deformations (as the registration is a rigid transformation) but you'll miss the possible shifts (even though I don't think there's any).

Your biggest problem will probably be all the measurements errors/sources of noise:
- the temperature, air humidity, etc. all have an impact on the measurements of the scanner (even if little)
- the sensor itself may not behave the same way depending on its own temperature (you generally need to warm it up, etc.)
- the scanner measurement is not reproducible (i.e. the laser never hit the same point twice)
- and last but not least : if you use C2C distances you'll get some small errors due to the clouds sampling (and the fact the laser never hits the same point twice). To achieve a more robust comparison process, You'll either have to use one of the local modelling strategies (see http://www.cloudcompare.org/doc/wiki/in ... omputation), or use the advanced qM3C2 plugin (http://www.cloudcompare.org/doc/wiki/in ... 2_(plugin)).

Don't hesitate to post some snapshots, data, etc. It's always interesting to discuss about these kind of considerations.

[Elbruno]

Daniel is fast :D

[kayillerwhale]

thx for the fast responses:

here are 2 screenshots. in the first picture you see both pointclouds one above the other just right after loading them in CC.

http://www.directupload.net/file/d/4428 ... 9j_jpg.htm

bizarrely it doesn't seem to work if i try to register both clouds. when i do the registration both clouds aren't covered anymore:

http://www.directupload.net/file/d/4428 ... qb_jpg.htm

as already mentioned i'd like to prove that there aren't any deformation in the house facade but that there might be some deformations in the wall.

[kayillerwhale]

when i load them separately - so at first just compare 2 wall segments and then compare 2 facade segments - i get more differences/deformations in the facade than in the wall. normally it should be excactly the other way round. i don't get what i'm doing wrong..

here are the results when i register them with rotation only in Z axis and a disabled scale factor

http://www.directupload.net/file/d/4428 ... in_jpg.htm

http://www.directupload.net/file/d/4428 ... mv_jpg.htm


ps: when the compared cloud is a bit smaller/bigger than the reference cloud and there aren't any points to compare CC is ignoring these spots right? because it seems that in the edge areas the "deformations" are bigger and that CC is trying to compare these areas with areas which doesn't exist.

[daniel]

First question: can you use the 2.7.0 version (or the 2.8 beta) instead? (just in case)

Second: are you sure both clouds have the same extents? Can you show each cloud separately? If they don't have the same extents, then you'll have either to use the smallest one as aligned/data cloud, or remove the non overlapping part, or use an overlap percentage below 100%.

[Elbruno]

Daniel, If him/her uses control points wouldnt it get more accurate?

[daniel]

@Elbruno Indeed. But in this case, if the scanner hasn't moved it shouldn't be necessary to register the clouds.

@kayillerwhale You should carefully read how the C2C distances computation works (see the links to the wiki above). It will compute the distances from ALL the points of the compared cloud to the reference once. Therefore if you have non overlapping areas (with missing points in the reference cloud), you'll get higher distances...

To avoid this, you can of course segment both clouds at the same time (with the scissors tool) so as to be sure you'll have the same extents. And for an even more robust approach, consider using the qM3C2 plugin (where you can give a 'direction' for searching the nearest points, e.g. the surface normal).

Moreover, if the facade is farther than the wall (relatively to your scanner), wouldn't it be more logical that the distance is higher (as the scanner noise / inaccuracy is higher)? Or did I misunderstood you?

[kayillerwhale]

@daniel: okay at least i got how the C2C computation works. i tried it again by making the compared cloud a bit smaller than the reference cloud, though you are right: i could have just segment both clouds simultaneously with the scissor tool (i think that makes even more sense).

yes you are right with the scanner noise and inaccuracy regarding the facade but: in contrast to the wall (somebody else already proved with another measure-method that the wall is "moving") the house facade is fixed. so even if there's some noise and inaccuracy, if they are the same in both scans shouldnt they neutralise each-other?

btw: thx for your awesome feedback (u2 Elbruno!)