3 ms·
We are using ODM for generating orthomosaic photos and it produced better results than the commercial offerings we have seen (In some cases MUCH better). Note
by mohaine 8y ago
We are using ODM for generating orthomosaic photos and it produced better results than the commercial offerings we have seen (In some cases MUCH better). Note this did require us to tweak the settings some but overall it was pretty easy process.
Things of Note:
1) ODM didn't quite scale as well to very large number of photos. (I think this may have been fixed now).
2) Our use case was pretty brutal. ~1 cm resolution photos of a mostly uniform row crop fields. Some of the other tools were really bad at not rotating the rows 90 deg in parts of the field.
3) I was in on the POC and selection process but not the production runs so I'm not sure how things have changed over the last year.
4) Some of the comparisons where with different photos (Looking at a custom full path)
5) We didn't look at 3d much at all, but it was pretty cool to be able to see 3d tractor tire marks across and freshly planted field. The 3d quality would really fall off at the edges when there was less overlap. I think it was only good in relative hight as well but our tests were very flat.
- plausibilities 8y agoOne of its dependencies, OpenSfM, does a lot of the heavy lifting with regard to generating things like HOG descriptors (since SIFT = $IFT) That project used to have a bug with their multithreading implementation where if your photo sets got too big children threads would terminate but fail to get reaped and your heap size would just continue to grow until things kaboomed at the SfM phase. Not entirely their fault though as it stemmed from a deeper issue with Python stdlib's pool implementation. Back then, with certain photosets I would literally run OOM on my homelab which was equipped with 128 GB DDR4 Should be fixed by now though. You wouldn't happen to work for a small MPLS based startup would you?