DSM are always not realistic very high values, output projection always UTM


Thanks for helping out!

Hmm, not sure if or how altitude would impact things during reconstruction, honestly. If the input Geolocation data is sane, the reconstruction should also be.

Is your reference DSM using values above Mean Sea Level or another vertical datum? Same for the sensor, is it doing Above Ground Level, above Mean Sea Level, etc?


Okay, that is reassuring. The geolocation data is sane.

The reference DSM uses the NAP vertical datum, common in (parts of) Western Europe, close to MSL I expect as it is a reference based on water level in Amsterdam.
I am not sure yet about the vertical datum of the sensor, looking into that now. However, with differing vertical datum one would not expect a difference in unit, right? There seems to be an approximate (exact?) factor 2 difference in unit between the reference DSM (meters above NAP) and the generated DSM.

1 Like

Our output products are always the most appropriate local UTM Zone, so they will be meters, so no, there should not be a unit difference if your local reference is also meters.

Clear. The vertical datum is in fact the same, so we should expect directly comparable values.

The large z-values get introduced during the openSfM stage. The generated reconstruction.json contains a sparse point cloud that already has z-values in the range of 2450 to 2550 meters.

The puzzling part is that DSM generation using the same input data goes fine using commercial software (Correlator3D), which makes me wonder where the issue could come from. We will continue digging for now.

If anyone (you? :slight_smile:) would be interested in playing with the data, I would be happy to share a few images accompanied by geo.txt.

1 Like

ZIP is corrupted or is it my MacBook ?

1 Like

Maybe try a download manager? 7zip tested it clean here locally.


This dataset is close to orthographic imaging condition due to high-latitude flight. Regarding the focal length : pixel pitch of 4 micron x 26460 pixels=0.10584 meter sensor size. Actual physical focal is 212.1 mm, so we have a focal ratio of 212.1/105.84=2.00396825397.

Principal point in X is 0.12mm, so c_x = 0.12/105.84=0.00113378684

The camera_model.json should be :

