ODM Parameter Suggestions for clearer orthophoto image

Hi,

I have the below sample comparison of Pix4D(left) vs WebODM(Right):

Untitled

There are these red circles where the issue is present.

The configuration that I have used for processing in ODM is:
Options: orthophoto-resolution: 3, ignore-gsd: true, debug: true, crop: 0, skip-3dmodel: true, depthmap-resolution: 1000, verbose: true

There were 452 images present in the dataset. RAM available was 64 GB.

How can this issues be removed or a better image quality can be achieved?(Please let me know if you need any more information). Any better parameters(options) that can be used to achieve better quality?

Any help appreciated.
Thanks

1 Like

Remove your --skip-3dmodel flag. That forces ODM to not do a proper photogrammetric work flow, which would create these artifacts.

Good luck!

2 Likes

Sure will try and keep you posted.

Thanks :smile:

2 Likes

I had also been comparing WebODM results against those from Pix4D, and the straigth lines are somehow challenging when processing in WebODM, but is not an impossible task.

As far as I can tell, the more acurate 3D model the best results you get on the orthophoto. Specially with these straigth lines.

Sometimes seting texturing-nadir-weight to 32 can help. Not sure if this is the case.

2 Likes

Agreed, also a good flag. But the primary problem here is --skip-3d-model.

3 Likes

Hi @smathermather-cm,

It did not help much as you can see from the below image.

image 1

The circled areas will show you the issues. The lines are still not straight.

Could you suggest some more parameters apart from below parameters?

image 2

Thanks

1 Like

@israelbar’s suggestion is the next step.

3 Likes

Sure, will try that and keep posted. :smile:

3 Likes

Hi @smathermather-cm,
I ran the processing with new parameter(setting texturing-nadir-weight to 32) added.
And I ran into error.

Reading PLY: 118173107 verts...
done.
Removing low-confidence geometry (threshold 0.6)...
Deleted 11041790 low-confidence vertices.
Writing mesh: /var/www/data/3ef14189-efa6-465e-a372-cf3216780a95/mve/mve_dense_point_cloud.filtered.ply
Writing PLY file (107131317 verts, with normals, with confidences, with values, 0 faces)...
done.
[INFO]    Finished mve stage
[INFO]    Running odm_filterpoints stage
[INFO]    Filtering /var/www/data/3ef14189-efa6-465e-a372-cf3216780a95/mve/mve_dense_point_cloud.ply (statistical, meanK 16, standard deviation 2.5)
[INFO]    Splitting point cloud filtering in chunks of 250000 vertices
[INFO]    running pdal split -i "/var/www/data/3ef14189-efa6-465e-a372-cf3216780a95/mve/mve_dense_point_cloud.ply" -o "/var/www/data/3ef14189-efa6-465e-a372-cf3216780a95/odm_filterpoints/parts/part.ply" --capacity 250000 --writers.ply.sized_types=false --writers.ply.storage_mode='little endian' --writers.ply.dims="x=float,y=float,z=float,nx=float,ny=float,nz=float,red=uchar,blue=uchar,green=uchar"
PDAL: writers.ply: Unknown dimension 'red' in provided dimension list.
Traceback (most recent call last):
File "/code/run.py", line 62, in <module>
app.execute()
File "/code/stages/odm_app.py", line 95, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 350, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 350, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 350, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 350, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 350, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 331, in run
self.process(self.args, outputs)
File "/code/stages/odm_filterpoints.py", line 30, in process
max_concurrency=args.max_concurrency)
File "/code/opendm/point_cloud.py", line 114, in filter
point_cloud_submodels = split(input_point_cloud, partsdir, "part.ply", capacity=VERTEX_THRESHOLD, dims=dims)
File "/code/opendm/point_cloud.py", line 62, in split
system.run(cmd)
File "/code/opendm/system.py", line 76, in run
raise Exception("Child returned {}".format(retcode))
Exception: Child returned 1

Could you please tell me what has gone wrong?

Thanks

Hi @pierotofy ,

Following this post in the community, can you suggest what could have went wrong with my case?

Update: I re-ran the processing and it went fine, without issues. I am still unsure of the reason for issue. but the output was not good compared to last time. Infact I observed some unfamiliar things on the map. as they can be seen on below image.

image

These black regions were not there in any of the earlier processing.

Edit 2:
Hi @israelbar, looks like your suggestion couldn’t help me. Did not make the processing better and I got those black regions shown in above image.

2 Likes

Hello @darkl1ght , I am very young in this matter, although I would like to add my contribution. For clearer images, it has worked for me to load the images without resizing and in turn ignoring the resizing in the process (-1), although just avoiding resizing when loading works fine. It could also help next to the Ignore-gsd = false flag and set ortho-resolution to 2 or 1. For the number of images it is an expensive configuration and it would take a long time. I hope it can serve.

Regards!

2 Likes

Hi @tatowem

Will try this and let you know. I am using this config as per your suggestion.

resize-to: -1, orthophoto-resolution: 2, debug: true, crop: 0, depthmap-resolution: 1000, verbose: true

1 Like

Hi @tatowem,
First of all, thanks for your contribution.
It took 6 hours to process 452 images dataset and still not luck with quality.

Parameters used: resize-to: -1, orthophoto-resolution: 2, debug: true, crop: 0, depthmap-resolution: 1000, verbose: true

What I want =>
image
What I get =>
image

You can clearly see the difference. Straight line issue has not been resolved.

And if you zoom more, you see more skewed lines.
image

Hi @smathermather-cm any more suggestions on solar type of data, where st. lines are far more important from client perspective.

Thanks in advance.

2 Likes

I have no answer for this, can you share the dataset?

1 Like

Quick question - which drone and sensor did you use for the photos? Just want to rule out rolling shutter errors. Also look at the camera lens correction flag. Brown type lens is recommended :mask:

1 Like

@darkl1ght

I’m suspicious on the tiles, what if you download the .tif orthophoto file and visualize in qgis?

I’m also curious to see what happens if you change texturing-data-term to area.

Hi @MikeF,

Drone is DJI PHANTOM 4 PRO
and sensor details are present here: https://www.dji.com/phantom-4-pro/info#specs

Any details you could provide for camera lens correction flag? after getting above details.
Thanks

CMOS sensor with typical CMOS readout (rolling shutter), but with a mechanical leaf shutter available down to 1/2000s exposure to help compensate for some of that distortion.

So, without ODM having rolling shutter compensation, there might be bowling/distortion, even with the Brown-Conrady camera model, especially if you acquired the photos while moving quickly.

2 Likes

Camera Types

The type tells ODM which mathematical model to use to correct lens distortion in the photos.

Saijin describes the rolling shutter issues very well the previous post. (Thanks to @Saijin_Naib who always provides keen insights)
M

4 Likes

It may be worth mentioning that the mechanical shutter on the P4P has to be enabled as well. I don’t recall if it’s on by default though.

3 Likes