Note 12 — ToA layer shipped; H hides track/plane; the projected-image ROTATION bug (Incident Viewer Taos Engine App)

**Note** from Bead: Incident Viewer Taos Engine App · [canonical source](https://redfish.acequia.io/guerin/.agents/cbf8b027-e80c-4b9f-8eb3-91d40af072d5/2026-06-11/notes/12-toa-layer-h-mode-and-rotation-bug.md) · session 2026-06-11 · discussion: Talk: Incident Viewer Taos Engine App

## Shipped (repo `e97d062`, deployed 2026-06-12) 1. **Fire-progression ToA layer** — catalog-driven from the incident's `progression` collection (Sandy live; Palisades pending — see decisions). Flamesim RGB decode (seconds-since-first-timestep; **black AND white = unburned sentinels**, span-clamped — the white-background trap cost one cycle), per-pixel arrival UTC, terrain-following grid drape, recolored against the **master clock** with the note-09 ramp (blue past ↔ red future, desaturate at present, ±12 h). Master span now includes time-extended layers → Sandy's timeline spans the full 5-day burn. This is the first realized instance of the globe heat-map direction. 2. **H/sensor-lock hides ALL aircraft track + plane geometry** (Stephen's directive; supersedes V-1's beyond-range exception — even distant tracks read as streaks across the sensor view).

## The projected-image ROTATION bug (Stephen's screenshots, 2026-06-12) Stephen: *"note in cases, the projected image is rotated — projected first image and unprojected second image."* The two screenshots show the world-projected footprint and the cap image with **inconsistent orientation** — in cases the projection is rotated relative to truth. **Hypothesis (strong):** `lookRotation(dir)` constrains only the look axis — **roll about that axis is whatever the chosen up-vector convention gives**, not the sensor's true roll. We aim the projector by `sensor → frame-center` direction alone and never compose the MISB attitude chain (platform heading/pitch/roll ⊕ gimbal azimuth/elevation/roll). When the aircraft banks or the gimbal rolls, the projected image rotates about the boresight by the difference. The cap shares the same `lookRotation`, so projected-vs-cap can disagree with the world differently. **Fix paths (next build):** - **Proper:** compose the full MISB rotation — platform `heading/pitch/roll` × gimbal `sensor_relative_azimuth/elevation/roll` (fields exist in the KLV; the long-name dialect carries them — verify presence per clip in the telemetry JSONs) → projector/cap rotation in ENU at the platform position. This is the geometrically true orientation. - **Pragmatic fallback** where attitude fields are missing: derive roll from the MISB **offset corner points** (`offset_corner_latitude_point_1..4`) when present — align the projected quad's top edge to the corner geometry. - Verification: project onto terrain and compare burned-in HUD north arrow / known ground features at multiple bank angles; the Jan-8 night clip (visible city grid) is a good test.

## Decisions still open - **Palisades ToA**: not in fireProgression `output2025` — progressionMaker run (Cody) vs. derive from our 6 perimeter KMLs (levelset). Awaiting Stephen.