Page 1 of 1
[FIXED] decreasing distance of cloud during trans, rotation
Posted: Mon May 19, 2014 3:56 pm
by jacobylarson
I have two point clouds sets that I am trying to merge by hand. They were collected with different 3D lidar sensors, both measuring in meters. I import them both into CloudCompare and then leave #1 stationary as I translate and rotate #2 so they align correctly. I have measured the length of point cloud #2 from the instance it was imported and every time I perform a rotation. The distance measurement is decreasing every time I translate and rotate the point cloud. It started at 308 meters and went down from there: 285 m, 265 m, down to 222. It is not a constant reduction in distance and it doesn't occur if point cloud #2 is imported just by itself without point cloud #1, only when they are imported together. Both point clouds are measuring their scaling at 1,1,1. At some point during this test I change the rotation center, but that is just to make the measurements easier to make. Any ideas on why this might be happening?
Re: decreasing distance of point cloud during trans, rotatio
Posted: Mon May 19, 2014 4:04 pm
by daniel
Hi,
That's puzzling indeed. When you say that you merge "by hand" I guess you mean that you use the "manual transformation tool" (scissors icon)? And which version do CloudCompare do you use exactly? (we had a problem in a recent version with the scaling factor suggested during importation of clouds with large coordinates).
Re: decreasing distance of point cloud during trans, rotatio
Posted: Tue May 20, 2014 6:33 pm
by jacobylarson
I used the translate/rotate button (right next to the scissors) to merge the two point clouds together. I am using version 2.5.3 Windows 64 bit. I also used a 3Dconnexion 3D mouse which I used to change perspective during the translate/rotate process. Maybe that has something to do with it as well. But it doesn't seem to occur during import, but during the rotation and translation part.
Re: decreasing distance of point cloud during trans, rotatio
Posted: Wed May 21, 2014 6:54 am
by daniel
Oups, yes I wanted to say "next to the scissors" icon but I wrote too fast.
I'll try to reproduce the bug on my side. If you have time, can you test with the 2.5.4 version?
Re: decreasing distance of point cloud during trans, rotatio
Posted: Wed May 21, 2014 10:52 pm
by jacobylarson
Yes, I will upgrade and see if I can repeat the error.
Re: decreasing distance of point cloud during trans, rotatio
Posted: Fri May 23, 2014 7:27 am
by daniel
Well I couldn't reproduce the error on my side (with the 2.5.4 version). I even did it with a 3D mouse just to be sure.
Can you give more details on your configuration? Are the clouds shifted at loading time? Maybe you can share them with me? (cloudcompare [at] danielgm.net)
Re: decreasing distance of point cloud during trans, rotatio
Posted: Thu May 29, 2014 7:13 pm
by jacobylarson
I have tested it again using version 2.5.4.1 windows 64 bit on windows 7 and have had the same results. I tried it again with and without the 3D mouse and it the length of my point cloud shrinks by about 3-4 meters every time. I think before it was shrinking by larger lengths (10-20 meters). I noticed this time that the length doesn't change when I am just translating, only when rotating. One of the point clouds was previously imported from a .ply file, then I had segmented some of the sections of it and saved it as a .bin. The second point cloud is a .ply file. So I load the .bin and the .ply file now and after rotating and measuring multiple times I start to see the effects of it. The point clouds are fairly large, so I will send them through a file sharing site.
Re: decreasing distance of point cloud during trans, rotatio
Posted: Fri May 30, 2014 8:16 am
by daniel
Thanks for the detective work! I'll track the issue and get back to you.
Daniel
Re: decreasing distance of point cloud during trans, rotatio
Posted: Fri May 30, 2014 9:08 pm
by daniel
Ok, I've found the issue... and more importantly I fixed it.
In fact, as we we do most of the computations in standard 32 bits ('float') precision, the accuracy is rather limited. When you compose hundreds of rotation matrices this way, the error is increasing each time and the final rotation matrix tends to shift towards a not so 'normal' matrix that might shrink the cloud by a very small quantity. And this happens each time you validate/close the 'graphical transformation' tool.
So to fix this I had to make CC use double-precision matrices in all the rendering pipeline, and I also added a normalization step before applying the transformation matrix. So now the only numerical error that remains is the "standard" one (i.e. about 10^-7 or 10^-8 relative error). And to limit its effect it's a good idea to stay inside the tool as long as possible before validating it.
The corresponding beta version is here (Windows 64bits -
tell me if you need another version):
http://www.cloudcompare.org/release/Clo ... in_x64.zip. This is a brand new version (based on Qt 5) so don't hesitate to report any error or strange behavior (directly by email).
To observe the effect of numerical errors more easily, you can create a label between two points as you did in your demo. But 'save' it (with the floppy icon) before leaving the 'Point picking' tool. This way the label will stay attached to the clouds during your next manipulations and you'll see the distance being automatically updated each time.
Re: decreasing distance of point cloud during trans, rotatio
Posted: Mon Jun 02, 2014 10:48 pm
by jacobylarson
I have tested out my point clouds in the new beta version of Cloud Compare and I am not getting the same problem as before. The length of the point cloud is not shrinking and it all seems good to me. Thanks for looking into this and fixing it. Your response was very quick and makes me want to continue using Cloud Compare for future work. Also thanks for the tip on measuring the two points and saving that measurement. That saves me a lot of time. I have noticed, like you mentioned, that the measurement of the point cloud does change just slightly, by about .00001 meters over a 308 meter length, but it isn't continually shrinking like I noticed before, but getting either smaller or larger or staying the same. I am ok with that amount of error and thanks for explaining it as well.