compare clouds for deformation-analysis

[kayillerwhale]

ok when comparing the wall-clouds 6h-to-9h and 6h-to-13h i finally get some logical results :)

6-9h:
mean distance: 0,007087
std deviation: 0,003005

6-13h:
mean distance: 0,007803
std deviation: 0,004393

so at least there seem to be some minimal deformations the higher the temperature is. is it somehow possible to convert these values to a metric unit (like mm, cm)? the scan resolution was 1,66mm per 10m.

now i'm just stucked with the house facade. i hope i find a way to show that there aren't any deformations. if you have another tip or solution i'd welcome it ;)

btw: it would be very cool if you can export these 2 values (m-distance + std dev) when saving the result-cloud as an ascii-file ;)

[daniel]

As a scanner noise is a random process, when you compare both clouds, their respective noise doesn't compensate. Quite the opposite, it's additive in fact!

[kayillerwhale]

Hey Daniel,
might it be possible that you have a look on the pointclouds? I cleaned them in cyclone and did a export to .pts. I loaded them all together in CC. Marked them and segmented all to the same size via scissor-tool. Then i compared every cloud to the 6h cloud (e.g. 6&7, 6&8, 6&9 ..). Without registrating the clouds. I get the following results for the first standpoint:

stp1:
6-7
md: 0.006941
sd: 0.003750
6-8
md: 0.007156
sd: 0.003911
6-9:
md: 0.007398
sd: 0.003186
6-10:
md: 0,009529
sd: 0,004971
6-11:
md: 0.009611
sd: 0.005811
6-12:
md: 0.008812
sd: 0,005234
6-13:
md: 0.008937
sd: 0.004901

At 6h in the morning i had a temperature of 22° and ended up at 13h with 35° C. do you maybe have an idea why the mean-distance gets smaller at 12h? what also keeps me wondering is, that there’s a „big jump“ between 6-7h (md: 0.006941) and after that the mean distance is just increasing just a little bit (~0,00200) to 0,007156.

Download Pointsclouds:
https://ufile.io/2b99d

[daniel]

Interesting.

I started the same process as you (I cropped all clouds with the same extents) but then I used the 2.5D volume calculation tool (projection along Y, step: 0.02). The way the volume is computed makes the result much more robust to noise and to the density variations (this tool projects the clouds in the same regular grid and then extracts the average heights of both cloud in each grid cell and eventually compute the difference) :

7h (compared to 6h, as all the others)
Volume: -0.24
Surface: 120.37
----------------------
Added volume: (+)0.19
Removed volume: (-)0.43
----------------------

8h
Volume: -0.38
Surface: 120.20
----------------------
Added volume: (+)0.16
Removed volume: (-)0.54
----------------------

9h
Volume: -0.26
Surface: 120.27
----------------------
Added volume: (+)0.18
Removed volume: (-)0.44
----------------------

10h
Volume: -0.96
Surface: 120.22
----------------------
Added volume: (+)0.12
Removed volume: (-)1.09
----------------------

11h
Volume: -1.07
Surface: 120.29
----------------------
Added volume: (+)0.11
Removed volume: (-)1.18
----------------------

12h
Volume: -0.87
Surface: 120.82
----------------------
Added volume: (+)0.10
Removed volume: (-)0.97
----------------------

13h
Volume: -0.84
Surface: 119.34
----------------------
Added volume: (+)0.10
Removed volume: (-)0.95
----------------------

The surface is slightly varying because of the holes in the scans. But overall it's pretty stable. And we can clearly see the same jump after 10 am, and then a slight decrease after 12 am.

Then I computed the M3C2 distance to see what happens at 7 am and 10 am.

7h

M3C2 distances 7h / 6h

m3c2_wall_full_7h.jpg (87.12 KiB) Viewed 6253 times

10h

M3C2 distances 10h / 6h

m3c2_wall_full.jpg (107.1 KiB) Viewed 6253 times

