merge-skip-blending option is missing in config json for WebODM

[lfeldb]

merge-skip-blending option is missing in the json the config returns for webodm.

I'm still getting familiar with the code base, would it be sufficient to add the option here?

ODX/opendm/config.py

Line 806 in 3e36271

[pierotofy]

I originally reverted the merge-skip-blending option (adb2bb2) because I'm not entirely convinced about the approach.

I'd be interested to hear more about the use case of why that option is useful, if you can share.

[lfeldb]

Thank you for your quick response, in the meantime i also found your reverted code and was just about to update this issue :)

We are processing 4000+ image datasets, and would like to split-merge for the following two reasons:

1. speedup processing time (which grows non-linearly with the number of photos). The merge step is very slow (seems to be running on a single core, have seen some discussions about this on the forum/github). For agricultural applications we sadly cannot wait days for the result.
2. hopefully decrease wrongly matched photos. For example in a lot of agricultural applications the fields look very similar (especially when mapping wheats for eample). This means if images are matched on keypoints this is not always very robust. Manually split-merging the dataset (like we did before) reduces the chance of mis-matching a lot, but it is a bit of a workaround so we're testing the split-merge option.

[pierotofy]

1. So it sounds like the issue is really speed. merge-skip-blending simply skips the (important) blending step, but without it your orthophotos will have visible seams. If that's desirable, at that point just skip the merge step altogether, just process the submodels and merge them with gdal_merge.

2. I'm not sure merge-skip-blending is relevant.

There's probably ways to make the orthophoto merge / blend step faster. If the goal is faster processing, then we should focus on making the process faster.

[lfeldb]

You are correct, this step should better be improved instead of skipped. It seems that for small split sizes the blend is also significantly faster than on large (2000+) batches.
For now your suggestion to merge them afterwards is I think our best option (gdalwarp is pretty fast).

I was also hoping to use the split-merge method so we could also produce stitching statistics (mainly the gps errors/deviations), but this is not implemented yet ( #19 )

[pierotofy]

I would expect merge/blending to take longer linearly to the megapixel count, e.g. 4000x4000 would take at least 16 times longer (probably more because we have multiple passes) than 1000x1000, does that match your observations? If it's more than 3*16 (48) times longer, then we're probably not making efficient use of I/O caching.