GCPs not aligning, up to 0.5m error

Hello folks,

I am experiencing bad results in my last processing job, the GCP are not aligned in the orthophoto, with RMS error = 0.123m according to the report.

I have double checked the gcp.txt and the pixel selection is perfect, I have no idea what is causing this issue, almost all gcp are off, the flight pattern was not bad and the gcp coordinates was collect properly.

Here is my dataset:
https://drive.google.com/drive/folders/1Oh6mckrOdT_2RvJAaEo7fHcV9_LxnVlH?usp=sharing

And here is the WebODM Lightning output:
https://wln1.nyc3.cdn.digitaloceanspaces.com/872287fe-a380-4df0-9420-c02a4d169604/all.zip

Any insights about what could be causing this issue?

image
image
image
image
image
image
image
image
image
image
image
image

1 Like

This is the same type of “circular” error I’m seeing. I would love to know what’s causing this.

2 Likes

Thanks for providing this all!

I’m testing your and SkyView’s data to see if my ideas are headed the right direction or not.

A have some important new information to add!

I have processed this same dataset in Agisoft Metashape for a sanity check and I obtained similar results: almost all gcp are out, some up to 1-2m… in Metashape I was able to better understand each gcp effect, some of then does not looked good, causing several outliners in the sparse cloud, so I discarted those gcp and reprocessed in metashape using only 7 of the original 12 gcps, this is the results:

MetashapeReport.pdf (1.4 MB)
(check Table 4, the gcp are very well aligned)

However, as expected, the discarted gcp, now been used as verification points are completely off:

WhatsApp Image 2021-09-08 at 21.16.52 (4)
WhatsApp Image 2021-09-08 at 21.16.52 (3)
WhatsApp Image 2021-09-08 at 21.16.52 (2)
WhatsApp Image 2021-09-08 at 21.16.52 (1)
WhatsApp Image 2021-09-08 at 21.16.52 (3)

So, I guess, maybe, at least in my case, there is nothing wrong with WebODM, instead the most probable cause is the accuracy of the collected GCPs (at least some of them).

I was not responsible for the field operation and now I have started asking questions to the guy who did it. I also asked another colleague to take a look.

Thanks again for the help, I will keep you updated.

3 Likes

Thanks for further testing/confirmation!

Another wrinkle in all this:
Was the sUAS stopping to take each image, or was it moving the entire collect? If so, I’m wondering if Rolling Shutter distortion isn’t biting us and MetaShape in the rear here… Pix4D should be able to correct for it when Rolling Shutter Compensation is forced on, but I don’t have a license anymore to test :frowning:

1 Like

The images were collected in movement, so there is Rolling Shutter effect.

Here is another report of the dataset processed in Pix4D:

Pix4DReport.pdf (1.5 MB)

All gcp are very well centered!

So I no longer suspect there is something wrong with the dataset (both photos and GCPs) there must be something with me or WebODM.

1 Like

Thanks for providing that.

Can you re-run with forcing the Rolling Shutter Compensation for your camera model to “on”?

That 5% difference between initial/optimized seems high, and I think the Rolling Shutter Compensation should reduce that greatly, and therefore, hopefully, a bit more inaccuracy will be resolved.

I can’t, I don’t have Pix4D too. Someone else processed it and just sent me the report.

1 Like

Ah, gotcha. Well thank you (and them)!

image


Original:

**Options:** cog: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 1, dsm: true, matcher-neighbors: 16, mesh-size: 300000, min-num-features: 16000, orthophoto-resolution: 1, pc-classify: true, pc-ept: true, pc-geometric: true, pc-quality: high, use-3dmesh: true, verbose: true

report.pdf (7.9 MB)

image

image

0: 1.017m
1: 0.137m
2: 0.346m
3: 0.148m
4: 0.473m
5: 0.478m
6: 0.368m
7: 0.158m
8: 0.427m
9: 0.474m
10: 0.150m
11: 0.169m

Pre-Processed 03m:

**Options:** cog: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 1, dsm: true, gps-accuracy: 3, matcher-neighbors: 16, mesh-size: 300000, min-num-features: 16000, orthophoto-resolution: 1, pc-classify: true, pc-ept: true, pc-geometric: true, pc-quality: high, use-3dmesh: true, verbose: true

report.pdf (7.9 MB)

image

image

0: 1.098m
1: 0.189m
2: 0.300m
3: 0.221m
4: 0.418m
5: 0.427m
6: 0.305m
7: 0.157m
8: 0.599m
9: 0.259m
10: 0.171m
11: 0.268m

That is to say, I’m not sure. Pre-Processing and constraining the GPS accuracy to the more realistic X/Y of 3m very slightly worsens the reported accuracy, though it “looks” closer in many instances.

Looking at the Pix4D report, this is likely due to the bias in the camera GPS. Pix4D computes and adjust for any bias that might occur (likely in altitude, can be seen in the GPS mean error on Z and also a bit of Y components) between the GPS and GCP sensors.

Since feat: bias transform in SfM · mapillary/OpenSfM@6e20d7c · GitHub , OpenSfM now also compute and adjust for such bias and also put it in the report as well. By default, however, it is not activated, but can be set with the option bundle_gps_bias_compensation to true in OpenSfM config.yaml.

We tested it a bit and it can dramatically improve GCP error on datasets with big GPS bias in the image/drone (from meter to centimeter error). It would be nice, if you could test this fucntionality on this dataset, however, I’m not sure which OpenSfM version/commit ODM uses these days.

ping @pierotofy

1 Like

Ah, beautiful. Thanks, Yan!

I’ll see if I can try it locally.

Edit:
Whoops. No idea what happened to the config.yaml in our fork.

Thanks @YanNoun, I’ll take a look in the upcoming days. :pray:

It’s a bit strange though, because by default we set bundle_use_gps to false when we detect a GCP file.

2 Likes

Ho, I didn’t know that, then compensation will not help in that case.

Got 0.074/0.085/0.078 X/Y/Z error with bias compensation.

1 Like

That is amazing!

Hum, interesting, could you share the results, please? Or at least the report and some pictures of the GCP in the ortho.

2 Likes

Also try to update to the latest version and reprocess; yesterday I pushed a change to ODM that should improve this. :pray:

2 Likes

Hello,

In the first try the report indeed shows a much lower error for GCP, however I don’t see much of a change in the ortho.

image

GCPs still looks not aligned by the same amount:

image
image
image
image
image
image
image
image
image
image
image
image

Results from Lightning v 2.6.3:
https://wln2.sfo3.cdn.digitaloceanspaces.com/972d3fc8-44b9-4f67-8f9e-19904ed8b8f6/all.zip

report 2.6.1.pdf (9.6 MB)

report 2.6.3.pdf (9.5 MB)

I also noted, the new ortho is a little bit slower to open in QGIS before generating overviews and the 3D maps (points cloud and texture model) didn’t open in WebODM (for Windows 1.9.3 build 30) at all… no idea if this is related to Lightning v2.6.3 or not.

How are you checking the GCP results?

Did you try to import the ground_control_points.gpkg file in QGIS and overlay it on the orthophoto?

1 Like