Page 1 of 2

Issues w/M3C2

Posted: Sat Feb 03, 2018 11:29 pm
by ilovecoffee1125
Hello,

I am trying to run M3C2 to calculate distance change so I can then convert that distance to a volumetric calculation to see if Cloud can accurately show the removal of an object from one scan to another. It will not accurately do this, and when I run on the guess parameters setting cloud crashes. I am not using my entire image, I am clipping the .0164m3 box from the image, which is pretty small. Why am I running into issues doing this?

I cut the box, set my parameters to projection and normals to .05 and my max depth to 1.0. I then export the M3C2 out of cloud into an excel file to see all the values. It shows me a 5m change in some scans. That is larger then the actual box.

Ideas?

CS

Secondary issue:I have used the volumetric tool to calculate vol loss as well. The issue I am having is it is reporting a positive value often when it should be negative. Also, The first scan has the box and the second scan does not. When I change my direction from X to Z I often get 0 change for X and a reasonable change for Z, but sometimes it is positive. If I change the order of the scans I get a closer value to the actual known loss. Why is it not consistent?

Re: Issues w/M3C2

Posted: Sun Feb 04, 2018 7:43 pm
by daniel
Not sure to understand... can you share your cloud with me? Or some snapshots at least?

Re: Issues w/M3C2

Posted: Sun Feb 04, 2018 8:19 pm
by ilovecoffee1125
Daniel,

Yes, I would be happy to share an image with you. They are large files, what is the best method for doing this? I can share a link to a dropbox if you have an email you can share.

Basically, everything I use the guess parameters option in M3C2 it crashes and stops working. Also, when I'm using the volumetric tool option I notice that I get accurate volume change in the X direction when my scan order is opposite of what it should be. So scan 2 is the before scan and scan 1 is the after. But when I calculate for Z direction and the scans are in the proper order (scan 1 and then 2 is the after) the vol change makes sense. I know the change as it was a box that was removed, so I have the actual value of change. Why is the volume change dependent on the Z or X direction? Isn't loss determined by the before and after scan and not which direction you are using?

CS

Re: Issues w/M3C2

Posted: Sun Feb 04, 2018 8:28 pm
by daniel
Yes, Dropbox is fine (you'll have to use: daniel.girardeau [at] gmail.com), or any cloud solution like Google Drive, etc.

And the 2.5D volume calculation needs a direction because of the way it works. Clouds are first rasterized (in the specified direction) before being compared to deduce the volume. Hence the '2.5D'. This won't work with a 3D cloud. If multiple points are at the same 'altitude' (along the projection dimension) then it can't work properly.

And the fact that M3C2 is crashing when hitting the 'Guess params' button is not normal. So if it's a bug I'm very interested to fix it.

Re: Issues w/M3C2

Posted: Sun Feb 04, 2018 8:35 pm
by ilovecoffee1125
Daniel,

I have shared two scans with you. The lower number in the title is the first scan with the box present, and the higher number scan is the image without the box.

So to clarify, when I use the volumetric tool I do have to adjust the scan order depending on direction? That is correct to do? What about in an environment where you are comparing scans based on time? An example would be monitoring erosion, how would you know to use the Z vs. X direction and if the resulting calculation was accurate?

And yes, M3C2 crashes when I run on guess parameters every time. I downloaded the stable version.
Thank you,
CS

Re: Issues w/M3C2

Posted: Mon Feb 05, 2018 6:14 pm
by daniel
The volumetric tool has been designed to process data acquired typically "from above" and compare at two different epochs (for stock-pile, or landslides, etc.). The projection dimension you choose is used to get a dense enough raster, so you can't use any direction indeed. In your case, with a TLS scanner, you probably can't acquire the scene "from above", so you would have to make sure the scene is always scanned from the same rough orientation of the scanner... Of course you can rotate the clouds (together) before comparing them.

For the M3C2 crash, can you test with the latest 2.10.alpha version? And if it still crashes, can you send me the exact clouds you use to make M3C2 crash? (with the same extents - or are there exactly the ones you sent me?)

Re: Issues w/M3C2

Posted: Mon Feb 05, 2018 11:08 pm
by ilovecoffee1125
Daniel,

The clouds I sent you are a few of the same types of scans I am having issues with. When I hit guess parameters, it fills in projection and normals with numbers like .0000001. It will run when I use numbers like .05, but then the change I get is wrong. We used the box to try to understands accuracy of the both the scanner and the software to get the best change results.

So the volumetric tool should not be used in my calculation? Like I said, when I change from X direction to Z it get closer to the actual vol loss, but I do have to change the order of the scans to get that value to be accurate.

Carly

Re: Issues w/M3C2

Posted: Mon Feb 05, 2018 11:09 pm
by ilovecoffee1125
Daniel,

Also, the clouds are together with 99% accuracy when I bring them into Cloud from another program.

CS

Re: Issues w/M3C2

Posted: Tue Feb 06, 2018 5:07 pm
by ilovecoffee1125
Daniel,

I sent you an email with screen shots showing what is happening when I try to run M3C2. Even with the new 2.10 download, it still crashes on me.

Also, since you are getting it to work, which values are you using in M3C2 for projection, normals, and max depth.

Thank you for your help this far,
CS

Re: Issues w/M3C2

Posted: Tue Feb 06, 2018 7:51 pm
by daniel
Considering your data, it seems quite 'dangerous' to use the volume calculation tool. If you get the wrong volume with the correct order, it's maybe because the 'change' is not happening along +Z but along -Z? (once again, remember that this tool is meant to be applied on objects with geographic coordinates (i.e. highest points have greater Z coordinates).