Agisoft Metashape drone survey workflow: from photos to deliverables

1. Why your processing workflow determines whether the field data was worth collecting

A drone survey is only as valuable as the deliverables it produces. You can fly a perfect mission — RTK fixed throughout, 80% overlap, ideal GSD — and still deliver unusable data if the processing workflow is wrong. The alignment settings, the camera optimisation parameters, the depth filtering choice, the CRS configuration — each of these decisions affects the accuracy of the final orthomosaic, DEM, and point cloud. Get any of them wrong and the checkpoint residuals will tell the story before the client does.

This matters commercially because the processing stage is where you create the deliverables that clients actually pay for. The flight is logistics. The processing is the product. For mining clients expecting audit-quality volumetrics, or construction clients comparing your DEM against a design surface, the difference between a disciplined Metashape workflow and a rushed one is the difference between a defensible report and a liability.

Agisoft Metashape Professional is the processing platform I use for every technical deliverable. It handles the full pipeline from RTK/PPK-geotagged image import through to GeoTIFF, LAS, and DXF export. It runs offline — critical for processing in the field on a laptop when internet access is unreliable — and gives the operator full control over every parameter. That control is the advantage over cloud platforms, but it also means the operator must understand what each setting does and why it matters.

2. The Metashape processing pipeline — six stages, one project file

Every Metashape survey project follows the same six-stage pipeline. The stages are sequential — each depends on the output of the previous one. Understanding this pipeline as a single continuous process, not six separate operations, is what separates a reproducible workflow from ad hoc processing.

The project file (.psx) stores every intermediate result. Save after each major stage. If a dense cloud build fails or a checkpoint review reveals a CRS error, you can revert to the alignment stage and reprocess without re-importing images. This is one of Metashape’s structural advantages over platforms that run the full pipeline as a single black-box operation.

3. Project setup and image import

3.1 Project creation and folder structure

File → New. Save immediately to a dedicated folder named with the date, site, and client: 2026-04-15_Omai_StockpileSurvey. Consistent naming is not optional — when you have 40 projects across repeat-survey clients, searchability is what keeps the archive usable.

Keep the Metashape project file (.psx) and its associated data folder in the same parent directory as the source images. Do not move images after import — Metashape stores relative paths and will lose the image links.

3.2 Importing images — the two PPK paths

There are two routes for getting PPK-corrected geotags into Metashape, and which one you use depends on the job.

Path A: PPK in DJI Terra first, then import corrected images to Metashape. This is the faster route for straightforward jobs. Run Local PPK in DJI Terra — load the PPKRAW.bin and base station DAT file, enter base coordinates, calculate. Terra overwrites the EXIF geotags with corrected positions. Import the corrected images into Metashape via Workflow → Add Photos. The geotags are already PPK-corrected; Metashape reads them directly.

Path B: Use Metashape’s GNSS/INS processing tools. For complex jobs where you need finer control over the correction process, or when working with third-party base station RINEX data that Terra does not accept natively, import the raw-geotagged images into Metashape and use Tools → GNSS/INS Offset to apply corrections within the Metashape environment. This path keeps the entire workflow inside one application.

For RTK missions where the flight log shows uninterrupted Fixed solution, import the images directly — the RTK-corrected geotags in the EXIF are already centimetre-accurate.

3.3 Setting the coordinate reference system

In the Reference pane, set the CRS to WGS84 / UTM Zone 21N (EPSG:32621) for all Guyana work. Verify that camera positions display correctly on the map view after import. If positions cluster at the origin or scatter randomly, the CRS is wrong or the geotags did not import correctly — fix this before proceeding.

4. Photo alignment — settings, thresholds, and what to do when it fails

Workflow → Align Photos. This is the most consequential step in the pipeline. Alignment determines camera positions, orientations, and the initial tie point cloud. Everything downstream — dense cloud, DEM, orthomosaic — inherits whatever errors exist in the alignment.

4.1 Alignment success threshold

Target: ≥95% of images aligned. Below 95%, inspect the unaligned images — they are usually caused by motion blur, insufficient overlap at mission edges, or images captured during turns. Below 90% alignment, the dataset has a structural problem: either the overlap was insufficient, the geotags are corrupted, or lighting conditions caused widespread feature-matching failure.

4.2 Tropical lighting and alignment quality

In Guyana, the equatorial sun at midday produces harsh overhead light that eliminates surface texture on flat, light-coloured materials — sand, concrete, laterite. This directly reduces tie point density over those surfaces, which in turn creates weak areas in the alignment where the dense cloud will have holes. Fly at 07:00–09:00 or 15:00–17:00 to get raking light that reveals surface texture. If you must process a midday dataset, expect lower tie point density over low-contrast surfaces and inspect the sparse cloud carefully before proceeding to dense cloud.

5. GCP and checkpoint integration

