Webodm: Stripes on point cloud, georeferencing is out.

[bcirulis]

How did you install WebODM? (Docker, natively, ...)?

Windows 10 Docker CE

What's your browser and operating system?

Chrome 65 on Windows 10

What is the problem?

Generated .ply and .las files are striped. I think its the same issue as this:

https://github.com/OpenDroneMap/OpenDroneMap/issues/522

What should be the expected behavior?

correctly referenced point cloud / dsm etc.

How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing? If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed)

Using webodm interface on auto-node default settings.

I have tried multiple different projects but they all end up with the same striped .ply/las files:

The textured model looks great:

georeferencing is out:

dsm is weird:

project photos here: https://drive.google.com/file/d/1T8RoKDHCmuNlQobbrrk04cmKXCkFFuku/view?usp=sharing

[bcirulis]

To add to this, I had it working 3 days ago on a different project, just retried it and the same issue occurs. Could it be something in the latest update to node-opendronemap? it was updated 28 hours ago.

[pierotofy]

Perhaps this is a bug. Sounds like a possible regression of PDAL https://github.com/OpenDroneMap/OpenDroneMap/issues/522, but will need to find some time to test to confirm this. In the meanwhile if other users are experiencing the same issue, please chime in.

[farmdude]

I'm having the same issue...

[pierotofy]

Thank you @farmdude. I will have some time hopefully this weekend to look into it.

[bcirulis]

Awesome, thanks!

[pierotofy]

This was introduced by changes in https://github.com/OpenDroneMap/OpenDroneMap/commit/96be8c43aa165e5ce727dd6262b88bea106b5c88.

Boils down to float datatypes not being large enough to handle the georeferencing offset addition (which truncates precision in both X and Y coordinates).

Currently affects all datasets.

Example PLY output (odm_georeferenced_model.ply):

...
property float curvature
end_header
576727 5.1882e+06 162.601 61 69 96 0.025 -0.048 0.999 0
576727 5.1882e+06 162.853 38 52 41 -0.257 0.345 0.903 0\
...

Working on a fix, just need to treat PCL pointclouds XYZ as double instead of float.

cc @dakotabenjamin

[pierotofy]

Well, this is proving trickier that I thought.

Turns out PCL doesn't let you just change from float to double (even by defining a new point datatype as indicated in http://pointclouds.org/documentation/tutorials/adding_custom_ptype.php):

Floats are hard coded all over the place when executing a transform:

http://docs.pointclouds.org/1.7.1/transforms_8hpp_source.html (line 83):

cloud_out[i].x = static_cast<float> (transform (0, 0) * pt.coeffRef (0) + transform (0, 1) * pt.coeffRef (1) + transform (0, 2) * pt.coeffRef (2) + transform (0, 3));

I'll have to manipulate the point cloud without PCL and apply the transform using Eigen directly.

[pierotofy]

A PR has been opened, when it gets merged this should be resolved.

[bcirulis]

Great stuff. Looking forward to trying it out.

[andesce]

Thank you guys for looking into that bug. Dakota, I watched your opendronemap presentation in youtube, it was very helpful for me, a beginner trying to understand this open cloud world.

[bcirulis]

Working amazingly well for me. Thanks for the fix @pierotofy

Check out this point cloud of very complex/sparse forest. Was not expecting it to work this well

[pierotofy]

This is now resolved. Do an update to pull the latest node-opendronemap image.