Lucky imaging camera settings: exposure, sampling and frame rate

Lucky imaging stacks the few sharp frames hidden inside thousands of blurred ones, so the camera's job is to deliver as many uncompressed frames as the atmosphere allows. A consumer camera hides exposure, gain and output format behind scene modes; a machine vision camera hands you each setting as a number. The four that decide the result are exposure, pixel sampling, region of interest (ROI) and data rate. This page works through each one with formulas, a worked example on a 50 cm f/10 telescope, and the checks to run before you order a camera.

What lucky imaging asks of a camera

Turbulence above the telescope smears most frames and lets the image snap sharp for a few milliseconds at a time. Lucky imaging captures thousands of those short frames, scores every frame for sharpness, aligns the good ones and stacks them: noise averages down while resolution survives. Because the stacker re-centers each frame, mediocre tracking is survivable over a run of minutes.

That workflow puts four demands on the camera. Uncompressed frames first: compressed video discards exactly the fine speckle detail the stack needs, so record raw mono frames. Then fully manual exposure and gain, fixed for the whole run. Then a high frame rate from a small ROI, because sharp frames arrive at random moments and you want as many draws as possible. And pixel sampling matched to what the aperture can resolve, which the next section quantifies.

Shutter type, interface and full-frame rate are the numbers to shortlist on:

The LS-BCM-0003 is rated 120 fps at its full 3.1 MP resolution over USB3, with a 1/1.8" global-shutter sensor — the shape of a planetary camera in one line of specs.

Pixel sampling: match the pixels to the aperture

The atmosphere, not the sensor, sets most of the resolution. Two limits bound it: the aperture's diffraction limit and the night's seeing. Sample the finer of the two at two pixels across; anything finer adds noise and bandwidth, not detail.

The third line follows from the first two: sampling the Dawes limit at two pixels gives a focal ratio of 3.6 × pixel size in µm. That is f/10 for 2.9 µm pixels, f/12 for 3.45 µm pixels, f/21 for 5.9 µm pixels. A barlow pushes the focal ratio up and a reducer pulls it down, so the rule tells you which adapter the setup needs.

Seeing clamps it from above. A typical site runs 1.5-2.5 arcsec FWHM; a very good site 0.4-0.6 arcsec. Two pixels across 2 arcsec seeing asks for 1 arcsec/pixel, which any planetary focal ratio already beats — on average nights you are oversampled, and the fix is frame rate and 2×2 binning, not more focal length. Build for the 3.6 p rule and bin on the bad nights; the trade is set out in binning and sensor readout. This is the same Nyquist argument that matches industrial sensors to lenses, worked through in Nyquist limit and camera resolution. Converting pixel pitch and focal length into a real size per pixel is everyday arithmetic in machine vision too — see this pixel distance calculation guide.

Worked example: a 50 cm f/10 telescope

Take a 500 mm mirror at its native 5000 mm focal length. The Dawes limit is 116 / 500 = 0.23 arcsec, so critical sampling wants 0.23 / 2 = 0.12 arcsec/pixel.

• 2.9 µm pixels: s = 206.265 × 2.9 / 5000 = 0.12 arcsec/pixel, which is 0.23 / 0.12 ≈ 1.9 pixels per Dawes element. Nyquist met at native f/10 — no barlow.
• 3.45 µm pixels: s = 206.265 × 3.45 / 5000 = 0.14 arcsec/pixel, only 1.6 pixels per element. A 1.5× barlow to f/15 gives s = 711.6 / 7500 = 0.095 arcsec/pixel, or 2.4 pixels per element — sampling met.
• 1.1 µm pixels, the single-board camera class: s = 206.265 × 1.1 / 5000 = 0.045 arcsec/pixel, 5.2 pixels per element — 2.6× finer than the aperture can use. Resolution does not improve; each pixel collects (0.12 / 0.045)² ≈ 7× less light and Jupiter spans 1,000 pixels instead of 375, so frame rate and bandwidth pay for nothing.

Jupiter spans about 45 arcsec, so at 0.12 arcsec/pixel it is 375 pixels across, and a 640 × 480 ROI frames 77 × 58 arcsec with margin for the limb. The decision: 2.9-3.45 µm pixels at f/10-f/15 cover a 250-500 mm planetary telescope, and anything below about 2 µm oversamples a native f/10.

Exposure: freeze the seeing

Seeing decorrelates in roughly 10 ms — 5-20 ms across sites and conditions. Exposures longer than one decorrelation time average over several atmospheric states and the sharp frames vanish, so set exposure between 5 and 20 ms. Bright planets take 2-6 ms at moderate analog gain.

The frame-rate ceiling follows directly: fps ≤ 1000 / exposure in ms. A 10 ms exposure caps the run at 100 fps; 6 ms allows about 160 fps. For the rare case that needs longer than one frame period — a dim target, a drifting scene — the workarounds sit in why camera exposure time has a maximum limit.

