Geo-referencing Inaccurate

pierotofy · 19 October 2017 20:56

From @dsandson on Tue Aug 29 2017 15:16:59 GMT+0000 (UTC)

I’ve been trying out WebODM for a little while now, and trying to gain enough knowledge to incorporate it into my work.

I have installed Ubuntu 16.04 LTS, and got WebODM up and running in Docker.

I gathered a data set with RTK GPS surveyed GCPs, then used the recommended technique of loading the images in QGIS & building a GCP list.txt file, with coords set to EPSG:29902 (Irish Grid). I also realise that georeferencing has issues with the default image resizing, so I’ve ran the process with ‘skip-resize’.

When the process has finished I have loaded the original GCPs in QGIS, alongside the orthophoto, both set to EPSG:29902. However I would expect the GCPs visible on the ortho to align with the point layer GCPs. However they are out by between 8.9-12.4 meters.

The process was run with the following flags;
min-num-features: 8000, mesh-size: 150000, dem-terrain-type: ComplexNonForest, skip-resize: true, use-25dmesh: true

I’ve checked the gcp file, with the original survey coords and they’re correct. also double checked the image coords. Cant see what else is incorrect.

I’ve used the following guidance on compiling the GCP file;

Not sure if this is up to date, or if theres a new improved technique.

Screenshot from QGIS and WebODM log (hopefully) attached, as well as GCP file. I can provide a link to the raw images if needed.

Regards
David

Copied from original issue: Geo-referencing Inaccurate · Issue #276 · OpenDroneMap/WebODM · GitHub

pierotofy · 19 October 2017 20:56

From @dsandson on Tue Aug 29 2017 15:21:17 GMT+0000 (UTC)

Sorry, uploads didnt attach to files linked below

pierotofy · 19 October 2017 20:56

From @pierotofy on Tue Aug 29 2017 18:39:46 GMT+0000 (UTC)

Mm, this could be a software fault. What happens if you use UTM coordinates for the GCP file? The fact that the georeferencing is off by a few meters might be a problem related to reprojection.

pierotofy · 19 October 2017 20:56

From @dsandson on Tue Aug 29 2017 19:22:00 GMT+0000 (UTC)

Thank you Piero,

I’ve loaded another orthophoto produced using just the exif data from the onboard gps, and they’re about 0.5m out as I’d expect.

We don’t use UTM often, but I’ll convert the coords to ED50 UTM 30N in qgis in the morning and see How it works out.

pierotofy · 19 October 2017 20:56

From @dsandson on Wed Aug 30 2017 13:00:15 GMT+0000 (UTC)

Well,

I converted the GCP coords to ED50 UTM 30N EPSG:23030 in QGIS, and with reprojection on-the-fly enabled it showed the new point layer as perfectly overlapping the existing points in Irish Grid (29902).

Transferred the new coords into the GCP_list.txt file and amended the EPSG code, and the output still exhibits the same X&Y error once imported into QGIS, with both layers loaded as EPSG 23030.

Photos and associated GCP files are linked below;
https://drive.google.com/file/d/0B7_UoiZt_fsyVE9XLUFVMDNScFk/view?usp=sharing

Regards
David

pierotofy · 19 October 2017 20:56

From @pierotofy on Wed Aug 30 2017 13:13:57 GMT+0000 (UTC)

Thank you for trying. If my analysis is correct, I think the problem is instead related to the datum used (in this case, ED50). I don’t think OpenDroneMap currently handles well datum different than WGS84.

github.com

OpenDroneMap/ODM/blob/ea5aeef213354a56e2c0a4296e236c4c53885161/modules/odm_extract_utm/src/UtmExtractor.cpp#L219


      
            dy = floor(dy);
          
          
  // Open output file
            std::ofstream outputCoordStream(outputCoordFileName_.c_str());
            if (!outputCoordStream.good()) {
              throw UtmExtractorException("Failed to open " + outputCoordFileName_ + " for writing.");
            }
            outputCoordStream.precision(10);
          
          
  // Write coordinate file
            outputCoordStream << "WGS84 UTM " << utmZone << hemisphere << std::endl;
            outputCoordStream << dx << " " << dy << std::endl;
            for (std::vector<Coord>::iterator iter = coords.begin(); iter != coords.end(); ++iter) {
              outputCoordStream << (iter->x - dx) << " " << (iter->y - dy) << " " << iter->z << std::endl;
            }
          
          
  outputCoordStream.close();
          }
          
          
