Problems with output from Parrot Sequoia RGB

[janm]

Hi all,
I have an issue with poor results of WebODM and a particular dataset (437 images rgb) which means mostly visual distortion so intense, that even parts are unrecognisable and messed up. This dataset is pretty big to experiment with (took roughly hours to compute), so I prepared a two smaller subdatasets, called north and south (as they are in fact two opposite ends of the area and also were subjects of severe distortion when computed in the original full dataset). These two smaller areas, however, contains I suppose enough visual information to be successfully used for orthophoto.
But main problem is, even that I was able to find some good settings for one of these two subdatasets, it either does not suit well for the other, or for the final full dataset, again causing distortion.
As the original full dataset is very big and it takes a long time to do, I would stay with the two smaller parts of it.
Here is the link of my selection of these two subareas.
https://drive.google.com/drive/folders/1xoprZJ6M-G3zAw3_tdtMaLizvIlhoiM0?usp=sharing

Each subdataset consists of several folders. Setting 1 is always a default setting for WebODM v. 1.9.11. Other settings are setting where I recorded the lowest GPS / 3D errors. There is a file “map.png” illustrating the GPS points of supplied images. Numbers correspond to numbers in names of the image files (last number in the name of the image file in the “data” folder).
In the results, a ​letter T in the name of the setting (folder) means that sfm_algorithm use triangulation.
Triangulation does not help at all, in fact, it further contributes to distortion and higher error values.
I tried to watch out for errors - RMS errors. But low values not always denote a good orthophoto. So a visual inspection is necessary.

There seems not to be a unified setting for the both of these two areas. Setting 1, for instance, is good for southern part (visually, although rather high RMS errors). Setting 3 seems to suit for the both parts visually, but for the south part there is rather high RMS error for X GPS. Again if used for the full dataset, a strong distortion is manifested, either on the south or north part, even that separately it does not occur. Or setting 2, lowest RMS errors for south part, but for north a strong distortion and also RMS errors are present. I also suppose, that having RMS errors for X or Y GPS higher than 10 (meters) is a sign of something bad.
Even that I tried to minimize RMS GPS errors for X and Y, my results are far above those of Pid4D, having X and Y always
below 5, while for my results, it is close to 10 and even more than 20 in some settings.
Pix4D reports are also included as are the reports of WebODM.

I though that triangulation could havily improve the results of WebODM, but just yesterday I read that there is a problem
with that functionallity too. Interesting, that Pix4D does not seem to be affected and is more robust, regarding of that part of metadata notation, used for triangulation.

I came here for the help as I do not have anybody here around me to consult with.
Please help yourself and look at my shared folder, everything is there, even the results of Pix4D. Used base setting Ag RGB. If you are able to suggest any good setting, not already used, I could try it on the two smaller sets and even try it on the full dataset.

[Saijin_Naib]

Welcome, Jan!

Great write-up, and quite helpful.

May I inquire as to whether or not the imagery was taken with the sUAS stopping for each photo, and what the flight speed was set to for both sections of the sampled area?

[janm]

Thank you for reply, Saijin. I did not expect that question. Perhaps relevant in answering about any blurring effects, which might degrade photos.
And which parameter should tell us about that? I found that the shutter speed is 1/333 of second. Isn’t that not fast enough to capture the photo even while moving? Altitude should be 416 meters above sea. I find no motion blur effects on photos. Perhaps just not too much sharp. Perhaps it was due to the time and light conditions? Photos were taken on May at 7:30 AM. But apart from a bit of lacking contrast, I would say that the photos are sufficient enough. Looking at the photos, I would expect a better performance of ODM, anyway. OK., even a bit of distortion or not perfectly continuous tiles, but not screwing 60% of the ortho. When comparing to Pix4D. Perhaps the poor results are due to a flawed triangulation.
If there is not a parameter telling us that information (stopping), then I would suggest that there were no UAV stoppings at all.

[janm]

meanwhile I prepared the whole orthophoto (complete big area) with WebODM and also included Pix4D for comparison. All is in my shared folder under the “whole area” folder in root. Setting 4 is the new setting used for this orthophoto. I prepared setting 4 for both north and south subdatasets as well. For these two subdatasets it appears to perform rather better. But when launched on the whole area, the result is so poor, that it even surprises, if it is a WebODM actually, that is responsible for this. Having RMS err jumping to over 150 meters (over 300 for Y). I just cant believe what I am seeing. And Pix4D, RMS err, as always, below 5 meters. Is this even possible?

