SfM: Parameter Reference

Requires the SfM licence feature

The photogrammetry workflow appears only when your licence includes the SFM feature. See Why Is This Greyed Out?.

Every value has a sensible default — you can run a first reconstruction without changing anything and tune afterwards. Select a workflow to see its settings in the Properties pane, in these groups:

Group	What it holds
Run setup (open)	What a typical survey needs: Build up to, Quality, GPS altitude is MSL, the region of interest and Confirm each run with its plan
1. Feature extraction (changes re-run the solve)	Detector, alignment image scale and the feature budget
2. Feature matching (changes re-run the solve)	Ratio test, repetitive-texture guard, GPS direction veto, inlier floor, match strategy and retrieval, GPS pair distance and cross-view candidates
3. Alignment and calibration (changes re-run the solve)	Shared intrinsics and square pixels, registration and triangulation gates, the GPS prior and its gross-error gate, lens distortion and auto calibration, bundle adjustment, and which points reach the sparse cloud
4. Dense reconstruction (changes re-run dense only)	Every dense MVS dial
5. Texturing (used by the next texture bake)	The levers of Texture Mesh from Photos
Camera display	How this workflow's cameras are drawn (see Display properties)
Diagnostics	Undistorted previews and verbose logging

The numbered groups start collapsed. That is deliberate: everything in them defaults to a safe or Auto value, so the usual path is to pick a goal and a quality, and run. Each group's name says what a change in it costs. The sections below are arranged by topic rather than by group; the table says which group to open.

What you have changed shows. A setting that differs from a new workflow's default has its name in bold, and its description ends with the default value. When Quality reads Custom, a Nearest preset row under it says which preset the settings are closest to and which fields differ — pick that preset to bring them back in line.

Feature extraction & matching

These control how features are found in each image and matched across images. They have the biggest effect on how many photos register and how complete the sparse cloud is.

Detector

• What it is: the feature detector/descriptor algorithm.
• Options / default: SIFT (default), ORB, AKAZE.
• What it does: SIFT gives the most robust, repeatable matches on natural rock texture and is the best default for quality. ORB is a fast binary detector—much quicker and lighter on memory, but produces fewer reliable matches. AKAZE sits in between.
• Example: keep SIFT for final outcrop reconstructions. Switch to ORB for a fast sanity check on a very large image set, or when you only need a rough camera layout quickly.

Alignment image scale

• Setting key: align_image_scale
• Options / default: Full, Half (1/2) (default), Quarter (1/4), Eighth (1/8), Sixteenth (1/16).
• What it does: the working resolution for feature detection, relative to each photo rather than an absolute pixel cap. Smaller is faster and uses less memory but finds fewer fine features.
• Why relative: an absolute cap makes a preset mean different things on different cameras. At a 3200 px cap, a 45 MP frame and a 12 MP frame both land at 3200 px, so the larger sensor buys nothing. A relative ladder preserves each camera's angular resolution, so a preset means the same thing everywhere.
• Example: Half for normal work, Quarter for quick tests, Full to squeeze maximum detail from a small, high-resolution set.

This matches Metashape's alignment accuracy ladder: their High = Full, Medium = Half, Low = Quarter. The presets set it for you — Fast = Quarter, Balanced = Half, Accurate = Full.

Replaces "Max image dimension"

Older projects stored an absolute max_image_dim in pixels. It is read and converted to the nearest rung when such a project is opened; the setting itself is gone.

Features per megapixel

• Setting key: features_per_mpx
• Default: 2000. 0 ignores density and uses the cap as a flat count.
• What it does: keypoint density on the working (downsampled) image. The budget for a photo is this times its working megapixels, then capped by Max features per image. Expressing it as a density rather than a count keeps detection even across mixed-resolution sets.
• Example: leave at 2000. Raise it on low-texture scenes where pairs are hard to verify. Ignored by the AKAZE detector.

Max features per image

• Default: 20000 (Fast 6000, Accurate 40000).
• What it does: the upper bound on keypoints kept per image, applied after Features per megapixel sets the budget. More features give more matches and a denser sparse cloud at the cost of speed and memory. On typical frames the density, not this cap, decides the count.
• Example: leave it to the preset; lower it for speed on a very large set, or raise it with the density on low-texture scenes (smooth, uniform rock) where pairs are hard to verify.

Lowe ratio test

• Default: 0.8 (typical range 0.7–0.8).
• What it does: a match is accepted only if the best descriptor match is clearly better than the second-best by this ratio. Lower is stricter (fewer but cleaner matches); higher keeps more matches but admits more noise.
• Example: lower to 0.75 on repetitive texture (e.g. bedded sandstone, brickwork) to suppress ambiguous matches.

Repetitive-texture guard

• Default: on.
• What it does: rejects a match when the feature has a near-identical lookalike a short distance away in its own photo — the next bed along on a striped outcrop. Such a match is a coin flip that the epipolar check cannot reject when the stripes run along the flight line, and enough of them weld points on different beds into one track: a duplicate, offset surface. Costs one extra self-match per photo.
• Its three dials:
  • Guard veto ratio (0.9) — reject when the cross-photo match is at least this fraction as close as the in-photo lookalike. Toward 1.0 vetoes less; lower vetoes more.
  • Guard band min (px) (8) — lookalikes closer than this, in original-resolution pixels, are the same corner detected twice, not a stripe, and never veto.
  • Guard band max (px) (400) — lookalikes farther than this are left to the epipolar check, which can reject distant repeats on its own.

GPS direction veto

• Default: on, threshold GPS veto threshold (deg) 30.
• What it does: rejects a verified photo pair whose relative-motion direction disagrees with the GPS baseline between the two cameras. On self-similar ground (shingle beach, wave-cut platform) the epipolar check can lock a whole pair onto a shifted copy of the pattern, and enough such pairs reconstruct a displaced duplicate of the surface. Needs photo GPS; does nothing without it.
• The threshold is the long-baseline strictness: short baselines get extra allowance automatically, because GPS noise dominates their direction. The run log reports the median error of the accepted pairs — tighten toward 25 if that sits well below the threshold, raise it if good pairs are being rejected.

Min geometric inliers

• Default: 20.
• What it does: the minimum number of geometrically-verified inlier matches for an image pair to be trusted. It is also the floor used when choosing the initial pair and registering later views. Higher = stricter (cleaner pose graph, but a thin-overlap dataset may fragment); lower admits weaker pairs.
• Example: raise to 30–40 on clean, high-overlap datasets for robustness; only lower below 20 (cautiously) when overlap is genuinely sparse.

