Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Capturing for Helia

Stacking can only recover what the capture contains. This page says what to record so that Helia has the most to work with. The reasoning, and the sources for it, are in the imaging methods research; that document marks each claim as checked against a source or as background knowledge, and so does this page where it matters.

The short version

  • Save as SER, 16-bit if your camera offers it. An MP4 from a camera or phone works for quick results, but it has been compressed and loses detail (see below).
  • Use a short exposure, a few milliseconds or less, so each frame freezes the seeing.
  • Record many frames, at 50 frames per second or more, by cropping the sensor to a region of interest.
  • Set the gain so the histogram peaks at roughly half to two thirds of full scale, and never clip.
  • Sample the image properly: roughly f/13 for a 3.76 micron pixel in white light (table below).
  • Keep the files: darks and flats are not applied yet, but you will want them.

SER, AVI or MP4

SERAVI (uncompressed)MP4, MOV, MKV, WebM (compressed)
Made for astronomyYesNoNo
Raw sensor data (Bayer)Yes, with a pattern codeOnly 8-bit, and the pattern is not stored in the fileNo: already converted to colour and compressed
Bit depth8 or 168 or 16 (Y16) in the formats Helia readsUsually 8-bit, 4:2:0 colour
Per-frame timestampsOptionalNoNot used
CompressionNoneNoneLossy (H.264, H.265, MJPEG and similar)
NeedsNothingNothingThe optional ffmpeg program

Prefer SER. It is simple, uncompressed and carries the colour layout.

Helia also reads uncompressed AVI, including the large OpenDML files (over 1 GB) that SharpCap writes. It reads BI_RGB, Y800/GREY, Y16 and 24-bit BGR video. A compressed AVI (for example MJPG) is handed to ffmpeg, like an MP4, described next. For a raw colour camera recorded to AVI, SharpCap also writes a CameraSettings.txt next to the video, and Helia reads it to learn the Bayer pattern. See Troubleshooting if the colours or the channel look wrong.

When an MP4 is fine

Helia reads MP4, MOV, M4V, MKV and WebM files, and compressed AVI, through ffmpeg when it is installed (see Installation). Helia itself stays free of video codecs; it runs ffmpeg as a separate program.

Raw SER or AVI captures keep more detail, for reasons that matter to stacking:

  • The codec throws away fine, low-contrast detail first, and granulation is exactly that. What was thrown away cannot be stacked back.
  • H.264 and H.265 compress in blocks and across frames, which adds blocking and smears detail from one frame into the next. The sharpness measure then partly ranks how the encoder behaved, not how the air behaved.
  • Typical video is 8-bit with colour detail halved in each direction (4:2:0), and a camera that records MP4 has already demosaiced and sharpened the picture.

An MP4 is fine for a quick look at a day's seeing, for a camera or phone with no other output, or for an archive you have no raw copy of. Helia then says so: helia info, the Open step of the desktop app and the API's inspect response all carry a note such as "lossy 8-bit 4:2:0 video (h264): fine for quick results, SER/AVI raw captures keep more detail". If you can choose, record SER.

Two practical points. Frames are decoded once, by ffmpeg, into an uncompressed file in a cache directory, and removed afterwards, so you need free space for the whole video as raw frames: a 4K clip of 7,500 frames is about 60 GB. Helia checks the space before it starts and says what is missing. And colour video is stacked as luminance, or as the red, green or blue channel you choose with --channel (the desktop app has the same chips).

Why a SER header can be wrong

A SER header is 178 bytes the recording program fills in once, from what it believes about the camera. It is not checked against the pixels, and programs differ in what they believe. Known ways it goes wrong:

  • Colour mode. SharpCap has written raw Bayer data from a colour camera (a ZWO ASI482MC, for example) with ColorID 0, which means mono. Nothing in the file then says the frames are a mosaic. Helia checks the pixels of a SER file that says mono; see Troubleshooting. The same camera and program do not always do it: of two SER files from one ASI482MC session in Helia's test captures, the 16-bit one says BAYER_RGGB and the 8-bit one says MONO. Check with helia info after the first capture of a session rather than assuming.
  • Byte order. The flag for the byte order of 16-bit pixels has been written inverted by some programs. Helia checks it against the data.
  • Bit depth. A program can write the depth of its sensor (12 bit) or its mode where the data is stored as 16.
  • Dates. The DateTime fields are often zero, and the per-frame timestamps at the end of the file are optional.