up: whole area, WebODM, setting 4

(compare it to north and south parts, subdatasets, the same setting 4)

up: north part, WebODM, setting 4

up: south part, WebODM, setting 4

Compare it to Pix4D:

up: whole area, Pix4D, thats how the orthophoto should look like, setting Ag RGB

up: north part, Pix4D, Ag RGB

up: south part, Pix4D, Ag RGB

When I do orthophoto of the whole area using default setting in WebODM, although some parts of the orthophoto seem to match (clearly looking better that of that with setting 4), other do not. The image is also distorted, in the center and also in the south part. Lines are either not straight or are even heavily deformed, bowled, neighboring parts are messed up like randomly placed cards of a pexeso. This should definitely not be.

[smathermather]

@janm

up: whole area, WebODM, setting 4

What does setting 4 mean?

[janm]

setting 4 can be found in the setting 4 folder under the results for WebODM north and south parts (files “params” and console.txt) , but you are asking:

auto-boundary: true, camera-lens: brown, matcher-neighbors: 12, pc-geometric: true, pc-quality: low, pc-sample: 10, use-3dmesh: true, use-fixed-camera-params: true

but, since I have discovered that the list of parameters displayed above the console window on the webpage of WebODM is heavily dependant on the base template, I would suggest you to see console.txt for setting 4. In aforementioned folders. It should make no difference which one you pick, as setting 4 should be always the same.

I can also try to paste first rows of console.txt here

[INFO]    auto_boundary: True
[INFO]    boundary: {}
[INFO]    build_overviews: False
[INFO]    camera_lens: brown
[INFO]    cameras: {}
[INFO]    cog: True
[INFO]    copy_to: None
[INFO]    crop: 3
[INFO]    debug: False
[INFO]    dem_decimation: 1
[INFO]    dem_euclidean_map: False
[INFO]    dem_gapfill_steps: 3
[INFO]    dem_resolution: 5
[INFO]    depthmap_resolution: 640
[INFO]    dsm: False
[INFO]    dtm: False
[INFO]    end_with: odm_postprocess
[INFO]    fast_orthophoto: False
[INFO]    feature_quality: high
[INFO]    feature_type: sift
[INFO]    force_gps: False
[INFO]    gcp: None
[INFO]    geo: None
[INFO]    gps_accuracy: 10
[INFO]    ignore_gsd: False
[INFO]    matcher_neighbors: 12
[INFO]    matcher_type: flann
[INFO]    max_concurrency: 1
[INFO]    merge: all
[INFO]    mesh_octree_depth: 11
[INFO]    mesh_size: 200000
[INFO]    min_num_features: 8000
[INFO]    name: f811fa23-40d7-4dd4-8ea3-4e75d8034a40
[INFO]    optimize_disk_space: False
[INFO]    orthophoto_compression: DEFLATE
[INFO]    orthophoto_cutline: False
[INFO]    orthophoto_kmz: False
[INFO]    orthophoto_no_tiled: False
[INFO]    orthophoto_png: False
[INFO]    orthophoto_resolution: 5
[INFO]    pc_classify: False
[INFO]    pc_csv: False
[INFO]    pc_ept: True
[INFO]    pc_filter: 2.5
[INFO]    pc_geometric: True
[INFO]    pc_las: False
[INFO]    pc_quality: low
[INFO]    pc_rectify: False
[INFO]    pc_sample: 10.0
[INFO]    pc_tile: False
[INFO]    primary_band: auto
[INFO]    project_path: /var/www/data
[INFO]    radiometric_calibration: none
[INFO]    rerun: None
[INFO]    rerun_all: False
[INFO]    rerun_from: None
[INFO]    resize_to: 2048
[INFO]    sfm_algorithm: incremental
[INFO]    skip_3dmodel: False
[INFO]    skip_band_alignment: False
[INFO]    skip_orthophoto: False
[INFO]    skip_report: False
[INFO]    sm_cluster: None
[INFO]    smrf_scalar: 1.25
[INFO]    smrf_slope: 0.15
[INFO]    smrf_threshold: 0.5
[INFO]    smrf_window: 18.0
[INFO]    split: 999999
[INFO]    split_image_groups: None
[INFO]    split_overlap: 150
[INFO]    texturing_data_term: gmi
[INFO]    texturing_keep_unseen_faces: False
[INFO]    texturing_outlier_removal_type: gauss_clamping
[INFO]    texturing_skip_global_seam_leveling: False
[INFO]    texturing_skip_local_seam_leveling: False
[INFO]    texturing_tone_mapping: none
[INFO]    tiles: False
[INFO]    time: False
[INFO]    use_3dmesh: True
[INFO]    use_exif: False
[INFO]    use_fixed_camera_params: True
[INFO]    use_hybrid_bundle_adjustment: False
[INFO]    verbose: False