Match strategy

• Options / default: Auto (default), Exhaustive, Vocabulary tree.
• What it does: decides which image pairs are matched at all. Exhaustive tries every pair — the most thorough, but the work grows with the square of the image count and becomes impractical past a couple of thousand photos. Vocabulary tree matches each image only against its most visually similar neighbours, which collapses the cost and tends to improve robustness by never attempting pairs that cannot overlap. Auto is exhaustive up to the threshold below, then switches.
• Example: leave on Auto. Force Exhaustive on a small, awkward set where every possible pair is worth trying.

Auto retrieval threshold (images)

• Default: 600.
• What it does: the image count above which Auto switches to vocabulary-tree retrieval. Ignored unless Match strategy is Auto.

Retrieval neighbours

• Default: 40.
• What it does: how many similar images each image is matched against under retrieval. Higher finds more overlap at proportionally more matching time.
• Example: raise to 60+ if a large set is registering poorly; drop to 20 for speed.

Retrieval sequential overlap

• Default: 0 (retrieved candidates only).
• What it does: additionally matches each photo against this many neighbours either side of it in capture order, whatever the similarity search made of them.
• Example: set to 2–5 on ordered flight lines. Retrieval ranks images by visual similarity, so a frame over featureless sand, water or snow can score poorly against its true neighbours and never be tried — this pairs it with them anyway, on the strength of capture order alone.

Epipolar RANSAC (px)

• Default: 2.0, in detection-scale pixels.
• What it does: the inlier threshold used to verify a pair's geometry.
• Example: raise it if pairs that clearly overlap are being rejected on noisy or motion-blurred imagery.

Registration tolerance (px)

• Default: 4.0.
• What it does: the base reprojection tolerance for the gates that decide whether a photo registers at all.
• Example: raise to 6–8 when photos that obviously overlap still fail to register; lower to 3 for a stricter, cleaner model.

Min triangulation angle (deg)

• Default: 2.0.
• What it does: points whose viewing rays converge at a shallower angle than this are rejected — their depth is too uncertain to trust.
• Example: raise to 3–5 for a cleaner cloud; lower only for narrow-baseline sets where you are losing too many points.

Seed pair min median angle (deg)

• Default: 8.0.
• What it does: the geometry demanded of the first pair. A weak seed settles the solve into a poor basin and everything registered afterwards inherits it. If no pair qualifies, VRGS relaxes to Min triangulation angle and retries, logging a warning.

Cameras & calibration

Share intrinsics per camera

• Default: on.
• What it does: groups photos by camera make/model/focal length and image size so they share one set of intrinsics (focal length, principal point, distortion). Fewer unknowns means a more stable, faster bundle adjustment. A portrait photo counts as a different size from a landscape one only if it was rotated upright before import — see iPhone (HEIC) photos.
• Turn off when: every image may have different intrinsics—mixed cameras, or a zoom lens used at varying focal lengths. Per-image intrinsics need more overlap to solve reliably.
• Example: leave on for a single drone camera at a fixed focal length; consider off for an ad-hoc mix of phone and drone photos.

Square pixels (one focal length)

• Default: on.
• What it does: solves each camera with one focal length, as Pix4D and Metashape do, instead of separate horizontal and vertical ones. A camera's pixels are square to well under 0.1 %, and on a survey flown along a fairly straight line a second focal length lets the lens trade against the model's shape — measured against Pix4D, one focal length halved the structure offset on such a survey.
• Turn off when: the sensor's pixels genuinely are not square (an attached calibration with a real aspect ratio). Changing it forces a full re-solve, and a lens VRGS solved earlier with two focal lengths is solved again once.

Where the starting focal length comes from

Bundle adjustment needs a focal length to start from, and it is taken from one of three sources, in this order:

1. A calibration already attached to the photograph — including one written by an earlier reconstruction of the same photos. This is the most accurate source, and it is why re-running a workflow often starts from better intrinsics than the first run did.
2. EXIF FocalLengthIn35mmFilm (tag 41989). It is normalised to a 36 mm frame, so fx = equivalent × width / 36 without needing the sensor size. The tag holds a rounded whole number of millimetres, which is close enough to start from.
3. A 50 mm assumption, if neither of the above is available.

The third is a guess, and a poor one for the imagery this tool usually sees: drone and phone cameras sit nearer 20 mm equivalent, so 50 mm begins the solve with a focal length roughly 2.5× too long. That is enough to stop photographs registering at all — and the symptom, a reconstruction that fails to register or comes out badly scaled, looks like a matching problem rather than a missing EXIF tag. The run now states it plainly instead of proceeding in silence:

[WARNING] SfM intrinsics: 12 of 255 photo(s) carry no usable focal length in
EXIF (FocalLengthIn35mmFilm, tag 41989) and were seeded from a 50 mm
ASSUMPTION. Drone and phone imagery is nearer 20 mm equivalent, so this seeds
fx roughly 2.5x too long.

If you see this line and registration is poor, attach a camera calibration to those photographs.

EXIF is read at import, not at solve time

Focal length, GPS and camera identity are read when photographs are imported and stored with the workflow. Photographs imported by an earlier version keep whatever was read then, so re-import them if you want a later version's reading.

Cameras that correct their own lens

Some cameras remove lens distortion in firmware, before the JPEG is written — every DJI drone does this, and so do most phones. The file you get is already rectilinear even though it is the original, straight off the card.

VRGS reads the camera make and model from EXIF and recognises these bodies automatically. When it does, it holds the distortion coefficients at zero through bundle adjustment instead of solving for them, and says so in the log:

[INFO] SfM intrinsics: camera 0 'DJI FC330' 4000x3000 seed fx=2222.22
       -- de-warped in firmware: distortion FIXED at zero

A camera with a genuinely raw lens is reported the other way and solved normally:

[INFO] SfM intrinsics: camera 0 'SONY NEX-5R' 3568x2368 -- distortion will be
       refined by BA

This matters more than it looks. If distortion is left free on an already-corrected camera, bundle adjustment will still find coefficients for it — a near-nadir survey makes distortion, focal length and depth strongly correlated, so the solver can lower reprojection error by absorbing feature-matching noise into the radial terms while the poses and points quietly compensate. The result reports an excellent reprojection error and is geometrically wrong, and the damage only becomes visible later, when the model is used to project photographs onto real geometry: each photo lands slightly off, by an amount that grows toward its frame corners, and the texture bake blends the disagreement into smeared bands across the model.

