GCPs not aligning

#1

I don’t know if this is a southern hemisphere issue or not, but when I use GCPs the alignments are significantly worse that without it. Here’s what I’m talking about:
Without GCP:
https://survey.nwk1.com/public/task/625ea9fd-e047-4e4f-87a2-657a1d18dd80/map/

With GCP:
https://survey.nwk1.com/public/task/bb9286e2-3236-46b8-beb2-68848bfe2097/map/

+proj=utm +zone=60G +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs
373579.113781435 5453764.93337272 62 93 443 1604E2C0_545D_11E9_A65C_31FF18339E5A.JPG
373579.094333286 5453764.63310408 62 82 376 1667E76C_545D_11E9_A29C_34FF18339E5A.JPG
373651.690547535 5453678.97649911 61.9 480 276 4208F442_545D_11E9_B908_C9FF18339E5A.JPG
373654.536549364 5453676.44791605 61.9 357 178 4890C1F0_545D_11E9_8467_050019339E5A.JPG
373651.42149942 5453677.83868497 62 366 250 48933C96_545D_11E9_B2A0_020019339E5A.JPG
373609.996267733 5453674.42918769 62 99 119 48933C96_545D_11E9_B2A0_020019339E5A.JPG
373655.247525837 5453676.27378741 61.9 340 75 49135BF6_545D_11E9_8B5E_080019339E5A.JPG
373532.578217167 5453644.92218737 61.9 189 277 4B569BF0_5460_11E9_9D44_048918339E5A.JPG
373555.448459279 5453665.30584248 61.9 410 256 4B569BF0_5460_11E9_9D44_048918339E5A.JPG
373532.241247693 5453644.34043672 62 178 173 51E52F90_5460_11E9_9343_388918339E5A.JPG
373555.982051402 5453666.53587926 62 403 161 51E52F90_5460_11E9_9343_388918339E5A.JPG
373595.963530727 5453636.00687596 62 520 471 51E52F90_5460_11E9_9343_388918339E5A.JPG
373555.700780369 5453665.98488698 62 387 56 52E509EC_5460_11E9_8713_408918339E5A.JPG
373531.952229574 5453644.23850178 62 165 70 52E509EC_5460_11E9_8713_408918339E5A.JPG
373596.121416094 5453636.13724726 62 507 372 52E509EC_5460_11E9_8713_408918339E5A.JPG
373781.259853167 5453386.55959108 62 317 396 618E1A60_5460_11E9_A82F_BB8918339E5A.JPG
373781.223009406 5453386.27483886 61.9 320 198 6381A2E2_5460_11E9_8040_D08918339E5A.JPG
373781.167262252 5453386.3388021 61.9 217 295 64F452E6_5460_11E9_8ECE_ED8918339E5A.JPG
373781.124422652 5453386.52478774 61.9 231 201 66E0E4CA_5460_11E9_AFF9_008A18339E5A.JPG
373781.190623321 5453386.32028978 61.9 318 297 67576C9E_5460_11E9_8F54_FE8918339E5A.JPG
373593.631019184 5453855.50141883 62.1 303 464 159ED656_545D_11E9_AAA2_30FF18339E5A.JPG
373599.365808116 5453836.73382722 62.1 342 329 159ED656_545D_11E9_AAA2_30FF18339E5A.JPG
373599.873771759 5453837.12218241 62 365 446 1517E3F8_545D_11E9_AB00_2DFF18339E5A.JPG
373663.965545833 5453684.74438772 61.9 416 472 41DD6138_545D_11E9_B545_C6FF18339E5A.JPG

All of the points convert back to lat/long properly, and when dropped into Google Maps (as lat/long) they match the GCPs. What am I doing wrong?

0 Likes

#2

Do 3 of the points match well and the rest don’t?

0 Likes

#3

Do you mean the WGS to Lat/Long? They all match well.

0 Likes

#4

No, I mean the registration of the dataset to GCPs currently chooses a best 3 (if memory serves) which means it will match 3 very well and may match the rest quite poorly.

0 Likes

#5

