I get this when global seam leveling is OFF. When it is ON we get a floating point exception.
1 Like
I get this same error with another dataset and driving me crazy. Do you guys have any clue how can I get through this?
1 Like
Have you updated again to v2.5.3 and/or v.2.5.4? Any changes/improvements?
1 Like
Yes, we are on the latest version.
1 Like
Could you give us a better idea of your flight plans?
Overlap, sidelap, and height above ground?
Looking at the dataset you linked above, it is a pretty difficult dataset since each image is so homogenous both within itself and between other frames.
I’ve employed a work-around I’ve used in the past a few times, and I was able to process your dataset (mostly) successfully!
The images were pretty washed out, low sharpness, and had very low scene detail.
So, I pre-processed them lightly in XNConvert with an Enhance Detail and Auto-Contrast filter.
Original Image:
Pre-Processed Image:
The difference is subtle, but it is enough to really help during the matching phase.
Processing using pretty much default settings worked great:
Options: crop: 0, debug: true, dsm: true, verbose: true
Orthophoto:
DSM:
Point Cloud:
The Point Cloud is where we see some of the limitations of this dataset, this pre-processing workflow, and my settings come together.
The strong “waffling” is just a consistent lack of tiepoints extracted during matching. Maybe we could do significantly better by forcing the min-num-features up, or by cranking up pc-quality, feature-quality, and turning off resizing.
To that end, Piero is tracking a feature request for OpenDroneMap to do this pre-processing in the background transparently for the user just for the matching phase, and then pass the original/unprocessed images to the pipeline for point-cloud coloration, orthophoto generation, and model texturing.
1 Like
Hi,
Thank you for your post, I truly appreciate you put this issue on your agenda. We have had success generating the orthomosaic with the default settings problems start to occure when we go high-res and define the resolution. It would be useful to see if these enhancements help with the following settings:
dem-resolution: 0.9, dsm: true, ignore-gsd: true, orthophoto-resolution: 0.9, pc-quality: high
When we try using them we run into a an error: empty initial point-cloud followed by a opendm.system.SubprocessException: Child returned 1
1 Like
Interesting! I was getting a failure to stitch with the settings above (Options: crop: 0, debug: true, dsm: true, verbose: true) until I pre-processed the images.
I can try again with Lightning with the same pre-processing I did before and the settings you included above. I’ll update you in time when it finishes.
Trying locally:
1 Like
Amazing, thank you!
What was the error? Empty initial point-cloud?
If I recall correctly, yes.
At the moment, I don’t think I can reproduce. My system runs out of RAM almost immediately during feature extraction at the settings you’ve indicated (32GB RAM, 1GB SWAP).
I can’t reproduce on Lightning as the values for ortho and dem resolution are clamped, along with ignore-gsd not being valid.
Thank you for the update. I have registered on Lightning to give it a try myself. Also have made the suggested conversion on the images and running on my installation. Will get back to you on the results. Even if the image quality is not the best these errors are disturbing. I have run the processing on Pix4D and got the desired outcome in 20 mins. It seems it that can deal with the image quality.
1 Like
Pix4D Fields? I doubt that Pix4D Mapper could do an entire 3D reconstruction in that timeframe, not with the density of data in this dataset.
What were your settings for Pix4D processing?
Well, this is just a first impression. I used the same resolution in Fields. I haven’t tried Mapper yet. I do not need 3D models just 2D. Anyway, Pix4D is not an option for me. I just wanted some reference point.
1 Like
If you just need 2D, I can change the processing parameters in WebODM and try again. Let me do that.
1 Like
New learning. Empty point-could can be eliminated if I turn on fast-orthophoto which will skip dense recostruction and 3D model building. Since I don’t need 3D this is ok for me. Processing went over and I again run into the floating point exception even with the preprocessed images. 
Must be something with the data but what?
New learning 2: if I switch off global beam leveling than processing goes over and I get a 3rd error message. Strange…
Rendering the ortho photo…
… model rendered
Writing ortho photo to /var/www/data/ea2715aa-8021-4ecf-8217-a6527107c2b6/odm_orthophoto/odm_orthophoto_render.tif
Unsupported bit depth value: -1
===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 1
===== 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 Flying Tips — OpenDroneMap 2.5.5 documentation
100 - done.
Traceback (most recent call last):
File “/code/stages/odm_app.py”, line 83, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 338, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 338, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 338, in run
self.next_stage.run(outputs)
[Previous line repeated 6 more times]
File “/code/opendm/types.py”, line 319, in run
self.process(self.args, outputs)
File “/code/stages/odm_orthophoto.py”, line 73, in process
system.run(’"{odm_ortho_bin}" -inputFiles {models} ’
File “/code/opendm/system.py”, line 90, in run
raise SubprocessException(“Child returned {}”.format(retcode), retcode)
opendm.system.SubprocessException: Child returned 1
Here’s what I’m trying currently:
Options: cog: true, crop: 0, debug: true, dem-resolution: 0.9, dsm: true, fast-orthophoto: true, ignore-gsd: true, matcher-neighbors: 0, max-concurrency: 4, orthophoto-resolution: 0.9, skip-3dmodel: true, use-3dmesh: true, use-hybrid-bundle-adjustment: true, verbose: true, rerun-from: dataset
It is likely going to take another day or more before my computer processes this.
After many tries I have concluded that the chain of errors are likely caused by the different exposure on the sides of the input images. I think the algorithm has difficulties to deal with the unbalanced saturation when trying to stitch the images. As the overexposure only affects one side of the picture preprocessing cannot fix it. I had success processing image sets which does not have this effect. All in all, to my opinion this should be registered as a bug, at least a better message should be generated.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.