Photogrammetry software turns overlapping photographs into measurable maps and three-dimensional models. It is not an image editor with extra buttons; it is a reconstruction system that estimates where each photograph was taken from, works out where every point those photographs show sits in space, and builds outputs from that geometry. The same math runs whether the source photos came from a drone, a handheld camera circling a building, or a turntable scanning a small part — only the capture method and reference data change. This piece covers the shared pipeline: photos to geometry, the standard outputs, and how to judge whether a reconstruction deserves to be trusted.
Two photos and a hunch: why overlap is the whole trick
A single photograph carries no depth information. Everything visible projects onto a flat plane, so a nearby fence post and a distant hill can land on the same pixel with no way to tell them apart. Depth appears only once the same physical point shows up in at least two photographs taken from different positions — the same reason two eyes judge distance better than one. That is the entire trick: capture enough photos with enough shared coverage that every point of interest is visible from several angles, then let the software solve for the geometry that explains what those photos have in common. Skip the overlap and there is no geometry to solve.
Matching the same point across dozens of photos
The software scans each image for small, distinctive features — the corner of a shingle, a crack in pavement, a rock with an odd silhouette — the kind of detail a person would also use to recognize the same spot in ten pictures. It searches the rest of the image set for that feature, and a feature recognized from several vantage points becomes a tie point: one physical location with several 2D observations attached to it. Textured, well-lit surfaces hand the matcher plenty of tie points; flat water, fresh snow, glass, and repeating patterns like a tiled roof give it almost nothing to grab, which is why those surfaces are the usual suspects when a reconstruction comes back with a hole in it.
Solving for the camera and the scene at once
Once thousands of tie points exist, the software solves two sets of unknowns simultaneously: where every camera was positioned and pointed, and where every tie point sits in three-dimensional space. It adjusts both together until the projection of each 3D point lands back on the pixel where it was actually observed, across every photo it appears in. The output is a sparse point cloud — a skeleton of perhaps a few hundred thousand points, plus a recovered capture path. This is the moment to inspect the work: a path that looks broken or missing a stretch is a coverage problem, not a rendering glitch, and it is far cheaper to fix by shooting more photos than by hoping a later stage smooths it away.
From skeleton to surface: dense reconstruction
A sparse cloud proves the geometry can be solved; it does not carry nearly enough points to describe a surface. The next stage compares each photo against its near neighbors pixel by pixel, using the now-known camera positions to estimate depth far more densely, often producing tens of millions of points for a routine job. That dense cloud can stand on its own, or it can be connected into a mesh — a continuous skin of small triangles that turns scattered points into a surface, which can then be wrapped in the original photo texture so it reads convincingly from any angle. Meshing and texturing are structural and cosmetic conveniences; neither adds measurement accuracy beyond what already exists in the underlying points.
The four outputs, and what each one actually answers
Most jobs end in some mix of four outputs, and they are not interchangeable — each answers a different question.
An orthomosaic is a single, distortion-corrected top-down image, stitched from the source photos and reprojected so scale stays consistent across the frame. It answers "what does this look like from directly above," and it reads easily because it still resembles a photograph. It is a poor tool for judging height, since flattening a view to top-down also flattens away height.
A point cloud is the dense set of measured points itself: a position, and usually a color, for millions of individual locations. It answers "where exactly does this point sit in space," and it is the rawest output on the list, because nothing has been filled in or interpreted on top of it.
A mesh connects that point cloud into a continuous triangulated surface, optionally textured with the source photos. It answers "what is the shape of this object or site," and it is what people rotate on screen or run a volume calculation against, because a surface has an inside and an outside in a way a raw point cloud does not.
A digital surface model (DSM) is an elevation grid of whatever the cameras saw — rooftops, canopy, vehicles, stockpiles, all included. A digital terrain model (DTM) is an elevation grid of bare ground only, which requires classifying and stripping out everything that is not terrain. A DTM is therefore an interpreted product rather than a direct measurement, and its classification step deserves the same scrutiny as any other processing decision.
Where reconstructions actually fail
The same handful of conditions account for most disappointing results: overlap thinner than planned, water or vehicles or people that moved between passes, reflective surfaces, texture-less ground such as fresh snow, and exposure that drifted as light changed over a long session. None of this throws an error message; it shows up as a hole, a smear, or a warped patch in the finished product — which is why a successful alignment is not the same claim as a correct dense reconstruction. Alignment only means the photos agree well enough to connect; it says nothing about whether the resulting surface matches the real object.
Reference data does not replace an independent check
Image positions recorded by onboard GNSS can help initialize a project. Ground control points and independent checkpoints — physical, surveyed marks visible in the photos — add observations from outside the photo set entirely. None of these alone prove the reconstruction is correct; they narrow the range of possible error and give a reviewer something concrete to compare against. A model can be perfectly self-consistent, every photo agreeing tightly with every other, and still sit in the wrong place if nothing ever tied it to an external reference.
Reviewing the reconstruction, and documenting the handoff
A colorful thumbnail is not quality assurance. A real review starts with the sparse cloud and camera path before any dense product is generated, continues by orbiting dense products from several angles rather than judging one screenshot, and compares checkpoints against the model directly wherever they exist. The step most often skipped is opening the export files in whatever software the recipient will actually use, since that is where missing spatial reference or a broken texture link surfaces. Whatever survives that review needs a note attached — coordinate system, dates, which checks ran, what is still unverified — labeling a visualization as a visualization rather than leaving it to be mistaken for a survey result.
How to judge a photogrammetry tool
Feature lists are a poor way to compare photogrammetry software, since most tools claim similar outputs. A better comparison asks what a specific tool actually surfaces to the operator: whether alignment problems are visible before dense processing burns hours of compute, how calibration and control points are handled, whether classification tools are transparent about their assumptions, and whether a finished project can be reopened and reproduced by someone other than the person who built it. Where the computation runs — a remote server or the operator's own machine — is one factor among many, not the single question that decides the comparison.
Where this pipeline gets specific
Everything above holds regardless of what took the photos. Aircraft introduce their own decisions and failure modes: Drone Photogrammetry Software: What Commercial Pilots Actually Need. Matching a client's request to the correct export is its own skill: What Is Drone Mapping Software? From Photos to a Usable Deliverable. And when the output must satisfy a licensed surveyor's coordinate and control requirements: Surveying Software and Drone Data: What a Usable Deliverable Requires. For a local-processing comparison, see DroneDeploy Alternative: Local Photogrammetry Without Per-Map Fees.
If you are deciding which part of the reconstruction pipeline needs a closer look, ask the follow-up on Ask Mav at pilotledger.com.