The volume of overhead imagery now collected over any contested area exceeds what human analysts can ever inspect frame by frame. The intelligence question is rarely "what is in this image" – it is "what is different from the last time we looked." Change detection answers that question directly: it compares co-registered imagery across passes and reduces a stack of identical-looking scenes to a short, geolocated list of places where the physical world moved. New revetments appear, vehicles mass at a depot, a bridge is cut, a runway is repaired. This article walks the full pipeline – co-registration, radiometric normalization, the change models themselves, false-alarm control, and the analyst-cueing stage that turns a change mask into an intelligence product. The same discipline that powers computer vision on ISR drones applies here, but the temporal dimension changes everything.

What change detection actually produces

The deliverable of a change-detection system is not an image – it is a decision aid. A working pipeline ingests a reference image (the last trusted baseline of an area) and a new image (the latest pass), and outputs a set of change polygons: bounded regions where the scene differs meaningfully from the baseline, each tagged with a confidence score, an area, a WGS84 footprint, and ideally a change class. An analyst receives a ranked cue list with before/after image chips rather than a full scene to scan. This inversion – from "interpret everything" to "adjudicate only what moved" – is the entire value proposition. It multiplies analyst throughput and, more importantly, shortens the time between a physical change on the ground and an alert in the hands of a decision-maker.

That framing matters because it sets the engineering priorities. The system is judged not on how much change it finds but on the trustworthiness of its cue list. An analyst who is shown ten cues and finds nine of them are noise will stop trusting the eleventh. Precision – the fraction of cues that are real – is the metric that governs operational adoption, and almost every design decision below is in service of it.

Co-registration: the precondition for everything

Two passes of the same coordinate are almost never pixel-aligned. The platform flies a slightly different orbit or track, the sensor looks from a different angle, terrain relief induces parallax, and orthorectification leaves a residual error of its own. Every one of these geometric differences is read by a naive change model as change. The result is a halo of false alarms tracing every high-contrast edge in the scene: building outlines, road margins, field boundaries, coastlines. In practice the single largest source of operational false alarms is not the change model – it is registration error.

The fix is sub-pixel co-registration. Both images are first orthorectified against a digital elevation model (DTED or a commercial DEM) and projected to a common map frame, which removes the bulk of terrain-induced parallax. The new image is then registered to the reference using tie-point matching or phase-correlation in the Fourier domain, refining alignment to better than 0.5 pixel RMS. Tiles that cannot be registered to that tolerance – over featureless desert or open water, for instance – should be flagged and excluded rather than forced, because a poorly registered tile contributes only noise.

Why orthorectification is not optional

It is tempting to skip orthorectification for nadir-looking imagery on flat terrain. This is a trap. Even small off-nadir angles combined with vertical structures – buildings, towers, terrain edges – produce lean and displacement that vary with look geometry between passes. A 30-metre building imaged from two different azimuths will appear to "move" by several metres at its roofline. Without orthorectification and a height model, that apparent motion is indistinguishable from real change, and the false-alarm rate around every tall structure becomes unmanageable.

Radiometric normalization: removing what changed but does not matter

Even perfectly aligned imagery differs radiometrically between passes. Sun angle shifts with time of day and season, atmospheric haze and aerosol load vary, and sensor gain and calibration drift. A change model that sees raw intensity will flag an entire hillside as "changed" simply because the afternoon sun lit it differently than the morning baseline. Radiometric normalization rescales the new image so its intensity distribution is comparable to the reference, using either physics-based atmospheric correction (converting to surface reflectance) or relative normalization against invariant features – rooftops, paved surfaces, deep water – that should not have changed.

Alongside normalization, the pipeline masks nuisance classes that change naturally and carry no intelligence value. Cloud and cloud shadow are the obvious ones; a passing cloud will otherwise dominate the change mask. Dense vegetation moves with wind and grows between passes, open water has a constantly varying surface, and terrain shadow shifts with sun angle. Masking these classes before the change model runs – or weighting them down – keeps the model focused on the semantic change the analyst cares about. The principles here overlap heavily with the broader GEOINT platform architecture that hosts these products.

Change models: from pixel differencing to learned change

The simplest change detector is image differencing: subtract the reference from the new image and threshold the magnitude. It is fast and interpretable, and on well-registered, well-normalized imagery it works for high-contrast change. But it is brittle – it cannot distinguish a tarp laid over equipment from a genuine structural change, and it has no concept of what kind of change matters. Classical refinements include change vector analysis across spectral bands, principal component analysis of the stacked image pair, and the IR-MAD (iteratively reweighted multivariate alteration detection) transform, which is statistically robust to residual radiometric differences.