A low reprojection error does not prove the camera model is right

Bundle adjustment fits image features, and those features carry whatever bias the images have. The honest test is photometric — do overlapping photographs agree when sampled at real geometry? That is exactly what the texture bake's distortion self-check measures.

Auto lens calibration

• Default: on. In 3. Alignment and calibration.
• What it does: when a camera has no held calibration, VRGS looks for a convergent view cluster in the survey — an orbit of a structure, views that look at one spot from many directions — solves the lens freely on just that subset, validates the result, and then holds it fixed for the whole reconstruction.
• Why it exists: it is the answer to the corridor survey. A strip of near-parallel views cannot separate lens from structure: pinning distortion bends the residual into focal length and principal point instead, a bounded box saturates against its limits, and free refinement rubber-sheets the model. A convergent subset can separate them, and a lens solved there transfers to the rest of the survey.
• Cost: seconds, where convergent geometry exists. Where it does not — or where the subset solve fails validation — the run falls back to the normal automatic behaviour and says so in plain language rather than proceeding in silence.
• Re-runs: the phase reuses the cached poses from a previous solve, so a re-run builds once with the lens already held rather than solving twice.

Distortion policy

• Default: Auto. In 3. Alignment and calibration, where the row is labelled Lens distortion.
• Options:

Option	What it does
Auto	The decision chain below. Almost always what you want.
Fix at zero	Hold the distortion coefficients at zero. For a camera you know de-warps in firmware and VRGS has not recognised.
Refine freely	Solve distortion without constraint. The explicit escape hatch — see the caution below.
Fixed (attached calibration)	A calibration-first workflow: seed everything from the photos' attached calibration, hold distortion constant, and hold focal length and principal point close to it. Cameras without a usable attached calibration fall back to Auto.

Under Auto, VRGS works down this chain and logs one sentence saying which branch it took:

1. A valid calibration attached to the photographs — held, not refined.
2. An auto-calibrated lens from the convergent subset above — held.
3. Bounded refinement, when GPS or ground control can keep it honest.
4. Pinned at zero, when nothing else applies.

"Refine freely" is not the safe option it sounds like

Freely refining distortion from attached values is how a single bad writeback poisons a project: the solver drifts away from a good calibration and writes the drift back, and the next run starts from that. Auto holds an attached calibration rather than refining it, and Refine freely is the deliberate override.

GPS & georeferencing

These only matter when your photos carry EXIF GPS (most drone imagery does).

Use GPS prior

• Default: on.
• What it does: uses EXIF GPS to (1) optionally pre-filter image pairs that are too far apart to overlap, and (2) after a purely visual reconstruction, align the whole model to a metric East-North-Up frame and refine it with GPS as a soft constraint. The result has real-world scale and georeferencing.
• Turn off when: photos have no/poor GPS, or you deliberately want a scale-free visual reconstruction.
• Example: on for drone surveys; off for ground-based photos with no GPS.

GPS altitude is MSL

• Default: off (heights are treated as ellipsoidal).
• What it does: tells VRGS how to read the EXIF altitude. Off means ellipsoidal height — what most drones actually write, despite the EXIF specification saying otherwise — and VRGS converts it into the project's vertical frame if a vertical datum is configured. On means the altitude is already MSL/orthometric and is passed straight through without a second geoid correction.
• Why it matters: getting this wrong shifts the whole model vertically by the local geoid separation, which can be tens of metres. It is nothing to do with horizontal accuracy, and it will not look obviously wrong — it just sits at the wrong height.
• Example: leave off for DJI and most consumer drones. Turn on only if you know your camera or flight software wrote true MSL altitudes.

GPS sigma XY (m)

• Default: 5.0.
• What it does: the assumed horizontal uncertainty of the GPS positions— how much to trust GPS versus the visual geometry. Smaller pulls cameras harder onto their GPS coordinates; larger lets the photo geometry dominate.
• Example: 1–2 m for RTK/PPK drones; 5–10 m for consumer/phone EXIF.

GPS sigma Z (m)

• Default: 10.0.
• What it does: the assumed vertical uncertainty. GPS altitude is usually much less accurate than horizontal position, so this is normally larger than GPS sigma XY.
• Example: 10–20 m for consumer EXIF altitude; smaller for survey-grade vertical control.

GPS pair max distance (m)

• Default: 100.0. 0 disables it.
• What it does: when greater than 0 and both photos in a pair have GPS, matching is skipped if the cameras are farther apart than this. On large flights most pairs cannot overlap, so this is a big speed-up. Pairs where either photo lacks GPS are always tried, so projects without GPS are unaffected.
• Example: set to roughly 2–3× your photo spacing/footprint (e.g. 30–50 m) on a big survey. Raise it (or set 0) if photos that genuinely overlap are failing to register — for example a convergent set shot from far apart, or imagery whose EXIF GPS is poor enough to push a real pair over the limit.

caution

This is on by default at 100 m. If your survey has overlapping photos taken more than 100 m apart — long-range oblique or telephoto shots, for instance — those pairs are dropped before matching is even attempted. Raise the value or set it to 0.

Cross-view-direction min candidates

• Default: 16, with Cross-view-direction min pitch (deg) 25.
• What it does: guarantees every photo at least this many match candidates among photos looking in a different direction, nearest first, even when the GPS distance limit above would drop them. Oblique photos image ground at range, so the shots that tie a cliff set to a nadir set are the ones taken farthest apart — exactly the pairs the distance limit removes.
• Min pitch is how different two photos' gimbal pitch must be before they count as looking in different directions — a nadir foreshore shot against a near-horizontal cliff shot, for example. It is used only by this setting.

GPS gross-error gate (sigma)

• Default: 15 (75 m at the default 5 m GPS sigma XY).
• What it does: how many GPS sigmas a solved camera may sit from its own recorded position before the model is judged wrong about it. No receiver is 75 m out, so a camera beyond the gate is not imprecise, it is in the wrong place. This is what catches a survey that reconstructed in two pieces: the cliff and the foreshore each look perfect while one sits hundreds of metres from where it belongs. Measured in 3D, so obliques flown high are not penalised.

GPS gross-error action

• Options / default: Drop (default), Warn, Off.
• What it does: what happens to cameras that fail the gate above. Drop removes them from the model — their poses are wrong, so the points they carry and the photos they would texture are wrong too — and lists them as not registered. Warn keeps them for inspection but still stops their GPS steering the refinement; treat that geometry as unverified. Off restores the old behaviour, where a misplaced group showed up only as a large alignment RMS.

