Key takeaways
- Satellite image streams are not camera feeds — revisit intervals, resolution variation, atmospheric interference, and orbital geometry mean that object detection models trained on ground-level imagery fail systematically when applied to overhead data without domain adaptation.
- Change detection is the primary analytical output in most remote sensing workflows — detecting that an object is present is less useful than detecting that it was not present in the previous pass, and the detection pipeline must be designed for temporal comparison from the start.
- Structured data output — not annotated imagery — is what downstream analysis systems require. A detection pipeline that produces bounding-box overlays on image files has not solved the integration problem; one that produces machine-readable object records with geospatial coordinates, classification confidence, and change flags has.
- Throughput at orbital scale means processing thousands of image tiles per revisit cycle without manual triage. The pipeline must handle the full ingestion-to-output loop autonomously, with human review reserved for flagged edge cases and confidence thresholds, not routine processing.
The challenge: making sense of continuous overhead imagery at scale
A constellation of earth observation satellites produces imagery on a schedule that human analysts cannot keep pace with. Each revisit pass over a monitored area generates hundreds of image tiles. Across a full constellation and a wide area of interest, the volume of incoming imagery far exceeds any realistic capacity for manual review. The question is not whether automated processing is needed — it is whether the automated processing can be made reliable enough to trust at the classification and change-detection thresholds the downstream use cases require.
The client in this engagement operated an earth observation platform serving infrastructure monitoring, land use analysis, and logistics intelligence use cases. Their existing workflow used a combination of manual analyst review and rudimentary threshold-based change detection that triggered human inspection when pixel-level difference exceeded a set value. The approach was generating too many false positives from atmospheric variation and too many missed detections from objects that changed state without significant pixel-level change — a vehicle repositioned within a compound, a structure partially obscured by cloud in one pass and clear in the next. The requirement was a detection pipeline that could process the full incoming image stream, produce per-object structured records, flag genuine changes, and do so without manual review in the loop for routine passes.
"A pipeline that produces annotated images has not solved the problem. The downstream systems need object records, coordinates, classifications, and change flags — not pictures with boxes drawn on them."
The deployment context
The image stream in this engagement comprised multispectral imagery at 0.5 to 1.5 metre ground sample distance, delivered as tiled GeoTIFF files with associated metadata covering capture timestamp, satellite position, sun elevation angle, and cloud cover percentage. Revisit frequency over the primary areas of interest ranged from six to eighteen hours depending on constellation geometry and tasking priority. The object classes of interest spanned vehicles by type, fixed structures by category, maritime vessels, and infrastructure elements including storage tanks, antenna arrays, and landing pads.
The pipeline was required to produce a structured object record for each detected object on every pass, link each record to the object's detection history across previous passes, flag any object whose classification, position, or presence status had changed since the last valid observation, and deliver all outputs to the client's downstream analysis database within thirty minutes of image ingestion — without human intervention in the processing loop for passes with overall cloud cover below a defined threshold.
The domain adaptation problem: why ground-level models fail overhead
Object detection models trained on ground-level imagery — even large, well-generalised ones — exhibit systematic failure modes when applied to overhead satellite imagery without domain adaptation. The failures are not random; they are predictable from the differences between the two domains. Ground-level imagery shows objects from near-horizontal viewing angles, with consistent scale relative to camera distance, under lighting conditions that produce familiar shadow patterns and texture gradients. Satellite imagery shows the same objects from directly or near-directly above, at resolutions that vary with altitude and sensor, under sun angles that shift with latitude and time of day, and with atmospheric interference that varies pass to pass.
A vehicle seen from the side is recognisable to any ground-level model. The same vehicle seen from 500 kilometres above, as a roughly rectangular patch of pixels approximately 2 metres wide at 0.5 metre GSD, with a shadow offset by the sun angle, requires features that ground-level training data does not supply. The Botron detection model for this engagement was trained on a curated dataset of overhead imagery spanning the object classes of interest, augmented with synthetic data generated to cover the range of sun angles, resolutions, and atmospheric conditions present in the operational image stream. Domain-specific augmentation — simulating cloud thin-cover, varying GSD within the operational range, and applying orbital geometry-appropriate shadow transforms — was applied throughout training rather than as a post-hoc correction.
Why GSD variation is not a detail
Ground sample distance — the ground area represented by a single pixel — varies across a satellite's operational envelope as orbital altitude and sensor configuration change. A model trained exclusively at 0.5 metre GSD and deployed against 1.5 metre GSD imagery will see objects at one-ninth the pixel area it trained on. Without explicit GSD-range training, detection recall drops sharply at coarser resolutions — precisely the resolutions that dominate higher-latitude passes and off-nadir imaging. The model in this engagement was trained and validated across the full 0.5 to 1.5 metre GSD range of the client's constellation.
Change detection: comparing across passes, not pixels
Pixel-level change detection — comparing raw pixel values between two passes to identify regions that changed — is sensitive to everything that changes between passes: illumination angle, atmospheric haze, sensor calibration drift, and seasonal vegetation state, in addition to the ground-truth changes of interest. The result is a high false positive rate that makes the output unreliable for any use case where analyst time is constrained. The alternative is object-level change detection: running detection on both passes independently, producing object records for each, and comparing the records rather than the pixels.
Object-level change detection flags changes that matter — a vehicle present in pass N and absent in pass N+1, a structure whose classification changed from incomplete to complete, a vessel that moved between two observed positions — without flagging changes that do not: a slight shift in shadow angle, a thin cloud layer that reduced apparent contrast, a calibration difference between two satellites in the same constellation. The Botron pipeline implements object-level change detection through a persistent object registry that maintains a detection history for each tracked object across passes, associates new detections to existing registry entries using geospatial proximity and classification consistency, and generates change flags only when the object record attributes — presence, classification, position beyond a defined displacement threshold, or associated metadata — diverge from the previous valid observation.
| Detection approach | How it works | Where it performs well | Where it falls short |
|---|---|---|---|
| Pixel-level change detection | Compares raw pixel values between two co-registered image passes. Flags regions exceeding a difference threshold. | Large, high-contrast ground changes such as construction clearing or flood extent mapping. | High false positive rate from illumination, atmospheric, and sensor variation between passes. Cannot classify the nature of the change. |
| Object-level change detection | Runs detection on each pass independently, produces object records, and compares records across passes for presence, classification, and position changes. | Operational monitoring where false positives consume analyst time. Classification-aware change flagging across revisit cycles. | Requires a reliable per-pass detection pipeline as input. Change flags are only as reliable as the underlying detections. |
| Temporal model fusion | Multi-pass imagery is ingested jointly by a model that attends to both the current and previous pass simultaneously. | Subtle changes that are below single-pass detection confidence but consistent across passes. | Requires precisely co-registered multi-pass inputs. Higher compute requirement. Less interpretable change attribution. |
The object registry approach also handles the case of a missed detection in a single pass — a common occurrence when an object falls in a cloud-obscured tile or at the edge of a low-confidence detection region. Rather than generating a spurious absence flag, the pipeline maintains the object's last valid observation in the registry and marks the current pass as unobserved for that object, distinguishing an unobserved state from a confirmed absence. A confirmed absence flag is only generated after a configurable number of consecutive unobserved passes, a threshold set per object class based on the revisit frequency and the operational significance of absence for that class.
Structured output: what downstream systems actually need
The output of an object detection pipeline for remote sensing is often described as annotated imagery — the input image with bounding boxes and classification labels overlaid. For analyst visualisation, this is useful. For downstream analysis systems — databases, alerting platforms, intelligence workflows, logistics tracking tools — it is not the right output format. These systems need machine-readable object records: a unique object identifier, geospatial coordinates in a standard reference system, classification label and confidence score, bounding polygon in ground coordinates, pass timestamp, change flag and change type if applicable, and a link to the detection history.
The Botron pipeline produces output in this form: a structured JSON record per detected object, with geospatial coordinates derived by applying the image's rational polynomial coefficients to the pixel-space detection bounding box and projecting to WGS84. Each record is validated against a defined schema before delivery to the downstream database, and records that fail validation — typically from detections at image edges with incomplete RPC coverage — are flagged for review rather than silently discarded or delivered with incorrect coordinates. The pipeline also produces a per-pass summary record covering ingestion timestamp, image tile count, cloud cover percentage, detection count by class, change flag count by type, and processing latency, which provides the operational monitoring layer with the information needed to assess pass quality without inspecting individual object records.
Geospatial coordinate accuracy is a pipeline requirement, not a post-processing step
Object detection in pixel space identifies where an object is in the image. Geospatial projection — converting pixel coordinates to ground coordinates using the image's sensor model — determines where it is on Earth. Errors in this step propagate directly into the object registry: an object detected at 10 metre geospatial error in one pass may not associate correctly to its registry entry, generating a false new detection and a false absence flag for the original entry. RPC-based projection accuracy was validated against ground control points for each satellite in the client's constellation as part of the pipeline integration, not assumed from the imagery provider's stated accuracy specification.
Processing throughput at orbital scale
The volume of imagery produced by a multi-satellite constellation over a wide area of interest is not a workload that can be processed sequentially on a single compute node within an operationally useful latency window. The ingestion-to-output pipeline for this engagement was designed as a distributed processing architecture: incoming image tiles are queued on ingestion, inference workers pull tiles from the queue and run detection in parallel, and the object record assembly and registry update steps are serialised only at the object level to prevent concurrent write conflicts on the same registry entry.
Model inference is the dominant compute step. The detection model was quantised to INT8 precision for deployment on the inference worker fleet, with per-layer sensitivity analysis applied to preserve detection quality in the layers most sensitive to quantisation error. Tile batch size was tuned to the inference worker hardware to maximise GPU utilisation without exceeding the memory envelope available on the deployment instances. End-to-end latency — from first tile ingested for a pass to last structured object record delivered to the downstream database — was measured at a median of 17.4 minutes across the full operational test period, within the 30-minute requirement.
"The throughput requirement is not a performance optimisation — it is an operational constraint. Intelligence derived from imagery that is two hours old is a different product from intelligence derived from imagery that is eighteen minutes old."
Results in operational deployment
The pipeline was validated against a held-out test set comprising 94 passes over the primary areas of interest, spanning the full range of sun angles, cloud cover levels below the operational threshold, and GSD values present in the client's constellation. Mean average precision across all object classes at the operational confidence threshold measured 94.7%, with per-class precision ranging from 91.2% for partially occluded maritime vessels to 97.4% for fixed structure classification. False positive change alerts — flags generated by the pipeline that did not correspond to a genuine ground-truth change — were reduced by 91% relative to the prior pixel-level threshold system across the same test imagery.
Track continuity across the object registry — the rate at which a given object maintained a consistent registry identity across all passes in which it was detectable — measured 98.6% across the test set, with the remaining 1.4% comprising objects that fell at tile boundaries in specific passes and were re-associated on the following pass. No object present in the test set's ground truth annotation was permanently lost from the registry across the full test period. The pipeline has been in operational deployment since February 2025, processing full constellation passes autonomously with human review limited to the confidence-threshold review queue and the per-pass summary monitoring layer.
What this demonstrates
Satellite remote sensing at operational scale requires a detection pipeline that is designed for the domain from the start — trained on overhead imagery, validated across the GSD and illumination range of the operational constellation, and built to produce the structured outputs that downstream systems consume rather than the annotated imagery that human analysts review. The change detection and object registry architecture described here is what makes the output actionable: not a list of detections per pass, but a persistent, history-linked object model of the monitored environment that surfaces genuine changes and suppresses the noise that makes pixel-level approaches unreliable.
The detection and registry architecture described here is part of Botron Dynamics' broader object detection and autonomous perception work, applied here to the specific constraints of the satellite remote sensing domain — orbital geometry, multispectral imagery, GSD variation, and the throughput requirements of continuous constellation operations. The same architectural principles — domain-specific training, object-level temporal comparison, structured output with validated geospatial coordinates, and distributed inference at scale — transfer to any earth observation use case where the output of imagery analysis must be trusted without a human in the processing loop.