Align by DGPS positions in images in SfmTransform - test with DJI drone images for example

[belveder79]

Description

The changes were made to the SfmTransform executable mainly, plus building the dependency GeographicLib from public github repo, and having the feature ON/OFF in the main cmake configuration depending on GeographicLib being available (either built from the dependencies) or the system. The mode aligns the reconstruction using a Ceres implementation and a Huber Loss Function to the x/y/z coordinates given by the GPS coordinates (in metric UTM). The reconstruction ends up in a local coordinate system. The global center coordinates are stored in a separate file.

Features list

• [X] Adds a switchable dependency on GeographicLib which determines if the feature is available or not.
• [X] SfmTransform can now use an additional method gps2utm to align to good GPS positions in images. Good means for example from DJI drones, which are +/- 20cm off, or DGPS measurements work as well. Having all 3, latitude, longitude and altitude in the Exiv-Tags of the images is mandatory.
• [X] The alignment is based on a transform to an UTM coordinate system. The GeographicLib automatically returns the correct system when the latitude/longitude are provided. The mean of right/up/sky is calculated and removed to put the reconstruction into a local metric coordinate system again. The mean and UTM EPSG zone is stored into a new file localcenter.json in JSON format, which can be used later for global alignment.
• [X] The SfmTransform is supposed to plug in between the StructureFromMotion and DepthMapPrepare Node in Meshroom. It estimates scale, translation and rotation. Matlab code for verification is available too if needed.
• [X] For whatever reason the alignment is correct, but the "final" alignment of a textured reconstruction (i.e. at the end of the full Photogrammetry pipeline) has flipped axes. It is still right-handed, but Y/Z are inverted. Therefore the SfmTransform node applies a second transform right after the alignment to invert Y/Z. That gives the correctly textured 3D model which is in a local coordinate system, but globally aligned with correct right/up/sky coordinates. This can be verified in Meshlab (+z is sky, +y is up, i.e. towards north pole on the northern hemisphere, and +x is right).

Implementation remarks

Depending on the real use case, one might want to make additional modifications like (not implemented):

• [] the final transform (inversion of Y/Z) optional with a flag (not implemented right now). If the goal is to do some localization, because this might be broken by inverting the Y/Z coordinates in the sense that the localization result is not the real UTM coordinate. The goal was to have the textured model aligned correctly, not the sfm.abc file at the end of the SfmTransform node. The best might be to have 2 files stored, one for making the textured model "correct" and one to have the correct alignment for localization.
• [] passing a variable to the executable to store the local UTM center in a file named by the user
• [] make the algorithm robust wrt. data spanning 2 zones, which might be rarely the case, however.
• [] alignment chooses poses only which have valid GPS Exiv tags. Probably testing with missing tags would be an option, but this is really artificial if one uses DJI drone footage.
• [] adding initial parameters to the algorithm could help in alignment (i.e. if an initial camera should be chosen as for the coordinate system instead of the mean of all camera coordinates). Again, this is merely optimization. One could think of more stuff.

The alignment was tested on 2 sets of images from DJI Mavic drone footage and shown to work very well.

[belveder79]

thx for the comments. I'm going to review your suggestions and update the request accordingly.

Yes, it has certainly something to do with the coordinate system convention used. It does not convert left-right handed or something, it is a pure 180° rotation around the x-axis. The inversion essentially makes z point to the sky and x/y correspond to right/up in the UTM coordinate system (which is still right-handed). From that point on it is also correct metric scale if it was not before.

Admittedly, the rotation actually makes the visualization in Meshroom look a bit odd, which (I believe) assumes z to be forward and y point down. In a MeshRoom pipeline, the SfmTransform would plug in right after the StructureFromMotion node and before any (I don't recall the exact names) PrepareDense node. That makes the entire textured reconstruction at the very end of the pipeline correct.