GPS authority during build (sigma)

• Default: 0 (the long-standing behaviour).
• What it does: how far, in GPS sigmas, a camera's recorded position keeps pulling at full strength while the model is being built. At 0 the pull stops growing past 2 sigma: right for one stray camera, which its neighbours should place, but it makes the survey's own shape invisible to the GPS — a model that has quietly bowed by tens of metres is bowed by the same amount whatever sigmas you choose.
• When to change it: for a domed or bowed survey, set it to the gross-error gate value, so the priors can correct the shape while the model is still soft enough to follow. Cameras that grossly disagree are dropped from each solve rather than trusted. Changing it forces a full re-solve.

Georeferencing refinement rounds

• Default: 1.
• What it does: how many times, at the end of the build, the model is re-anchored on its GPS and re-solved. The rigid alignment before it cannot change the model's shape at all, so this is the only step that can flatten a bowed or waved survey — and on a large survey a single pass moves the cameras about half a metre and stops, because one solve against a finished model cannot travel far.
• Example: raise it on a large survey whose GPS error lines show a systematic bow or wave rather than scatter. Extra rounds stop early once a round stops moving anything, so a model that already agrees with its GPS costs at most one extra solve. Changing it forces a full re-solve.

Bundle adjustment

BA max iterations (global)

• Default: 100.
• What it does: the maximum optimiser iterations per global bundle-adjustment pass. The solver usually converges well before the cap; more iterations can refine a difficult solve at the cost of time.
• Example: leave at 100; drop to 30–50 for fast previews.

BA max iterations (mid-growth rounds)

• Default: 0 (use the global cap).
• What it does: the iteration cap for the periodic global passes that run while the model is still growing; the closing passes keep the global cap. On a 1,716-photo survey the late growth rounds took 7–8 iterations and 4–5 minutes each to move the RMS by under 0.5 %.
• Example: 3 is a reasonable trial on a survey of more than a thousand photos. Changing it re-solves the sparse model on the next run.

BA linear solver

• Options / default: Auto (default), Sparse Cholesky, Iterative (Schur-Jacobi).
• What it does: how bundle adjustment solves its linear system on models above 150 cameras. Auto and Sparse Cholesky use a direct factorisation, which uses only part of the processor on a large model. Iterative uses conjugate gradients, threaded throughout, once 500 or more cameras are being solved. Iterative changes the result in its last digits, so choosing it re-solves the sparse model on the next run.

Huber threshold (px)

• Default: 2.0, in original-image pixels.
• What it does: sets how much reprojection error bundle adjustment will believe before it decides an observation is probably wrong.

Every tie point contributes a residual: the gap, in pixels, between where the solved model says the point should appear in a photo and where the feature matcher actually found it. Bundle adjustment moves the cameras and points to make those gaps small. The question this setting answers is what to do with the gaps that stay large.

Below the threshold, a residual is treated as ordinary measurement noise and counts at full strength. Above it, the observation still counts — but its influence is capped rather than growing with the square of the error. So a tie point that lands 40 px out is heard, not obeyed.

That cap is what stops one bad match from wrecking a model. Without it, error grows quadratically without limit, so a single gross mismatch — a repeated texture, a moving object, a reflection matched across two photos — can outweigh hundreds of good observations and visibly bend the cameras around it. The wreckage usually shows up far from the actual mistake, which makes it painful to diagnose.

• Lower (1.0–1.5): stricter. Reasonable for sharp, well-textured imagery where a large residual really does mean a bad match.
• Higher (3.0–4.0): more forgiving. Reasonable for soft, noisy, or motion-blurred imagery, where honest observations routinely land a few pixels out and a tight threshold would quietly discount most of your data.

These are not the same pixels as Epipolar RANSAC

Epipolar RANSAC (px) is in detection-scale pixels — measured on the downsampled working image and scaled up internally. Huber threshold (px) is in original-image pixels. The same number means different things in the two boxes, and the gap is large: on a 45 MP frame at Alignment image scale Quarter, the working image is about 2.9× smaller, so 2.0 detection px is roughly 5.8 original px.

The practical consequence is that this threshold has to track Alignment image scale. Downsample harder and feature positions get scaled up further, so their noise in original pixels grows; a threshold left where it was would sit below the noise floor and start treating routine noise as suspect. The fit would not break — it would lean toward a median rather than a mean — but you would lose precision you had paid for.

The quality presets do this for you: 4.0 for Fast (Quarter), 2.0 for Balanced (Half), 1.5 for Accurate (Full), with Registration tolerance moved the same way (6.0, 4.0, 3.0). You only need to move it yourself if you set Alignment image scale by hand, in which case scale it inversely — halve the resolution, roughly double this.

note

This applies to image observations only, across every bundle-adjustment pass (local, global, and the ground-control refinement). GPS and ground-control priors are robustified separately, at 2 sigma in units of their own quoted accuracy (for GPS while the model is built, unless GPS authority during build says otherwise), and are unaffected by this setting — tune those with GPS sigma XY / Z and the per-point accuracies in your control CSV instead.

Min views per sparse point

• Default: 3 (range 2–6).
• What it does: a point must be seen by at least this many photos to appear in the sparse output cloud. The solve itself always keeps two-view points, which carry connectivity, so changing this only remakes the cloud and never re-runs the reconstruction. 3 hides the barely constrained noise.
• Example: drop to 2 if weakly seen real ground — featureless beach, sand at the water's edge — disappears from the sparse cloud.

Dense MVS

Dense MVS runs after sparse SfM and produces the dense surface cloud. It is off by default.

Turning the dense stage on

There is no separate switch on the Properties page any more: the dense stage runs whenever Build up to is Dense cloud or further, and produces a dense coloured point cloud (<name> dense) beside the sparse one. (Older versions had a Dense MVS (learned) row here; it was the on/off switch, not a choice of a learned estimator.) The setting key is still dense_mvs_enabled, which Athos can set: turning it on raises a sparse goal to Dense cloud, and turning it off lowers any goal to Cameras and sparse cloud.

Dense MVS backend

