DSM are always not realistic very high values, output projection always UTM

ODM
1

Dear all,
We produced DSM and the value are always very high values (around 2000m), in reality they should have a elevation around 0m. Do you know why it like this?

Also the final product always us WGS/UTM as projection system. but the image has geo.txt using local projection (amersfoort RD new). Is there any force reprojection in the end?

Thanks
Yi

1 Like
2

It is hard to say without seeing your input data and parameters.

I will say that in general, the elevation values should closely match the GCPs or the images provided.

No, we currently do not support anything other than the most appropriate local UTM CRS for processing. You will need to transform the data products after processing if you need another CRS.

3

Typically, elevation values accuracy ranges from 1 to 3 times the average GSD of the dataset. Map accuracy — OpenDroneMap 2.6.4 documentation
It heavily depends on the input data.

2 Likes
4

Basically we didn’t supply any GCPs since they are large format dataset and EO parameter has been optimised. We could create good DSM using other commercial software. Is that not possible to create good DSM without supply GCPs?

5

What input and parameters that needed for GCPs? Can you help us if we provide the input data?

6

It is very possible to create good-quality DSMs without GCPs as myself and others do so regularly.

Usually issues like this come down to the dataset and processing parameters.

You can read more about GCPs here:
Ground Control Points — OpenDroneMap 2.6.4 documentation

7

Thanks for let us know that it is possible without GCPs! We might will try it
Our file were processed using following command: docker exec -it fbaf3c96fafc python3 /code/run.py --project-path /datasets project --dsm --geo /code/geo.txt
the images are 80% overlapped in a row, and all large format datasets (>100megapixels)

the geo.txt is just normal geo.txt like this EPSG:28992
364495.tif 103062.195 483859.266 4375.39 -0.0626 -0.4109 0.3094
…

Do you know what could be the important parameters that we could adjust?

8

What was the sensor and collection method used for that imagery? Push-broom?

Do you have a small example set you can share?

9

the camera called: UltraCam Eagle M3. we are not so sure what kind of method the images were collected.
We uploaded 6 test sample images in following link.
https://odm-neo.s3.eu-west-1.amazonaws.com/Sample+Images.zip

Best regards,
Yi

2 Likes
10

Mei,

Looks like upstream OpenSFM doesn’t support the Vexcell UltraCam Eagle Mark 3 natively, so I’m opening an inquiry to see how we might go about adding the sensor, since you’re at least the third person to be using data from that sensor this year so far:
https://github.com/mapillary/OpenSfM/issues/808

2 Likes
11

Thanks for pick this up!! :slight_smile:

2 Likes
12

Hi Saijn,
Do you know if it is possible we just supply the camera.json file ourselves and OpenSFM can handle this camera?
We tried to give a camera.json like below:

{
“vexcel imaging gmbh ultracam eagle mark 3 f210 26460 17004 brown 0.0 rgb”: {
“projection_type”: “brown”,
“width”: 26460,
“height”: 17004,
“focal_x”: 212.1,
“focal_y”: 212.1,
“c_x”: 0.12,
“c_y”: 0,
“k1”: 0,
“k2”: 0,
“p1”: 0,
“p2”: 0,
“k3”: 0
}
}

And it gives an error message

Pairs: []
Reconstruction: []
[ERROR] The program could not process this dataset using the current settings. Check that the images have enough overlap, that there are enough recognizable features and that the images are in focus. You could also try to increase the --min-num-features parameter.The program will now exit.

Best regards,
Yi

1 Like
13

Yes, a camera.json should work just fine if supplied.

Are you 100% sure that all of your values are correct for it? Did you get that from the manufacturer’s calibration?

14

The images we got are pansharpened product, so we used the same camera parameter as Panchromatic Camera, and the folowing camera calibration report is delivered together with image provider:
The only doubt that we had is the ‘c_x’, ‘c_y’. we just assume that they are x_ppa and y ppa. the other parameters are pretty correct.
Do you see anything incorrect?

image
image1530×971 47.9 KB

1 Like
15

I don’t know enough about calibrating the camera models to say, unfortunately.

I would need assistance from someone else.

16

I don’t know what the implications of using the pan camera parameters would be, but it might be useful to run the process without calibration parameters and see what the output calibration parameters end up being and compare them.

2 Likes
17

Hi smathermather,
we got the camaraparameter like below if we don’t supply any camera.json file

{
“vexcel imaging gmbh ultracam eagle mark 3 f210 26460 17004 brown 0.0 rgb”: {
“projection_type”: “brown”,
“width”: 26460,
“height”: 17004,
“focal_x”: 0.8497944640729491,
“focal_y”: 0.8497944640729491,
“c_x”: -0.0017468346459664549,
“c_y”: -0.0051470470594294545,
“k1”: -0.0005636817790550932,
“k2”: 0.001715852316516194,
“p1”: 0.0015175907261913819,
“p2”: 0.0001995573847020751,
“k3”: -0.0021889982439198897
}
}

Best regards,
Yi

1 Like
18

Hi Saijin,
You were have a inquiry about how to add 4 different focal length to OpenSFM, do you know what to add if we want to use the single focal length (210mm) in OpenSFM? Could we try ourselves?
Best regards,
Yi

1 Like
19

You’d edit the two JSON files according to the other sensors.

If you look at the pull request I made for the Skydio 2, you can see the general format:

20

Hi Sajin and Yi,

I’m working together with Yi and want to give a small update. We managed to get openSfM to recognize the camera, in a similar way as you (Sajin) did here: Add Sensor Database support for Skydio 2 by Saijin-Naib · Pull Request #812 · mapillary/OpenSfM · GitHub

This was translated in ODM to the following camera.json:
{
“v2 vexcel imaging gmbh ultracam eagle mark 3 f210 26460 17004 brown 0.0 rgb”: {
“projection_type”: “brown”,
“width”: 26460,
“height”: 17004,
“focal_x”: 0.85,
“focal_y”: 0.85,
“c_x”: 0.0,
“c_y”: 0.0,
“k1”: 0.0,
“k2”: 0.0,
“p1”: 0.0,
“p2”: 0.0,
“k3”: 0.0
}
}

This is very similar to the output obtained following smathermather’s suggestion (see Yi’s comment above)

The output DSM however still shows large values of 2450m to 2550m, while a reference DSM shows values of -2m to 30m.

ODM is obviously designed for handling drone images, while the images we try to feed it are taken from an airplane with a much larger sensor. Can altitude play a role in this issue? Our images are taken at 4000-5000m above ground, while I see values of ~200m above ground in e.g. this example dataset (reffered to in ODMData: GitHub - pierotofy/drone_dataset_brighton_beach

1 Like