Correct the saturated-nucleus claim and cancel the booking it justified #17
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "correct-core-saturation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Correcting PR #16
PR #16 claimed the 21 July Centaurus A data came back with a saturated nucleus, and booked a short-exposure core set on T32 to fix it. The claim was wrong. This corrects the record and cancels the booking, which never ran and cost nothing.
What went wrong
The 65313 ADU figure came from taking the maximum pixel inside a 300 x 300 px box centred on the frame. That measures the brightest thing near the middle of the image, which is not the same as measuring the galaxy — and what it found was a foreground star 128 px (69 arcsec) from the nucleus, sitting comfortably inside the box.
Measured properly, by median-filtering the inner 800 x 800 px to remove stars:
The core looked blown in the processed image because of the stretch, not the sensor. The white point sat at the 99.995th percentile — a level set by field stars — so the galaxy's entire range, from a 7 ADU sky to a 1944 ADU peak, was compressed into the top few percent of the tone curve. Re-rendering the same frames with a second curve scaled to the galaxy recovered the core completely, from existing data.
The error was caught by an independent surface-photometry analysis of the same stack, which reached the same conclusion for the same reason, and was then confirmed directly.
What changed
plans/hdrcore-t32.txtstays in the repo and on the scope. 47 Tuc and the SMC (queue #5) may genuinely saturate — a dense cluster core is the fastest thing there is to clip — and the ladder is ready if they do.Tools used
Python (astropy, scipy) to re-measure the saturation properly; PowerShell against the WebForms reservation grid to cancel, with the target row asserted by plan name in the same response the tokens came from, since the grid's delete buttons are addressed by position rather than by reservation id and the CrA run sat one row below.