WebODM Seems to Hang Compressing All.zip

Thank You so much for the help! I pressed cancel then restart from ortho photo - No Joy
image
the clock never moved, but the process took about 7 minutes

system RAM 16 GB according to performance tab of task manager
image
I’m trying the next suggestion now

Did you mean for us to create a new task in the same project? I didn’t see a way to do that.

First attempt new project name test

I kept the hung task and re loaded the other project that was not running with GCP file, then clicked “Start Processing” from the newly created task? 5 minutes in and same result

image

second attempt (name test2) without GCP file/ I left both projects (test and UPS Malvern 2) open and running, I then added only the images from the first open project (UPS Malvern 2). Success

image

Ok, so I panicking a little. I’m supposed to fly a 550 acre quarry next week and I getting anxious.

I was readingthis page on github and decided to try again using WGS84 for my GCP’s and naming the file exactly “gcp_list.txt”. While using the “GCP Interface” in WebODM I added my points in WGS84,

image

I then looked at the GCP file and I noticed the file generated by the interface had shortened the Lat/Lon to only 2 decimal places and again appeared to be using Tabs instead of spaces ad delimiters (I don’t know if the tabs make a difference, but I’m sure the Lat/Lon need more than 2 decimal places)
+proj=longlat +datum=WGS84 +no_defs
-93.09 34.43 135.972323823458 1655.87 1000.59 DSC00798.JPG 4
-93.09 34.43 135.972323823458 1977.85 2119.13 DSC00797.JPG 4
-93.09 34.43 135.972323823458 1785.70 3058.08 DSC00818.JPG 4
-93.09 34.43 135.776944647647 1516.74 2419.22 DSC00801.JPG PLStrip
-93.09 34.43 135.776944647647 1329.68 1375.76 DSC00802.JPG PLStrip
-93.09 34.43 135.776944647647 2019.79 1576.71 DSC00815.JPG PLStrip
-93.09 34.43 134.981711777615 1547.12 1729.01 DSC00807.JPG PumpStation
-93.09 34.43 134.981711777615 1882.35 2330.70 DSC00809.JPG PumpStation
-93.09 34.43 134.981711777615 1738.79 1256.34 DSC00810.JPG PumpStation
-93.09 34.43 134.205376737381 1328.27 2635.81 DSC00822.JPG 3
-93.09 34.43 134.205376737381 1098.61 604.72 DSC00824.JPG 3
-93.09 34.43 134.205376737381 2465.55 2287.95 DSC00831.JPG 3
-93.09 34.43 134.205376737381 4292.84 2094.18 DSC00833.JPG 3
-93.09 34.43 134.205376737381 4143.53 1305.02 DSC00834.JPG 3
-93.09 34.43 133.851499634236 1927.48 2551.29 DSC00824.JPG 1
-93.09 34.43 133.851499634236 1771.60 1541.38 DSC00825.JPG 1
-93.09 34.43 133.851499634236 1549.76 675.64 DSC00826.JPG 1
-93.09 34.43 133.851499634236 1772.65 2722.77 DSC00829.JPG 1
-93.09 34.43 133.851499634236 1753.19 1395.86 DSC00830.JPG 1
-93.09 34.43 133.851499634236 1772.33 248.47 DSC00831.JPG 1

(In windows note the file reads as one long file with tabs between fields, see screen shot)