Judge exposure by the histogram, not the preview: raise gain until the brightest limb sits at 70-80% of the 8-bit range with no clipping, then fix exposure and gain for the entire run. Raise analog gain first; digital gain only rescales the numbers.

Frame rate, ROI and the bandwidth ceiling

Uncompressed frames cost bandwidth, and the interface sets the budget:

Mono8 is one byte per pixel. GigE moves about 118 MB/s at the host; USB3 Vision about 380 MB/s.

That last row explains the ROI trick: shrink the region and the frame rate climbs with it. What a given link really carries is worked through in GigE Vision for a high-speed camera, and the same arithmetic plans a very fast recording stream in high frame rate camera data rate.

A 1.6 MP global-shutter mono sensor over GigE covers the planetary case:

The MV-CB016-10GM-M-W takes an M12 lens mount, which keeps the camera head compact behind the focuser.

Shutter, mono and bit depth

Global shutter exposes every row at the same instant, which is what a planetary stack wants while seeing displaces the image by fractions of a pixel between milliseconds. A rolling-shutter sensor sweeps its rows over a readout time that grows with resolution, smearing those displacements into the frame. Planets suffer; the Moon does not. For lunar panels the sensor's size decides the field:

The MV-CS200-10UM is that class: a 1" 20 MP mono sensor over USB3.0 on a C-mount. A 1-inch sensor spans about 13 mm at focus, so at 5000 mm focal length it covers roughly 9 × 6 arcmin per panel — crater fields, not the 31 arcmin lunar disk — and its rolling shutter is acceptable because the Moon barely moves between rows.

Mono versus color: a mono sensor records true detail in every pixel, while a Bayer color sensor spreads each color across a 2 × 2 block and interpolates roughly half the luminance detail away. For stacks where resolution is the point, mono wins; for live outreach, one-shot color at 60 fps is the simpler rig. Pixel format also reshapes the frame-rate budget, as RGB camera frame rate limits shows.

Bit depth: Mono8 gives the highest frame rates, and stacking averages noise down anyway, so 8-bit is the planetary default. Reserve 10- and 12-bit formats — 25-50% more data per frame — for the lunar terminator, where the dynamic range is real.

The settings to set, in order

A machine vision camera exposes these as GenICam features. Set them once, before streaming starts, and they hold for the night:

1. ExposureAuto = Off, then ExposureTime in microseconds — 5,000 to 20,000 to start.
2. GainAuto = Off, then a fixed Gain that puts the histogram at 70-80% of range.
3. PixelFormat = Mono8 for planets; 10- or 12-bit only for the lunar terminator.
4. Width and Height to the planetary ROI.
5. AcquisitionFrameRate to the value your bandwidth math allows.

Order matters because an auto mode that re-engages after acquisition start quietly overrides the manual numbers: the startup-order failure mode is in set manual exposure before streaming, and the case where an auto exposure limit never applies at startup is in auto exposure upper limit not applied.

Machine vision camera or consumer camera

A consumer camera can demonstrate the workflow; it cannot hold exposure and gain fixed, deliver lossless frames, or trade resolution for frame rate on demand. That trio is the whole reason to put a machine vision camera on the focuser.

Choosing and checking before you order

• Critical scale: 58 / D(mm) arcsec/pixel — 0.23 for a 250 mm aperture, 0.12 for 500 mm.
• Focal ratio: compare native f-number with 3.6 × pixel µm; below it, plan a barlow.
• Bandwidth: pixels × fps × 1 byte (Mono8) against about 118 MB/s for GigE or 380 MB/s for USB3.
• Shutter: global for planets; rolling acceptable for the Moon.
• Sensor: mono when resolution is the goal, one-shot color for live outreach.
• Mechanics: C-mount, CS-mount and M12 heads all adapt to standard 1.25-inch focuser holders with simple spacers; read the frame-rate-at-ROI column of the datasheet rather than the full-frame number.

Both camera families work here: area scan cameras offer the widest sensor and interface choice, while board-level cameras save weight and space on the focuser. The camera finder filters by resolution, shutter and interface directly.

Set the sampling and bandwidth numbers first, then let the camera step of the configurator filter the catalog to what matches. If the optical side of the build needs the same treatment, the lens configurator starts one step over.

When the usual advice is wrong

• Oversampling is not always waste: drizzle-style stacking can recover up to about 1.5× linear resolution when frames are plentiful and sharp, so a very fine-pitch camera on a stable mount still has a path. You pay in frame rate and per-pixel signal.
• A big sensor beats fps for lunar work: the Moon barely moves between rows, so a rolling-shutter 20 MP camera at 30 fps panels outperforms a fast small one for crater fields.
• One-shot color beats mono RGB when the audience is live: a color global-shutter camera streaming Jupiter at 60 fps needs no filter runs at all.
• Measure seeing before buying for the diffraction limit: record a bright star at 100 fps and read the FWHM from the stacked average. On a 2 arcsec night every planetary focal ratio oversamples the sky — the fix is binning and more fps, not a finer-pitch camera.

Run the sampling math for your aperture first; every other setting follows from that number.