DRONE EMOTIONS TECHNICAL SCENARIO · 02
An illustrative professional workflow for organizing, testing, processing and validating several thousand high-resolution UAV images while balancing output requirements, computing resources, storage performance and quality control.
02
TECHNICAL SCENARIO
Scalable Aerial Processing
Several thousand images
Multiple flights · Professional outputs
PREPARED BY DRONE EMOTIONS
ILLUSTRATIVE SCENARIO
This technical scenario was developed by Drone Emotions to explain how a comparable large aerial project could be structured and processed. It does not describe a specific customer engagement or claim measured processing times. Dataset size, hardware requirements, settings, duration, accuracy and deliverables must be validated against the actual images and project objectives.
PROJECT BRIEF
The assumed project contains several thousand high-resolution aerial photographs acquired during multiple flights over an extensive site. The expected products include a referenced point cloud, elevation model and orthomosaic, with the possibility of additional 3D outputs where required.
At this scale, an inefficient decision made at the beginning can consume substantial processing time, storage capacity and operator effort. The objective is therefore not to start every stage at the highest possible setting. It is to establish a controlled sequence in which the dataset, alignment, reference quality and resource demand are tested before expensive products are generated.
Large projects also introduce operational questions: whether to process as one coherent block or divide the work, how to preserve connections between flights, when network processing is justified, how shared storage may affect throughput and which intermediate results should be retained.
✓ Inspect the dataset before committing resources
✓ Preserve geometric connections between flight blocks
✓ Match processing strategy to required outputs
✓ Validate quality at defined acceptance gates
SCENARIO PROFILE
SCALESeveral thousand images
ACQUISITIONMultiple UAV flight blocks
REFERENCECamera data, GCPs and checkpoints
PROCESSINGWorkstation or local network
PRIMARY OUTPUTSPoint cloud, DEM and orthomosaic
MAIN RISKCostly reprocessing after late errors
SCALING PRINCIPLES
Additional hardware can expand processing capacity, but it does not correct weak acquisition, inconsistent reference data or an unsuitable project structure.
01
Define resolution, accuracy, coverage, coordinate system and delivery format before selecting processing parameters.
02
Find blurred images, duplicate files, missing metadata, inconsistent flights and storage problems while they are still inexpensive to resolve.
03
Use a carefully selected subset to test quality, resource demand and output suitability without treating it as a guaranteed full-project timing estimate.
04
Approve alignment and reference quality before starting point-cloud, elevation, orthomosaic or model generation.
PROPOSED WORKFLOW
The workflow separates data readiness, geometric reliability and production. Each stage has a clear reason to stop, inspect and correct before continuing.
01
Confirm which outputs are required, their spatial reference, target resolution, validation criteria and delivery format. Remove processing stages that do not contribute to a required deliverable.
02
Organize imagery by flight, camera and acquisition date. Verify file integrity, focus, exposure, dimensions, GNSS metadata, calibration groups, control coordinates, units and coordinate reference systems.
03
Estimate source, intermediate and export storage needs. Decide whether the dataset should remain one coherent block or use logical chunks, ensuring that adequate overlap and reference connections are preserved across any division.
04
Select alignment settings based on image content and reference reliability. Inspect unaligned cameras, flight-block connections, tie-point distribution, calibration behaviour, control residuals and independent checkpoints before approving the geometry.
05
Choose depth, point-cloud, surface, DEM and orthomosaic settings according to the target output and available resources. Use batch or network processing only after the project structure and shared data paths have been tested.
06
Check spatial completeness, seam behaviour, elevation consistency, artefacts, checkpoints and export settings. Archive the report, coordinate definitions, processing log, project version and limitations with the final products.
PROCESSING ARCHITECTURE
A powerful workstation, a carefully segmented workflow and a processing cluster solve different problems. The correct architecture depends on project frequency, stage-specific resource use, storage throughput, network capacity and operational complexity.
Network processing can distribute supported tasks across workers, but every participant must reliably access the project data and intermediate results through the shared storage architecture. A slow or unstable data path can limit the benefit of additional nodes.
OPTION 01
Suitable when projects can be completed within available RAM, GPU, CPU and local fast-storage limits and operational simplicity is important.
OPTION 02
Useful where logical project divisions exist, provided connections, references and final merging requirements are designed before processing.
OPTION 03
Appropriate for recurring heavy workloads when supported tasks can be distributed and workers, server, clients and shared storage are correctly configured.
OPTION 04
Valuable for repeatable operations after settings and quality gates have been proven. Automation should preserve logs and stop conditions rather than conceal errors.
QUALITY CONTROL
Quality assurance should be performed at the moment an issue can still be corrected efficiently. A clean final orthomosaic cannot compensate for weak block geometry or an incorrectly defined coordinate system.
Confirm that the required flights, images, control records and coordinate definitions are complete. Record excluded images and the reason for each exclusion.
Review unaligned cameras, weak or isolated regions, flight-to-flight connections, camera calibration groups and tie-point distribution across the entire project.
Verify units and coordinate systems, inspect control residuals and evaluate independent checkpoints separately. Do not use the same evidence both to establish and to claim validation of the solution.
Inspect surface noise, holes, edge effects, water or vegetation artefacts, seamlines, colour discontinuities and local elevation behaviour before final export.
Retain the processing report, settings, software version, logs, project structure and export definitions needed to understand or repeat the result.
EXPECTED DELIVERABLES
These are potential deliverables for the illustrative scenario. Their resolution, accuracy, completeness and suitability must be confirmed from the actual acquisition and validation evidence.
●
A spatial dataset prepared for inspection, classification or downstream analysis.
▲
An elevation product generated and classified according to the required application.
■
A georeferenced image product reviewed for seams, distortions and coverage gaps.
✓
Project settings, reference results, checkpoints, exclusions and known limitations.
EXPERT DECISIONS
Not automatically. The correct settings depend on source resolution, feature scale, required output, available resources and delivery tolerance. Higher settings increase demand but cannot correct missing overlap, blur, poor control or weak geometry.
Chunking is appropriate when there are defensible geographic, acquisition or production boundaries and sufficient connections can be maintained. Arbitrary division may complicate calibration, alignment, referencing, merging and final quality assessment.
Adequate RAM helps a project complete without excessive memory pressure, but processing speed also depends on the stage, CPU, GPU, storage, data access and software settings. The main bottleneck should be identified before hardware is expanded.
No. Benefit depends on whether the selected task can be distributed effectively, worker capability, server configuration, shared-storage performance, network throughput and project structure. The complete architecture should be benchmarked with a representative task.
No. A representative subset is useful for comparing settings and identifying bottlenecks, but scaling may not be linear. Full-project geometry, storage behaviour, task subdivision and output size can change resource use.
HOW TO INTERPRET THIS SCENARIO
This page is a professional planning example, not a benchmark report. It does not claim that a specific workstation, cluster or setting will process a given number of images within a guaranteed time.
It also does not state a guaranteed positional accuracy, ground sampling distance or output resolution. Those values require the real camera data, flight geometry, control survey, coordinate system and validation results.
PROJECT-SPECIFIC RISKS
✓ Image overlap, blur and exposure
✓ Flight-block and camera consistency
✓ Coordinate systems, GCPs and checkpoints
✓ RAM, GPU, CPU and storage constraints
✓ Network and shared-storage performance
✓ Surface complexity and required outputs
CONTINUE EXPLORING
Move from the illustrative scenario to live learning, customized support, software information and official documentation.
LIVE WEBINAR
Explore the dedicated live session for demanding aerial photogrammetry projects.
View WebinarTRAINING
Choose workshops, online courses or consultation focused on your own data.
Explore TrainingSOFTWARE
Review the professional edition for advanced and distributed workflows.
View Professional EditionOFFICIAL RESOURCE
Consult the current manual for version-specific processing and network guidance.
Open Official ManualsFROM SCENARIO TO REAL DATA
Tell Drone Emotions about your image count, camera resolution, acquisition structure, hardware and required outputs. We can help you evaluate a suitable Agisoft Metashape workflow, training path or processing architecture.
Technical scenario prepared by Drone Emotions S.R.L. — Authorized Agisoft Reseller & Training Center · Last reviewed September 2026
