ODM Parameter Suggestions for clearer orthophoto image

darkl1ght · 1 October 2020 07:10

Hi,

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

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

smathermather · 1 October 2020 11:48

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

Good luck!

darkl1ght · 1 October 2020 13:55

Sure will try and keep you posted.

Thanks

israelbar · 1 October 2020 22:52

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.

smathermather · 1 October 2020 23:23

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

darkl1ght · 3 October 2020 15:26

Hi @smathermather,

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

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

Could you suggest some more parameters apart from below parameters?

Thanks

smathermather · 3 October 2020 15:28

@israelbar’s suggestion is the next step.

darkl1ght · 3 October 2020 15:29

Sure, will try that and keep posted.

darkl1ght · 4 October 2020 06:01

Hi @smathermather,
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

darkl1ght · 6 October 2020 10:17

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.

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.

tatowem · 6 October 2020 22:32

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!

darkl1ght · 7 October 2020 06:08

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

darkl1ght · 8 October 2020 09:51

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 =>

What I get =>

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

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

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

Thanks in advance.

israelbar · 8 October 2020 13:56

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

MikeF · 8 October 2020 14:10

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

israelbar · 8 October 2020 14:11

@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.

darkl1ght · 8 October 2020 15:05

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

Saijin_Naib · 8 October 2020 15:13

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.

MikeF · 8 October 2020 16:26

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

JulianW · 8 October 2020 16:40

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.