**Note** from Bead: Georegister Image · [canonical source](https://redfish.acequia.io/guerin/.agents/58091f55-cb28-41b6-98a9-be56cdab5890/2026-06-17/notes/00-georegister-image.md) · session 2026-06-17 · discussion: Talk: Georegister Image
Stephen's framing (2026-06-17): georegistering an image (which becomes an **ortho-image**) is just a **different camera type — an orthophoto camera**. We won't only use GCPs; we may use **UVs from other posed images as constraints**. Reference the established georeferencing workflows (QGIS, Google Earth, ESRI). Shares a lot of UX/UI with **pose-ux-ui** (`edb06426`).
## The reframe: georegistration = solving a camera Georegistration assigns a mapping from image pixels `(u,v)` to world coordinates. Resampled onto a regular map grid that mapping yields an **ortho-image**. Instead of treating it as a bespoke "warp," treat it as **solving a camera** for the image — the same `(pose + intrinsics + distortion + time)` tuple as every other camera in the ecology (the nuke-geo-camera isomorphism, `a55f5270`): - **Perspective camera** = an oblique photo: full 6-DOF pose + perspective intrinsics. (pose-ux-ui's snapshot-view-as-pose / campanile UV↔geopoint end.) - **Orthophoto camera** = the degenerate **orthographic, nadir** case: the image *is* the ground plane. A KML `<GroundOverlay><LatLonBox>` (north-up + rotation) or `<gx:LatLonQuad>` (affine quad) is precisely an orthophoto-camera placement on a flat ground. So "georegister an image" and "pose an image" are the **same operation at two ends of one camera spectrum**; the orthophoto camera is the special case whose output is map-aligned (an ortho-image). ### Ortho-image proper needs a DEM A flat-ground affine/projective fit (KML ground overlay) is an *approximate* ortho. **True orthorectification** removes relief displacement by projecting through a **DEM** — the orthophoto camera + the terrain the rest of the stack already uses (AWS Terrarium / taos-engine). Flat-plane = quick; DEM-backed = correct over relief.
## Constraints: not just GCPs (this is the interesting part) Georegistration becomes a small **bundle-adjustment / factor graph** (feedback_every-constraint-is-soft; solver precedent = the LM bundle-adjust `camera-calibrator` in `74c30681` / nuke-geo-camera): 1. **GCPs** — image `(u,v)` ↔ known world `(lon,lat,elev)`. The classic control point. 2. **UV tie-points from other posed images** — a feature seen here at `(u,v)` and in another image (with a **known camera pose**) at `(u',v')`. The other camera back-projects `(u',v')` to a world ray/point that constrains THIS image's pose. = multi-view SfM with some cameras held fixed; tie this image into the existing posed-image graph instead of needing surveyed GCPs. 3. **KML prior** — a `LatLonBox`/`LatLonQuad` from the image's KMZ initializes the solve (soft prior), reweighted as GCPs/tie-points land. (See pose-ux-ui `edb06426/2026-06-17/notes/01`.) 4. (Future) DEM/ray-to-terrain, edge/coastline, sun-shadow, time — all soft constraints on the same graph. The output pose (orthophoto camera) + a resample step = the ortho-image; the pose record binds to the catalog as a STAC Item with a `view`/pose (catalog `90f902e0`).
## Prior-art workflows to reference (and what we take from each) - **QGIS Georeferencer** — load raster → drop GCPs (map px ↔ coord, or against a reference layer) → pick a **transformation** (Linear/Helmert/Polynomial 1–3/**Thin-Plate-Spline**/Projective) + resampling (nearest/bilinear/cubic) + target CRS → GeoTIFF. Per-GCP **residuals**. *Take:* the GCP table + residual feedback + the transform-family choice (projective = our flat orthophoto camera; TPS = rubber-sheet for uncalibrated locals). - **Google Earth — Image Overlay** — drag/scale/rotate a `GroundOverlay` to fit, or pull the corner handles. `<LatLonBox>` (north-up + rotation), `<gx:LatLonQuad>` (arbitrary quad). KML/KMZ is the interchange. *Take:* the **direct-manipulation** corner-drag UX (low-friction, no surveyed points) and the KML import/export as our orthophoto-camera serialization. - **ESRI / ArcGIS Pro Georeference** — control-point "links" → transformations (zero-order/affine/similarity/projective/polynomial/**spline**/adjust) → per-link **RMSE** → rectify to a new raster; plus auto "georeference to imagery." *Take:* the transformation taxonomy + RMSE-per-link bookkeeping + the "register against existing imagery" idea (= our UV-tie-point-against-posed-images).
## Shared UX/UI with pose-ux-ui (`edb06426`) — link, don't fork - The **UV↔geopoint constraint editor** (click pixel, click world point, repeat, solve) is the GCP editor *and* the tie-point editor — one interaction, different right-hand side (a world point vs another image's pixel). - The **solver** (LM bundle-adjust, soft weighted constraints + soft prior) is shared with the calibrator. - The **2D direct-manipulation** (drag/scale/rotate on a map) is the santafe.live placement surface = the orthophoto-camera quick path. - The **layer-tree / interaction grammar** (visibility, opacity, fly-to `h`, time-span `t`, touch parity) comes from geospatial-ux-ui (`f80f1929`).
## Open questions 1. Flat-plane vs DEM-backed ortho as the default output — and when to auto-escalate to DEM. 2. Tie-point matching: manual only first, or assisted (feature matching) against the posed-image graph? 3. Camera model for the orthophoto type — pure orthographic, or a "frustum-at-infinity" so the perspective and ortho cameras share one code path? 4. Output product: a STAC `raster` Item with a worldfile/GeoTIFF + the orthophoto-camera pose record — same shape as the TOA/IRHS drape layers in the viewer?