Exposure Recommendation¶

When the Star Detection Optimizer's search lands Brightness Sensitivity at the bottom of its range, the wizard's Summary page shows a Star signal block above the recommended step size. A gate that low means the detector accepted almost anything above the noise to find stars at all: the frames are signal-starved, and the focus curve fitted from them rests on low-confidence detections. The block responds with a longer exposure rather than a lower gate, and derives the number from the same accepted-star measurements the run already made.

The logic lives in ExposureRecommender.cs; its Summary copy lives in StarSignalCopy.cs.

When it appears¶

The block shows up purely from the landed gate value: Brightness Sensitivity at or below 1.0 for the run you are viewing, the same value the Summary page's Changed parameters table below it prints. It does not look at star counts to decide whether to appear.

The threshold is 1.0. Sensitivity's search axis spans [0, 50] with an initial step of 1.0, and the pattern search that lands it near the floor refines that step by repeated halving down to one eighth of it, so a genuinely floored search typically settles at 0.125, 0.25, or 0.5, well short of bit-exact 0; testing for exactly 0 would miss most real cases. 1.0 is one full search step off the floor, and also exactly a tenth of the default gate this recommendation targets. 2.0 was considered and rejected: a legitimately hand-tuned gate of 2 on a rich, well-exposed field is plausible on its own and should not trigger an exposure nag.

See Brightness Sensitivity for what the gate measures and why smaller values admit fainter stars.

How the recommended exposure is derived¶

The recommender reduces every frame to one number: the N-th brightest surviving star's sensitivity-gate SNR. N is the same star-count target the objective's own median-count score uses (\(N_{\text{target}}\), 20 by default; 60 when the run optimized for aberration inspection). Frames from the far-from-focus recovery wing are skipped; they are deliberately sparse and do not represent ordinary gate strength. A frame with fewer than N surviving stars falls back to its faintest survivor: a bounded under-estimate, since the true N-th-brightest star, had the frame had that many, could only have been brighter. That frame is counted separately as a short frame.

\(S_{\text{now}}\) is the median of that per-frame number across the run's usable frames. The recommended exposure then follows a sky-limited scaling law:

\[ t_{\text{new}} = t_{\text{old}} \left(\frac{10}{S_{\text{now}}}\right)^{2} \]

where 10 is the shipped default Brightness Sensitivity gate: the faintest star that default, out-of-the-box gate would still admit.

That law answers the signal question and nothing else. When the signal already meets the target but every usable frame is short of stars, the ratio is at or below 1 and the formula would argue for a shorter exposure, so the block sets the law aside; what it offers instead depends on whether the gate rejected anything. See When the field is short of stars, not signal.

Below MinFramesForRecommendation = 3 usable frames, with no per-star SNR data recorded, or with a non-positive current exposure to scale from, there is not enough to trust a derived number: the block still names the floored gate, but the recommended-exposure row and its number are hidden. Older saved runs that recorded no exposure at all fall back to your profile's auto-focus exposure for this calculation, and the block says so when that happens.

Why the N-th brightest star, not the median star¶

Asking the median accepted star to clear the gate over-recommends: on a rich 200-star frame that would demand 100 stars clear the default gate, far more than the objective actually needs to build a good curve. The N-th-brightest star asks the real question this recommendation exists to answer: what exposure would put \(N_{\text{target}}\) stars per frame above a healthy gate. That is also why the statistic is pinned to the objective's own star-count knee, not a literal number baked into the recommender: retuning the objective's target moves this recommendation with it, so the two stay in sync.

The √t assumption¶

The scaling law assumes SNR grows with the square root of exposure time. That holds when sky background dominates the noise: background-limited noise \(\sigma\) grows as \(\sqrt{t}\), so SNR (signal over \(\sigma\)) grows the same way, and reaching an SNR ratio \(r\) costs a time factor of \(r^{2}\).

