17 August 2026  ·  🔭 Astronomy

Why have I been shooting 300 seconds all this time? – the optimal sub length, measured and calculated

Three hundred seconds per frame. The number came with the profile I inherited; it turns up in almost every article I have written – filters, dithering, calibration – and I have never justified it. Which sits badly with my own principle that an inherited number is not yet a checked number.

This morning I finally got round to it. A holiday house in Denmark, my son still asleep, my wife out walking, me at the dining table with the laptop – and in Texas it is the middle of the night. For once seven time zones are an advantage: what is mid-morning before breakfast here is the best hour of the night there. With the full version of SharpCap I spent two sessions taking the measurements this calculation had been missing.

What this is about

Total time is not the question. Five hours are five hours, whether in 60 frames of 5 minutes or 10 of 30. The one thing that differs is read noise: it arises afresh with every readout, regardless of how long the exposure was. Sixty subs mean 60 helpings of it, ten subs only ten.

From which it follows: longer is better. Always. The only question is when it stops paying off – namely as soon as the photon noise of the sky background swamps the read noise. The sky is noisy too: light does not arrive as a steady stream but as countable photons. If a pixel counts N of them on average, that number varies by √N. Once this noise is larger than the noise of the electronics, adding a little more electronic noise makes no difference.

Robin Glover, the author of SharpCap, cast this into an equation you can remember:

t = C · R² / P

t is the optimal sub length, R the read noise in electrons, P the rate at which the sky delivers electrons per pixel per second.

C depends only on how much added noise you accept: C = 1/((1+E)²−1). At five per cent that is 1/(1.05²−1) = 9.75, at ten per cent 4.76.

Two things are packed into it. Read noise enters as a square – half the noise, a quarter of the time. And the sky enters linearly – a dark sky calls for longer subs, and a narrowband filter turns that into the extreme case.

So there are two numbers to obtain.

R – the read noise of my camera

This one I did not have to estimate. SharpCap has a sensor analysis built in that measures the whole response curve from around 900 frames against an evenly lit surface. My flat panel is ideal for it: cover shut with the light on for the bright frames, cover shut with the light off for the darks, and the brightness adjustable in 4096 steps.

2.80 electrons down to 1.395 – a factor of 2.01, in a single step. That is the high-conversion-gain switchover point of the IMX533. I run gain 125 anyway, for other reasons; what I never worked out there is that this one setting cuts the required sub length to a quarter, because read noise enters as a square.

In passing, this also exposes gain 124 as the worst setting on the whole curve: the highest noise immediately before the step and the lowest dynamic range of all. One step off costs you twice. The full table is in the appendix.

From here on I use R = 1.395 e⁻. That is the figure in the Low Noise readout mode, which is where my camera is set – whether that mode buys anything at all was worth an investigation of its own, and it is in the appendix too.

P – my sky

For a long time this was the weak spot in the calculation. In the flat panel article I estimated 0.8 electrons per pixel per second in the luminance filter, derived from SQM 21.9, 81 mm of aperture and 2.03 ″/px – and divided by seventy for narrowband, because the 4.5 nm filters pass roughly that much less.

Now it is measured. SharpCap's Smart Histogram gives the rate directly, in one night for all seven filters:

Two things stand out.

My estimate held up. 0.68 instead of 0.8 in the luminance filter – fifteen per cent off, for a number derived from an SQM reading and an aperture.

And the factor of 70 is right. 0.68 divided by 0.01 is 68. Exactly what I had assumed without being able to show it.

One limitation remains: SharpCap prints only two decimal places, and in narrowband that is the end of it. All three filters read 0.01 – the true value lies somewhere between 0.005 and 0.015, and Hα, OIII and SII cannot be told apart. What that means for the recommendation comes further down. What matters in a measurement like this, and how to manage it without a SharpCap licence, is in the appendix.

The result

Put into t = 9.75 · R² / P:

From half a minute to half an hour – a factor of 68, exactly the ratio of the sky rates. And the colour filters need longer exposures than luminance, because only about a quarter of the light comes through them.

Luminance: 99.5 per cent of what is theoretically possible. Even 60 seconds would sit at 97.7. There is nothing left to gain here.

R, G, B: around 98 per cent. Here too 300 seconds is plenty; 180 would still reach 96 to 97.

Narrowband: 77.9 per cent. That sounds like a small loss, but it is the wrong way to look at it – and the place where I got stuck myself on first reading. So here it is in full.

The yardstick is an infinitely long exposure: there the read noise arises exactly once, and it does not get better than that. With 300-second subs I reach 77.9 per cent of it – at the same total time. And because signal-to-noise grows only with the square root of time, catching up costs not 22 per cent more time but the square of that: 1 ÷ 0.779² = 1.65.

Worked through for one night:

So nearly forty per cent of the night is gone – not because anything breaks, but because the read noise of 120 readouts adds up.

And what if the 0.01 is off? It could mean anything between 0.005 and 0.015, after all. The recommendation holds regardless:

In all three cases the step from 300 to 600 seconds buys twelve to thirteen percentage points.

Why I am not going to 32 minutes anyway

The formula knows two quantities. Reality knows more, and every one of them argues for shorter frames.

The usual suspect is the mount – the longer the exposure, the more opportunity for a tracking error that no amount of stacking will repair. That can be tested: I took the PHD2 log of the M16 night, 4,412 frames, and cut it into sliding windows of five to sixty minutes. If guiding degrades over time, it has to show up here.

The RMS does not change – 0.78 arcseconds, whether the window covers five minutes or an hour. Only the largest single excursion grows, and across two and a half hours there was not one excursion beyond 3 arcseconds. On that night a 30-minute sub would in fact have been guided more evenly than the worst five-minute window.

