Speed compare WebOdm windows version vs Docker version vs Pix4dField

I test the 3 software at the same time in the same workshop.

Database, 254 RGB, 5472*3648, single file 8MB.
Drone: DJI P4P

Pix4Dfiled, finish in around 20 min. result is 0.99 inch/pix, size: 22628x18188 pixels, file 647.5MB
WebOdm 1.92 native windows Version: expected in 4-8 hours
WebOdm Docker version 1.93:

pix4d result docker setting native process setting


from beginning, the 3 apps process useage of CPU and RAM

compare 01

compare 02

pix4d Filed finish in around 20 mins.

When monitoring the usage, the pix4dfiled use most of CPU when it start. Looks like pix4D doesn’t require too much RAM.

The native is using much less CPU all the time and very low RAM.

All the time, all 3 apps don’t require too much RAM totally, at most 25%.

Look like the windows version doesn’t really use the pc resource. It it can progress use all resource of PC, it will much faster.

Pix4DFields works substantially differently than WebODM. We are not going to even attempt to match the runtime or memory requirements of Pix4DFields, because they work differently (run Pix4DFields with an urban scene, you’ll see what I mean).

In the future, there might be the case for developing a new processing engine that uses approaches similar to Pix4DFields for agriculture-specific scenes, but it’s a substantial effort (interested in contributing?)

1 Like

understand the pix4dField is special for agriculture.
The big different from urban scene is the difficulty to finish it fast.
The WebOdm also have a forest mode, Is that for agriculture scene?

The agriculture uses a lot drones.

Docker version finished in 82 mins.
file 233MB, 10628x8850

windows native version finish in 106 min

file size: 283MB, 10539x8833

final resul:

pix4Dfiled, size, 647MB, 22 min, resolution: 22628x18188
WebOdm Docker Version: size, 233MB, 82 min, 10628x8850
WebOdm native windows version, size, 283MB, 106 min, 10539x8833

The closest comparison between pix4d fields and webodm would be to use the --fast-orthophoto option.

But even then, you’re comparing a photogrammetry tool (WebODM) with a mosaicking tool (Fields). It’s kind of like doing a speed comparison between a truck or lorry and a sports car: it’s not a comparison that makes a lot of sense.

But, as long as you’re doing it (I understand the love for the sports car), use the flag above to at least for completeness of the overall picture.


Pix4DField has some planarity assumption but actually makes a decent job as long as a single plane can be seen (most likely the ground). Sure, it is not suited for many cases, but as you found out, its speed is unbeatable. I agree that’s a nice piece of software with some neat algorithms.

Comparing with Pix4DMapper would be a fairer comparison.

But again, you’re comparing a multi-million company with several dozens of developers working 8 hours a day, with an open-source software where most people usually spend these 8 hours for another company.

Nevertheless, as one of the OpenSfM contributors, I have ideas for better and faster handling of planar scenes, but as mentioned, it’s about time, days are only 24 hours.

This paper is a good candidate : https://people.eecs.berkeley.edu/~yima/psfile/Planar-CVPR12.pdf OpenSfM has everything, we just need to implement the track construction trough homography linking, get the homographies for each image, recover translation and rotation, triangulate point on the plane and then bundle. Would be much faster than the current incremental SfM. 2-3 weeks works, I guess.



Do you think it’d be a worthwhile candidate for a Quadratik funding drive like we’ve done for other work?

Do you have the team you need to do such work? Do you know how much it would cost?


I would not be able to do it as a side project for money given my current employment, so if anything happen on my side, it’ll be for free :

  • Either it fits and intersect my day-to-day work duties and I’ll need to do it
  • Or I can spend some time just writing a bit of doc on how to do it by giving some code pointers, so someone else can do the actual bulk of work

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

I’m giving the Robust Plane-Based Structure From Motion paper a shot; I’m almost done implementing the TRASAC algorithm from the paper:

Blue points are plane inliers, red dots are outliers. Seems to work!


Yeah, seriously, wow, I can’t see anything misclassified.

This is many excite…


Plane estimates and local reconstruction from homography linking:


What is this mean?

It means Piero is successfully working on near real-time processing of images for flat areas.