That is the right assumption for these frames. An autofocus sweep is deliberately defocused, so a star's flux is spread thin across many pixels, and sky background dominates the noise even for a fairly bright star. It is also the conservative branch: for \(r > 1\), \(r^{2}\) always asks for more exposure than a plain \(r\) would. A read-noise-limited setup, where background noise is negligible next to a fixed per-pixel read floor, needs less exposure than the figure this block shows: SNR there scales closer to \(t\) itself than to \(\sqrt{t}\).

The two caps¶

Two independent limits bound how far a single recommendation can push the exposure:

At most 4× the current exposure in one step. Under \(\text{SNR} \propto \sqrt{t}\), a 4× time factor is exactly a 2× SNR jump, the largest single-step change this recommendation trusts. A signal-starved run is usually starved by more than that, so the cap leaves the number short and lets a second optimizer pass, now working from frames with real signal, refine the answer further.
An absolute ceiling of 30 seconds per frame. The wizard's default sweep already samples 9 points (±4 offset steps); at 30 s each that is 4.5 minutes of pure integration before counting focuser moves and frame downloads, and a live run's recovery wing widens the sweep further still. Past that, a sweep stops behaving like an autofocus run and risks hitting NINA's own autofocus timeout, the opposite of what this recommendation is for.

Whichever cap binds, the figure is rounded up to a practical exposure-time ladder — 0.5 s steps below 10 s, 1 s steps from 10 s to 30 s — and only when the capped value actually exceeds the current exposure; an unchanged value is never rounded. (The ladder also has a coarser 5 s step above 30 s, but a recommendation's capped value never exceeds 30 s, so this block never actually shows you that tier.)

That rounding step always rounds up, so when the run-relative 4× cap is what bound the number, the figure you see can land up to one ladder step past it — for example, a 2.2 s current exposure caps its raw factor at 8.8 s (2.2 s × 4), which rounds up to the 9.0 s a run like that would actually show. The absolute 30 s ceiling does not have this overshoot: every ladder step at or below 30 s divides 30 s evenly, so a value capped at 30 s always rounds to exactly 30 s, never past it.

Example

A 3 s run measuring S/N 4.1 computes a raw (10 / 4.1)² factor of about 5.9, or roughly 17.8 s. The run-relative cap (3 s × 4 = 12 s) binds before the absolute one and rounds up to the row:

Recommended exposure   3 s → 12 s (measured star S/N 4.1; target 10)

Its tooltip carries the arithmetic: "Sky-limited scaling: 3 s × (10 / 4.1)² = 18 s per frame, roughly 3 minutes per auto-focus run. Capped at 12 s: one run raises exposure at most 4x. Run again to refine."

What it never does¶

The recommender never proposes a shorter exposure than the one the run already used. When the measured signal already meets the target (\(S_{\text{now}} \ge 10\)) and at least one frame found a full \(N_{\text{target}}\) stars, the block says so: "Your brightest stars measure S/N 22.4, meeting the default S/N target of 10, so the floor is not for lack of bright stars. Brightness Sensitivity is low, so far fainter candidates are being admitted below them." If some, but not all, frames came up short of the star-count target it adds the count: "3 of 9 frames found fewer stars than the star-count target; Brightness Sensitivity is low to scrape for count in a star-poor field."

The instruction it ends on is about the gate, not the exposure: "Review the frames: if they show plenty of stars, the optimizer chose the floor on its own, not because stars were missing. Set Brightness Sensitivity by hand in the star detection options and run this wizard again in 'use current settings' mode to compare that landing against this one."

When the field is short of stars, not signal¶

When \(S_{\text{now}}\) meets the target but every usable frame found fewer than \(N_{\text{target}}\) stars, the run is short of stars rather than short of signal, and the sky-limited law has nothing to derive from. The block splits that case on one further measurement: did the Brightness Sensitivity gate reject any candidate?

If the gate rejected candidates, or if it is provably inert, more signal might still convert something. The gate is inert when its threshold sits at or below Star Peak Response times the effective Star Clipping Multiplier, because the clipping stage guarantees every candidate that reaches the gate already measures above that, so a count of zero rejections there is empty by construction rather than evidence. The block then offers a fixed 2× probe with its own stopping rule instead of a derived number: "All 9 frames found fewer stars than the star-count target: the stars found are bright enough (S/N 14.2), there are just too few. A longer exposure may or may not find more; try doubling it, and if the star count does not rise, the field is the limit and no exposure will fix it." The row's tooltip says the same about the arithmetic, that there is no S/N shortfall to derive from, and it names the 30 s ceiling when a doubling would cross it. The run-relative 4× cap never binds on a probe that only doubles.

If the gate could have rejected something and did not, the run has shown that these frames hold every star the detector can find, and no exposure is offered: "All 9 frames found fewer stars than the star-count target, and no candidate was rejected for being too faint, so a longer exposure will not add more: these frames contain every star the detector can find. Detection binning is the lever that can still help; otherwise this field simply supports fewer stars."

In both states the block adds a sweep-geometry note when candidates were discarded for being flat and featureless. That happens on frames far enough from focus that stars spread into plain discs, which no exposure recovers; a smaller step size keeps more of the sweep close enough to focus to be measurable.

Live vs. saved runs¶

What the block asks you to do about the number depends on where the run's frames came from.

A Live sweep run in Optimize mode adds a New sweep exposure row inside the Star signal block whenever there is a longer exposure to capture at: an editable exposure box, pre-filled with the recommended value, next to a Capture a new sweep and optimize button. Adjust the number if you want, then the button recaptures the sweep at that exposure and re-tunes detection settings against the new frames, without leaving the wizard. A Live sweep run in Use current settings mode has nothing to re-tune, so that row is hidden; the block instead tells you to switch to Optimize mode and run the wizard again.

A saved ("Replay") run has no rig attached to recapture from, so the block tells you to raise your auto-focus exposure to about the recommended value in NINA's focuser options and run the wizard again in Live mode once you have frames at the new exposure.

Whichever of those three shapes applies, the block adds the same rider whenever the number it just quoted was trimmed by the absolute 30 s ceiling rather than the run-relative 4× cap: the sentence loses its full stop and continues "; or, if you shoot narrowband, auto-focus through a broadband filter with a filter offset instead." The capped number is still worth capturing in that case: the rider offers an alternative alongside it, not a replacement.

Accepting the run in front of you is still a legitimate choice in every case: the settings it found are the best fit for the frames you actually have.

Detection binning changes the same measurement

The per-star SNRs this recommendation reads are measured in the run's own binned-pixel space, so the result is self-consistent within that run, but a Detection Binning change raises the same per-pixel SNR on its own. When the summary offers both recommendations at once, they are not independently additive: change the binning factor first and let the next run re-measure the exposure. Stacking both changes in the same step over-corrects.

When exposure has run out¶

There is a third state where the block does not offer a longer exposure, beyond the \(S_{\text{now}} \ge 10\) case in What it never does and the no-rejections case in When the field is short of stars, not signal: the run's exposure is already at or past the 30 second absolute ceiling (see The two caps), and the measured signal still falls short of the default gate (\(S_{\text{now}} < 10\)). Unlike the \(S_{\text{now}} \ge 10\) case, this is not a healthy field — the data genuinely wants more exposure. But the recommender's raw, uncapped factor would ask for something past 30 s, and the absolute cap pulls that back down to the current exposure rather than proposing anything shorter, so there is nothing longer left to recommend. The block says so directly: "Reaching the default S/N target would need more time per frame than an auto-focus sweep can spend; no longer exposure is offered."

With the exposure route genuinely exhausted, the block's remedy here is a different lever entirely: "If you shoot narrowband, auto-focus through a broadband filter with a filter offset instead."

A narrowband filter passes so little broadband sky and star light that the exposure this recommendation would need to reach the default gate is already impractical for an autofocus sweep. Auto-focusing through a broadband filter instead — and letting NINA's per-filter focus offset return the focuser to the narrowband focus point — reaches usable star signal without extending the exposure any further.