So the usual suspect is ruled out. What remains are three other reasons:

My decision

Narrowband: 600 seconds. The loss falls from nearly forty per cent to a quarter, and there are still enough frames left for outlier rejection. Going further buys four percentage points and costs the statistics.

Luminance: shorter, 60 seconds. Still 97.7 per cent, and having fewer burnt-out stars is a gain in itself.

R, G, B: 180 seconds. That puts me at 96 to 97 per cent while giving me two thirds more frames than 300 seconds – and burnt-out stars are especially annoying in the colour channels, because they take the star colours with them. At 60 seconds it would be only 90 to 92 per cent, which is too short.

The theoretical optimum is never the answer. It is the ceiling you weigh your choices against.

I worked all of this through, as has become my habit, together with Claude AI.

Appendix A – the second readout mode: does it buy anything?

The Ares series has a second sensor mode, “Low Noise”. Player One explicitly recommends it for deep sky in the manual. It is found here:

Whether it buys anything is disputed in the forums: several owners of the identical Ares-C Pro could not measure any difference; Player One called the result “very strange” and never supplied an explanation.

This can be settled, because SharpCap stores the sensor analysis separately per readout mode – you can see it in the file name, …~MONO16~Low Noise.json next to …~MONO16~Normal.json. Two runs, one answer:

The mode does something – but mostly where hardly anyone works. Below the HCG point it gains six to sixteen per cent. At my working point it is 2.8. Above gain 200 the advantage disappears, and from 400 Normal is even slightly better.

Which also explains the forum argument: measure at high gain and you find no difference, because there is none. Measure at low gain and you find a clear one. Both camps were right.

One caveat goes with this. I ran the Low Noise analysis twice and got 1.37 electrons once and 1.395 the other time – 1.8 per cent scatter between two runs of the same camera in the same mode. The repeatability is therefore almost as large as the advantage it is supposed to measure at gain 125. At my working point the readout mode is thus not a relevant factor. I leave it on Low Noise because it costs nothing.

Appendix B – the full sensor analysis

SharpCap Sensor Analysis, 14 Aug 2026, against the flat panel, sensor at −10 °C. The values come straight from the two JSON files SharpCap writes to %APPDATA%\SharpCap\SensorCharacteristics – readable as plain text with a Pro licence.

Measured bit depth 14 in both modes · linear to 99.7 per cent (Low Noise) and 99.6 (Normal) respectively.

Dynamic range rises at the HCG step. From 124 to 125 it grows by almost a full stop even though the full well gets smaller: 6,331 : 1 to 12,215 : 1. More gain does not cost dynamic range here; it buys it. Beyond that it stops paying off – gain 150 saves 0.04 electrons of noise and costs 4,000 electrons of saturation capacity.

The saturation column is not a measurement but a conversion: every value is exactly e⁻/ADU × 16,383, that is, the span of the converter expressed in electrons. What the pixel really holds is not in there. So the 74,918 electrons at gain 0 are not evidence against ZWO's figure of 50 ke for the IMX533 – the 99.7 per cent linearity is a hint in that direction, no more.

A side finding I would not have got anywhere else: the JSON files also contain the offset curve. At gain 125, offset 150 corresponds to exactly 600 ADU, so four ADU per offset step. My offset of 50 therefore gives a 200 ADU pedestal against 5.4 ADU of noise – thirty-seven sigma clear of zero, so nothing is being clipped. At offset 0, by contrast, the median sits exactly at 0.0, and there it would clip.

Appendix C – how to measure the sky rate

With SharpCap Pro it is one button: Smart Histogram → Measure. It requires a sensor analysis of the same camera in the same readout mode. The program turns the gain up to maximum, takes a series of ever longer exposures and picks the darkest spot in the field. Measurement is per filter, since it is precisely the filter that lowers the background.

This is what my run looked like – an empty field in the Square of Pegasus, new-moon week, the Moon down for three hours:

Four conditions decide whether anything usable comes out of it:

The time. Sun below −18 degrees. This is where it easily goes wrong with a remote rig: seven hours separate my desk from Texas, and what is an ordinary mid-morning here is the hour before sunrise there. Half a degree of twilight is enough to lift every reading.

An empty field above 60 degrees. Away from the Milky Way band, with no extended nebulosity – otherwise you measure that as well.

Narrowband first, while the field is at its highest. And max exposure set to 30 minutes, otherwise SharpCap reports nothing but “No Solution below 600s” for Hα and falls back to a higher gain.

And the best test of all is in the timestamps. Hα, OIII and SII took 28 minutes each, the four broadband filters two to three. A narrowband measurement that finishes after two minutes has aborted early and returns a far too high value.

Without a licence it works too, using material you produce anyway:

Two frames of different length on the same night, say 60 and 300 seconds.

P = (Median₃₀₀ − Median₆₀) × e⁻/ADU ÷ (300 s − 60 s)

Median rather than mean, so the stars do not count. The electronic pedestal cancels out, so no dark is needed. The trap: the driver scales the converter's 14 bits up to 16, recognisable by every pixel value being divisible by four. In that case you work with 1.04/4 = 0.26 e⁻/ADU.

The same conditions apply as above. My 77 narrowband frames of SH2-129, for instance, are expressly unsuitable: Cepheus lies in the middle of the Milky Way, and the nebula fills the frame.

With that, not a single number in this article is estimated any more. All that remains open is the resolution in narrowband: two decimal places are not enough there to tell Hα, OIII and SII apart. Anyone needing better can work around it – the Optimal Exposure that is displayed has one decimal place and scales with 1/P. From the broadband measurements SharpCap's internal constant comes out at P × t ≈ 17.4, and that lets you back out P from the exposure recommendation.