[Saijin_Naib]

@janm

use-fixed-camera-params: true

Have you run without this setting?

[janm]

on the whole area not, but I started orthophoto again on the whole area and with default setting at this time and I suppose that default setting in 1.9.11 has this as false. So we shall see on Wednesday. However, north and south (subareas) are there without it and it is setting 1.
Also, I have read that fixed camera setting is suitable for rolling shutter types of camera and I also observed, that pix4d performed a rolling shutter optimization for these datasets.

[smathermather]

@Saijin_Naib

Have you run without this setting?

Good catch.

This is the core of the problem. On smaller subsets, this didn’t introduce the kind of error you would see on the larger area.

This parameter should almost never be used. If you don’t have a >$50k lab calibrated camera, this isn’t a parameter that should be used with OpenSfM.

Unfortunately, we don’t yet have any fixes for rolling shutter, but you should get much better results with just default, and we can help you refine from there.

Cheers! And welcome.

[Saijin_Naib]

@janm

Also, I have read that fixed camera setting is suitable for rolling shutter types of camera and I also observed, that pix4d performed a rolling shutter optimization for these datasets.

Stephen pointed you in the right direction with this flag.

We don’t have a Rolling Shutter Correction model yet, unlike Pix4D and Agisoft. It is something we’re looking into, and if a number of things line up right, we should be able to start on it at some point this year.

Any shots taken with appreciable speed moving over a surface will have some rolling shutter distortion and you won’t necessarily see it as plainly as motion blur induced by too long of a shutter speed, for instance.

[Gordon]

@janm

1/333 of second. Isn’t that not fast enough to capture the photo even while moving?

See Incomplete Orthomosaic - #17 by Gordon

[janm]

OK., thanks for suggestions. I ran orthophoto in default, like I said, unfortunately this time WebODM returned an error. I do not understand what is the source of this problem as I ran it before with no errors. But I cannot swear that it was the default setting too.
Console

90
.
.
.
Input file size is 3603, 5774
0...10...20...30...40...50...60...70...80...90...100 - done.
[INFO]    running gdalbuildvrt -resolution highest -r bilinear "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/merged.vrt" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/tiles.small_filled.tif" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/tiles.tmp.tif"
0...10...20...30...40...50...60...70...80...90...100 - done.
[INFO]    running gdal_translate -co NUM_THREADS=1 -co TILED=YES -co BIGTIFF=IF_SAFER -co COMPRESS=DEFLATE --config GDAL_CACHEMAX 47.55% "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/merged.vrt" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/tiles.tif"
Input file size is 3603, 5774
0...10...20...30...40...50...60...70...80...90...100 - done.
[INFO]    Starting smoothing...
[INFO]    Smoothing iteration 1
[INFO]    Completed smoothing to create /var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/mesh_dsm.tif in 0:00:11.402316
[INFO]    Completed mesh_dsm.tif in 0:00:18.714972
[INFO]    Creating mesh from DSM: /var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/mesh_dsm.tif
[INFO]    running "/code/SuperBuild/install/bin/dem2mesh" -inputFile "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/tmp/mesh_dsm.tif" -outputFile "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/odm_25dmesh.dirty.ply" -maxTileLength 2000 -maxVertexCount 200000 -maxConcurrency 1
[INFO]    running "/code/SuperBuild/install/bin/OpenMVS/ReconstructMesh" -i "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/odm_25dmesh.dirty.ply" -o "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/odm_25dmesh.ply" --remove-spikes 0 --remove-spurious 0 --smooth 0 --target-face-num 400000 -v 0
03:53:48 [App     ] Build date: Jan 15 2022, 01:48:36
03:53:48 [App     ] CPU: AMD Ryzen 5 2600 Six-Core Processor             (1 cores)
03:53:48 [App     ] RAM: 96.84GB Physical Memory 2.00GB Virtual Memory
03:53:48 [App     ] OS: Linux 5.11.0-46-generic (x86_64)
03:53:48 [App     ] SSE & AVX compatible CPU & OS detected
03:53:48 [App     ] Command line: -i /var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/odm_25dmesh.dirty.ply -o /var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/odm_25dmesh.ply --remove-spikes 0 --remove-spurious 0 --smooth 0 --target-face-num 400000 -v 0

