@VDS I ran your data using both GCP files, both ortho images generated did not appear to be in Montana, both did run to completion at about 1:45 minutes on my system, and they did align with each other. Just FYI. Also the points didn’t seem to align with the target’s as well as I would expect.
left to right
I wondering if this is typical accuracy? Did WebODM actually process the GCP’s? If not, then did I actually complete the process going past “Compressing All.zip”
Any thoughts?
@pierotofy another reason I question whether or not my process actually used the GCP’s is -The scale problem I usually have didn’t show up.
I would think that either:
- WebODM didn’t recognize or apply the GCP’s, (if it had then why didn’t the scale problem show up)
or
- my issue is with the EXIF tags on my images. What do you think?
A copy of the log would help determine if the GCPs were used in processing.
Link to my files, the logs are labeled in the VDS folder
GCPs were used. See the --gcpFile option.
running /code/build/bin/odm_georef -bundleFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/opensfm/bundle_r000.out -imagesPath /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/images -imagesListPath /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/opensfm/list_r000.out -inputFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/odm_texturing_25d/odm_textured_model.obj -outputFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/odm_texturing_25d/odm_textured_model_geo.obj -inputPointCloudFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/opensfm/reconstruction.ply -outputPointCloudFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/odm_25dgeoreferencing/odm_georeferenced_model.ply -logFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/odm_25dgeoreferencing/odm_georeferencing_log.txt -outputTransformFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/odm_25dgeoreferencing/odm_georeferencing_transform.txt -georefFileOutputPath /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/odm_25dgeoreferencing/odm_georeferencing_model_geo.txt -gcpFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/gpc/gcp_file_100-105.txt -outputCoordFile /var/www/data/e1b6e5d1-ce61-406a-aafe-ec390da29caa/odm_georeferencing/coords.txt
In the above images, I overlayed the actual GCP’s on the orthophoto from WebODM in QGIS then took six screenshots.
@pierotofy, do you think the accuracy demonstrated in the above images typical, three of the targets were very close, but it appears that three were off by 10 to 20 centimeters?
I plan on re running my DATA tomorrow, is there something I should specifically check in my DATA?
So I re-ran the ATOKA job again using Double checked UTM15N coordinates- no joy same problem scalle to small
Hello.
I’ve been following this thread closely: I’m also doing some photogrammetry and interested in using a GCP file, with the WebODM tool. The problem I have is very similar to what is happening to @mwfoshee lately (small scale) and not to the OP (WebODM hanging: indeed I could use a GCP file, and retrieve the assets without any problem. I didn’t try the OP’s dataset though). I will also add a message to the corresponding issue in Github (here).
What I find is that when using a GCP file, the orthophoto (Geotiff) is shifted by almost 10 meters but not the other assets. I thought it is related to this discussion, but let me know if I need to create a new thread or issue. In details:
- I used WebODM without GCPs (dataset 1) and with GCP in GWS84 UTM31N (dataset 2, GCP list below)
- In dataset 1 all assets match each other, but due to the typical unprecise GPS measurements from the drone, they are not accurate enough.
- In dataset 2 the GCPs are definitely used (the verbose messages indicate it, I also checked that the altitudes are corrected, and that distances between characteristic landmarks do change)
- the DSM (tiff) and cloud point (PLY) are correctly positionned (I can see in the cloud point, by picking point coordinates in CloudCompare, that the coordinates of my GCP targets are much closer to the expected values than in dataset 1 without GCP file)
- the Orthophoto 2 is shifted by almost 10 meters. Remark: compared to @mwfoshee the scale is correct.
- I used custom parameters: no change of image pixel size, dtm and dsm, ortho resolution 40pix/m, dem resolution 20pix/m, NonComplexForest.
I wanted to attach several screenshots from QGIS but as a new user I can only post one (I’ll put them in another message):
- orthophoto and colored dsm from dataset 2 (GCP file), they do not match:
A partial view of the GCP file, to show the format:
+proj=utm +zone=31 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
731068.542 4946336.485 2556.679 2861 1128 DJI_0090.JPG
731068.542 4946336.485 2556.679 2827 1948 DJI_0091.JPG
731068.542 4946336.485 2556.679 2790 2760 DJI_0092.JPG
731068.542 4946336.485 2556.679 4061 2452 DJI_0095.JPG
731068.542 4946336.485 2556.679 4102 1632 DJI_0096.JPG
…
I plan to change the WebODM parameters (fast orthophoto for example) on the same dataset, tonight.
Cheers
denis
Hi! I use the latest LiveODM and the issue of hanging WebODM is still there. When i use GCP file, WebODM stuck in ‘Post Processing’. This is the same problem - see my previous post.
Try updating, we’ve made some changes to the task processing. If you run out of memory you should at least get an error message now!