bool UtmExtractor::convert(const double &lon, const double &lat, const double &alt, double &x, double &y, double &z, int &utmZone, char &hemisphere)
          {

github.com

OpenDroneMap/ODM/blob/1385ab12168adc6df34b5c2f274dbc3a78d186d3/opendm/types.py#L290


      
              return
          
          
with open(_file) as f:
              # extract reference system and utm zone from first line.
              # We will assume the following format:
              # 'WGS84 UTM 17N'
              line = f.readline()
              log.ODM_DEBUG('Line: %s' % line)
              ref = line.split(' ')
              # match_wgs_utm = re.search('WGS84 UTM (\d{1,2})(N|S)', line, re.I)
              if ref[0] == 'WGS84' and ref[1] == 'UTM':  # match_wgs_utm:
                  self.datum = ref[0]
                  self.utm_pole = ref[2][len(ref) - 1]
                  self.utm_zone = int(ref[2][:len(ref) - 1])
                  # extract east and west offsets from second line.
                  # We will assume the following format:
                  # '440143 4588391'
                  # update EPSG
                  self.epsg = self.calculate_EPSG(self.utm_zone, self.utm_pole)
              # If the first line looks like "EPSG:n" or "epsg:n"
              elif ref[0].split(':')[0].lower() == 'epsg':

@dkbenjamin can you confirm this? If so I’ll go ahead and open an issue under the ODM repository.

pierotofy · 19 October 2017 20:56

From @dkbenjamin on Wed Aug 30 2017 13:57:07 GMT+0000 (UTC)

If they used the EPSG code then it shouldn’t be an issue. ODM/types.py at 1385ab12168adc6df34b5c2f274dbc3a78d186d3 · OpenDroneMap/ODM · GitHub

For something to be a few meters off maybe it’s a floating point precision issue from the conversion?

pierotofy · 19 October 2017 20:56

From @dkbenjamin on Wed Aug 30 2017 14:01:53 GMT+0000 (UTC)

@dsandson you may want to try to calibarate your images. Distortion from each image will propagate in error in the orthophoto which might lead to further issues. I see issues like this a lot with DJI cameras especially.

See: GitHub - dakotabenjamin/CameraCalibration

Note that you will have to redo the GCP file because removing distortion will change to pixel locations.

pierotofy · 19 October 2017 20:56

From @dsandson on Wed Aug 30 2017 15:15:44 GMT+0000 (UTC)

dakotabenjamin thank you, I’ll give that a go. Looks like that might be a useful addition to ODM/WebODM too.

I’d be surprised if that was the only issue. As I said using only the WGS84 coords from the EXIF data produces errors in the range of 0.5m.

This may take a few days to get done.

0x906 · 14 February 2018 20:35

Do we have any news about this issue? I’m facing the same problem. I collected about 10 images and I used ground control points surveyed by Trimble R10. I processed the images using WGS84 UTM 13N zone (New Mexico) and my control points are off by 4 to 12 meters. Any idea why this is happening?

dsandson · 15 February 2018 12:29

Interesting timing! I have just recently got WebODM installed on my work pc and have rerun this dataset using the latest build. Just loaded the results up in QGIS a few mins ago and the error now seems to be between 10 to 20cm.

I don’t know if I’ve seen things correctly, but think that the georeferencing system has changed into the OpenSFM module so that may have improved things.

I need to set up the camera calibration software now and see if that removes the rest of the error.

Have you checked that the GCP file has image coords measured from the top left of the image, all in integers, no + or mins signs, and each GCP referenced to at least 3 images?

I can upload the full dataset for you to download & test yourself if you like?

dsandson · 15 February 2018 12:37

Heres the full data if you need it. Images are uncorrected. Ran via high quality, min_num_features=10000.

0x906 · 15 February 2018 14:13

Appreciate the response. I run my dataset through the command line. I still see the 0.3.1 version on github dated back on May 2017. Am I missing something? I thought the WebODM was just a frontend for the ODM itself. My installation is few months old, maybe last summer or so. It’s not enough If I pull the ODM again from github?

BTW, I do not see your attachment. It would be interesting to see what the 2 versions are doing in terms of accuracies.

Thanks again!

EDIT: Ok, I see 187 commits after the release day of ODM 0.3.1. I have it installed via command line and configured it on a remote server running Ubuntu 14.04 LTS. I think I have to go through docker installation of ODM to get the latest of the commits and try my data set again.

dsandson · 16 February 2018 09:24

0x906

Sorry, link below.

https://drive.google.com/open?id=1O3qjfMb15dt-JnY_1qZXp1mZumuQ5otV

I’d highly recommend using the latest versions. Be careful though, I beleive the current version will only run on Ubuntu 16.04 LTS, which is what I’m running on. You should get the same results though regardless whether you use WebODM or command-line to ODM. Let us know how you get on.

0x906 · 16 February 2018 20:35

Thanks for the answer. Please allow me some comments while I am trying to grasp how this thing is working.

I went ahead using docker and I processed your dataset. I only changed the name of the GCP_list.txt to gcp_list.txt and I placed the images inside /images folder. The command I used is the following:

docker run -it --rm -v $(pwd)/images:/code/images -v $(pwd)/odm_orthophoto:/code/odm_orthophoto -v $(pwd)/odm_texturing:/code/odm_texturing opendronemap/opendronemap

The dataset finished successfully but it didn’t detect the gcp_list.txt. So, no ground coordinates for the orthorectification others than those the DJI GPS system provided.

I placed then orthophoto and your GCP file in QGIS and indeed the control points were about 30-40cm off. Your whole orthophoto is covering an area of 240m so, since we have a UTM projection and it has a scale accuracy of about 1:1000 you expect an error in your dataset of about 24cm. Add here the error from the GPS system that you used to get the control points and you are more or less good with the results. Everything makes sense.

How is this possible? The DJI GPS system accuracy should be about 1m to 1.5m unaugmented even with active GLONASS and GPS constellations. Is there any chance the ODM is indeed using the gcp file provided but is reporting:

[WARNING] No coordinates file. Generating coordinates file: /code/odm_georeferencing/coords.txt ? Because only then the results would have been making sense.

Then I tried the same command but forcing the use of the gcp file like this:

docker run -it --rm -v $(pwd)/images:/code/images -v $(pwd)/odm_orthophoto:/code/odm_orthophoto -v $(pwd)/odm_texturing:/code/odm_texturing opendronemap/opendronemap --gcp /home/py/UAV/Garvagh/gcp_list.txt

and the system, while it detected succesfully the gpc file, failed for the following reason:

Error in Georef:
Failed opening gcp file /home/py/Garvagh/gcp_list.txt for reading.

[ERROR] Georeferencing failed.
Traceback (most recent call last):
File “/code/scripts/odm_georeferencing.py”, line 150, in process
‘-outputCoordFile {coords}’.format(**kwargs))
File “/code/opendm/system.py”, line 34, in run
raise Exception(“Child returned {}”.format(retcode))
Exception: Child returned 1