• Setting key: dense_mvs_backend
• Options / default: PLANE_SWEEP, PLANE_SWEEP_GPU (default since October 2026), CASMVSNET. A workflow saved with PLANE_SWEEP keeps it.
• What it does: chooses the depth estimator.
  • PLANE_SWEEP is the built-in CPU plane-sweep (normalised cross-correlation). It needs no model file and runs anywhere. Roughly 22 seconds per view.
  • PLANE_SWEEP_GPU is the same algorithm as Vulkan compute shaders, on any Vulkan 1.1 GPU. Roughly 0.2 seconds per view — a 370-view survey sweeps in about a minute instead of two and a quarter hours. It needs no model file and no 3D view open, and it falls back to PLANE_SWEEP for the whole run if no suitable device is available, reporting why in the log.
  • CASMVSNET is a learned neural-network estimator that requires a casmvsnet.onnx model in the project MODELS folder and a CUDA-capable GPU.
• Do the two plane sweeps agree? They are held to the same result by differential tests: on a synthetic scene the GPU chain reproduces the CPU sweep's winning depth bin on 196,606 of 196,608 pixels, with identical validity. They share one code path for the depth bracket and for every post-filter, so they cannot drift on those at all. The refinements that follow the sweep — slanted-plane and geometric-consistency iterations — run only on PLANE_SWEEP_GPU, so with them on (the default) the GPU cloud is the better one, not just the faster one.
• Example: keep PLANE_SWEEP_GPU if your machine has a Vulkan GPU — it is far faster, it carries the refinements, and it is what makes a raised depth hypotheses count affordable. Choose CASMVSNET only if you have the model file and a GPU and want to compare learned depth.

Depth map quality

• Setting key: depth_map_quality
• Where: 4. Dense reconstruction; Quality sets it (Fast Eighth, Balanced Quarter, Accurate Half).
• Options / default: Full, Half (1/2), Quarter (1/4) (default), Eighth (1/8), Sixteenth (1/16) — the same relative ladder as Alignment image scale, applied to dense matching.
• What it does: the working resolution for dense depth estimation, relative to each photo. Cost and memory grow with the square of this, so one rung up is roughly four times the work.
• Memory: the plane-sweep grid is trimmed if it will not fit its memory budget, and the log reports both the grid actually used and the budgets it was measured against. On the PLANE_SWEEP_GPU backend the cost volumes live in graphics memory, so only fusion is priced against system RAM.
• CasMVSNet: its ONNX input is locked at 1152×864, so for that backend Half and Full buy detail by tiling instead, at roughly (T+1)² inferences per view.
• Example: Quarter is the default and is a good balance. Matches Metashape's depth map quality ladder: their Ultra High = Full, High = Half, Medium = Quarter. What Half buys is not smoother flat rock (the noise on planes barely moves) but corners and edges: on a 253-photo cliff survey the inward rounding of every bend went from 3.5 mm to nothing, the worst flat-rock noise fell by a quarter, and coverage rose five points, for four times the dense time and four times the points. Choose it for ledges and overhangs you will measure; keep Quarter for a first look. Smoother flat rock at Quarter comes from Dense MVS slanted-plane iterations (on by default), which buys more there than Half does for a tenth of the extra time.

Dense MVS neighbor views

• Setting key: dense_mvs_num_views
• Default: 5.
• What it does: how many neighbouring source views are used to estimate depth for each reference view. More views give more robust depth (slower); fewer are faster but noisier.
• Example: 5 is a good default; try 7 for wide-baseline captures, 3 for speed. (The CASMVSNET backend uses the view count baked into its model.)

Dense MVS depth hypotheses

• Setting key: dense_mvs_num_depths
• Default: 128. Allowed: a multiple of 32 from 32 to 1024.
• What it does: how many candidate depths the sweep tests per pixel. The sweep spaces them evenly in inverse depth, which is the right choice for perspective imagery but means the hypotheses are fine near the camera and coarse far away.
• Example: leave at 128 for close-range or flat-on captures. Raise to 256 or 512 on the GPU backend when the log shows wide depth brackets, or when you see a plume of points projecting away from the camera below the outcrop. If a value is too large for your GPU the run reports the device limit and falls back to the CPU sweep rather than producing a wrong cloud. The CASMVSNET backend ignores this setting; its hypotheses are baked into the exported model.

The depth resolution at the far end of a view's range is (far / near - 1) / (hypotheses - 1), expressed as a fraction of the depth itself. A view whose visible scene spans 2 m to 42 m — a 20:1 range, ordinary when looking along a cliff — therefore resolves its far end in steps of about 15%, or 5.5 metres at 42 m, when 128 hypotheses are used.

That shows up in the cloud as points landing on discrete shells metres apart: a plume projecting away from the camera, typically below and behind the outcrop. It is a quantisation artefact rather than a matching failure, so no confidence, consistency or outlier filter can remove it — a measurement whose quantum is 5 m cannot be repaired downstream. The cure is more hypotheses, or a narrower depth range.

To keep far-end resolution under about 4%:

Depth range (far / near)	Hypotheses needed
5:1	128 — the default is fine
10:1	256
20:1	512

Your own ranges are in the log. Each view reports a line like MVS depth diag view 370: bracket 2.10643-42.4069 m over 128 bins (bin width 0.0158811 m near / 5.55205 m far). If that far bin width is a significant fraction of the detail you care about, raise the setting.

Time and memory both scale linearly with the count. On PLANE_SWEEP_GPU that is about 0.08 s per view at 128 and 0.33 s at 512, which is what makes the setting practical. On PLANE_SWEEP the same change takes a view from roughly 22 s to 88 s and shrinks the working image: the CPU backend holds its cost volumes in system RAM, so the memory budget trades image area for hypotheses, and 128 → 512 costs about three quarters of the grid. The GPU backend keeps those volumes in graphics memory and checks the graphics heap instead, so raising the count there costs time only.

Dense MVS confidence cutoff

• Default: 0.75 (used by the PLANE_SWEEP backend).
• What it does: per-pixel confidence threshold on the plane-sweep result, mapped as (NCC + 1) / 2, so 0.75 corresponds to NCC >= 0.5 (a well-matched, textured pixel). Pixels below the cutoff are discarded before fusion. Raise for sparser/cleaner output; lower for denser/noisier.
• Example: 0.75 default; 0.6 (NCC >= 0.2) to densify a sparse cloud once depth is trustworthy; 0.85 for a cleaner cloud.

Dense MVS CasMVSNet confidence cutoff

• Default: 0.3 (used only when backend is CASMVSNET).
• What it does: the equivalent cutoff for the learned backend. Its confidence is a network probability on a different scale (it peaks much lower than the plane-sweep value), so this default is far below 0.75. Applying the plane-sweep cutoff to it would reject almost every point.
• Example: 0.3 default; raise to 0.4–0.5 for a cleaner learned cloud.