“vexcel imaging gmbh ultracam eagle mark 3 f210 26460 17004 brown 0.0 rgb”: {
“projection_type”: “brown”,
“width”: 26460,
“height”: 17004,
“focal_x”: 2.00396825397,
“focal_y”: 2.00396825397,
“c_x”: 0.00113378684,
“c_y”: 0.0
“k1”: 0.0,
“k2”: 0.0

Also, OpenSfM wasn’t able to read in the tif EXIF file, so the produced OpenSfM EXIF data has no altitude, thus no geo-referencing.

Let me know how it goes.



Thanks Yann for providing the json file,
we supplied the camera.json file and reran our process with default(–min-num-features values as 8k) and --min-num-features values as 40k, they failed with this setting
[ERROR] The program could not process this dataset using the current settings. Check that the images have enough overlap, that there are enough recognizable features and that the images are in focus. You could also try to increase the --min-num-features parameter.The program will now exit.

Best regards,

1 Like

Indeed, I had to hack a bit OpenSfM to make it work. OpenSfM has some watchdogs to avoid degenerate configurations (planar scene or rotation-only configuration) but that also prevent close-to-ortho configurations such as manned flight at high altitude with long focal length to bootstrap the SfM.

You’ll find a temporary fix here : GitHub - mapillary/OpenSfM at fix-adaptive-rotation-threshold


1 Like

Hi Yann, thanks for making this modification !!
and @Saijin… do you know where to make changes in order to point this git branch?

Best regards,

1 Like

Mei, I do not. We use our own fork with its own patches and changes, so reconciliation between the two is beyond me, unfortunately.

Given it will take some time for this to make its way downstream, do you think they could use incremental in order to trigger plane-based initialization built into that approach?

The reconstruction from two views can be done by two algorithms depending on the geometry of the scene. If the scene is flat, a plane-based initialization is used, if it is not flat, then the five-point algorithm is used. Since we do not know a priori if the scene is flat, both initializations are computed and the one that produces more points is retained (see the two_view_reconstruction_general() function).

1 Like

Dear community,
Our colleague tried two ways:
First, when the branch from “fix-adaptive-rotation-threshold” in OpenSfM is completely copied in Docker Container got below error:

[ec2-user@ip-10-0-3-61 ~]$ docker exec -it fd119644fa76 python3 /code/run.py --project-path /datasets project --dsm --geo /code/geo.txt --cameras /code/camera.json
Traceback (most recent call last):
File "/code/run.py", line 18, in <module>
from stages.odm_app import ODMApp
File "/code/stages/odm_app.py", line 10, in <module>
from stages.run_opensfm import ODMOpenSfMStage
File "/code/stages/run_opensfm.py", line 14, in <module>
from opendm.osfm import OSFMContext
File "/code/opendm/osfm.py", line 18, in <module>
from opensfm.large import metadataset
File "/code/SuperBuild/install/bin/opensfm/opensfm/large/metadataset.py", line 9, in <module>
from opensfm import io
File "/code/SuperBuild/install/bin/opensfm/opensfm/io.py", line 11, in <module>
from opensfm import context, features, geo, pygeometry, pymap, types
File "/code/SuperBuild/install/bin/opensfm/opensfm/types.py", line 23, in <module>
class Reconstruction(object):
File "/code/SuperBuild/install/bin/opensfm/opensfm/types.py", line 53, in Reconstruction
def get_biases(self) -> pymap.BiasView:
AttributeError: module 'opensfm.pymap' has no attribute 'BiasView'

Second, we tried only copied the file with recent changes to docker file ( reconstruction, exif, vlad, dataset,
feature_loading, masking, matching, reconstruction_helpers, dataset_base, pairs_selection,
actions/detect_features, commands/command_runner)
then got following errors:

  1. In pairs_selection.py at line 563, it is expecting value for “matching_graph_rounds” key. This key was not their in previous version and had commented all the relevant lines in pairs_selection.py

  2. Next, the script now fails with an error:

Namespace(command='match_features', dataset='/datasets/project/opensfm', dataset_type='opensfm')
Traceback (most recent call last):
File "/code/SuperBuild/install/bin/opensfm/bin/opensfm_main.py", line 15, in <module>
File "/code/SuperBuild/install/bin/opensfm/opensfm/commands/command_runner.py", line 38, in command_runner
with dataset_factory(args.dataset, args.dataset_type) as data:
AttributeError: __enter__

Can you please guide, how to approach here and fix these issues?

1 Like

Hi All,

We are able to manually identify all the changes from “mapillary/OpenSfM” branch “fix-adaptive-rotation-threshold” and add them in the Docker file except for the files with an extension “.pyi” files.

The .pyi files are converted to cpython-39-x86_64-linux-gnu.so extension file.

At moment, ODM fails with below error:

File “/code/run.py”, line 18, in
from stages.odm_app import ODMApp
File “/code/stages/odm_app.py”, line 10, in
from stages.run_opensfm import ODMOpenSfMStage
File “/code/stages/run_opensfm.py”, line 14, in
from opendm.osfm import OSFMContext
File “/code/opendm/osfm.py”, line 18, in
from opensfm.large import metadataset
File “/code/SuperBuild/install/bin/opensfm/opensfm/large/metadataset.py”, line 9, in
from opensfm import io
File “/code/SuperBuild/install/bin/opensfm/opensfm/io.py”, line 114, in
def bias_from_json(obj: Dict[str, Any]) → pygeometry.Similarity:
AttributeError: module ‘opensfm.pygeometry’ has no attribute ‘Similarity’

It is expecting Class “Similarity” in pygeometry.cpython-39-x86_64-linux-gnu.so file (In master branch of mapillary/opensfm repo this class is there in pygeometry.pyi file).

Can you please help with either solution?

  1. Help with the command to generate cpython-39-x86_64-linux-gnu.so files for all the .pyi files?

  2. Or merge the main branch of mapillary/opensfm in OpenDrone/Opensfm repo?

Just for information, OpenDrone/Opensfm is considerably out of sync with Mapillary/OpenSFM main branch and to spend considerable time to identify gaps and fix them.

Yes, we added quite a lot of new things also in the C++ code under opensfm/src (Similarity is one of them)

1 Like

Can you help with the command that generates .so files for these sets of .pyi files?

Dear ODM Team,

We are trying to build a docker image by updating GIT Repository(line 21) value " GitHub - OpenDroneMap/OpenSfM: Open source Structure from Motion pipeline" in ODM/External-OpenSfM.cmake at master · OpenDroneMap/ODM · GitHub file with “GitHub - mapillary/OpenSfM: Open source Structure-from-Motion pipeline” main branch but fail.

Please advise, how to create with Docker Image using “GitHub - mapillary/OpenSfM: Open source Structure-from-Motion pipeline” repo?

Hi Saijin, Sam,

Any update or thought?

This is tough:
OpenDroneMap/OpenSfM at 265 (github.com)

This branch is what ODM 2.6.5 is using, so compare that, but still, we carry patches and other customizations that are different from upstream OpenSFM.

I don’t know that one can just swap in unmodified upstream OpenSFM at this point.