Odm: Dome distortion on reduced size image calcs of large area

[KommandorKeen]

I mapped 52 hectares in 20 mins with my DJI phantom 4 flying at 10m/s at 110m altitude.
I have processed the data in ODM and Photoscan.
Photoscan High resolution point cloud yields 123M points and looks like this:

Photoscan Medium resolution point cloud yields 23M points and looks like tis:

ODM resize to 2000 pixels yields a similar number of points and produces a similar doming:

The 340 images take all night to process (11:47) using GCPs (scaled to fit the 2000x1500 image size) and the following options:
Options: mesh-octree-depth: 8, min-num-features: 10000, force-focal: 3.61, resize-to: 2000, pmvs-threshold: 0.7, force-ccd: 6.24, orthophoto-no-tiled: true, mesh-size: 1000000, matcher-distance: 200, verbose: true, dem-radius: 2, dem-sample-radius: 5, dem: true, opensfm-processes: 1

I probably have the memory to try full size images (40GB) but does anyone have any other suggestions?

[KommandorKeen]

ODM full size images still have same dome effect, slightly reduced.

[dakotabenjamin]

I've found that flying a cross-grid pattern reduces the dome effect due to the different camera angles. This does not reduce the need to find a solution in software, however. I'm going to label this issue as a bug because I don't think there's a current solution.

[KommandorKeen]

Will try the grid solution, thanks.

[merkato]

Maybe it's silly, but... I'm wondering, if we can use EXIF GPS tags, and GCP's in one run. I can try to prepare some dataset with both...

[dakotabenjamin]

A GCP file will override and ignore any EXIF data as it stands right now.

[DurhamPC]

Doming issues have to do with camera calibration and are mode influenced by how you fly than by the code. Even Photoscan will dome like crazy if you feed it bad imagery with a poor network geometry. Fly with oblique views, forget the old fashion approach of having the camera pointing down all the time. go to google scholar and have a look at the work of Mike James at Lancaster uni and me (Patrice Carbonneau at Durham uni).

[dakotabenjamin]

I should update the wiki with good flying practices for getting good data.

That being said some corrections can be made software side, so long as good enough data exists.

[LucasMM86]

I was reading about SFM here: http://carlos-hernandez.org/papers/fnt_mvs_2015.pdf
and I found this:
"The bundle adjustment framework enables the combination of mul-
tiple sensors with the SfM objective in a principled optimization frame-
work. One way to fuse GPS and IMU constraints with SfM constraints
is to simply add additional terms to (1.2) that penalize deviations of Pi
from the predicted camera models from the GPS and IMU signals."

In other words, the bundle adjunstment (last process of the SFM pipeline) could take into acount that we were flying at constant altitude (... not necessary constant, but known altitude...) and force the camera positions to be near the corresponding GPS position from exif.

In openSfm I found this (https://github.com/mapillary/OpenSfM/blob/master/opensfm/config.py):
"bundle_use_gps: yes # Enforce GPS position in bundle adjustment
bundle_use_gcp: no # Enforce Ground Control Point position in bundle adjustment
"

Are this parameters realy implemented in OpenSfm?
If the answer is yes, could this be also used in ODM?

[dakotabenjamin]

Yes this will be implemented very soon. I'm working on it now.

[LucasMM86]

Thanks Benjamin. So the parameteres does work on openSfm? and are going to be available in ODM? I like the idea of having more openSfm parameters (maybe all parameters) custommizable inside ODM. Maybe a sort of parameters for advanced users.

[dakotabenjamin]

See #628 for some info on the changes coming. Note that the self-calibration in bundle adjustment is only part of the problem, much of it is a data collection issue. Taking more oblique photos at converging angles has been shown to greatly reduce doming: http://onlinelibrary.wiley.com/doi/10.1002/esp.3609/epdf thanks to @DurhamPC for pointing this out

[KommandorKeen]

Flew the same area today and for a few of the legs tilted the camera slightly forwards, then ran a few low density cross lines with camera tilted 20 degrees up from vertical. The result? Perfect!
I think we can close this issue but update the wiki with good flying practises.

[LucasMM86]

Hello, i would like to share my small experience with "bundle_use_gps" parameter in opensfm:
The dataset is suposed to be of a relative flat region.
Changing manualy 'bundle_use_gps' to 'yes' (in file Superbuild/src/opensfm/opensfm/config.py) there is a little better flatness (less dome effect).
Then i changed the gps_dop from 15 to 1. My images have no GPS dop (dilution of precision) in the exif, so i changed it in file Superbuild/src/opensfm/opensfm/reconstruction.py, line 212. Now the flatness is much better. There are also less points, but notice that i used pmvs and --resize-to 500 in order to run it fast.
In the picture below you can see the 3 point clouds with different amount of dome effect.

[dakotabenjamin]

That's amazing! So you manually updated opensfm right?

Did you try enabling the following tags:

use_altitude_tag: True
align_method: naive

They should be changed together. I should have a PR soon with these.

[LucasMM86]

Yes opensfm paremeters were updated manually.
One important thing is that the dop should be in the exif of the images (or changing it manualy to a low number works also). If not, opensfm takes dop=15 as default and doesn't take the gps positions to much into account. Seems that opensfm uses dop as a weighting factor for the gps positions.

My last results were with
use_altitude_tag: no
align_method: orientation_prior
I will try with it use_altitude_tag: yes and align_method: naive later if i have the ime.

[kikislater]

Amazing ! Nice catch.

[dakotabenjamin]

644 has an option for diabling self-calibration and the altitude tags will be used if photos have altitudes in their exif.

[dakotabenjamin]

644 has been merged now