DensifyPointCloud stops with segfault

After a while I revisited a dataset which I have processed already several times with ODM, with success. I used the original aerial images and preprocessed ones. Preprocessing was about colour alignment of the thermal images which came with different colour palettes. Even with the preprocessed images the resulting orthophoto was very good, qualitiy of “stitching” was way better than when using the original thermal images. However, I tweaked a little bit the preprocessing, and now DensifyPointCloud failes with a segfault.
What can go wrong here?

[INFO]    running "/code/SuperBuild/install/bin/OpenMVS/DensifyPointCloud" "/var/www/data/31cc6831-cd87-49a1-bd6b-d75908520a23/opensfm/undistorted/openmvs/scene.mvs"  --resolution-level 0 --dense-config-file "/var/www/data/31cc6831-cd87-49a1-bd6b-d75908520a23/opensfm/undistorted/openmvs/Densify.ini" --min-resolution 2000 --max-resolution 2000 --max-threads 8 --number-views-fuse 2 --sub-resolution-levels 2 -w "/var/www/data/31cc6831-cd87-49a1-bd6b-d75908520a23/opensfm/undistorted/openmvs/depthmaps" -v 0 --cuda-device -2 --geometric-iters 0
21:49:20 [App     ] Build date: Aug 13 2022, 05:58:21
21:49:20 [App     ] CPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz (8 cores)
21:49:20 [App     ] RAM: 30.64GB Physical Memory 8.20GB Virtual Memory
21:49:20 [App     ] OS: Linux 5.10.0-19-amd64 (x86_64)
21:49:20 [App     ] Disk: 672.13GB (907.75GB) space
21:49:20 [App     ] SSE & AVX compatible CPU & OS detected
21:49:20 [App     ] Command line: DensifyPointCloud /var/www/data/31cc6831-cd87-49a1-bd6b-d75908520a23/opensfm/undistorted/openmvs/scene.mvs --resolution-level 0 --dense-config-file /var/www/data/31cc6831-cd87-49a1-bd6b-d75908520a23/opensfm/undistorted/openmvs/Densify.ini --min-resolution 2000 --max-resolution 2000 --max-threads 8 --number-views-fuse 2 --sub-resolution-levels 2 -w /var/www/data/31cc6831-cd87-49a1-bd6b-d75908520a23/opensfm/undistorted/openmvs/depthmaps -v 0 --cuda-device -2 --geometric-iters 0
21:49:20 [App     ] The camera directions mean is unbalanced; the scene will be considered unbounded (no ROI)
Segmentation fault (core dumped)

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 139
Traceback (most recent call last):
File "/code/stages/odm_app.py", line 88, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 378, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 378, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 378, in run
self.next_stage.run(outputs)
[Previous line repeated 1 more time]
File "/code/opendm/types.py", line 359, in run
self.process(self.args, outputs)
File "/code/stages/openmvs.py", line 114, in process
raise e
File "/code/stages/openmvs.py", line 105, in process
run_densify()
File "/code/stages/openmvs.py", line 100, in run_densify
system.run('"%s" "%s" %s' % (context.omvs_densify_path,
File "/code/opendm/system.py", line 106, in run
raise SubprocessException("Child returned {}".format(retcode), retcode)
opendm.system.SubprocessException: Child returned 139

===== Done, human-readable information to follow... =====

[ERROR]   Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See https://docs.opendronemap.org/flying/

Parameters:
auto-boundary: true, depthmap-resolution: 2000, dsm: true, feature-quality: ultra, gps-accuracy: 3, mesh-octree-depth: 13, mesh-size: 600000, min-num-features: 25000, orthophoto-cutline: true, orthophoto-resolution: 1, pc-quality: ultra, rerun-from: dataset, skip-3dmodel: true, verbose: true

After preprocessing the EXIF data is transferred from original images.

1 Like

Can you please try with default parameters?

1 Like

It gives the same segfault.

1 Like

Can you please share the dataset?

1 Like

Sounds like a bug that got squashed last week. How recently have you updated?

3 Likes

Yep, make sure the ODM engine version is 3.0.1 (you can see that from the first lines of the task output log).

3 Likes

The version used is ODM 2.8.8, I upgraded to ODM 3.0.1 now. Unfortunately the segfault still happens with default parameters:

[INFO]    running "/code/SuperBuild/install/bin/opensfm/bin/opensfm" export_visualsfm --points "/var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm"
[INFO]    Finished opensfm stage
[INFO]    Running openmvs stage
[INFO]    running "/code/SuperBuild/install/bin/opensfm/bin/opensfm" export_openmvs "/var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm"
[INFO]    Depthmap resolution set to: 320px
[INFO]    Running dense reconstruction. This might take a while.
[INFO]    Estimating depthmaps
[INFO]    nvidia-smi not found in PATH, using CPU
[INFO]    running "/code/SuperBuild/install/bin/OpenMVS/DensifyPointCloud" "/var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm/undistorted/openmvs/scene.mvs"  --resolution-level 1 --dense-config-file "/var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm/undistorted/openmvs/Densify.ini" --max-resolution 640 --max-threads 8 --number-views-fuse 2 --sub-resolution-levels 2 -w "/var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm/undistorted/openmvs/depthmaps" -v 0 --cuda-device -2
17:16:14 [App     ] Build date: Dec  6 2022, 16:53:45
17:16:14 [App     ] CPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz (8 cores)
17:16:14 [App     ] RAM: 30.64GB Physical Memory 8.20GB Virtual Memory
17:16:14 [App     ] OS: Linux 5.10.0-19-amd64 (x86_64)
17:16:14 [App     ] Disk:
17:16:14 [App     ] SSE & AVX compatible CPU & OS detected
17:16:14 [App     ] Command line: DensifyPointCloud /var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm/undistorted/openmvs/scene.mvs --resolution-level 1 --dense-config-file /var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm/undistorted/openmvs/Densify.ini --max-resolution 640 --max-threads 8 --number-views-fuse 2 --sub-resolution-levels 2 -w /var/www/data/aa5bf447-63f9-4502-abeb-869203c06f93/opensfm/undistorted/openmvs/depthmaps -v 0 --cuda-device -2
17:16:14 [App     ] The camera directions mean is unbalanced; the scene will be considered unbounded (no ROI)
Segmentation fault (core dumped)

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 139
Traceback (most recent call last):
File "/code/stages/odm_app.py", line 81, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 382, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 382, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 382, in run
self.next_stage.run(outputs)
[Previous line repeated 1 more time]
File "/code/opendm/types.py", line 361, in run
self.process(self.args, outputs)
File "/code/stages/openmvs.py", line 117, in process
raise e
File "/code/stages/openmvs.py", line 103, in process
run_densify()
File "/code/stages/openmvs.py", line 99, in run_densify
system.run('"%s" "%s" %s' % (context.omvs_densify_path,
File "/code/opendm/system.py", line 109, in run
raise SubprocessException("Child returned {}".format(retcode), retcode)
opendm.system.SubprocessException: Child returned 139

===== Done, human-readable information to follow... =====

[ERROR]   Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See https://docs.opendronemap.org/flying/


1 Like

I put the dataset on Google Drive:

Thank you very much for your time!

1 Like

Are there data missing? These images are in about 3 disparate surveys, and we do not really support this type of collection. Contiguous surveys are going to process reliably.

2 Likes

Yes, the drone mission only covered the whole area with the wide angle lense, the thermal camera has a small field of view and thus the areas are not contiguous. But it was the first time I experienced issues due to this.
However, thank you for analysing!

2 Likes

Yep, you’ll need to plan your flights for the lens on the thermal camera if you want to have its data stich reliably.

I’ve seen this numerous times, and I don’t believe any flight planners take the difference in focal length into account, and normally plan based upon focal length of the main visible camera.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.