Post processing not finishing and timer restarts after refresh

Hello community! It’s been a pleasure reading the forum the last couple of weeks.
Here is an issue I cannot resolve no matter how many times I tried.

Set up: Native installation on esxi server Ubuntu 16.04.06 (from ready-to-go installation script provided by webodm). 16gb ram (around 10-12gb usable) 100gb hdd.
The following has been tried in 2 different datasets around 250-300images/dataset using gcp.
Processing runs smoothly untill reaching post-processing when something really strange appears to be happening.
We get the message

Postprocessing: done (•̀ᴗ•́)و!


It has been stuck there for over 20hours. The strange thing is that when I click refresh to the page the timer starts counting from 00:39:51 which is the time the post-processing has successfully finished and compressing has started.
I have tried cancelling the task and starting over from the last step but with no luck.
I can find the all.assets(1.9gb) using SFTP but i cannot see the 3d/2d model on the webodm interface and I don’t know if the assets are processed correctly as the task does not finishes.

I have also tried to process another dataset in lighting network and similar behavior there as well. In lighting webpage everything seems to have finished and I can download but in my local server again the timer shows 02:26:06 and when refreshing it starts from there again.

Is there any solution to this? Could it be a server-related issue rather than webodm?

Attached are
Images (LOCAL reduced), gcp, console log: [LOCAL] survey test football court - Google Drive

Images (LIGHTING reduced), gcp, console log:

Webodm parameters set to high-resolution


It’s probably the same bug as

How did you pick this projection?

+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=-199.87,74.79,246.62,0,0,0,0 +units=m +no_defs

Hello and thanks for the prompt reply.
We have a local projection system EPSG:2100 and we used the following website in order to figure out the proj. conversion

Is there any workaround I can make this work? I am unsure if we can use webodm if we cannot bound gcp files, even in the wgs84 coords system. We even tried the wgs84 and again failed.
The gcp file header used for wgs84 is the following:


Have you tried a string like as follows?:
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

Thanks for your reply! Will try that for wgs84 and get back to this.
Still it would be extremely useful to have epsg support by working projections.

longlat projections will not work currently.

EPSG code support is on the roadmap and a high priority issue.

1 Like

Oh, right. That only works in the GCP interface as it gets automatically converted to UTM.

Is there a way to easily convert longlat to UTM in order to insert the projection string?

Go to the GCP interface and load/create your GCP text file. It should reproject it to UTM for you.

Hey @smathermather!
Maybe I’m doing something wrong, but when I export the file I still have the same projection as before.

Do I need to do something else to generate the re-projection?

I still have the same problem. I cannot use gcp at all even when trying with wgs.
Unfortunately I gave up at this untill a permanent fix is made.

Using latest build released today

I’ve currently got the same issue, although at a different stage of the task.
After 2 hours with no progress, if I go to diagnostics and back to the task, the timer starts from 7m13s each time.

173 images, auto-boundary: true, crop: 5, dem-resolution: 1.5, dsm: true, dtm: true, feature-quality: ultra, feature-type: orb, gps-accuracy: 5, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 15000, orthophoto-resolution: 0.8, pc-filter: 5, pc-geometric: true, pc-quality: high, pc-rectify: true, resize-to: -1, use-3dmesh: true

End of the console log, as its been for over 2 hours -

2022-05-07 15:21:08,158 WARNING: FLANN for binary descriptors offers poor performance. Switching to BRUTEFORCE.
2022-05-07 15:21:08,423 DEBUG: Matching DJI_0937.JPG and DJI_0965.JPG. Matcher: BRUTEFORCE (symmetric) T-desc: 9.265 T-robust: 0.018 T-total: 9.283 Matches: 37 Robust: 9 Success: False
2022-05-07 15:21:08,423 WARNING: FLANN for binary descriptors offers poor performance. Switching to BRUTEFORCE.
2022-05-07 15:21:08,830 DEBUG: Matching DJI_0889.JPG and DJI_0887.JPG. Matcher: BRUTEFORCE (symmetric) T-desc: 9.835 T-robust: 0.010 T-total: 9.845 Matches: 91 Robust: 51 Success: True
2022-05-07 15:21:08,830 WARNING: FLANN for binary descriptors offers poor performance. Switching to BRUTEFORCE.