Decimated faces 45165 (7.68%, 773ms, ETA 9s)...
Decimated faces 66784 (11.35%, 891ms, ETA 6s)...
Decimated faces 81163 (13.80%, 1s, ETA 6s)...
Decimated faces 103678 (17.63%, 1s, ETA 5s)...
Decimated faces 125235 (21.29%, 1s, ETA 4s)...
Decimated faces 147269 (25.04%, 1s, ETA 4s)...
Decimated faces 169299 (28.78%, 1s, ETA 3s)...
Decimated faces 190733 (32.42%, 1s, ETA 3s)...
Decimated faces 211539 (35.96%, 1s, ETA 3s)...
Decimated faces 229731 (39.05%, 1s, ETA 2s)...
Decimated faces 249258 (42.37%, 2s, ETA 2s)...
Decimated faces 267553 (45.48%, 2s, ETA 2s)...
Decimated faces 285136 (48.47%, 2s, ETA 2s)...
Decimated faces 303601 (51.61%, 2s, ETA 2s)...
Decimated faces 321537 (54.66%, 2s, ETA 2s)...
Decimated faces 339030 (57.64%, 2s, ETA 2s)...
Decimated faces 356273 (60.57%, 2s, ETA 1s)...
Decimated faces 373186 (63.44%, 2s, ETA 1s)...
Decimated faces 389223 (66.17%, 3s, ETA 1s)...
Decimated faces 405158 (68.88%, 3s, ETA 1s)...
Decimated faces 421233 (71.61%, 3s, ETA 1s)...
Decimated faces 437659 (74.40%, 3s, ETA 1s)...
Decimated faces 453854 (77.16%, 3s, ETA 1s)...
Decimated faces 469871 (79.88%, 3s, ETA 933ms)...
Decimated faces 485503 (82.54%, 3s, ETA 808ms)...
Decimated faces 500380 (85.07%, 3s, ETA 691ms)...
Decimated faces 514336 (87.44%, 4s, ETA 583ms)...
Decimated faces 528575 (89.86%, 4s, ETA 472ms)...
Decimated faces 542750 (92.27%, 4s, ETA 360ms)...
Decimated faces 556529 (94.61%, 4s, ETA 255ms)...
Decimated faces 570464 (96.98%, 4s, ETA 143ms)...
Decimated faces 584237 (99.32%, 4s, ETA 32ms)...
Decimated faces 588229 (100%, 4s759ms)
03:53:56 [App     ] MEMORYINFO: {
03:53:56 [App     ] 	VmPeak:	  350232 kB
03:53:56 [App     ] 	VmSize:	  147520 kB
03:53:56 [App     ] } ENDINFO
[INFO]    Finished odm_meshing stage
[INFO]    Running mvs_texturing stage
[INFO]    Writing MVS Textured file in: /var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_texturing/odm_textured_model_geo.obj
[INFO]    running "/code/SuperBuild/install/bin/texrecon" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/opensfm/undistorted/reconstruction.nvm" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/odm_mesh.ply" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_texturing/odm_textured_model_geo" -d gmi -o gauss_clamping -t none --no_intermediate_results      --max_texture_size=8192
/code/SuperBuild/install/bin/texrecon (built on Jan 15 2022, 01:47:53)
Load and prepare mesh:
Reading PLY: 171231 verts... 342596 faces... done.
Generating texture views:
NVM: Loading file...
NVM: Number of views: 434
NVM: Number of features: 287371


Loading 100%... done. (Took 133.908s)
Building adjacency graph:


Adding edges 100%... done. (Took 0.525s)
513838 total edges.
View selection:
Building BVH from 342596 faces... done. (Took: 666 ms)


Calculating face qualities 100%... done. (Took 305.913s)


Postprocessing face infos 100%... done. (Took 2.124s)
Maximum quality of a face within an image: 165333
Clamping qualities to 1273.19 within normalization.
Optimizing:
Time[s]	Energy
0	360632
8	358482
9	353996
9	351639
10	350444
11	349840
12	349397
15	349204
16	348993
17	348849
17	348750
18	348681
18	348603
19	348542
131693 faces have not been seen
Took: 329.082s
Generating texture patches:
Running... done. (Took 128.402s)
6438 texture patches.
Running global seam leveling:
Create matrices for optimization...  done.
Lhs dimensionality: 140494 x 140494
Calculating adjustments:
Color channel 0: CG took 100 iterations. Residual is 9.27642e-05
Color channel 1: CG took 100 iterations. Residual is 8.83614e-05
Color channel 2: CG took 100 iterations. Residual is 9.53038e-05
Took 0.786 seconds


