Does anyone have advice to improve processing images of grassy fields. Webodm recommends changing some setting minimum number of points and enabling pvms. I have tried this but it has not solved the issue.
I am taking images of a grassy field from a height of about 5m using a MAPIR survey3 rgb with attached gps. This is not a standard drone practice so it might contributing to the issue. The gps positions are good but the images are stitching into one block. I am not using gcp’s but plan to try using them.
Hi @Thomas_Eley – can you give more info on the problems you are having?
I am having trouble post-processing images of a grassy field. The gps points look ok in geosetter but when I try to process the images in webodm it does not work. This is probably due to a lack of gcp’s, or other identifiable points, but if anyone has suggestions about improving post-processing of relatively homogeneous areas of ground it would be appreciated.
I end up with either a single square at the start of the survey or a single square at the end. Ideally I would like images locations to closely relate to the exif data and then be adjusted to fit the next images. What currently happens is one square visible either at the beginning or end of the line I have photographed.
I am doing something that is not standard eg photography from a 5m pole rather than a drone 20m+ high. I have not used gcp’s yet. Any advice regarding post-processing options would be helpful.
What is your overlap and sidelap, or are you doing your pictures in a single line?
I am just doing a single line at present. I am trying a technique mapping using a pole camera so it is at an experimental stage. I am working on improving my field technique but what I also need to do is improve my post processing.
A single line is unlikely to work with ODM. I would recommend 3 lines if you can afford it, and two lines at an absolute minimum.
Thanks. I will try it. I have managed to process a single line by placing gcp’s every 4-5m. They are just coloured bean bags with numbers written on them but they seem to have worked.
The next problem I can foresee is that if I process 2 or 3 lines at the resolution I want then my laptop is likely to struggle. I am going to upgrade from 8 gb to 16 gb of ram but is there a way to reduce the file size of the orthophotos when adding them to QGIS?
Hi @Thomas_Eley – check out --orthophoto-resolution here: http://docs.opendronemap.org/using.html#additional-arguments
It’s pixels per meter rather than meters per pixel, so 20 (which is the default) is 0.05 meter pixels.
Hi @Thomas_Eley and @smathermather , I’m trying to stitch photos from a farm, but the process keeps failing. It suggest to edit the min max for homogenous areas (dense vegetation, crop, or grass). I noticed the min is automatically set to 8000. What would be the ideal setting for stitching farm land? Look forward to hearing from you soon.
Evenly planted farms can be quite tricky. The thing you need to do for your use case is to test multiple flying heights to find the scale at which you can unambiguously distinguish between different images. Too close and it will fail; too far and it will fail. I would try e.g. 25m, 50m, 100m and maybe some intermediate values to find out your optimum height. If none of those work, then you may need to change field of view (different camera) or fly higher if your local regulations allow it.
Hi Ryan,
I was working with a specific limitation which was my drone was operating really close to the ground. I overcame the problem by adding ground control points. The advice to try different heights sounds a good. Having more unique identifiable points is the best place to start.
we also fly fields really low (25m) and stitching can be an issue so i just installed WebODM to give it a try. so far i have achieved a successful mosaic by changing fast-orthophoto = true, min-num-features = 16000, use-hybrid-bundle-adjustment = true and resize = none. i would be interested in knowing other setting that have been changed and try them
Hi @fritzgr I tried your recommendations. 1.5hr into the stitching, I received a message suggesting more RAM required. Our server is 32 CPU and 60GB of RAM. There is no way this project should have run-out of space on our server. The project includes only 360 images collected at 60m with 75% overlap. The scenes offers plenty of similar objects to match with producing nice results in Pix4D. Can you please give me some idea on why I would have received that message.
I am not sure if this will help but what is the accuracy of your gps for georeferencing? Emlid have the Reach M+ system which should increase georeferencing accuracy to sub 10cm. What is your file size? Maybe try with a smaller file size or break the 360 into smaller groups.
Hi Thomas,
Good Idea. I will try processing 1/3 of the project to see if @fritzagr settings work better.
Update: I reduced the number of images and still no luck. I have ask @Piero for support on this subject as it maybe related to my server setup.
@ryan.cant could you copy/paste the output from your task? Don’t assume that because you have 60GB of RAM that every project will process. For example, if you have 32 cores, by default OpenDroneMap will attempt to use every single core availalble, which would give 1.8GB of RAM per core. It’s likely that you haven’t set a limit on the maximum number of cores (see --opensfm-processes and --pmvs-num-cores) and that the program actually did run out of memory.
We are always trying to improve the memory management of ODM (in fact, keep an eye for the upcoming changes on https://github.com/OpenDroneMap/OpenDroneMap/projects/2 which are going to reduce memory usage), but the user is given some power to decide how to allocate it (and choose between speed / memory requirement tradeoffs).
Hi @Pierotofy
What would I set the opensfm-process and pmv-num cores if my server is 8vCPU 30GBmem, 60GB local storage?
I could make some recommendations if I can see a copy of the task output… without it it’s a bit difficult.
edit: I see you sent it via e-mail. Next time post it here. Thanks.
Hi @Pierotofy I sent it to your email. I’m not sure how to add an attachment on this discussion board.
In regards to --opensfm-processes and --pmvs-num-cores
--opensfm-processes says "The max number of processes to use in dense reconstruction. Default: 8 - What should thins be set to? Should we make this value higher and by how much?
--pmvs-num-cores - I can’t find this in the edit menu. Where is this button located? and if my server is 8vCPU, should I make it 8?
1 Like
Ah, my fault. Never mind about the --pmvs-num-cores option. No need to tweak that (unless you check the --use-pmvs flag, you don’t need to worry about it).
For --opensfm-processes if the task fails with a memory error (you should see the word Killed or MemoryError in the task log), try to lower it to 4, then 2 and finally 1.