DEM/Orthophoto - fine details missing when compared to Metashape

What is the problem?

I’m running WebODM and Metashape on a landslide dataset to check for similarities/differences. I don’t have GCPs for this dataset.

In Metashape, I used the “high” option for sparse and dense clouds. The DEM has 6cm/px resolution and the orthophoto, 3cm/px (automatically calculated)

In ODM, I used the “ultra” option for pc-quality, feature-quality, and set the DEM resolution to 5cm and 3cm for the ortophoto.

At a first glance, the DEM and the orthophoto produced by ODM seem OK, but when zooming in, I can see that the ones produced by Metashape have more fine detail. The shaded relief of the ODM DEM is quite noisy and there are visible seams:

Orthophotos

Metashape

ODM

Metashape

ODM

Metashape

ODM

Shaded reliefs

Metashape

ODM

Metashape

ODM

Metashape

ODM

What should be the expected behavior?

I would love to replace Metashape with ODM in my research. Just need help tuning the parameters maybe?

How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing? Please include multiple screenshots of the problem! If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed)

The dataset can be accessed here. Just note that this is part of unpublished research, so please keep it to yourself and contact me if you would like to use it for any publication.

The processing report from Metashape is here.

ODM processin options:
resize-to: -1, rerun-from: opensfm, min-num-features: 8000, feature-quality: ultra, matcher-neighbors: 8, depthmap-resolution: 1000, opensfm-depthmap-method: BRUTE_FORCE, skip-3dmodel: true, ignore-gsd: true, mesh-size: 600000, mesh-octree-depth: 12, pc-quality: ultra, pc-las: true, pc-filter: 0, texturing-outlier-removal-type: gauss_damping, texturing-tone-mapping: gamma, dsm: true, dem-resolution: 5, orthophoto-resolution: 3, gps-accuracy: 5, optimize-disk-space: true

1 Like

Decrease dem-resolution, orthophoto-resolution and increase depthmap-resolution.

3 Likes

Should they also drop the skip-3dmodel and maybe increase mesh-octree-depth a bit, or would that not take effect for the DSM?

1 Like

“decrease” as in “larger pixels”? I don’t see how that would improve the visual details…

Decrease as in smaller number, or finer GSD.

I would also drop opensfm-depthmap-method: BRUTE_FORCE, unless you have a need of using opensfm for your depthmap method, for some reason. This is probably the source of some of your artifacts (assuming this sets the method and triggers using opensfm for depthmap calculation).

1 Like

Yes, the old terminology problem… after all a higher spatial resolution means finer pixels, so when one says to decrease spatial resolution, would mean to increase pixel size (i.e., larger pixels)…
That’s why I prefer to use fine/coarse instead of high/low.

But back to the question, I’m already using the same pixel size as Metashape. Will try and report later.

2 Likes

Yup, as per Piero, you’ve got to modify the depthmaps, as those drive everything downstream.

And make sure you aren’t using OpenSfM for depthmaps. It’s actually decent but noisy. Use the default OpenMVS instead.

2 Likes

Ok, I managed to test it and the results are really good!

Using depthmap-resolution=1200 resulted in an orthophoto almost identical in detail to the Matashape one, although its limits were quite smaller than the one made with depthmap-resolution=640.

Metashape (full view)

ODM depthmaps=640 (full view)

ODM depthmaps=1200 (full view)

Metashape (zoom)

ODM depthmaps=1200 (zoom)

Another aspect is the file size: about 840 MB from Metashape and 430 MB from ODM. That’s nice, the only issue is that the ODM tif takes a lot longer to load in QGIS (maybe because it’s compressed?)

This leaves me with two questions:

1 - What controls the limits/extent of the orthophoto (the default crop of 3m wouldn’t be responsible here)? I used mesh-size: 3000000 just to be sure.

2 - depthmap-resolution is set as deprecated and likely to be removed in the future. Given its role here, I’d vote to keep it, since pc-quality: ultra didn’t change the orthophoto alone. Can we?

1 Like
  1. crop does have an impact. Try using crop 0. It could also be influenced by the min-num-features not being high enough.

  2. pc-quality doesn’t increase the ortho’s quality by itself. It is for the depthmap and point cloud. You also need to use it in conjunction with the dem/ortho resolution flags.

The old flags for depthmap and feature resolution are being deprecated because the absolute numerical value is far less friendly and adaptable to use than a Quality scaling factor/ratio, like the new quality-level flags use.

As for the difference in size, the likely thing is that MetaShape is building internal overviews, whereas ODM will not unless you specify that it should using the build-overviews flag.

My personal preference is to make them later in QGIS as external overviews so I can rebuild/remove as wanted.

You can add the --build-overviews flag to have OpenDroneMap build the overviews. It will result in a larger file that loads faster in QGIS.

Nice to see it’s quite similar, cropping aside. Brett’s comments on cropping are good advice above.

1 Like

The thing is, I tried pc-quality with fine resolution in dem and ortho, but it didn’t produce a detailed orthophoto. I only got good details when using depthmap-resolution:1200. So it seems that we need this option. If not as a numerical option, a categorical one, but something that controls dephtmap directly. I believe this is what Agisoft calls “depth filtering”, with categories of “mild”, “moderate” and “aggressive”.

Regarding crop, it does change the boundaries but only a little (see images), but even with a higher value of min-num-features (increased from 8.000 to 14.000) the resulting assets are way smaller than those created with depthmaps of 640.

depthmap 640, crop 3, min-num-features 8000

depthmap 1200, crop 3, min-num-features 8000

depthmap 1200, no crop, min-num-features 14000

2 Likes

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