Modern operational systems use learned change models, most commonly a Siamese network: two weight-sharing encoders process the reference and new image into feature embeddings, and a decoder fuses the two feature streams into a per-pixel change-probability map. Convolutional Siamese architectures (such as the Siam-Diff and FC-Siam families) and, more recently, transformer-based change detectors capture context that pixel methods cannot – they learn that a new linear feature in a field is more likely a track than a shadow, and that a rectangular addition next to a building is construction. The output is a continuous change-confidence raster, not a hard binary mask, which preserves the information needed for the thresholding stage.

SAR and coherent change detection

Optical change detection is blind at night and under cloud. Synthetic aperture radar is not, and this makes SAR change detection an all-weather, day-night complement that is often the more operationally valuable mode. Beyond simple amplitude differencing, SAR enables coherent change detection (CCD): comparing the interferometric phase coherence between two complex SAR images of the same scene. Where the surface has been physically disturbed at the scale of the radar wavelength – vehicle tracks across soil, fresh digging, footpaths, recently moved equipment – coherence collapses, and these disturbances stand out vividly even when no amplitude change is visible to the eye. A common operational pattern fuses the two: a coherence loss in SAR cues a follow-on optical collection of the exact coordinates, so the all-weather sensor triggers the high-resolution one.

False-alarm control and analyst cueing

Having produced a change-confidence raster, the pipeline must convert it into a trustworthy cue list. This is a multi-stage filtering problem. First, a confidence threshold and morphological cleanup remove speckle and isolated pixels. Connected regions are then vectorized into change polygons, each annotated with area, footprint, confidence, and – if a classifier is present – a change class. A persistence requirement is one of the most effective false-alarm suppressors available: requiring a change to appear across two or more consecutive passes before it is promoted eliminates most single-pass artifacts (a transient cloud edge, a one-off registration glitch) while still surfacing genuine activity within an acceptable delay.

The surviving polygons are ranked – typically by a combination of confidence and area, with operator-defined priority zones boosting changes inside named areas of interest. Each cue is packaged with a before/after image chip so the analyst can adjudicate in seconds without opening the full scene. Critically, the analyst's verdict (real change, nuisance, already known) is captured and fed back as labeled training data. This closes the loop: the model that produced the cue learns from the analyst who judged it, and precision improves over the deployment's life. The same human-in-the-loop discipline underpins AI-assisted ISR data triage more broadly.

Key insight: The dominant failure mode of operational change detection is almost never an inadequate change model – it is upstream geometry. Misregistration of even one pixel along a high-contrast edge generates a change signal larger than the genuine change you are hunting for. Invest engineering effort in sub-pixel co-registration and radiometric normalization first; a mediocre change model on perfectly aligned imagery will outperform a state-of-the-art model on misaligned imagery every time.

Latency, revisit, and the move to the edge

How fast a change must be detected depends entirely on the target. Monitoring fixed strategic infrastructure tolerates revisit measured in days and processing latency measured in hours – the baseline barely moves, and a slow, careful product is acceptable. Monitoring activity is different. When the intelligence value is in vehicle build-up, equipment movement, or fresh excavation, the change is the warning, and a cue that arrives a day late is a cue that arrives after the decision window has closed. Tactical change detection therefore pushes toward hourly revisit and minutes-scale processing latency from downlink to cue.

That latency pressure is the main driver behind moving change detection toward the sensor edge. The classic architecture downlinks every full image to a ground processing center, which is bandwidth-hungry and slow. The emerging architecture runs co-registration and the change model on-board or at a forward node, so only the change polygons and small before/after chips – kilobytes, not gigabytes – traverse the constrained downlink. This is the same edge-inference philosophy applied across modern ISR, where the network is the bottleneck and the answer is to ship the decision, not the data.

Engineering the system end to end

A production change-detection system is a chain of components, each of which can sink the product if it underperforms: an orthorectification and co-registration front end, a radiometric normalization and masking stage, the change model itself (optical, SAR, or fused), a thresholding and vectorization back end, and a cueing and feedback layer wired into the GEOINT picture. The model is the part that attracts the most attention, but it is rarely the part that determines whether analysts trust the output. Geometry, normalization, and disciplined false-alarm control decide that. Build those well, keep a human in the adjudication loop, and the change-detection product becomes what it should be: a tip-and-cue engine that points scarce analytic attention at exactly the coordinates where the world changed.

For the on-device inference side of this problem – running detection and change models close to the sensor – see our companion piece on computer vision for defense systems.

Turn every pass into a change cue, not another image to scan

Corvus SENSE ingests satellite and aerial imagery, co-registers and normalizes it across passes, and surfaces ranked, geolocated change cues directly in your common operating picture – so analysts adjudicate what moved instead of scanning what did not.

Explore Corvus SENSE → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical GEOINT and ISR systems for defense and government organizations. Learn about our team →