I tried also to mount the file as volume through the -v /home/py/Garvagh/gcp_list.txt command but nothing changed.
I tried to check the possibility of folder permissions kicking in, but nothing. All looks good.

What is the best way to force the use of gcp file? Any help would be greatly appreciated.

0x906 · 17 February 2018 06:13

Ok, I installed the WebODM on a Mac running OSX Sierra having 64G Ram. I processed my images successfully including the gcp file.

The issue now is the final orthophoto. It’s flipped, kind of a mirror of the place.

0x906 · 18 February 2018 03:16

That’s probably the final update of the project, so I am going to give a more clear path of what I did, just for the purpose of documentation.

The area located in New Mexico, United States, EPSG:32613. The covered area is about 100m x 70m, and I collected 10 images from an altitude of 30m.
I also received 3 control points surveyed with a Trimble R10 system. The distribution of the points is mostly close to the points of interest. The surveyed datum used is the WGS84, with the Earth Gravitational Model 2008. The system was capable of receiving GPS, GLONASS and Galileo signal along with WAAS augmentation. The visible satellites were between 20-24 all the time.
I converted the Lat, Lon using the UTM module in a python (jupyter) script. Here is a warning. If you try to use Microsoft Excel, the accuracy of your points will be reduced to 2 fractional digits. We need at least 4 fractional digits for increasing the accuracy of the results.
Using the ImageJ (Fiji) software (open source) I opened each of my images to identify which pixel corresponds to my control points. Then I created the gcp_list.txt file with the proper format (Easting, Northing, Elevation, PixelX, PixelY, Image Filename). Easting and Northing have 4 fractional digits precision while elevation has 3 digits accuracy.
I processed the images with high-quality settings.

Results: The precision between the surveyed ground control points and the ground markers visible at the imagery is between 2cm to 4cm. The RMSE is 2.78cm.

The ipython script(-ish) I used:
import utm
GridA = utm.from_latlon(00.00000000, -00.00000000) # change the 00.0000000 with your coordinates
GridB = utm.from_latlon(00.00000000, -00.00000000)
GridC = utm.from_latlon(00.00000000, -00.00000000)
‘GridA {:}’.format(GridA), ‘GridB {:}’.format(GridB), ‘GridC {:}’.format(GridC)

The utm module: utm · PyPI

Fiji - https://fiji.sc/

dsandson · 19 February 2018 13:54

Hello again,

not sure why my data set would appear flipped. I’ve heard of people reporting this. Perhaps the image calibration would help.

Not sure i can help you any more than this. If you copy your replies into a new thread then one of the lead developers is quite regular on here, and he should comment fairly quickly. His name is Piero Toffanin.