Sfm-algorithm: triangulation

My drone image contain data for pitch/yaw/roll for both drone and gimbal besides the gps data.

Is that enuf to use “triangulation”?


Looks like that’s all that’s needed!


I did only se lines about phi/gamma/kapa not the same as in the exif. Did I miss something

If your data is different and it doesn’t process properly, we might need to open an Issue or PR to get that style of EXIF supported.


For now, only DJI Yaw/Pitch/Roll tags are supported in ODM :

They also going to be supported natively in OpenSfM :

FYI, using triangulation algorithm results in 2x speed-up for the reconstruction part.

There’s also feature matching that can use angles, by setting all matching_XXX options to 0 and set matching_graph_rounds: 50. Should also work without angles if the camera is moderately tilted (0 < tilt < 30 degrees)


Is it useful for a consumer drone or is it more for a rtk-drone?

Tested on very high-end manned capture (similar to Ultracam) and also on a DJI Phantom 4.

1 Like

I have Mavic 2 Pro, I’m running a small test now.

The process completed but the result is horrible.
Might be that triangulation isn’t working for Mavic2Pro.

Images to share ?

1 Like


I have obtained similarly poor results using smf triangulation with Mavic 2 Pro images. For a comparison of incremental versus triangulation smf algorithms please see https://community.opendronemap.org/t/geolocation-files-versus-exif-and-omega-phi-kappa-versus-pitch-roll-yaw/9905/4 and https://app.box.com/s/6kngeyemqv02c2ytt5ydmuiv1o4co4rz

Any suggestions would be greatly appreciated.


The result I got wasn’t usable at all.

Could you share more original images ? There’s only one in the Box folder.

1 Like

It´s a small set, about 3 hours for computation.

My settings:
[{“name”: “auto-boundary”, “value”: true}, {“name”: “build-overviews”, “value”: true}, {“name”: “crop”, “value”: “3”}, {“name”: “debug”, “value”: true}, {“name”: “dem-resolution”, “value”: “2”}, {“name”: “dsm”, “value”: true}, {“name”: “feature-quality”, “value”: “ultra”}, {“name”: “feature-type”, “value”: “orb”}, {“name”: “gps-accuracy”, “value”: “10”}, {“name”: “matcher-neighbors”, “value”: “38”}, {“name”: “min-num-features”, “value”: “24000”}, {“name”: “orthophoto-resolution”, “value”: “2”}, {“name”: “pc-filter”, “value”: “5”}, {“name”: “pc-geometric”, “value”: true}, {“name”: “pc-quality”, “value”: “ultra”}, {“name”: “pc-sample”, “value”: “0,02”}, {“name”: “resize-to”, “value”: “-1”}, {“name”: “sfm-algorithm”, “value”: “triangulation”}, {“name”: “texturing-tone-mapping”, “value”: “gamma”}, {“name”: “use-hybrid-bundle-adjustment”, “value”: true}, {“name”: “verbose”, “value”: true}]


There’s clearly a conversion issue between the Mavic YPR → OPK that we didn’t have when trying with Phantom 4 data.

Summoning @pierotofy here.


Thanks for the quick reply.

I have uploaded 12 additional images in images.zip to the same Box folder.

Please let me know if I can help with anything else at this stage.


Make an announcement when you figured it out so we can try it.

1 Like

Based on my observations, it seems that DJI products do not have consistent conventions when it comes to yaw values. Yesterday for example I noticed that my Mavic Mini uses a different value to indicate north compared to a dataset I captured with a Phantom 3 Adv.

This will require sample datasets and a database to get the correct orientation for all models right. Ugh… DJI…


Starting a repository to collect sample images here: DJI OPK - Google Drive

If you have a DJI drone, please help?


Good idea @pierotofy. The conventions may be different for any and all 3 YPR angles.

Looking at the comments in your code at https://github.com/mapillary/OpenSfM/pull/838/files the following occurs to me.

            # YPR conventions (assuming nadir camera)
            # Yaw: 0 --> top of image points north
            # Yaw: 90 --> top of image points east
            # Yaw: 270 --> top of image points west
            # Pitch: 0 --> nadir camera**
            # Pitch: 90 --> camera is looking forward
            # Roll: 0 (assuming gimbal)

For the Mavic 2 Pro, Pitch 0 is a forward facing camera, Pitch -90 is a nadir camera. For example:

         Gimbal Pitch Degree             : -85.30

is the EXIF entry for my images taken with a pitch 5 degrees off nadir.