Gaps in large split dataset output - paramater suggestions?

General Help
#1

41%20AM
41%20AM1427Ă—1029 786 KB

4,005 image dataset. On the left is what someone processed with Pix4D. On the right is the output from WebODM with defaults and min-num-features: 10000, split: 400, split-overlap: 120
Any suggestions for parameters to tweak to get those gaps filled in?

#2

Hi Dan,

Can you share the log? It looks like some of the batches aren’t processing. It would be good to know where they are failing in the process.

Thanks,
Best,
Steve

#3

Also, this is a forested patch which can be a nightmare for matching: what’s your overlap and sidelap, height of flight, and the approximate height of the trees? If the issue is with the SfM steps on these blocks, then we may be able to relax some constraints on bundle adjustment to allow for lower quality matches, which would likely be how Pix4D is working around the issue (if my hunch as to the issue is correct) automagically.

#4
#5

Are all these orthos valid, or is there a silent failure for any of these?:

/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0000/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0002/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0003/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0005/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0010/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0007/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0008/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0001/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0009/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0004/odm_orthophoto/odm_orthophoto.tif
/var/www/data/17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d/submodels/submodel_0006/odm_orthophoto/odm_orthophoto.tif
#6

will those be saved in the docker image on the WebODM node? are they part of what is purged after 2 days?

#7

Oh dear, I don’t know as I’m almost always running natively. @pierotofy, thoughts?

#8

Yes those will get deleted after 2 days.

They are stored in the “master” node that is selected to do the processing. To find which one that is, telnet into ClusterODM and type:

> route info 17c1ef4e-fb4b-4dd4-bb4d-4e909cb76c4d

Although that route might have been “cleared” also after a certain amount of time, so you might get a “no route” message back (but try).

I would increase min-num-features. It looks like some parts of the orthos simply did not reconstruct, not that the submodels failed (that would have stopped the process and not given you any output).

1 Like
#9

FWIW default number of features with agisoft is 40k, though you might start lower.

Rather than rerun all, I would troubleshoot first in your areas that were incomplete. Subset your dataset to one of these areas and start twisting the number of features knob until hopefully something works. (Now that he points it out) Piero is right — there are no outright failures, so likely incomplete submodels.

@pierotofy — is there anything in opensfm/config.py that might help relax the matching at all?

#10

Actually, I’m wondering if alternative feature extraction techniques might be useful to test in these cases as well.

#11

bumped min-num-features up to 15000 and ended up with different, but still really bad, gaps:

13%20PM
13%20PM2014Ă—1362 648 KB

https://gist.github.com/danbjoseph/01b991545f2e1c80d14923bbf3677b34

#12

Try to bump that to 20,000 - 30,000. Also try to set --resize-to to -1 and increase --matcher-neighbors to 20.

1 Like