GCPs not aligning, up to 0.5m error

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

No, I was using the GCP coordinates in .txt that were used to create the gcp.txt file used in the processing.

The alignment in the ortho does not change much when looking at ground_control_points.gpkg…
Grey = original GCP
Yellow = from gpkg file

image

image
image
image
image
image
image
image
image
image
image
image

1 Like

The GCP file might have some errors. For example, the tagged images did not seem to be properly centered for certain GCP points:

image

Triple check your ground control point file. Perhaps start with fewer points (5 GCPs are sufficient, with 3 images per GCP), so a total of 15 lines.

2 Likes

What kind of sorcery is this?

I was not able to replicate your screen, this is what I got using Lightning online GCP Interface:
image

However, this is what I get using WebODM for Windows GCPi, seens perfect, this is tool I used:

DJI_0692.JPG
image

DJI)0694.JPG
image

I also get the same result when using the client WebODM Lightning.

I will create a new gcp file using the Lightning online tool and reprocess. Could you try to replicate my results using both WebODM for Windows and the WebODM Lightning client, please?

Looks like a few images are missing from your upload to Google Drive. They comprise 2/3 images for tagging GCP01, so it should be dropped from the gcp_list.txt
image

I’m also finding, like Piero, that some of the tagged pixel locations can be pretty varied. Manually tagging is hard, though, so it isn’t super uncommon.
image

Yep… I haven’t developed POSM GCPi, so I can’t really be sure why it didn’t tag the images correctly. I would trust the GCP tool on Lightning better. (Disclaimer: my company, UAV4GEO, wrote the tool).

1 Like

I still don’t understand why I see such a difference when opening in Lightning a file originally created in POSM GCPi…

Anyway, I created a new gpc file, I see improvement, the rGCP error in the report looks good, however they are still not aligned!

70000.PNG
70001.PNG
70002.PNG
70003.PNG
70004.PNG
70005.PNG
70006.PNG
70007.PNG
70008.PNG
70009.PNG
700010.PNG
700011.PNG

Checking in QGIS:
Grey = original GCP
Yellow = from gpkg file
70000
70001
70002
70003
70004
70005
70006
70007
70008
70009
70010
70011

image

report.pdf (9.3 MB)

Download link for the results:
https://wln2.sfo3.cdn.digitaloceanspaces.com/34011b34-a539-4dd3-a90f-287ea13ed0bb/all.zip

OBS: I have updated the dataset, number of photos rised from 390 to 433.
https://drive.google.com/drive/folders/1Oh6mckrOdT_2RvJAaEo7fHcV9_LxnVlH?usp=sharing

1 Like