Systems / IMAGING · SYNTHETIC APERTURE RADAR · 2026
Forming SAR images on a consumer GPU
A synthetic aperture radar pipeline that forms images from Sentinel-1 and Umbra phase-history data, plus a viewer for on-demand Earth observation that was designed around the real bottleneck: bandwidth.
- 3.15 s
- GPU image formation versus about 59 minutes on CPU, same scene2026-09-10
- 0–1 px
- registration to the vendor's own image product across 4 km2026-09-10
- 1.6714 m
- ground-range resolution, identical to the vendor's published figure2026-09-10
- 0.34 m
- offset of the cross-correlation peak against the vendor product on a second, larger scene2026-09-25
- 432 → 746
- tests, from the imaging pipeline to the full viewer2026-09-24
- 20×
- how wrong my first bandwidth estimate was, in the pessimistic direction; measured and corrected the same day2026-09-09
I wanted to know whether a gaming GPU could form a radar image from raw phase history. It can: 3.15 seconds against 59 minutes on CPU, registered to the vendor's own product within a pixel. My first bandwidth estimate for the viewer was wrong by twenty times, and the design document says so first.
The problem
Earth-observation imagery is expensive to move and slow to form. I wanted to know whether a consumer GPU could form a synthetic aperture radar image from raw phase history, how close it would come to what the vendor ships, and what a viewer that fetched imagery on demand would cost in time.
What I built
A reader for the CPHD phase-history format, a range-compression stage, and back-projection image formation on the GPU. On the first Umbra scene it registered to the vendor's product within a pixel across four kilometers and matched the published 1.6714 m ground-range resolution; 3.15 seconds on the GPU against roughly 59 minutes on CPU. A second, larger scene over the Panama Canal ran the full chain (download, pulse read, range compression, back-projection) in 18.4 minutes on a GPU shared with a weather training run; the write-up reconciles the two by contention, not algorithm.
The viewer around it, built in a day from the laptop: an API, 13 data providers, 25 processing recipes, a worker, notifications, and a web shell, with 746 tests. Not deployed yet.
How it’s checked
Against the vendor. Cross-correlation offset, Pearson correlation (0.81) against their product, and measured resolution on isolated scatterers against the computed limit (azimuth ratio 1.01–1.16). Where range resolution came in wider than the theoretical limit, the number is reported as measured.
The design assumption that got tested hardest was bandwidth. My first note said a baked scene cost 20–30 minutes of wall clock, two-thirds of it moving bytes. I didn't believe it. The measurement, done the same day: 3–4 minutes, single-stream 3.05 MB/s, eight streams 4.71 MB/s. The first estimate was wrong by about twenty times on one assumption, and the verdict document says so before it says anything else.
What happened
The SAR pipeline is the basis of the satellite viewer the space officers asked for. The viewer is waiting on a deployment window.
Links and credits
Built withPython, CUDA via PyTorch, Sentinel-1 via ASF, Umbra open data. Written with five parallel Claude Code agents, directed by me.