We ran into an error when processing a large dataset (approximately 6000 photos). The challenge is there are two different crops in the photos. One requires feature levels set at ‘high’ (normally we process at medium), when performing the job we run into this problem, probably similar to this (closed) post:
Postprocessing face infos 100%... done. (Took 0.012s)
Maximum quality of a face within an image: 0
Clamping qualities to 0 within normalization.
Optimizing:
Time[s] Energy
0 389174
0 389174
0 389174
0 389174
0 389174
0 389174
0 389174
389174 faces have not been seen
Took: 2047.57s
Generating texture patches:
Running... done. (Took 69.915s)
0 texture patches.
Running global seam leveling:
Create matrices for optimization... Floating point exception (core dumped)
===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 136
Traceback (most recent call last):
File "/code/stages/odm_app.py", line 82, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
[Previous line repeated 3 more times]
File "/code/opendm/types.py", line 449, in run
self.process(self.args, outputs)
File "/code/stages/mvstex.py", line 119, in process
system.run('"{bin}" "{nvm_file}" "{model}" "{out_dir}" '
File "/code/opendm/system.py", line 112, in run
raise SubprocessException("Child returned {}".format(retcode), retcode)
opendm.system.SubprocessException: Child returned 136
===== Done, human-readable information to follow... =====
[ERROR] The program exited with a strange error code. Please report it at https://community.opendronemap.org
100 - done.
Thanks!
non-gpu images seems to work. I gues it’s also difficult to debug these issues since there is a high dependency on input data, and a lot of third party dependencies.
We’re still having issues creating a good orthophoto since sometimes the photos are very similar… Tried all feature settings, different feature descriptors, and now looking into openSFM settings (planar, and matching neighbours to constrain the search area)
We are not able to stitch the large job yet, and also noticed some issues on smaller jobs.
We’ve set up two machines, one with a gpu docker version, one with a cpu version. ( How to know ODM version with Docker and change to previous NodeODM GPU's dockers version? this would be really helpful for reverting between versions, in the future we will build and tag them ourselves, since it is highly preferred to be able to revert to working versions in a production environment)
The M30T and M350 we’re working with now include a diagonal, oblique, path at the end of the mission. This path sometimes troubles the image matching algorithm. When removing these paths the matching is improved slightly.
1.1. We tried different sfm-algorithm settings, planar did not succeed and triangulation resulted in errors, we’re sticking to incremental for now. The idea was that since the farm land is quite uniform this would result in ‘wrong’ matches. Given the GPS-RTK coordinates priority over feature matching would be nice (like matcher-neighbours, however this fails, possibly because of the oblique diagonal?).
We notice a difference between the dspsift algorithm and sift, where sift is much more reliable for agricultural scenarios. Increasing the feature quality for dspsift resolves this in some cases.
At the moment we’re finalizing the experiments and will try to share the reports when I get an OK from the owner of the data.