Dense MVS consistent views

• Default: 2.
• What it does: a fused point is kept only if at least this many other reference views agree on its depth (so 2 means a 3-view consensus including the source view). Higher = cleaner/sparser; lower = denser/noisier.
• Example: 2 default; 1 for maximum density (noisier); 3 for a clean cloud on high-overlap data.

Dense MVS depth tolerance

• Default: 0.01 (= 1%; 0.025 before November 2026).
• What it does: the relative depth-agreement tolerance used by the cross-view consistency check above. Loosen it to keep more points; tighten it for a cleaner cloud.
• Example: raise to 0.04 if the cloud is too sparse once per-view depth is good; the old 0.025 is the first thing to try. With Dense MVS slanted-plane iterations on, 0.01 cost nothing on flat rock on a 253-photo cliff survey and took a point and a half off the fattened edges (2 % fewer points); on a 46-photo bay survey at 40 m it changed nothing. Set 0.025 to reproduce a cloud made before it changed.
• Also applied: each agreeing view's own estimate of the point is projected back into the reference photograph and must land within 4 pixels (at the depth-map resolution) of the pixel it was read for, or it does not count. The depth tolerance is loosest exactly where the cameras are close to the rock and far apart, and this check is tightest there. The count of agreeing views is checked again after the estimates of other surfaces are trimmed away, so a point that only met the requirement on estimates later discarded is dropped. The pixel limit is dense_mvs_fb_reproj_px in the workflow's sfm.json (0 turns it off); it has no control in the settings dialog.

Dense MVS sky filter

• Default: on.
• What it does: runs the bundled SkyWater SegFormer model over each undistorted dense-MVS image and removes the predicted sky before depth matching and fusion. Water and person predictions are not removed. VRGS keeps sky predictions with probability at least 0.5 only when they belong to a component connected to an image border; this avoids cutting isolated pale or blue areas out of the rock. It then expands the mask by 3 pixels at dense-MVS resolution to cover the mixed sky/foreground pixels that create white or blue silhouette halos.
• Effect on reconstruction: masked pixels are excluded from plane-sweep and CasMVSNet matching. Any remaining masked depth and confidence values are also cleared before cross-view fusion, so sky cannot re-enter the dense cloud from a later stage.
• Example: leave this on for outcrops, cliffs and landscapes photographed against the sky. Turn it off only when the sky itself must remain eligible for reconstruction or while comparing diagnostic runs. The fusion log reports a sky-masked count showing how many depth pixels the active sky filter removed.

VRGS ships FP16 and FP32 ONNX versions of the model. It tries FP16 on CUDA first, then FP32 on CUDA, and finally FP32 on the CPU, so the filter still works on a machine without a compatible NVIDIA GPU. A project-specific model with the same filename in the project's MODELS folder takes precedence over the installed copy. If no model can be loaded, or inference fails for one photograph, VRGS logs the reason and uses the older colour-and-confidence sky test for the affected view instead of failing the dense reconstruction.

Semantic probability maps are cached as PNG files in <workspace>/sky_masks/. Re-running Dense MVS normally reuses them; changing the source image, image geometry, model file or preprocessing version invalidates the corresponding cache entry automatically.

To check the segmentation visually, open the Photo Browser, right-click the image and choose Show Sky Mask (magenta). VRGS overlays the exact sky mask used by the most recent successful Dense MVS run on its undistorted MVS image. The command is disabled until a successful run has produced a preview for that photo. Mask-preview mode is read-only and temporarily hides tie-point, keypoint and ground-control-point markers because those markers use the original photo's distorted pixel coordinates. Choose the command again to return to the original photo.

Dense MVS fusion voxel

• Setting key: dense_mvs_fuse_voxel_size
• Default: 0 — size it from the imagery. Otherwise a voxel edge in metres.
• What it does: fusion bins every surviving depth observation into a regular 3D grid and emits one point per occupied cell, at the confidence-weighted centroid of the observations in it. That is what stops two views of the same rock face producing a pair of slightly offset parallel surfaces. It also means the voxel size is the output resolution, and it is by far the largest influence on final point count, which scales as 1 / voxel².
• Example: leave at 0. Set a larger value (say 0.02) when you want a lighter cloud for interpretation or export; there is little point setting it smaller than auto, because that subdivides a single pixel's footprint and only splits noise.

Auto uses one ground sample distance — depth / focal length in MVS pixels, the spacing of two adjacent depth-map pixels where they land on the rock. That averages across views, which is the noise reduction the voxel grid exists for, without averaging across surface, which is detail the sweep measured. It therefore follows the thing that actually determines resolution: how far away the subject is and what resolution you swept it at.

The fusion log names the choice and the reason:

Fusion voxel 0.00372 m (auto: one ground sample, i.e. depth / focal in mvs pixels) over 446948470 observations

A gridded-looking cloud means the voxel is too coarse

If the points look laid out on a regular lattice rather than scattered over the surface, the voxel is much larger than a ground sample. Each emitted point is then the mean of many observations spread through its cell, and the mean of many samples in a cube converges on the cube's centre — so every point sits near a grid node.

Divide voxels by the consistency>=2 count in the fusion funnel to see how many observations are being averaged into each point. A handful is healthy; hundreds means the voxel is far coarser than the imagery and detail is being averaged away. Setting 0 restores the automatic size.

Dense outlier removal

• Options / default: Auto (default), KNN, Voxel, Off.
• What it does: how the statistical outlier pass after fusion is computed. Auto uses the high-quality k-nearest-neighbour filter up to 20 million points and the much cheaper voxel-occupancy filter above that, where the k-NN filter would run for a long time with no visible progress. Both remove the same scattered stragglers around the real surface. KNN or Voxel forces one; Off skips the pass (the component filter below still runs).

Dense MVS min component size

• Default: 200 points (0 disables).
• What it does: after fusion and outlier removal, the cloud is split into spatially connected components and any isolated clump with fewer than this many points is deleted (the largest component is always kept, so the filter can never remove the model itself). This is the filter that kills the small floating patches of noise that can appear below the model over low-texture or repetitive ground: those patches are locally dense, so the statistical outlier stage cannot tell them apart from real surface — only their isolation gives them away.
• Example: if a few larger islands survive, raise it (500–1000); if a genuinely separate part of the scene (a detached block, a second outcrop face) is being removed, lower it or set 0. The fusion log reports how many islands and points were dropped.

