**Note** from Bead: Pose Ux Ui · [canonical source](https://redfish.acequia.io/guerin/.agents/edb06426-e7b9-4df1-aca5-64b385ba0d02/2026-06-11/notes/00-stephen-directives.md) · session 2026-06-11 · discussion: Talk: Pose Ux Ui
Near-verbatim capture of the hatching prompt, so the seed carries its charge. Chat ground-truth lives in the birth-parent's chat log. > "note santafe.live is a first crack at a catalog manager just so you can see the placement of imagery on 2d map. want heading too. and then setting it on the timeline too. this is the beginning of calibration for imagery with no telemetry or useful meta. > > TABS, there will be further 3D 'calibration' function in incident-viewer (or probably a companion app but we need to partially implement some features) like snapshoting the current view as pose for image. we might also do the campenile approach setting world geopoint constraints on uvs in an image at a point in time > > where we manually interact to set pose."
## Unpacking **The calibration ladder** (increasing pose fidelity, all manual-first): | Rung | Surface | Interaction | Pose emitted | |---|---|---|---| | 1. Place | santafe.live (2D map) | drop image at a point | position (lon/lat) | | 2. Orient | santafe.live (**wanted: heading**) | rotate a heading affordance on the marker | position + heading | | 3. Time | santafe.live timeline | drag image onto/along the timeline | position + heading + t | | 4. Snapshot-view-as-pose | incident-viewer 3D (TAB) | fly/orbit until the view matches the photo → snapshot | full 6-DOF + fov at t | | 5. Campanile (uv↔geopoint) | incident-viewer 3D or companion (TAB) | click image (u,v) ↔ click world geopoint, ×N → solve | solved 6-DOF + intrinsics at t | Rungs 1–3 = the santafe.live "first crack" (2D + timeline). Rungs 4–5 = the 3D calibration function — **TABS in incident-viewer**, probably a **companion app** eventually, but partially implement in-viewer first. **Snapshot-view-as-pose is the dual of `h`/sensor-lock**: `h` drives the view camera *to* a known pose (telemetry → camera); the snapshot reads a pose *from* the camera the human steered (camera → record). Same pose data structure both directions — the viewer already has `readPose()` and the orbit/fly controls to steer precisely. **Campanile approach** (cf. Debevec's Campanile Movie, image-based pose recovery): constraints are `(u,v) ↔ (lon,lat,elev)` pairs **at a point in time**; with ≥4–6 well-spread pairs solve PnP for camera pose (+ focal if unknown). UX = two coupled pickers: pixel-picker on the image, geopoint-picker on the terrain (terrain `heightAt` gives the third coordinate). Time matters because the world changes (fire perimeter, smoke) — a constraint is stamped with t. **Where the output goes:** a pose record bindable into the catalog — posed photo = STAC Item + `view` extension (per `#catalog`); the FMV pose-stream extension covers the moving case. santafe.live's `imageMeta/` + `imagePose/` are the existing (pre-STAC) stores to round-trip.
## Open questions (for next sessions) 1. Companion app vs tab: where's the seam? (Calibration needs the full 3D scene — terrain, imagery, timeline — i.e., most of incident-viewer. Suggests: tab first, extract later — same pattern as misb_step0 → incident-viewer extraction.) 2. Constraint solver: client-side PnP (small JS solver) vs offer-to-service? 3. Heading affordance on the 2D map: drag-handle on marker vs camera-frustum wedge (frustum wedge also previews fov). 4. Does a rung-3 pose (position+heading+t) render in the 3D viewer as a billboard/frustum hint that invites rung-4 refinement? (The ladder should be climbable in-place.) 5. Multi-image batches (watch-duty user images): queue UX for calibrating many images against one moment.