How Stacking Works (And Why More Frames Isn't Always Better)
What stacking does to an astrophoto, why it is not averaging pictures together, how many frames are enough, and why more frames eventually stop helping.
Ask why we stack astrophotographs and you will usually be told “to reduce noise.” That is true and not much help. It does not tell you how many frames you need, why your stack of 200 looks worse than someone else’s stack of 60, or why adding another hour sometimes changes nothing.
The actual argument is short, and once you have it most stacking decisions follow from it.
Signal adds. Noise does not.
Point your telescope at a nebula and take an exposure. Each pixel receives some number of photons. That number is not fixed: photon arrival is random, and the count varies from exposure to exposure by roughly its own square root. Collect 100 photons and the frame-to-frame variation is about 10. Collect 10,000 and it is about 100.
Now stack N frames. The signal, the real photon count from the object, adds linearly: N times as much. The noise is random and partly cancels, so it grows only as the square root of N.
So the signal-to-noise ratio improves by √N.
That one relationship explains most of what you see:
- 4 frames is twice as good as 1.
- 16 frames is twice as good as 4.
- 64 frames is twice as good as 16.
Each doubling of quality costs four times as many frames. This is why the difference between 10 and 40 frames is dramatic and the difference between 200 and 260 is invisible. If the second one disappoints you, you have not done anything wrong. You added 30% more frames for a 14% improvement, and 14% is below what the eye reliably notices.
For a visible step up from a 200-frame stack, you need around 800.
Which is why read noise decides your sub length
A second noise source does not behave like this. Every time the sensor is read out, the electronics add a fixed penalty. It does not depend on exposure length; a 5-second frame and a 500-second frame each pay it once.
So a given total integration time carries read noise in proportion to how many frames you split it into. Ninety minutes as 540 ten-second subs pays the penalty 540 times. The same ninety minutes as 18 five-minute subs pays it 18 times.
That is the whole argument for longer sub-exposures. It is also why a guided setup pulls away from a smart telescope on faint targets at the same total time. The guided rig does not collect more light. It reads the sensor thirty times less often.
The counter-pressure is that long subs need good tracking, and a trailed 300-second frame is worth nothing. The right sub length is the longest one your mount reliably delivers, which is a mechanical question rather than a processing one.
Alignment is where stacks are lost
The √N argument assumes every frame contributes the same signal to the same pixel. That requires the frames to be in register, and this is where most disappointing stacks fail.
Frames move between exposures: mount drift, refraction near the horizon, flexure and, on any alt-azimuth mount (which includes every smart telescope), field rotation. Over an hour, frames from the start and end can be rotated by tens of degrees relative to each other.
Alignment that handles only translation will not cope, and it fails quietly. There is no error message, just a stack where everything is slightly smeared. It looks like poor focus or bad seeing, and people spend a season chasing the wrong problem.
Proper registration works from the stars themselves. Build triangles from the brightest stars in each frame and describe them by side ratios, which survive translation, rotation and scale. Matching triangles vote for which star corresponds to which, an outlier-tolerant fit throws out votes that disagree, and a refinement pass brings the result to sub-pixel accuracy.
That last step matters. A consistent half-pixel error across the stack costs you the same detail you would lose to slightly worse seeing.
Rejection: the part that removes what averaging cannot
Averaging handles random noise. It does not handle things that are not random: satellites, aircraft, cosmic rays, a car’s headlights sweeping the field.
Average 100 frames where one has a satellite trail and the trail is still there at 1% strength. That is faint, but visible against a dark sky, and it survives stretching.
Rejection removes it by looking across the stack at each pixel and discarding values that do not belong. The methods differ in what “do not belong” means, and the choice between them is not arbitrary.
Sigma clipping takes the mean and standard deviation at each pixel and drops values beyond a threshold. It works well and is the default for good reason, but it assumes every frame samples the same distribution.
Winsorized sigma clipping pulls outliers in toward the bulk rather than removing them. It is safer on shallow stacks, where estimating a standard deviation from eight samples and then throwing values away tends to discard real signal.
Linear-fit clipping asks a different question. It sorts each pixel’s values across the stack and fits a line through them. A smooth spread, the kind produced by transparency changing through the night, is expected by that model and costs nothing, while a satellite trail is still one value far off the line.
That difference matters more than it sounds. When high cloud rolls in, or the target sinks toward the light dome, the frames really do differ. The spread is real data, not noise. Sigma clipping sees frames at the ends of the range as outliers and starts discarding them, and the ones at the dark end are usually the clearest frames of the session. You lose your best data to a method that assumed it was wrong.
The thing to watch is how much your per-frame sky level drifts. If it is stable, sigma clipping is right. If it moves by more than a few percent, a linear fit will do better. Akastroid measures the drift and switches automatically above about 8%.
Shallow stacks need different treatment
With eight frames you cannot estimate a distribution. Any rejection method is working from too few samples, and aggressive clipping will remove real signal while claiming to remove outliers.
Below about eight frames, plain averaging or a median is usually the safer choice. Between eight and fifteen, Winsorizing. Above that, real clipping becomes safe.
The failure is easy to miss. Aggressive rejection on a shallow stack produces an image that looks clean and is quietly missing faint detail. It does not look broken, just slightly empty, and nothing on screen tells you why.
When more frames stop helping
There are three cases where the next hour buys you nothing.
Read noise. With very short subs the noise floor is set by readout, not by sky photons. Stacking still helps, but you are fighting a fixed cost that more frames do not remove. Longer subs would.
Sky, on a faint target. Under bright skies the background dominates, and the faint outer parts of your target may never rise above it. Signal-to-noise still improves as √N, but √N of barely detectable is still barely detectable. Darker skies or narrowband filters change this. More time does not.
Alignment. If registration leaves half-pixel errors, adding frames adds more slightly misregistered data. The stack gets smoother and no sharper. Check this before blaming the sky.
A working answer
- Sub length: the longest your mount reliably tracks. This sets read noise, and read noise dominates faint targets.
- Frame count: think in factors of four. For a visible improvement, plan to quadruple.
- Registration: must handle rotation on any alt-az mount.
- Rejection: match it to the depth of your stack and the steadiness of your night.
- Know your limit: read noise, sky brightness, or alignment. Adding frames only helps the first two, and only slowly.
None of this needs any mathematics beyond √N, but it does explain why a stack you are unhappy with came out the way it did, which is usually more useful than another slider.
Also in Čeština · Dansk · Deutsch · Ελληνικά · Español · Suomi · Français · Hrvatski · Magyar · Italiano · 日本語 · Norsk bokmål · Nederlands · Português (Brasil) · Română · Slovenčina · Slovenščina · Srpski · Svenska · Українська · 繁體中文
Try it on your own data
Akastroid runs its processing on your own frames and logs each step it took.
Download Akastroid