Dense MVS fuse each point once

• Setting key: dense_mvs_fuse_once
• Default: off.
• What it does: fusion builds each point from all the photos whose depth maps agree on it. Without this, every one of those photos also adds its own version of the same point, each averaged from a slightly different set of photos, and the versions stack into a surface a centimetre or two thicker than it should be. The more photos overlap, the thicker it gets. With this on, the photos that went into a point do not add it again.
• Example: turn it on for surveys where every part of the rock is seen by many overlapping photos — a drone orbit or a dense close-range set. On a 253-photo cliff survey it made the cloud a fifth thinner (a third with Dense MVS one point per surface also on), a third smaller, and fusion twice as fast. On a 46-photo survey it changed little and lost a little coverage on edges, which is why it is off by default. The fusion log reports how many pixels it skipped (already fused in the fusion funnel).

Dense MVS bilateral matching

• Setting key: dense_mvs_ncc_bilateral_sigma
• Default: 0 (off). 0.2 is the usual value when on.
• What it does: each depth-map pixel is matched between photos using a small window of pixels around it, and every pixel in that window is assumed to lie at the same depth. Where the window straddles the edge of a ledge, the textured side wins and the ledge bulges a few centimetres past its true edge. With this on, each pixel of the window is weighted by how close its grey level is to the centre pixel's, so pixels across a colour edge stop pulling the match to their side. The weights come from the photo being matched, so they cost almost nothing.
• Example: turn it on at 0.2 for outcrops with sharp ledges and overhangs. On a 253-photo cliff survey it took a point off the share of edge pixels placed in front of the surface (21 % to 20 % at Quarter, 19 % to 18 % at Half) and trimmed the planar noise by 5 %, at no cost in time. The gain is modest because a ledge of the same rock in front of the same rock gives the weights nothing to work with; it is a free improvement, not a cure. Smaller values (0.1) weight more sharply; above 0.5 it is nearly off again.

Dense MVS matching window

• Setting key: dense_mvs_ncc_window
• Default: 5 pixels (odd, 3–15).
• What it does: the size of the window each depth-map pixel is matched with, in pixels of the depth map. A larger window averages more noise away on flat rock but smears every depth edge wider, because the whole window is assumed to lie at one depth.
• Example: leave it at 5. It is here so the trade can be measured, not because a different value helps: at Half quality a 9 window was worse on every score — planar noise, corners, edges — and a third slower, because nine depth-map pixels at Half is the same patch of photo as five at Quarter, which gives back exactly what Half quality bought. If edges matter, raise Depth map quality instead; if flat-rock noise matters, use Dense MVS fuse each point once and the outlier filters, which do not touch the edges.

Dense MVS slanted-plane iterations

