Incomplete ortho - is my dataset bad?

[gm2gabriel]

Hello folks,

I am having a hard time trying to process this dataset:

https://drive.google.com/drive/folders/1qY2_ZgK1658-XTbgkZ4Cg1bOINyssTHT?usp=sharing

525 photos
Sony Qx1 5456x3632 25mm lens
100m flight height
Corridor mapping with 4 lines
Photos taken every 25m
PPK geotag

This is my last attempt
https://wln2.sfo3.cdn.digitaloceanspaces.com/8f983380-d124-4195-a9dd-0c9858a7a862/all.zip

Options: auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 8, dsm: true, dtm: true, matcher-neighbors: 0, mesh-size: 300000, min-num-features: 20000, orthophoto-resolution: 1

(PiarroPadroPersonalizado-report.pdf)

PiarroPadroPersonalizado-report.pdf (4.0 MB)

So, my ortho is incomplete, missing several photos and I am trying to improve the results.

What I have noted so far:

• the ortho reconstruction stops around an hard area with dense vegetation. Makes sense, dificult to find good features…
• the GPS errors (8.71) are too high and makes no sense to be, because this was recorded using PPK
• changing --gps-accuracy from default 10 to a lower value (like 0.25) didn’t changed the results
• on previous works, the auto camera parameters gave me “v2 sony ilce-qx1 5456 3632 brown 0.0”, however now I am getting “v2 sony ilce-qx1 5456 3632 brown 0.85” with this dataset.

Could some one please take a look at my data set and give a few hints and advice please?

Is my dataset of bad quality? Is the sobreposition too low?

What is the diferrence of “brown 0.0” and “brown 0.85”?

[Saijin_Naib]

Have you tried boosting --feature-quality ultra?

[gm2gabriel]

No, I guess the Lightning network only allows up to “high”.

[Saijin_Naib]

Still a significant improvement over medium. It will likely help your reconstruction over the woods.

[gm2gabriel]

Was already processed in “high”, which is the default settings.

[Saijin_Naib]

Have you attempted higher feature numbers? 64k, maybe?

[gm2gabriel]

Trying 64k now.

Any news about the possibility to keep partial reconstructions?

In one try I got everything on the right of the woods, and in another I got everything on the left of the woods.

Maybe I will split the dataset and manually join the two resulting rasters…

[Saijin_Naib]

@gm2gabriel

Any news about the possibility to keep partial reconstructions

We should be handling them better, but they are still a bit tricky.

I think your approach is a good one if we can’t get you stitched.

Don’t be shy, try 96k and 128k if you don’t get an acceptable stich this time.

[gm2gabriel]

So, after several trials varying parameters without sucess, I have decided to split the dataset.

Base on this parcial reconstruction:

I split in West/East with a few overlapping photos in the middle, around the woods area.

I was expecting that in each dataset maybe some photos be descarted from the reconstruction, however, I got garbage output, scaling completely wrong…

Any idea what could be causing this error?

Could it be related to camera parameters estimation?

Could it be related to gps-accuracy set to 0.5?

Could it be related to trying to force reconstruction using photos of the woods, instead of just discarting they?

First parcial reconstruction:
auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 8, dsm: true, dtm: true, matcher-neighbors: 0, mesh-size: 300000, min-num-features: 20000, orthophoto-resolution: 1
Download results: https://wln2.sfo3.cdn.digitaloceanspaces.com/8f983380-d124-4195-a9dd-0c9858a7a862/all.zip

West dataset:
auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 8, depthmap-resolution: 1000, dsm: true, dtm: true, gps-accuracy: 0.5, matcher-neighbors: 25, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 32000, orthophoto-resolution: 1, pc-geometric: true, pc-quality: high, resize-to: -1
https://wln2.sfo3.cdn.digitaloceanspaces.com/07d3304c-3aa4-433d-9975-141e6c2cda16/all.zip

East dataset:
auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 8, depthmap-resolution: 1000, dsm: true, dtm: true, gps-accuracy: 0.5, matcher-neighbors: 25, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 32000, orthophoto-resolution: 1, pc-geometric: true, pc-quality: high, resize-to: -1
https://wln2.sfo3.cdn.digitaloceanspaces.com/6f083950-d651-4bc5-a073-7005af6d6782/all.zip

Westreport.pdf (6.6 MB)
Eastreport.pdf (6.2 MB)

[Saijin_Naib]

Can you try going up to 128000 for min-num-features? I want to see if we can hammer this thing.

[gm2gabriel]

I tried, but after 19h of processing and several hours without text update, I just canceled it.

Usually this dataset takes 3-4hours do process, so I assumed something went wrong and just cancelled.

However, 64000 min-num-features produced similar results.

[gm2gabriel]

I tried several differente parameters for a few days and couln’t got a complete reconstruction…

This is my final results with WebODM Lightning, after spliting the dataset:

West:
https://wln2.sfo3.cdn.digitaloceanspaces.com/1a8562f4-f4f7-49e9-9664-51f925aaafbb/all.zip

East:
https://wln2.sfo3.cdn.digitaloceanspaces.com/7015df2a-959f-45af-9632-fb2245bad498/all.zip

Processing options:
Opções: auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 8, depthmap-resolution: 1000, dsm: true, dtm: true, gps-accuracy: 6, matcher-neighbors: 0, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 20000, orthophoto-resolution: 1, pc-quality: high, resize-to: -1, verbose: true

reportWest5.pdf (3.9 MB)

reportEast5.pdf (4.6 MB)

Also manually stiching the two maps is no easy task, the idea to use a single GCP at the overlaping area, to enforce a match at least in this points does not produced good results:

East ortho:

West ortho:

As can me seen, the GCP (arrow head) are off by more than 2m!

GPS errors continues to be a mistery for me, why is it so high? PPK geotag was used.

For benchmarking: this same dataset produced better results in Agisoft Metashape: full reconstruction and lower GPS error (I guess, according to the cameras bundle adjustment):

reportMetashape.pdf (1.2 MB)

Concerning the pattern of the camera adjustments in Metashape, this can be explained by the lack of level-arm correction in the PPK geotag process.

My rover RTK antena is at least 20 off from the camera in the horizontal plane, so the level arm bias varies deppending on flight direction and drone orientation.

OBS1: was gcp really used in the West / East job? Why the report don’t say anything about it?

[Saijin_Naib]

One GCP is not going to do terribly much in terms of ability to warp/position the dataset properly… Think of a sheet of rubber you’re trying to shape by pushing on it with one fingertip at one point… You’re going to struggle. Three points of contact or more, and now you can start to shape the surface of the sheet.

As for whether or not it used the single GCP you made, it seems like not, according to the reports.

[gm2gabriel]

Ok, guess the single GCP was indeed not used.

What should I do to enforce it to be used?

I fully understood one GCP is not enough to warp/position de dataset properly. However I expected that at least this single point to be respected, i.e., even if other parts of the map have much lower accuracy or lower quality in general. It’s a tradeoff to improve the relative accuracy of one East dataset in relation to the West dataset when it’s not possible to get a single and complete reconstruction of the whole data.

[Saijin_Naib]

@gm2gabriel

What should I do to enforce it to be used?

It should have just been used… hard to say without seeing the full logs to start.