SESSION 2 · 08/26 · WORKED
Three analysis methods, all wrong — and the reason was in the frame the whole time
Built a processing stack and tried to rank the night's runs by sharpness. Every metric disagreed with my eyes. The bug wasn't in the metrics — it was that the lunar disc runs off the edge of the sensor, which silently breaks anything geometric.
The processing stack
Siril 1.4.4 as the flatpak (org.siril.Siril) — flathub has 1.4.4 where apt is still
on 1.2.1, so take the flatpak. Two things to know before you waste an hour like I did:
- Its scripted
registeris star-based and useless for lunar. The help text says so outright: "only works with deep sky images." The lunar path is the GUI, registration method KOMBAT ("planetary surfaces or full disk"). - The flatpak gets a private
/tmp, so any script you hand it has to live under$HOME.
PlanetarySystemStacker is the better lunar tool — multi-point alignment beats Siril's
global-only registration. It pins numpy<1.23, which has no cp312 wheels, so it will not
install cleanly. Install a modern stack first, then pip install --no-deps. It runs fine
on numpy 2.5.2 and OpenCV 5. Also: Python 3.12 venvs no longer ship setuptools, which
breaks any source build that assumes it.
Three metrics, three wrong answers
I wanted to rank the night's runs automatically instead of squinting at them.
- Laplacian-variance sharpness ranked the noisiest run as the sharpest. Of course it did — noise is high-frequency content, and that's precisely what the metric rewards.
- A limb-width focus metric gave anywhere from 27 to 170 px within a single batch.
- Disc radius from area came out 9% low, with the computed centre 171 px off.
The actual cause
The Moon overflows the sensor. At this focal length the disc is 2188 px across on a 2160 px axis — it hangs off by 28 px.
That single fact silently breaks area-to-radius (the area isn't a circle's), centroid alignment (the centroid of a clipped disc isn't its centre), and radial profiles (they run off the edge). None of it errors. It all returns plausible numbers.
The fix is to fit a circle to limb points, excluding frame-border pixels. And the real lesson: always find an independent check the fit never saw. The limb fit only became trustworthy when it reproduced a number I already knew.
What I now actually know about this rig
- Image scale: 0.853"/px. From the limb fit — Moon at 1866.6" spanning 2188 px.
- Field: 46.4' x 30.7'.
- Drift: about 17 px/s, undriven alt-az.
- Dawes limit at 76 mm: 1.53", which is 2.8 km on the lunar surface. No amount of focus, stacking or deconvolution beats diffraction.
That last one is the useful one. 1.53" spans only 1.8 px at this scale, so I'm slightly under-sampled — a 2x Barlow would sample the limit properly. And the drift is not the problem I assumed: it doesn't degrade a stack, it only caps how long a run can be. Park at the leading edge, hands off, let the Moon drift through the frame.
Correction to the record
I'd been calling this a 114 mm f/4.4 at 500 mm focal length all through the first session. It isn't. It's a 76 mm f/4.6 at 350 mm. Every derived number from night one was wrong until this was fixed — which is its own lesson about writing down what you actually have.