DSM resolution vs Ortho resolution

Hi all,

I am beginning to use the --dsm option as I would like to superimpose the dsm with my orthophoto.
I order to obtain the same size of pictures I pass the --dem-resolution with the same value as the --orthophoto-resolution but I observe that the dsm as a lower size than the orthophoto.
Only mitigation I have found so far is to use the --ignore-gsd.

Is this normal ? Is there another way to achieve my purpose because this way it de-caps the ortho resolution which is not my point.

Thank you for your help

1 Like

Can you give us some more detail about your parameters and data?

I think the ortho will always be twice the size of the DEM, but you could rescale one or the other afterwards.

[INFO] Running odm_dem stage
[WARNING] Maximum resolution set to 2.0 * (GSD - 10.0%) (1.62 cm / pixel, requested resolution was 1.00 cm / pixel)

Creating output file that is 11036P x 12463L.


[INFO] Running odm_orthophoto stage
[WARNING] Maximum resolution set to 1.0 * (GSD - 10.0%) (0.81 cm / pixel, requested resolution was 0.70 cm / pixel)

Creating output file that is 22073P x 24929L.

1 Like

Ho thanks @Gordon, it seems I had miss that in the logs.

What is the reason behind that ? Does it come from how we compute the DSM ?

If it is always the case perhaps we should add it to the doc because currently it says:

DSM/DTM resolution in cm / pixel. Note that this value is capped by a ground sampling distance (GSD) estimate

It should say that it is capped by 2*GSD no ?

I now have to find de fast and simple way to rescale it, perhaps gdal will help with this.


I believe the historical reason is that realistically, the vertical data is somewhere on the order of 1/4 to 1/2 the accuracy of the horizontal data, so we cap the DEM resolution to keep it subsampled a bit to smooth things out.

If I recall correctly, we raised it from 1/4th to 1/2 earlier last year in response to the proliferation of better GPS units in sUAS and ground units.

1 Like

Good point. Pull requests on docs welcome!

The reason for the cap is about the limitations of depthmap calculations in the face of a noise ceiling (floor?). If you want depth information for every pixel, you will significantly increase your noise without introducing more information.

Now, OpenMVS has improved its depthmap calculations substantially in the last few weeks, months, and years, so far it may be feasible to get good results at GSD. It’s certainly worth testing.


Thanks for the note, folks.

PR open, help/docs note should be fixed in an upcoming merge/update :slight_smile:

1 Like

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