![image|690x74](upload://8aHnCtev0ulLE10JrlVSK1zZhor.png

I corrected the Lat/Lon and replaced the Tabs with spaces:

+proj=longlat +datum=WGS84 +no_defs
-93.093155866304 34.425438198628 135.972323823458 1655.87 1000.59 DSC00798.JPG 4

-93.093155866304 34.425438198628 135.972323823458 1977.85 2119.13 DSC00797.JPG 4

-93.093155866304 34.425438198628 135.972323823458 1785.70 3058.08 DSC00818.JPG 4

-93.092677448247 34.425650221945 135.776944647647 1516.74 2419.22 DSC00801.JPG PLStrip

-93.092677448247 34.425650221945 135.776944647647 1329.68 1375.76 DSC00802.JPG PLStrip

-93.092677448247 34.425650221945 135.776944647647 2019.79 1576.71 DSC00815.JPG PLStrip

-93.092108529526 34.425955574617 134.981711777615 1547.12 1729.01 DSC00807.JPG PumpStation

-93.092108529526 34.425955574617 134.981711777615 1882.35 2330.70 DSC00809.JPG PumpStation

-93.092108529526 34.425955574617 134.981711777615 1738.79 1256.34 DSC00810.JPG PumpStation

-93.092420870471 34.425391808292 134.205376737381 1328.27 2635.81 DSC00822.JPG 3

-93.092420870471 34.425391808292 134.205376737381 1098.61 604.72 DSC00824.JPG 3

-93.092420870471 34.425391808292 134.205376737381 2465.55 2287.95 DSC00831.JPG 3

-93.092420870471 34.425391808292 134.205376737381 4292.84 2094.18 DSC00833.JPG 3

-93.092420870471 34.425391808292 134.205376737381 4143.53 1305.02 DSC00834.JPG 3

-93.09224178135 34.425548178913 133.851499634236 1927.48 2551.29 DSC00824.JPG 1

-93.09224178135 34.425548178913 133.851499634236 1771.60 1541.38 DSC00825.JPG 1

-93.09224178135 34.425548178913 133.851499634236 1549.76 675.64 DSC00826.JPG 1

-93.09224178135 34.425548178913 133.851499634236 1772.65 2722.77 DSC00829.JPG 1

-93.09224178135 34.425548178913 133.851499634236 1753.19 1395.86 DSC00830.JPG 1

-93.09224178135 34.425548178913 133.851499634236 1772.33 248.47 DSC00831.JPG 1

Then placing it in the same folder as the images. I then uploaded the images only( without selecting the GCP file) counting on WebODM to recognize and use my GCP’s

The project processed in 7 minutes, but as expected WebODM did not use any GCP’s

lastly, I used the corrected GCP file and selected it along with the images and after 6:28 I got a new error.

image

I’m increasing the minimum number of features from 8000 to 16000 now, I’ll post back with results

Same error heres a link to my Data, should be 40 images, and 2 GCP files, 1 exactly as it came from the webODM GCP interface and the one I edited, Thanks Again!

https://drive.google.com/drive/folders/16cogZJzThosSXG8TT8u0PM23NF6FZyP3?usp=sharing

@mwfoshee please open a new topic if this is a different issue. Thanks!! :pray:

Either on the same project or a new project. Didn’t matter. Seems like it’s not a memory issue, since processing started it means that nothing was killed.

Seems to get stuck only with datasets including GCP files then.

Will do, I’m not sure if it’s a new topic. It appears that when the coordinate system is WGS84 this is the issue and when the CRS is anything else this is still an issue.

Opened a bug: https://github.com/OpenDroneMap/WebODM/issues/547

If someone is able to figure out a way to reliably reproduce this issue, please document it, attach your dataset, your GCP file and report as much information as possible (environment, operating system, free disk space, memory allocated, etc.). I couldn’t reproduce this with the dataset from @VDS.

@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

image

image

image

image

image

image

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:

  1. WebODM didn’t recognize or apply the GCP’s, (if it had then why didn’t the scale problem show up)
    or
  2. 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:
    Capture%20d%E2%80%99%C3%A9cran%20de%202018-11-11%2022-18-10

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

  • orthophoto and colored dsm from dataset 1 (no GCP file), they do match:
    Capture%20d%E2%80%99%C3%A9cran%20de%202018-11-11%2022-18-17
  • orthophoto from dataset 1 and 2: they are shifted by almost 10m.
    Capture%20d%E2%80%99%C3%A9cran%20de%202018-11-12%2006-40-51

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!