Run helia info on the first capture of a session: it prints every header field as written next to the values Helia will use, and says where each came from. If the header is wrong in a way Helia does not catch, --bayer, --bit-depth, --endian and --flip-rows on the command line (and the same choices in the app's Open step and in the API) override it; the choice is recorded in the output file.

Exposure, gain and bit depth

  • Exposure. Keep it short enough to freeze the seeing, which is a few milliseconds in the research notes (that figure is background knowledge, not a measured value). In white light this is easy. In H-alpha through a narrowband filter you are short of light, and the trade between exposure and noise becomes the main constraint.
  • Gain. Raise it until the histogram sits at about 50 to 70 per cent of full scale, without clipping. Many frames at higher gain beat fewer frames with longer exposures: stacking averages the read noise down, and frame selection throws away the frames that moved during a long exposure.
  • Bit depth. Use 16-bit if you can. Granulation contrast is only a few per cent in white light, and 8-bit steps are about 0.4 per cent each, which is a real limit on a single frame (stacking dithers it). Helia reads 8 and 16-bit data and works in 32-bit floating point. 12 or 16-bit helps most where the detail is faintest, and granulation is: helia measure shows how much of it a stack holds.

Region of interest and frame rate

The atmosphere keeps changing while you record, and the sharp moments are brief. A study of 160 Hz solar sequences at the GREGOR telescope (Denker and others, 2018) concluded that rates above about 50 frames per second are needed to catch a good share of the best moments. On USB cameras the frame rate rises almost in proportion as the region of interest shrinks, so cropping to the part of the Sun you care about is the usual way to reach 100 to 300 frames per second.

How many frames? Helia keeps the best 25 per cent by default (12 per cent for white light and sodium D, where granulation needs only the sharpest frames), so a capture of a few thousand frames leaves hundreds in the stack. Longer captures help, but the Sun changes: granulation evolves over minutes, and for long captures or mosaics the field rotation and the Sun's own rotation matter (derotation is on the Roadmap).

Sampling: focal ratio and pixel size

To record all the detail your telescope can deliver, the pixel pitch p should be no larger than wavelength x f-ratio / 2, which means a focal ratio of at least 2 x p / wavelength. Worked values:

WavelengthPixel sizeFocal ratio for Nyquist sampling
550 nm (white light)3.76 micronsf/13.7
550 nm (white light)2.4 micronsf/8.7
656.3 nm (H-alpha)3.76 micronsf/11.5
393.4 nm (calcium K)3.76 micronsf/19.1

Seeing blurs the image below the diffraction limit, so in poor seeing a little under-sampling costs little. In good seeing, slightly over-sampling (up to about one and a half times Nyquist) helps the sub-pixel alignment and later sharpening. Helia does not compute your sampling for you yet, and sizes its alignment points in pixels, so if you change your focal ratio you may want to change --ap-size too (see How stacking works).

Darks and flats

Helia applies dark and flat frames, and a map of bad pixels, before it analyses anything: see Calibration. Record them in the same session as the Sun, because they are cheap and you cannot take them afterwards:

  • Flats matter a great deal for solar work. Dust on the sensor window stays put while the image moves, so a missing flat leaves a fixed pattern that stacking can make look sharper, and after local alignment it can be mistaken for granulation. Take flats at the same focus as your science data. In an etalon-based H-alpha system the interference fringes move with focus, so a flat at another focus will not match them.
  • Darks matter little for bright white-light frames, but in H-alpha, where the signal is low, they remove hot pixels and fixed-pattern noise. Record 50 to 100 with the lens capped, at the exposure and gain you used on the Sun.
  • Darks for the flats at the exposure of the flats, if that differs from the Sun's (it usually does): 20 to 50 frames.

The research notes also point out that an etalon passes a slightly different wavelength across the field unless the beam is nearly telecentric, so a disc brightness gradient is normal for such systems. A flat corrects the brightness across the field, not the shift of the pass-band, so Helia warns when a flat shows strong vignetting; see the sweet spot.

Naming and keeping files

For SharpCap AVI captures keep the CameraSettings.txt file next to the video with the name SharpCap gave it (capture.avi goes with capture.CameraSettings.txt). Helia finds it by that name.