Plate-solve the full sensor, with a cached optical calibration

[mrosseel]

Two changes to the solver, both aimed at the same thing: stop throwing away sky, and stop rediscovering the optics on every frame.

1. Solve the full sensor

The camera cropped every exposure to a centred square before solving — on the imx462, 1920×1080 down to 980×980, so roughly half the sensor area was discarded. Cedar Solve has no trouble with the whole frame, so that area is free plate-solving sensitivity.

The camera now publishes two frames per exposure:

	Size	Consumed by
display frame	512×512 square crop, unchanged	UI, focus, preview, align, SQM photometry
solve frame	whole sensor, native scale	the plate solver only

Bayer sensors bin 2×2 for the solve frame, which removes the RGGB modulation the old downscale to 512×512 was implicitly smoothing away.

Everything downstream of the solver is written against the display frame — SQM in particular scales matched centroids onto the raw photometry image and derotates them, a chain that only works starting from display-frame pixels. So a full-frame solve is projected back onto the display frame in one place (project_solution_to_display), and the projected copy is what the rest of the system sees. Matched stars outside the crop are dropped along with their catalogue counterparts: they contributed to the solve, which is the point, but they have no pixels in the crop to measure. SolveGeometry owns the mapping, composed from the affine transform of each pipeline stage.

Gated by solver_full_frame (default on), and disabled automatically when the camera has no sensor profile or the frame rotation is not a quarter turn — rotating a non-square frame by an arbitrary angle would clip exactly the corners this exists to recover.

2. Cache the optical calibration

The solver passed a fixed fov_estimate=12.0, fov_max_error=4.0 and never passed a distortion estimate at all, so Cedar re-derived both on every frame from scratch.

The first successful solve of a run now captures the measured FOV and lens distortion; later solves get a ±0.5° window and that distortion as a starting point. This speeds up pattern matching and improves centroid matching toward the frame corners — the part of the image the crop used to discard, and the part where lens distortion actually bites. A run of consecutive failures discards the calibration and reopens the window. Session-scoped; nothing is persisted.

What the field of view actually does

Worth stating, because it is counterintuitive: after the camera's quarter turn the solve frame's horizontal axis is the sensor's short side, which the square crop already spanned. So horizontal FOV grows only modestly (imx462 ~10.2° → ~11.2°) or not at all (imx296, HQ). Total area still roughly doubles — the extra sky arrives vertically. The FOV search window is therefore derived per camera from the known crop field rather than hard-coded.

Cost

Benchmarked over 220 archived sweep frames (imx462 and HQ), exposures 25 ms – 1.1 s, on an x86 dev box:

	pixels	extract	solve	total
512×512 crop (today)	0.26 Mpx	1.04 ms	6.5 ms	7.6 ms
full-sensor pixel count	0.52 Mpx	1.02 ms	4.9 ms	5.9 ms

2.0× the pixels cost −0.02 ms; 2.9× (HQ) cost −0.28 ms — nothing, within noise. Total extract+solve is 0.6–8% of one exposure cycle depending on exposure, so the CPU budget is not the constraint here.

Caveat on that benchmark: the sweep archive stores cropped raw, so the full-sensor arm is the real crop padded with its own background noise to the right pixel count. It measures the pixel cost honestly and the sensitivity benefit not at all — that needs a device run.

Testing

ruff clean, mypy clean on changed files, 1052 unit+smoke tests pass.

• Unit tests drive a marker through both real pipelines for all four sensor profiles × both rotations, checking the affine mapping against what the code actually produces
• Integration tests run a real Cedar solve of a test frame embedded in a larger canvas: RA/Dec/Roll match the crop solve, projected centroids land on the same stars (median 0.11 px), FOV projection round-trips
• Ran headless with the debug camera: solves normally, SQM unaffected

Not yet run on hardware — the debug camera has no sensor profile, so that exercises the wiring but not the full-frame path itself.