Adjusting texture patches 100%... done. (Took 23.732s)
Running local seam leveling:


Blending texture patches 100%... done. (Took 277.664s)
Generating texture atlases:
Sorting texture patches... done.

Working on atlas 40 100%... done.
Finalizing texture atlases... done. (Took: 0s)
Building objmodel:
Saving model... done.
Whole texturing procedure took: 1112.85s
[INFO]    Writing MVS Textured file in: /var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_texturing_25d/odm_textured_model_geo.obj
[INFO]    running "/code/SuperBuild/install/bin/texrecon" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/opensfm/undistorted/reconstruction.nvm" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_meshing/odm_25dmesh.ply" "/var/www/data/65255377-2a79-45f1-be54-422cf72c306b/odm_texturing_25d/odm_textured_model_geo" -d gmi -o gauss_clamping -t none --no_intermediate_results    --nadir_mode  --max_texture_size=8192
/code/SuperBuild/install/bin/texrecon (built on Jan 15 2022, 01:47:53)
Load and prepare mesh:
Reading PLY: 200208 verts... 399839 faces... done.
Generating texture views:
NVM: Loading file...
NVM: Number of views: 434
NVM: Number of features: 287371


Loading 100%... done. (Took 134.796s)
Building adjacency graph:


Adding edges 100%... done. (Took 0.615s)
599473 total edges.
View selection:
Building BVH from 399839 faces... done. (Took: 884 ms)


Calculating face qualities 100%... done. (Took 309.595s)


Postprocessing face infos 100%... done. (Took 7.963s)
Maximum quality of a face within an image: 0.999726
Clamping qualities to 0.981929 within normalization.
Optimizing:
Time[s]	Energy
1	107297
6	104730
7	99285
9	96562
10	95259
12	94523
13	94085
16	93856
17	93591
18	93426
20	93314
21	93218
22	93152
24	93114
25	93094
26	93072
27	93051
16192 faces have not been seen
Took: 347.78s
Generating texture patches:
Running... done. (Took 135.087s)
7109 texture patches.
Running global seam leveling:
Create matrices for optimization...  done.
Lhs dimensionality: 220828 x 220828
Calculating adjustments:
Color channel 0: CG took 96 iterations. Residual is 9.85506e-05
Color channel 1: CG took 100 iterations. Residual is 9.21131e-05
Color channel 2: CG took 99 iterations. Residual is 9.8651e-05
Took 1.206 seconds


