Feedback wanted: pre-checking mapping image sets before processing

[yan_imagery]

I’m working on a small tool for checking drone mapping image sets before sending them to processing platforms like Pix4D, WebODM, DroneDeploy, etc.

The checks are basic but practical:

- estimated compression savings
- preserved image dimensions
- RTK GPS quality
- unusually large files
- potentially blurry frames, shutter/drone speed analysis

Sample result:

Sample Drone Dataset Report

www.imageryworkbench.com

I’m mainly looking for workflow feedback:

- Do you pre-check image sets before processing?
- Would compression before upload be useful or concerning?
- Are there other checks that would matter more for mapping jobs?

Thanks.

 

[clackey]

approved by admin

 

[adm_geomatics]

I’m working on a small tool for checking drone mapping image sets before sending them to processing platforms like Pix4D, WebODM, DroneDeploy, etc.

The checks are basic but practical:

- estimated compression savings
- preserved image dimensions
- RTK GPS quality
- unusually large files
- potentially blurry frames, shutter/drone speed analysis

Sample result:

Sample Drone Dataset Report

www.imageryworkbench.com

I’m mainly looking for workflow feedback:

- Do you pre-check image sets before processing?
- Would compression before upload be useful or concerning?
- Are there other checks that would matter more for mapping jobs?

Thanks.

Did I see this on Reddit UAVmapping as well?

 

[jrios]

That sounds useful, especially for mapping jobs where the problems usually show up after processing has already wasted time.

For me, the most valuable pre-checks would be overlap gaps, blurry images, exposure changes, missing sections, weak GPS data, altitude inconsistencies, and whether the flight actually covers the full area the client expects.

I would be careful with compression though. For simple documentation it may be fine, but for mapping or measurement work I’d want to know exactly what is being changed before sending it into processing.

 

[yan_imagery]

That sounds useful, especially for mapping jobs where the problems usually show up after processing has already wasted time.

For me, the most valuable pre-checks would be overlap gaps, blurry images, exposure changes, missing sections, weak GPS data, altitude inconsistencies, and whether the flight actually covers the full area the client expects.

I would be careful with compression though. For simple documentation it may be fine, but for mapping or measurement work I’d want to know exactly what is being changed before sending it into processing.

Thanks, that is very useful feedback.

I agree on compression. For mapping/measurement work I would not want the tool to silently modify anything or imply that compressed images are always safe for reconstruction. My thinking is that compression should be presented as an estimate / optional workflow check, with clear reporting of what would change: file size, dimensions, format, quality setting, and ideally a before/after comparison.

The checks you listed are exactly the direction I’m thinking about:

- blur / sharpness outliers
- exposure changes
- altitude inconsistencies
- weak GPS / missing metadata
- file-size outliers
- missing or suspicious sections in the image sequence

Overlap gaps and full client-area coverage are probably the most valuable, but also harder because they require using image positions and/or the planned boundary rather than just inspecting the images.

Do you usually have a planned polygon/boundary available when you process mapping jobs, or are you mainly checking coverage visually after the flight?

 

[yan_imagery]

Did I see this on Reddit UAVmapping as well?

Yes, there was a similar discussion on r/UAVmapping recently around mission/raw-data QC before leaving a site.

I actually tried asking for feedback on Reddit too, but my posts kept getting caught by Reddit’s filters as a new account, so I’m asking here instead and other blogs.

The idea I’m working on is narrower: mainly image-set pre-checks before processing — blur/sharpness, exposure outliers, file-size outliers, dimensions, compression estimate, and eventually GPS/coverage-related checks. The other Reddit post looked more focused on MRK/RINEX/RTK mission health reporting.

I think both ideas point to the same underlying problem: people want to know whether a mapping dataset is usable before they waste time uploading or processing it.