For what it is worth, I’m using pretty much the same proj format string in SE NSW (zone 55) and the matching has been out at the most 1m at some of the peripheral points of the output geotiff, and within the GPS error radius (0.3m) of the points in most places. Not sure if this will affect it at all (without trouncing through the code), but the differences I noticed between your file and mine are:

  1. I don’t use the latitude band (ie I just use +zone=55). Not sure how the code handles the band but is is not strictly part of UTM (but used in MGRS).

  2. The easting/northing precision is a bit high? I thought that eastings/northings are effectively in metres, making your precision down to nanometers? I guess this is an auto translation issue, as my master GCP points (generated from QGIS) go down to 4 dec places in some points but true precision is 30cm.

  3. Are the x,y coords correct? It seems you are using pretty low res input images (or all of the points are close to the origin corner)? I am using a DJI P4PV2 (20 Mpx) and so get output such as below (taking a random sample):

+proj=utm +zone=55 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs
692622.61 6152791.69 594.9119 3300.71 2731.49 DJI_4276.JPG
692602.68 6152793.54 596.3819 2498.60 2683.92 DJI_4276.JPG
692605.19 6152874.58 593.6075 4496.91 1162.01 DJI_4222.JPG
692605.51 6152878.36 593.4007 4509.61 1015.38 DJI_4222.JPG
692585.68 6152881.95 594.2856 3716.64 881.85 DJI_4222.JPG
692619.24 6152771.15 595.5479 3168.65 3582.93 DJI_4276.JPG
692689.71 6152681.20 588.5081 4443.75 1788.25 DJI_4325.JPG
692689.71 6152681.20 588.5081 282.65 3394.68 DJI_4441.JPG
692693.29 6152681.76 588.3959 4566.50 1767.50 DJI_4325.JPG

I have a master GCP file (which I basically exported out of QGIS) where all files are listed as 1.JPG. I use the WebODM GCP tool to import that file - giving me all of the GCPs on the right and giving me an “unknown” 1.jpg picture on the left. I then import all of the real pictures I need to use for the final GCP file, delete 1.jpg and do the matches in the other photos. I then generate the GCP file from these matches (getting the output as above). Note that these all have eastings/northings to correct (1cm) precision. It has worked well over a number of runs (most around 30Ha, 600-900 photos, 90m alt, 80% overlap). The hardest part was the original master GCP.

1 Like

WebODM Code 1 exit with GCPs
#6

Thanks for the reply Mike. I think you might have spotted the most likely cause for the error - the pixel positioning. The data that I’m running this over is also from a P4 and no, all of the GCPs are not in the top left.

I’ve tried to streamline the GCP process for users significantly by displaying photos on a map (based on their EXIF GPS), having the user click the photo to add a GCP to, click the GCP on a photo and then click a point on a map, which are then tied together in a database. If they choose, the user can manually type in GPS coordinates for better precision. In other words, it’s possible to quickly create the GCP file using only a few clicks. When the survey is submitted into ODM for processing, the GCP file is generated and fed into ODM as part of the process.

What seems to be happening (which I hadn’t noticed until you pointed it out) is that the photos are scaled to fit the screen, but the pixel points are not scaled to match the reduced photo size. I’ll get that code fixed, and try a run again.

Thanks again!

Edit: As a quick dirty hack I’ve multiplied the pixels by the reduction in size of the orignal photos on screen (7.27x). It now looks a lot better:

-41.05689475095132 175.4957830340602 62  2653.55 3242.42 1517E3F8_545D_11E9_AB00_2DFF18339E5A.JPG
-41.056728275600456 175.49571253835938 62.1  2202.81 3373.28 159ED656_545D_11E9_AAA2_30FF18339E5A.JPG
-41.05689816921059 175.49577691137574 62.1  2486.34 2391.83 159ED656_545D_11E9_AAA2_30FF18339E5A.JPG

We’ll see how it renders…

0 Likes

#7

Glad to be able to help (rather than asking for help) :grinning:

0 Likes

#8

Just an update - that was the issue. Thanks Mike!

0 Likes