These articles are not testable. They are offered for students who want to understand the engineering of underwater mapping more deeply.
Article 1: Why Photogrammetry Needs Overlap
The fundamental operation in photogrammetry is triangulation. Given two photos of the same point taken from different positions, the software finds that point in both photos, then projects a line of sight from each camera through that point. Where the two lines intersect, in 3D space, is the position of the physical point.
For this to work, the software has to identify the same physical point in both photos. It does this by finding distinctive local features — corners, edges, texture patches — and looking for matching patterns. If a feature appears in only one photo, it cannot be triangulated. If a feature appears in only a small overlapping region, the triangulation is geometrically weak — the two lines of sight come from nearly the same direction, so a small error in matching produces a large error in 3D position.
The 80% overlap target is empirical: it gives the software enough common features per pair of frames to make robust matches, with enough geometric separation between camera positions to make those matches into well-conditioned triangulations. Below about 70% overlap, software reliability drops sharply. Below about 50%, modern software typically fails.
The 60% side overlap is similar but applies between adjacent strips in a grid pattern. It ensures that the same features appear in frames from multiple swim directions, which gives a more isotropic constraint on the 3D solution.
The 70–80% angular overlap for orbit photogrammetry exists for the same reasons, in a different geometry: each pair of adjacent frames around the object must share enough features to match, with enough angular separation to triangulate.
The cost of overlap is shutter count: more overlap means more photos, more battery, more storage, more processing time. The benefit is robustness. Industry practice has settled on these numbers as the sweet spot.
Article 2: Registration in Practice
Module 4 covered the concept of registration. This article covers what it looks like in practice.
When you finish Dive 2 and bring your photogrammetric image set ashore, you process it in software like Agisoft Metashape, Pix4D, or open-source equivalents. The output is a textured 3D mesh in some arbitrary coordinate system the software invented. The mesh might be oriented with "up" pointing sideways, scaled to the wrong size, and translated to the origin of a coordinate system that has nothing to do with the real world.
You then need to put this mesh into the same coordinate frame as your bathymetric data. Modern photogrammetry software supports this directly: you identify points in the image set whose real-world coordinates you know (the control points you placed before the dive) and enter their coordinates. The software computes the seven-parameter transformation (translation in three dimensions, rotation about three axes, and uniform scaling) that best fits the mesh to those known positions.
With three control points, the fit is exact. With more, the software computes the best least-squares fit and reports a residual error — the average distance between each control point's known position and where the transformation placed it. That residual is your registration accuracy.
The bathymetric data is already in real-world coordinates (GPS lat/lon for horizontal, sonar depth for vertical). You import the now-georeferenced photogrammetric mesh into the same GIS or processing environment, and the two products sit in the same coordinate space. You can drape the photogrammetric texture over the bathymetric surface, or visualize them side by side, or query points by their real coordinates.
ICP-style surface alignment is useful when you have overlapping regions of dense data in both datasets and few good control points. The algorithm is sensitive to initial conditions — you usually have to manually rotate the photogrammetric mesh close to its correct orientation before ICP can find the right local minimum. Practical advice: get the control points right; treat ICP as a refinement, not a primary alignment method.
Article 3: A Note on Recreational vs Survey-Grade Accuracy
The accuracy budget in Module 4 (±3–8 m absolute) sounds bad until you compare it to the alternative. A professional hydrographic survey using a multibeam sonar from a survey vessel with RTK GPS achieves centimeter-level horizontal accuracy and centimeter-level vertical accuracy. Such a survey costs in the tens of thousands of dollars per site and is conducted by licensed marine surveyors.
Your Deeper-and-camera setup produces a product accurate to a few meters absolute and sub-meter relative. That is enough to:
-
Identify and locate features for return visits.
-
Document changes in a site over time (relative accuracy matters, absolute does not).
-
Communicate site geometry to other divers.
-
Support recreational and educational purposes.
It is not enough to:
-
Define legal boundaries.
-
Support archaeological excavation.
-
Replace official navigational charts.
-
Support salvage operations.
Knowing what your data is good for, and what it is not good for, is part of producing it responsibly. When you publish a map, the accuracy statement matters.
Try it online: the Accuracy & Limitations statement builder in the Tools section at reefcartographer.com