Adjusting texture patches 100%... done. (Took 722.932s)
Running local seam leveling:
double free or corruption (out)
Aborted (core dumped)

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 134
Traceback (most recent call last):
File "/code/stages/odm_app.py", line 94, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 346, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 346, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 346, in run
self.next_stage.run(outputs)
[Previous line repeated 4 more times]
File "/code/opendm/types.py", line 327, in run
self.process(self.args, outputs)
File "/code/stages/mvstex.py", line 117, in process
system.run('"{bin}" "{nvm_file}" "{model}" "{out_dir}" '
File "/code/opendm/system.py", line 106, in run
raise SubprocessException("Child returned {}".format(retcode), retcode)
opendm.system.SubprocessException: Child returned 134

===== Done, human-readable information to follow... =====

[ERROR]   Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See https://docs.opendronemap.org/flying/
100 - done.

Apart of few last rows, everything before looks ok. Strange. Full console output is under whole area / WebODM / setting 1 folder.
So I will try whole area orthophoto again, this time setting 4 and use-fixed-camera-params false.

Regarding rolling shutter setting in WebODM I found this: use-fixed-camera-params — OpenDroneMap 2.7.1 documentation
it really suggests to use it to help with the rolling shutter. I would suggest to extend the note for users, if we should not use this setting. And I do not agree to renaming my original post topic as I think it is not so simple regarding distortion and failure in getting reasonable quality orthophoto. I suppose we will se it after setting 4 without use-fixed-camera-params is finished.

[Saijin_Naib]

@janm

Regarding rolling shutter setting in WebODM I found this: use-fixed-camera-params — OpenDroneMap 2.7.1 documentation
it really suggests to use it to help with the rolling shutter. I would suggest to extend the note for users, if we should not use this setting

I have it on my list to edit/extend. Thank you!

[janm]

Finished whole area, this time no fixed camera setting. Full output is under my shared folder whole area / WebODM result / setting 4 no fixed camera setting/
Alas, even worse than before, image is just a few randomly placed unidentifiable parts of something.

up: orthophoto of whole area, WebODM, setting 4 without fixed-camera (value of this setting is false)

I really want to know what is going on in this as I do not understand. Is there anything in the console output to look into? Or any idea why this full orthophoto is screwed up?

[smathermather]

@janm

setting 4 no fixed camera

Can you show your full set of parameters, your log, and all your photos?

Thanks!

[janm]

yes, although I supplied the path in my shared folder, you can reach it using this link too
https://drive.google.com/drive/folders/1tPWies3Rnr3_o8Gw11I7u17Imk2WN7FQ
file “console.txt”
I do not know if this post can display it all, but I can try

[INFO]    Initializing ODM 2.7.1 - Wed Jan 19 08:59:01  2022
[INFO]    ==============
...

I cannot, the page says that there is a limit on the character count so I would suggest you to use the link. When using the link, there is also a full PDF report.
I suppose that parameters can be seen in the console output on the begining, but I can try to state what ODM displayed during processing, these parameters:

auto-boundary: true, camera-lens: brown, matcher-neighbors: 12, pc-geometric: true, pc-quality: low, pc-sample: 10, use-3dmesh: true, use-fixed-camera-params: false
basically it is the same as “setting 4” as I said before, just without this fixed camera setting.

[Saijin_Naib]

Do you have all the data available in that folder?

[janm]

Thank you Saijin, as I realized that I should provide the full dataset as well, so I just uploaded it recently. Please use this link
https://drive.google.com/drive/folders/1NoPOx5jKJh9djp3Jjj76fPeDAfYzds4h
(or if you cannot acces, try data - Google Drive)
it is the location under the folder for the whole area. All images are there. Thank you for your prompt response.

[janm]

And I would continue, I prepared next 3 uploads for three runs over the whole area with WebODM. Previously (several weeks ago) I was able to get at least slight distorted ortho, but in repeat with the same setting, I am getting only these randomly placed blocky parts of the original images. I am even more surprised and worried, whether it is ever possible to get a normal ortho out of WebODM, or even ODM in this situation. Please see the attached images below.

https://drive.google.com/drive/folders/1yzoaSCTPLb1J_iCtbfZf94OTxZjUG74b?usp=sharing
up: previously at least partially correct and partially distorted ortho with certain settings (please see console.txt)

https://drive.google.com/drive/folders/1a4WZSBicqpgS6XVS15rWcU1rQlAPiLjA?usp=sharing
up: another previously partially correct ortho, another settings (camera lens auto - previously brown, and several other params changed in comparison to former)

As I do not have PDF report recorded out of that last launch, I decided to run it again with the same params (console.txt) but to my big surprise, the ortho came out again screwed completely.

https://drive.google.com/drive/folders/14OUI-AnoEeuONoOhGMm5lMt7qN3hjrpf?usp=sharing
up: same settings and also data as before, but this time also with PDF, but much worse ortho output.

from the webpage of WebODM I can read params (previously I did not record these)

auto-boundary: true, dsm: true, max-concurrency: 6, mesh-octree-depth: 9, mesh-size: 100000, min-num-features: 24000, orthophoto-resolution: 10

you can see no fixed camera setting, and also in the console.txt there is that setting set to false. So I doubt this setting is responsible for this bad output, if ever it was before.
I really can’t figure out what’s going up on there, but it is perhaps very simple in its core, but I can’t figure out what it is. It is a setting? Or damaged module and the need to reinstall? But we should find out what it is in order to prevent that from happening. There are no signs for errors in the console output, which is further troubling. I have plenty of RAM and disk space, so I really can’t get into it. I am afraid that I am no longer able to generate even previously partially distorted ortho, ending only with those randomly laid out blocks of shapes, like the last above. Perhaps a problem is having any temporary files, which conflicts with subsequent runs, or a bad module? But no signs in the console.txt.

[Saijin_Naib]

Looks like reconstruction isn’t going well.

Seems like this camera is not in the upstream OpenSFM camera database, so I’m working to get it upstreamed after testing it locally to make sure the camera parameters help reconstruction.