Floating point exception (Texturing phase)

[Saijin_Naib]

@nhavas

I have run the processing on Pix4D and got the desired outcome in 20 mins

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?

[nhavas]

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.

[Saijin_Naib]

If you just need 2D, I can change the processing parameters in WebODM and try again. Let me do that.

[nhavas]

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?

[nhavas]

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

[Saijin_Naib]

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.

[nhavas]

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.