The pattern we can see at 10h is a radial pattern, with a center approximately on the left of the wall (I guess it was approximately the point in front of the sensor?). This pattern is typical of a sensor artefact or even a calibration issue. And you get the same at 13h (I haven't tested the others).

Regarding why you didn't see the pattern before 10 am... there are several possibilities:

• the sensor was not 'hot' enough? If we increase the scalar field contrast, we can see some ripples... but very small compared to the ones at 10h.
• the sensor did move (even a little). Considering the distances and the small variations (the sensor was at least at 50 meters from the wall, while the variations are mostly below 3 cm), even a very small change of attitude of the sensor will have a big effect on the result. Especially we can clearly observe a global shift between 10h (or 11h) and 6h (mostly along Z, but also along X). To test this on your side, simply display only these 2 clouds, and then toggle one cloud on and off quickly.
  
  M3C2 can clearly detect it (here on a small part where it is the most visible):

  

  M3C2 distances 10h / 6h (closeup)

  wall_m3c2.jpg (104.48 KiB) Viewed 6253 times

  This issue might be disconnected from the pattern one. But it may increase the effect.
  >
• another option is that the scanner behavior is very unstable in time (was it in a shaded area or directly hit by the sun? etc.). Remember that the displacement is very small compared to the distance. And did the wall lighting conditions changed a lot during the day? I know some scanners are quite sensitive to this.

What are the specifications of the sensor by the way?

[kayillerwhale]

Hey Daniel,
thx for testing and the fast reply!

At first i have some minor questions: the 2.5D volume calculation tool doesn't seem to be included in v2.6.2 right? you used "project along Y" because of the differences back and forth, right? z would be for differences up and down and x for left and right? 0,02 is the grid-size, isn't it? did you interpolate the empty cells in the holes or left them empty? and why is it 2.5D btw? the clouds themselfs are 3D aren't they?

what are your parameteres when computing the M3C2 distance. i tried it with different settings but never managed to get the same result like you. and how can you select these 2 points like you did in the picture "M3C2 distances 10h / 6h". you are right left side was approximately the area in front of the sensor.

with a online-tool (http://www.sonnenverlauf.de/#/52.5221,1 ... 29/13:15/1) i just reconstructed the path of the sun on that day. the scanner was in a shaded area until ca. 10h. from 10 to 13h it was directly hit by the sun. for the wall itself it is the other way round (6-10h hit by the sun, 10-13 among the shades). so that could definetely be a reason for the jump at around 10/11 - as you assumed the sensor might not have been hot enough (its a Leica HDS 7000 btw).

so as an assumption we could say: when the sensor is getting too hot, we get that radial-pattern mentioned above. the volume + distance-results aren't really trustful then.

and the very last question: you wrote "the sensor was at least at 50 meters from the wall, while the variations are mostly below 3 cm". where do you see the variations below 3cm?

and again: thx for the awesome support!

[kayillerwhale]

btw: when computing the distances between the clouds of the second standpoint, i get completely irregular values. oh man, i really become desperate :(

stp2:
6-7:
0.085337
0.026530
6-8:
0.023939
0.010023
6-9:
0.088528
0.027606
6-10:
0.013793
0.006596
6-11:
0.038851
0.014562
6-12:
0.074792
0.023866
6-13:
0,076569
0,024537

[daniel]

1) The 2.5D calculation tool is available since version 2.6.3.beta (I would strongly advise you to use the 2.7 or the 2.8.beta version by the way).

This tool is 2.5D as it needs a projection dimension to work (it's used to project the clouds in the grid). Therefore I used the direction that was the most normal to the wall (it would be even better to rotate the cloud(s) so that the wall normal is parallel with one of the main directions). And 0.02 is the cell size (i.e. 2 x 2 cm).

I left the empty cells empty because I don't need a 100% overlap (all this is about statistics ;).

2) For M3C2: normal radius was 0.1, projection was 0.05 and max dist something like 0.25. The important parameter is how CC will deduce the correct normal orientation: as we are lucky enough to get the points directly in the sensor original coordinate system, we can use the '+(0,0,0)' preferred orientation (in the 'Normals' section, bottom 'Orientation' frame).

And I used all points for the computation (no subsampling, there's not so many points).

Then you have to hide the original clouds (M3C2 creates a new cloud by default). And you have to change the distances SF saturation to be able to see the pattern (reduce it to something like 2 or 3 cm).

3) Trusting the M3C2 results, we can see that most of the distances are below 3 cm (I used as a very coarse approach the 'Normal distribution' rule of thumb: 1 * std. dev. = 68% of points below / 2 * std. dev. = 95% of points below - even though the distribution is not exactly Normal/Gaussian ;). And of course a good part of these distances are probably due to noise and not to an actual change of the wall...

It was just to emphasize the fact that you are trying to detect very small variations relatively to the size and distance of the object. You'd better trust your sensor in this case.

4) For more reliable results you have to make sure:
- to protect at least the sensor from the sun (I am not sure this is the only reason by the way, but it could definitely be one)
- to assess the correct calibration of the sensor (when was the scanner calibrated for the last time?)
- to be absolutely sure that the scanner won't move, even of a few millimeters (and this can be quite challenging)
- take into account that even a calibrated HDS 7000 has up to several millimeters of error (RMS) at 50 m (and that the figures given by the manufacturer = in perfect conditions). It ranges up to 1 cm at 100 m. Therefore it might be a good idea to reduce the distance if possible (25 m.?)
- to use M3C2 to get robust distances

If you are able to make more measurement (in good conditions) I'd be happy to help.

P.S.: not sure if it's possible but it would also be interesting to shade a part of the wall to see if the measurement are consistent all over the wall, whatever the light conditions are, or if the shaded area follows a different pattern (in which case you'll have identified another source of potential error ;).

[kayillerwhale]

hey daniel,
thx for your reply. unfortunately there is no chance to measure the whole thing again. your support helped me a lot!

i might be quite annoying but might it be possible to take a screenshot of your colourfield and sf display params for the m3c2 comparison. i tried to change the saturation but i never got it as nice as you did it.

i understood everything else ;)


AND: might it be possible to measure the amplitude of the waves? to see how huge it is? i thougth of maybe fit a plane of the 6h cloud and compare this plane with the 6-10_m3c2 cloud. i don't know if that's possible..

[daniel]

I'll need to get back to my computer first (it may take some time).

I don't remember having made any special modification (make sure only the M3C2 output is visible, keep the default color ramp, you may have to set it as 'symetrical', and eventually I only changed the max saturation value).

And regarding the waves amplitude, you can indeed fit a plane and then compute the distances between any cloud and this plane ('Cloud To Mesh' distances in this case).

[kayillerwhale]

At the picture below you can see my display params and how it looks:

http://www.directupload.net/file/d/4448 ... gt_png.htm
http://www.directupload.net/file/d/4448 ... 9f_png.htm

your screenshots look way better.