Orthophoto resolution and GSD

I’m trying to generate an orthomosaic with 10cm/pixel resolution.
Here are my settings - I selected “Fast Orthophoto” then edited the settings to change dem-resolution and orthophoto-resolution to 10cm:
auto-boundary: true, debug: true, dem-resolution: 10, fast-orthophoto: true, orthophoto-resolution: 10, rerun-from: dataset, resize to: -1, verbose: true

Upon completion the task says the Average GSD is 1.01cm and I’m confused, I was expecting this to be 10cm based on my settings.

Can anyone help me understand this?

3 Likes

One way to get your 10cm GSD would be to resize your images by 0.1X, ie make a 5472 pixel wide image 550 pixels wide.
Processing will be massively faster!

2 Likes

Just download the DSM/DTM & Orthophoto and check the resolution using GIS software of each raster data. You may see the desired resolution.

1 Like

What does the orthophoto look like - 1 or 10cm per pixel?
The GSD of the original photos isn’t changed.

1 Like

Thanks guys, I"ll try those suggestions and let you know.
I’m wondering if the Average GSD is calculated from the original photos rather than the processed outputs…?

2 Likes

I loaded the GeoTiff into QGIS and measured the width of 1 pixel: 10cm exactly, so it looks like the odm-resolution parameter is doing what it’s supposed to.

I’ll try image resizing next.

3 Likes

You must be psychic…the images in this dataset are 5472 x 3648 pixels…!?!

3 Likes

Based on my experience,
Average GSD on the report is the GSD of the pointcloud which depends of feature quality and densification.
While the orthophoto-resolution parameter acts on the orthophoto real computed GSD. You can check the gsd of orthophoto with gdalinfoor QGIS

3 Likes

Yep, as Bernarde points out, the GSD in the Report is for the reconstruction, not for the final output products, so it is working as designed.

However, if you did resize them like Gordon said, then you’d see the Report GSD change as a result.

2 Likes

I tried resizing to 2048px but that’s ended with a “Cannot process dataset” error. The log shows:
2022-04-28 11:46:11,155 INFO: Reconstruction 0: 836 images, 57695 points
2022-04-28 11:46:11,155 INFO: Reconstruction 1: 18 images, 1555 points
2022-04-28 11:46:11,155 INFO: Reconstruction 2: 6 images, 324 points
2022-04-28 11:46:11,155 INFO: Reconstruction 3: 5 images, 302 points
2022-04-28 11:46:11,155 INFO: Reconstruction 4: 4 images, 122 points
2022-04-28 11:46:11,155 INFO: Reconstruction 5: 2 images, 50 points
2022-04-28 11:46:11,155 INFO: 6 partial reconstructions in total.
[WARNING] Multiple reconstructions detected (6), this might be an indicator that some areas did not have sufficient overlap
[INFO] Attempting merge
[INFO] Merging reconstruction 0
[INFO] Merging reconstruction 1
[INFO] Merging reconstruction 2
Traceback (most recent call last):
File “/code/run.py”, line 59, in
retcode = app.execute()
File “/code/stages/odm_app.py”, line 130, in execute
raise e
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)
File “/code/opendm/types.py”, line 327, in run
self.process(self.args, outputs)
File “/code/stages/run_opensfm.py”, line 37, in process
octx.reconstruct(self.rerun())
File “/code/opendm/osfm.py”, line 55, in reconstruct
self.check_merge_partial_reconstructions()
File “/code/opendm/osfm.py”, line 92, in check_merge_partial_reconstructions
new_point = merged.create_point(point.id, point.coordinates)
File “/code/SuperBuild/install/bin/opensfm/opensfm/types.py”, line 299, in create_point
return self.map.create_landmark(point_id, coord)
RuntimeError: Landmark 3332 already exists.

Prior to that I notice some of these warnings:
WARNING: Cannot align on GCPs only, GPS bias won’t be compensated.

2 Likes

Hmm… I’m not sure we support using GCPs with image positions that are different than the Resized images. You’d have to make the GCP file with the Resized images so the pixel positions match properly.

2 Likes

Ah, that makes sense.

1 Like

Well this is unexpected…
I ran two tests using Fast Ortho at 10cm/pixel ortho resolution settings:
Test 1 used 1631 images at 5472 x 3648 pixels. Completed processing in 4h25m. GeoTiff was 10cm per pixel.
Test 2 used 1631 images at 2048 x 1365 pixels. Completed processing in 4h22m. GeoTiff was 10cm per pixel.

I was expecting it to process much faster with lower resolution photos but the reduction in image resolution had negligible improvement on total processing time. RAM and disk space consumption was reduced by about 60%.

Is this expected behaviour?

1 Like

How did you accomplish the resizing? Resize during upload, or resize externally prior?

I’m curious if the various stages that Fast Orthophoto skips means that it isn’t really slowed much by total pixel count rather than total reconstruction area.

You’d likely see a more significant difference in standard processing.

No idea about Planar Reconstruction yet, though… Maybe something to try!

1 Like

I used IrfanView to create a set of images resized to 2048x1365px, and used WebODM to create a new GCP file with those resized images.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.