880 images project fail and tiny project 147 images finish but orthostatic images are twisted

[Samdrone]

880 images project fail and tiny project 147 images finish but orthostatic images

For the 147 images, result as below.

The two small project for 880 RGB images fail as

The log is here.

The 880 and 2640 images took around 35-40 hours to fail. And the RAM only use up to 50% of 256GB RAM. It should not caused by not enough memory.

Also I think the processing time is super long. I use same machine with Pix4Dfield, it take 1-3 hours to finish those process.
The size of orthosia as below.

I am happy to see the WebODM start to support this type drone(Quantix Mapper). But maybe some parameters are missing or wrong.

[Saijin_Naib]

Pix4D Fields is not performing the same analysis. Run your data with Fast Orthophoto preset to do a 2D-only reconstruction like Pix4D Fields.

[Samdrone]

Yes. All are using Fast Orthophoto preset .

[Saijin_Naib]

Are you able to post your datasets? At least the small 147-image one?

[Samdrone]

I shared another dataset before like this.

Multispectral data for 4 Acreage orchard in Quantix Mapper

Dataset URL (Dropbox, Google Drive, GitHub…): Google Drive Number of images: 196 Size in MB: 318MB EXIF GPS (yes/no): Yes GCP (yes/no): No RTK (yes/no): No Comment/Description: Multispectral data for 4 Acreage orchard in Quantix Mapper

[Saijin_Naib]

It looks like YanNoun pushed changes to OpenSFM to try and deal with the fact that the Quantix Mapper doesn’t write out the proper metadata to its image files, and it looks like our fork (2.57) has those changes, but it would appear that they’re still not sufficient to properly reconstruct data from your sensor.

Changes by YanNoun:

Never success to finish multispectral bands for agriculture

I just issue a fix here : fix: get image size by loading it by YanNoun · Pull Request #709 · mapillary/OpenSfM · GitHub But even with that, it is hard to get a scene without bowl effect.

I’ve opened a PR with what I believe to be the necessary specs for the AeroVironment Quantix sensor, but even with these values testing locally, I was unable to reconstruct your data.

Add Preliminary Sensor Database support for AeroVironment Quantix

By editing the exif.py and using a focal value of 0.54 (pulled out of a hat), I get this:

Looks like I’ll need some expertise from YanNoun to calculate that properly, if it is even needed.

[Samdrone]

Thank you for your input. Looking for future update.

I don’t know there are so much parameters involved in the process. Thank you again.

[YanNoun]

I’ve been playing with this dataset, but unfortunately, this falls in the terrible case of nadir capture + close-to-perfect fronto-parallel surface (field), which is a known hard case for general SfM systems. Commercial pipelines usually detects and deal with this kind of dataset with ad-hoc pipelines, algorithms and tweaks, a functionality that OpenSfM doesn’t have yet.

However, I’ll keep this dataset on the side, since it will be a perfect validation case of OpenSfM the day we’ll support these edge-cases better.

In the meantime, I would suggest to avoid pure nadir, by slightly tilting the camera if possible.

[Samdrone]

Thank you.
This is a Quantix Mapper, the camera is fixed and can’t be adjusted.
It also process very well in pix4dfield.

And one more thing to mention, the process time are around 30-60 times longer than pix4dfield. I don’t know why. But this could suggest some improvement for WebOdm.

Thank you again.

[Saijin_Naib]

As always, thanks so much for your assistance and expertise! I truly appreciate it.

[Samdrone]

Also found out a very interesting thing
Native windows are much slower than docker version. It sounds wired.

I run another 880 multispectral RGB , (wedOdm doesn’t support so far)
Docker version fail at 2:47. almost 3 hours.
But Native widows version still running 4:52

Docker one.

Windows version, 5 hours, still running, but it use very little RAM.

[Samdrone]

native windows version stop at 8.5 hours, almost 3 times than docker version.

---

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 1
Traceback (most recent call last):
File “D:\WebODM\resources\app\apps\ODM\stages\odm_app.py”, line 89, in execute
self.first_stage.run()
File “D:\WebODM\resources\app\apps\ODM\opendm\types.py”, line 340, in run
self.next_stage.run(outputs)
File “D:\WebODM\resources\app\apps\ODM\opendm\types.py”, line 340, in run
self.next_stage.run(outputs)
File “D:\WebODM\resources\app\apps\ODM\opendm\types.py”, line 340, in run
self.next_stage.run(outputs)
[Previous line repeated 3 more times]
File “D:\WebODM\resources\app\apps\ODM\opendm\types.py”, line 321, in run
self.process(self.args, outputs)
File “D:\WebODM\resources\app\apps\ODM\stages\mvstex.py”, line 108, in process
system.run(’"{bin}" “{nvm_file}” “{model}” “{out_dir}” ’
File “D:\WebODM\resources\app\apps\ODM\opendm\system.py”, line 106, in run
raise SubprocessException(“Child returned {}”.format(retcode), retcode)
opendm.system.SubprocessException: 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 https://docs.opendronemap.org/flying.html
100 - done.