• Setting key: dense_mvs_plane_iterations
• Default: 3. 0 turns it off; more than 3 adds nothing.
• What it does: the depth maps are first built by testing, at each pixel, a set of depths with the rock assumed to face the camera squarely. Rock that leans away from the camera — most of any outcrop — cannot match exactly at any of those depths, so the match settles on a compromise that wobbles with the texture: that wobble is most of the noise on flat rock. With this on, each pixel gets its own tilted plane after the sweep, found the way COLMAP and ACMH do it: every pixel tries its neighbours' planes and a few random tilts, keeps the best match, and repeats for the number of iterations set. Runs on the graphics card (the PLANE_SWEEP_GPU backend only).
• Example: leave it at 3. On a 253-photo cliff survey at Quarter quality it took a third off the noise on flat rock (from 2.5 times a Metashape reference's to 1.6 times), halved the inward rounding of ledge corners, and moved the whole surface closer to the reference, for a tenth more dense time — more than raising Depth map quality to Half buys on flat rock, at a quarter of the time and the points. It also stacks with Half (best corners and coverage) and with Dense MVS bilateral matching (edges). It cannot help on vegetation or rubble, which are not planes at any scale. Set 0 only to reproduce a cloud made before it existed. The run log reports the share of pixels that found a better plane in each iteration (slanted-plane refinement in the dense summary).

Dense MVS geometric-consistency iterations

• Setting key: dense_mvs_geom_iterations
• Default: 0 (off). 2 is the measured value; 1 is nearly the same.
• What it does: a second pass of the slanted-plane search, run once every photo has its depth map, in which a candidate plane is also charged for disagreeing with the other photos' depth maps: the point is projected into each neighbouring photo, that photo's own depth there is projected back, and the pixel error is subtracted from the match score (COLMAP's and ACMM's second stage). A plane that matches the pixels but puts the point where no other photo puts it — a fattened edge, a reflection, repeated texture — loses. Needs Dense MVS slanted-plane iterations above 0 and the PLANE_SWEEP_GPU backend.
• Example: leave it at 0 unless the survey has water, glass or repeating texture. On a 253-photo cliff survey the fusion's own consistency vote was already removing the points this catches, so two iterations bought a point off the fattened edges and nothing on flat rock or corners, for a sixth more dense time at Quarter and a tenth more at Half. The run log reports the share of pixels that found a better plane in each iteration (geometric-consistency round in the dense summary).

Texturing

These control the photo-texture bake, not the reconstruction. All of them are diagnosable from the mesh attributes the bake writes.

Texture multi-photo blend

• Setting key: texture_blend_enabled
• Default: on.
• What it does: blends every photograph that can see a texel, weighted by how well each sees that point, instead of taking one photo per triangle.
• Example: leave on. Turn it off to see where the photo boundaries actually are — they become hard-edged, which is useful for diagnosing stripes.

Texture blend sharpness

• Setting key: texture_blend_sharpness
• Default: 4.0.
• What it does: the seam-versus-sharpness dial for the blend. High confines mixing to a narrow band — and a narrow band between two photos that disagree shows as a stripe. Low blends broadly, which dissolves stripes but softens detail.
• Example: try 1.0 if you see stripes.

Texture two-band blend

• Setting key: texture_blend_two_band
• Default: on.
• What it does: blends in two frequency bands. The coarse band — exposure, vignetting, colour — is blended broadly so seams dissolve; the fine detail above it is taken with the sharpness weight, so it comes almost entirely from the best view and cannot ghost where two photos' poses disagree by a pixel. Off blends the full colour with the sharpness weight alone, as older bakes did.

Texture lens distortion

• Setting key: texture_distortion
• Options / default: Auto (default), On, Off.
• What it does: whether to apply the solved lens distortion when sampling photographs. Auto measures it: each bake compares, over points two photos both see, how well those photos agree with the model applied and without, and uses the winner when the margin is decisive (>5%).
• When to override: Off is right for any camera that de-warps in firmware — all DJI drones and most phones — where the JPEG is already corrected even though it is the original file. On is right for a genuinely raw lens with a well-conditioned solve. Both are obeyed exactly: the measurement still runs and is reported, but will not override you.
• Getting it wrong displaces samples radially from each photo's centre, and the blend turns that into smeared bands.

Texture max UV stretch

• Setting key: texture_max_uv_anisotropy
• Default: 8.0. 0 turns the check off.
• What it does: refuses to photo-texture a triangle whose UV mapping is stretched more than this ratio (1 = undistorted, over 4 is visibly smeared, over 16 is a streak). Rejected triangles take vertex colour instead.
• What it fixes: ribbons of repeating "ladder" texture that survive every calibration change. The photograph is innocent — the unwrap is at fault: a sliver triangle squeezed to near-zero width in UV space replicates one row of source pixels along its whole length. Because the bake writes through the same UVs the renderer reads, the smear is baked in and model-locked, so it does not move with the camera. Usually a fraction of a percent of the mesh, but each one is long, so they dominate visually.

Texture max view angle (deg)

• Setting key: texture_max_view_angle_deg
• Default: 70.
• What it does: rejects a photograph whose view of a surface is more grazing than this, in degrees from the surface normal. A source pixel seen at angle θ is smeared across 1/cos θ of surface, so 75° is a 4× smear and 84° is 10× — which is what the thin banded "comb" patches on steep faces and in recesses are.
• Example: lower it if you see banding; raise it if you would rather have a smeared texture than a flat facet. Square-on views already win on score, so this only decides what happens where no good view exists. Colour the mesh by the Texture view angle (deg) attribute the bake writes to see which areas are affected.

Texture rescue occluded triangles

• Setting key: texture_rescue_occluded
• Default: off.
• What it does: textures a triangle from its best-scoring photograph even when every photograph considers it occluded.
• Example: turn it on when genuinely visible surface is being left untextured by an over-eager occlusion test; leave it off otherwise, since the rescued colour comes from a photo that may be looking at something in front.

Texture max sample spacing (texels)

• Setting key: texture_max_texel_smear
• Default: 3. 0 turns the check off.
• What it does: rejects a photograph whose samples land further apart on the surface than this many texture pixels, along the direction it resolves worst. This is what the view-angle limit is really trying to measure, measured directly: sample spacing grows with range as well as with the angle, so an angle limit cannot tell a grazing view from 20 m away from the same angle from 200 m. It stops a near-horizontal photo winning a flat area that no downward-looking photo covered — which would paint that area with a picture of somewhere else. Rejected triangles take vertex colour.
• Example: 3 is a smear you can find if you look; over 4 reads as a streak; 1 would reject sound imagery.

Texture colour balance

• Setting key: texture_colour_balance
• Default: on.
• What it does: solves one gain and offset per colour channel per photograph so the photos agree where they overlap, before blending. Exposure and white-balance differences otherwise survive the blend as patches the shape of the photo footprints — a blend can melt a seam but not a brightness step. Applied only when it reduces the disagreement; the bake log reports by how much. Turn it off to keep each photograph's original colours.

Texture chart size (xatlas maxCost)

• Setting key: texture_chart_max_cost
• Default: 2.0.
• What it does: how far the UV unwrap lets a chart grow before it stops. Higher makes fewer, larger charts — less padding waste, fewer seams and a faster pack — at the price of more UV stretch, which Texture max UV stretch catches per triangle.
• Example: try 3–4 on a Poisson mesh, and judge it by the bake log's chart count and utilisation, UV-stretch percentiles and pack time.

Texture sampling sharpness (lod bias)

• Setting key: texture_sample_lod_bias
• Default: -0.5.
• What it does: how finely each photograph is read for a texel. 0 reads it at the exact footprint; negative reads finer and sharper, positive coarser and softer. The default is what graphics drivers use, because the atlas is filtered again when it is displayed. -1 is the sharpest sensible value; below that the photos alias into speckle.

Texture blend ghost filter

• Setting key: texture_blend_ghost_filter
• Default: 0.08. 0 blends everywhere.
• What it does: how far a photograph's colour may disagree with the photo that sees a texel best before it is dropped from the blend there. Photographs agree where blending helps (exposure, vignetting) and disagree where it hurts (a surface error, vegetation, a shadow edge), so this blends the first and picks the second, removing the doubled edges of a blend. Smaller is stricter.

Texture view smoothing radius (texels)

• Setting key: texture_view_smoothing_texels
• Default: 64. 0 uses each triangle's own normal.
• What it does: how far the surface normals that decide which photograph textures what are smoothed, as a radius in texture texels (the bake log gives it in project units). A triangle's own normal on a reconstructed surface is mostly noise, and choosing photographs by it makes the winner flip from triangle to triangle, so bedding steps across every triangle edge. Smoothed, the choice changes gradually; folds and the two sides of thin features keep their own orientation.

Texture onto decimated copy (million triangles)

• Setting key: texture_decimate_mtris
• Default: -1 (offer the size the texture budget suggests).
• What it does: bakes onto a simplified copy of the mesh instead of the full one. A dense mesh unwraps into millions of tiny charts whose padding fills most of the texture; on a copy with fewer, larger triangles the same pages hold several times the surface detail, and the bake is faster. The copy is a new mesh in the workflow; the full mesh is not changed. 0 always bakes the full mesh; any other value is the copy's size. The bake dialog starts from this setting and lets you change it for one bake.

Texture detail outside the selection

• Setting key: texture_background_detail
• Default: 0.25 (range 0.01–1).
• What it does: when you texture a mesh with full detail on a selection, the share of that resolution the rest of the mesh gets. 0.25 is a quarter of the resolution — a sixteenth of the texels — and the texels saved go to the selection. The bake dialog starts from this value.

Diagnostics & output

Write undistorted previews

• Default: off.
• What it does: saves an undistorted JPEG per registered view to <workspace>/undistorted/. Useful for quality control and for downstream tools that expect undistorted images.
• Example: turn it on only when you need the files: on a large survey writing them takes minutes and a lot of disk space.

Verbose logging

• Default: off.
• What it does: emits extra per-photo, per-pair, and per-cache diagnostic messages to the log.
• Example: turn on while tuning parameters or troubleshooting a run; turn off for clean logs.