Make egain per-body rather than a hardcoded class constant

[wtgee]

src/panoptes/pocs/camera/gphoto/canon.py returns a hardcoded gain as a class
property:

@property
def egain(self):
    """Estimated sensor gain (e-/ADU)."""
    return 1.5 * (u.electron / u.adu)

with bit_depth likewise fixed at 12 bits. That value is stamped into EGAIN
in every frame from every Canon body in the fleet.

Why a fleet-wide gain is load-bearing, not cosmetic

Gain sets the photon noise floor. For the transit survey, the ratio of achieved
scatter to that floor is the number that decides whether the precision target is
reachable at all, or whether it is a per-camera limit that no algorithm work can
move. A gain that is the same constant for every body makes that judgment
meaningless — and it is currently the same constant for every body, by
construction rather than by measurement.

panoptes-pipeline has carried effective_gain: float = 1.5 in its own
settings for the same reason. That is not an independent value; it is a copy of
this one. Fixing it downstream would give one consumer the right number and
leave every other consumer, and every frame already taken, with the wrong one.

Proposed

Measure gain per body by photon transfer — variance against mean across frame
pairs — and have the camera report its own measured value rather than a class
constant. Ten years of multi-frame sequences make the measurement straightforward
per camera and ISO; the measurement work is tracked at
panoptes/panoptes-pipeline#99.

Read noise and black level have the same argument and are in the same position:
absent from the header, and currently recoverable only by each consumer
separately.

Related

• Investigate ideal gain settings for ZWO #1396 — gain settings for ZWO. Different camera family, same
  question: the fleet is no longer one sensor.
• Treat the FITS header vocabulary as a declared contract #1479 — the header vocabulary this belongs to.
• plans/data-contract.md
  section 6.3.

---

_{Filed by Claude Opus 5 · effort: high · 🤖 Claude Code}