Even with RTK/PPK geotags delivering centimetre-accurate camera positions, GCPs and checkpoints serve distinct and non-redundant functions. GCPs constrain the model to ground truth. Checkpoints validate the accuracy independently. You can skip GCPs on RTK/PPK jobs if the geotag quality is confirmed — but you should never skip checkpoints. Checkpoints are what allow you to write an accuracy statement in the client report.

5.1 Importing and marking GCPs

5.2 Setting checkpoints

Checkpoints are GCPs that are excluded from the optimisation — they provide an independent accuracy assessment. In the Reference pane, right-click a marker and uncheck the ‘Control’ checkbox. That marker becomes a checkpoint: Metashape reports its residual error but does not use its coordinates to constrain the model.

Minimum standard: 2 checkpoints per survey area, at different elevations and positions. For mining audit-quality work, 3–5 checkpoints distributed across the site.

6. Dense cloud generation

Workflow → Build Point Cloud (Metashape 2.x) or Build Dense Cloud (earlier versions). This step generates the full 3D surface reconstruction from the aligned imagery. It is the most computationally intensive stage and the one most affected by GPU performance.

6.1 GPU acceleration

Go to Tools → Preferences → GPU. Enable all available NVIDIA GPUs. Dense cloud generation on an NVIDIA RTX card processes a 300–500 image dataset in 30–60 minutes at High quality. Without GPU acceleration, the same dataset can take 3–5 hours on CPU alone. If you are processing in the field on a laptop, this is the difference between delivering same-day results and telling the client to wait.

6.2 Inspecting for holes and artefacts

After the dense cloud builds, inspect it visually before proceeding. Rotate the 3D view and look for:

• Holes over smooth, reflective, or dark surfaces — common on wet laterite, standing water, polished metal roofing, and fresh asphalt. These areas lack texture for stereo matching.
• Canopy edge artefacts — in Guyana interior operations where forest clearings border the survey area, the transition from canopy to open ground produces noisy reconstruction at the tree line. Crop the dense cloud to exclude non-essential canopy areas.
• Noise clusters above the ground surface — caused by birds in flight, dust, or moving vehicles during the mission. Delete these manually with the selection tools before building the DEM.

7. DEM and orthomosaic generation

7.1 Building the DEM

7.2 Building the orthomosaic

Processing time for the DEM and orthomosaic together is typically 10–20 minutes for a 300–500 image project on an NVIDIA GPU workstation. These are the two primary visual deliverables for most clients.

8. Accuracy verification — checkpoint residuals and quality metrics

This is the step that separates a professional survey from a pretty picture. Before exporting anything, verify the accuracy of your reconstruction against the independent checkpoints collected in the field.

8.1 Checking residuals

Open the Reference pane. The Errors column shows the difference between the surveyed checkpoint position and the position predicted by the Metashape model. Review both the per-checkpoint errors and the summary RMSE.

8.2 What triggers a reprocess

If checkpoint residuals exceed the targets above, do not export the deliverables. Work backwards through the pipeline:

1. First: verify the checkpoint was measured correctly in the field and marked correctly in Metashape.
2. Second: re-run Optimize Cameras with additional parameters (enable ‘Fit additional corrections’).
3. Third: if the mission had RTK float periods, reprocess the geotags via PPK and re-import.
4. Fourth: if residuals persist, add GCPs to constrain the model and re-optimise.
5. Last resort: re-fly the mission.

9. Export and deliverable packaging

9.1 Orthomosaic export

File → Export → Export Orthomosaic. Format: GeoTIFF. CRS: WGS84 / UTM Zone 21N. Compression: LZW (lossless, reduces file size by approximately 40–60%). Enable ‘Write World File’ if the client’s GIS software requires a .tfw sidecar. For very large sites, enable tiling to produce manageable file sizes.

9.2 DEM export

File → Export → Export DEM. Format: GeoTIFF. CRS: same as orthomosaic. This is the elevation dataset used for volumetric calculations, contour generation, and cut/fill analysis. No-data value: –32767 (standard for GIS compatibility).

9.3 Point cloud export

File → Export → Export Point Cloud. Format: LAS (standard) or LAZ (compressed — approximately 10× smaller). CRS: same as above. Enable colour export if the client requires a colourised point cloud for visualisation. Include confidence values if calculated during dense cloud generation.

9.4 Contour export

For clients who require contour plans: Tools → Generate Contours. Interval: 0.5 m or 1.0 m depending on client specification. Export as DXF or Shapefile. Contours are derived from the DEM, so their accuracy inherits the DEM quality.

9.5 Metashape processing report

File → Export → Generate Report. This produces a PDF containing survey metadata, camera positions, GCP/checkpoint residuals, overlap analysis, DEM preview, and orthomosaic preview. Include this in every client deliverable package — it is the technical documentation that supports the accuracy claims in your report.

10. Settings reference table — the production defaults

This table documents every Metashape setting used in the production workflow. Bookmark it. These are not Agisoft defaults — they are the settings I use on commercial survey jobs after testing alternatives across dozens of projects in mining, construction, and O&G.

11. Common processing errors and how to fix them

12. Equipment and software for this workflow