Advice on Quality

[DvM]

Hi there,

so i was doing some Solar Mapping in the last days. The thermal map comes out okay but the Ortho from the RGB cam looks so much worse than the actual Photo Quality.

here are 2 screenshots as an example of the smae corner of the buliding:

1. the actual jpg from the drone:
   
   
2. The Ortho from ODM:
   
   

and here my Settings:

it was an 80/80 overlapp. The GSD should be somewhere between 0.1 and 0.2 depending on if i am looking at the top of the building or the ground.

Any Advice ? What settings should i change to get better outputs ?

[pierotofy]

Try decreasing orthophoto-resolution (set to it something really small, like 0.001).

[DvM]

i just started a set with 0.01 this morning, will be done soon. I’ll tell here how it did, anyone else any good ideas ?

[uplanddog]

what did you set min-num-features to and how many features are being detected? if it is low increasing it may help.

[shiva]

Alignment (which is a product of detected features) looks good but resolution seems low, so increasing orthophoto-resolution should do the trick.

[DvM]

Right thank you, here is the new one which looks way better with resolution set to 0.01

Thank you all, that seems to be the best solution.

[Tim]

Setting all ortho’s to be 0.01 makes them come out much better.

More info about why that happens here

Output resolution of orthos in webODM seems to be fixed and not a result of image resolution

Hi all, I seem to be getting the same resolution of ortho no matter what the base resolution of the images is. For example, in the datasets below, the one on the left was flown with an M3 (~20MP images) and the one on the right was with a P4 multispectral. GSD for the M3 (RGB) images is 0.8 while gsd for the multispec images is 0.7. I’m ~95% sure I didn’t downsize the images while uploading so I would expect the RGB ortho to be ~10% higher resolution (given the difference in GSD) but as far as…

[DvM]

Alright, so i understood that it is happening but i don’t see Why. Did you understand why this is happening and i would likly have to set the GSD to 0.001 or 0.01 ? Even if the “real GSD” is at about 0.2 a setting of 0.01 will give me better results than a setting of 0.1 ? I don’t really understand this.

Best

[Tim]

I don’t totally understand it technically, I agree I would think the ortho would use the available GSD. I always set mine to 0.01 and it comes out looking pretty good, but I haven’t tested it beyond that and I haven’t looked into what the actual output resolution of the ortho is under different scenarios. Just that setting that to 0.01 seems to fix the issue

[smathermather]

@DvM

Even if the “real GSD” is at about 0.2 a setting of 0.01 will give me better results than a setting of 0.1 ? I don’t really understand this.

We try hard to be inclusive of folks who show up with minimal machine specs. There’s nothing quite like showing up to use some software and you cannot get it to do anything.

So, we default to 5cm resolution (or estimated if that resolution is coarser than 5cm) unless the resolution is specified. So, if you’ve got plenty of RAM, re recommend setting your resolution to either your expected resolution, or better yet, a higher value since we won’t exceed the resolution we estimate your data at.

I’d like to change this in a way that still supports newcomers with limited RAM, but we’ll need to be thoughtful about how we do that.

[kikislater]

May be I’m wrong but when decreasing to 1 it doesn’t help more …
For example from gsd.py:
gsd = gsd * (1 - gsd_error_estimate) * gsd_scaling
where
gsd = opensfm_reconstruction_average_gsd(reconstruction_json, use_all_shots=has_gcp or ignore_resolution)

So for me, a value 1.0 mean the maximum possible
I tried on several project to decrease below 1.0 and already have same warning in log output:

[WARNING] Maximum resolution set to 1.0 * (GSD - 10.0%) (0.12 cm / pixel, requested resolution was 0.00 cm / pixel)

Here I tried to set 0.01, So may be there is a a problem in log.ODM_WARNING but I never get better than a value of 1.0