Speed compare WebOdm windows version vs Docker version vs Pix4dField

[YanNoun]

I would not be able to do it as a side project for money given my current employment, so if anything happen on my side, it’ll be for free :

• Either it fits and intersect my day-to-day work duties and I’ll need to do it
• Or I can spend some time just writing a bit of doc on how to do it by giving some code pointers, so someone else can do the actual bulk of work

[pierotofy]

I’m giving the Robust Plane-Based Structure From Motion paper a shot; I’m almost done implementing the TRASAC algorithm from the paper:

Blue points are plane inliers, red dots are outliers. Seems to work!

[Saijin_Naib]

Yeah, seriously, wow, I can’t see anything misclassified.

This is many excite…

[pierotofy]

Plane estimates and local reconstruction from homography linking:

[Samdrone]

What is this mean?

[smathermather]

It means Piero is successfully working on near real-time processing of images for flat areas.

[pierotofy]

More screens:

Point triangulation on plane.

I’ve had a chance to play with this concept for a while, and the main issue has been the drift error accumulation while performing homography linking. The error can be restricted quite a bit if the following assumptions hold true:

• Nadir-only images (captured with gimbal), so only yaw angles are allowed
• Images captured in terrain-follow mode (constant altitude for a flat terrain)
• Good estimate for the camera’s focal length is available in the camera database

Variations in flight altitude and camera angles make the problem much more difficult to speed up using the planar assumption. I think the constraints apply well to AG fields datasets, so the method should still be useful if it’s really fast.

[Saijin_Naib]

Where I performed agricultural field survey a good number of the fields are far from what one might consider flat, so we couldn’t deploy Pix4DFields for that exact reason…

Looks like we’ve got some good company in this problem space, at least!

[pierotofy]

Image matching graph:

[pierotofy]

And resulting homography graph:

Edges indicate the direction that an homography chain can be built from one image to another.

[Saijin_Naib]

Would these be part of the Processing Report? These are not only interesting, but look like they might be helpful for debugging… Not sure how they’d scale with lots of images, however.

[pierotofy]

Probably not (although yes they are useful for debugging).

More screens:

[YanNoun]

Couldn’t you chain homographies across many different spanning-trees and average things in order to smooth drift across all directions ?

Like start with a random image, draw a random spanning tree (or a probabilistic one where each edge has a change to be sampled according to its weight, you also jitter edge weight to have more random-ness), chain along the tree, store the solution (cameras and points), repeat N times and average ?

[pierotofy]

Yes it’s definitely possible (and a good idea!), the only drawback is that computing the homograhy graph using the TRASAC algorithm is not the fastest (granted I still have to optimize / make it multithreaded). I have had some good successess using a single graph starting from the most central image in the matching graph (minimizing the hops required to compute the homography chain for all images) and then letting bundle adjustment fix the drift, but as I experiment more with larger datasets I could add this one too.

Code (experimental) is being published here: GitHub - pierotofy/OpenSfM at planar-mine (mostly in reconstruction.py)

[pierotofy]

First ortho looking great !

And another one:

[Saijin_Naib]

This is pretty incredible!

[Samdrone]

Beautiful.

[pierotofy]

And pull request: Planar Reconstruction by pierotofy · Pull Request #1452 · OpenDroneMap/ODM · GitHub

Planar algorithm published here: OpenSfM/reconstruction.py at 283 · OpenDroneMap/OpenSfM · GitHub