Correct the saturated-nucleus claim and cancel the booking it justified #17

Merged
laurence merged 1 commit from correct-core-saturation into main 2026-07-21 14:51:06 +01:00
Owner

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:

Quantity Value
Galaxy peak, star-free 1944 ADU
Clip level ~63000-65535 ADU
Star-free pixels above 30000 ADU 0
Location of the frame's brightest pixel right-hand edge, 2370 px from centre

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

  • T32 reservation cancelled without running — 0 points spent. The other three reservations were verified intact afterwards; quota back to 6:05 of 8:00.
  • plans/hdrcore-t32.txt stays 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.
  • CAMPAIGN.md records the corrected habit: measure whether a core is saturated before buying time to fix it, filtering stars out of the measurement first. The check takes a minute and would have saved the whole detour.
  • TODO.md records a second result that affects future planning: the faint outer halo of that stack is limited by the sky-plane subtraction, which absorbed about 17.9 ADU/px of real halo light, rather than by exposure time. More integration alone would not have gone deeper — worth knowing before anyone books more time chasing Cen A's shells.

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.

## Correcting PR #16 [PR #16](https://git.discworld.casa/laurence/itelescope/pulls/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: | Quantity | Value | |---|---| | Galaxy peak, star-free | **1944 ADU** | | Clip level | ~63000-65535 ADU | | Star-free pixels above 30000 ADU | **0** | | Location of the frame's brightest pixel | right-hand edge, 2370 px from centre | 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 - T32 reservation **cancelled without running** — 0 points spent. The other three reservations were verified intact afterwards; quota back to 6:05 of 8:00. - `plans/hdrcore-t32.txt` **stays** 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. - CAMPAIGN.md records the corrected habit: **measure whether a core is saturated before buying time to fix it**, filtering stars out of the measurement first. The check takes a minute and would have saved the whole detour. - TODO.md records a second result that affects future planning: the faint outer halo of that stack is limited by the **sky-plane subtraction**, which absorbed about 17.9 ADU/px of real halo light, rather than by exposure time. More integration alone would not have gone deeper — worth knowing before anyone books more time chasing Cen A's shells. ## 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.
laurence added 1 commit 2026-07-21 14:50:59 +01:00
The previous commit asserted that the 21 Jul Centaurus A data came back
with a saturated nucleus, and booked a short-exposure core set on T32 to
fix it. The assertion was wrong.

It 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. The 65313 ADU
belonged to a foreground star 128 px (69 arcsec) from the nucleus, well
inside the box. Median filtering the inner 800 x 800 px to remove stars
leaves the galaxy peaking at 1944 ADU, roughly a thirtieth of the clip
level, with not one star-free pixel above 30000 ADU anywhere in that box.
The brightest pixel in the whole frame is at the right-hand edge, 2370 px
from centre.

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, with no new data.

The T32 reservation has been cancelled without running, so it cost
nothing. The other three reservations were verified intact afterwards
and quota is back to 6:05 of 8:00. plans/hdrcore-t32.txt stays in the
repo and on the scope: 47 Tuc and the SMC may genuinely saturate, a
dense cluster core being the fastest thing there is to clip, and the
ladder is ready if they do.

The corrected habit is recorded in CAMPAIGN.md: measure whether a core is
saturated before buying time to fix it, filtering stars out of the
measurement first. The check takes a minute and would have saved this
whole detour.

TODO.md also records a second result that affects future planning: the
faint outer halo of that stack is limited by the sky-plane subtraction,
which absorbed about 17.9 ADU/px of real halo light, rather than by
exposure time. More integration alone would not have gone deeper.
laurence merged commit de37a19ee6 into main 2026-07-21 14:51:06 +01:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: laurence/itelescope#17
No description provided.