Processing Seestar S50 FITS Files: What the App Doesn't Do For You

The ZWO Seestar S50 sells on a promise it genuinely keeps: point it at a target from your phone, wait, get a picture. For a lot of people that is the whole hobby, and there is nothing wrong with stopping there.

But the Seestar is quietly saving something better than the JPEG it shows you. If you turn on Save every frame in the settings, it writes each 10-second sub-exposure to disk as a FITS file. Those files contain measurably more than the live stack does, and the gap is larger than most people expect.

This is about what is actually in them, and what to do with it.

What the live stack gives up

The Seestar’s on-device stacking has to run in real time on a small ARM processor while also driving the mount, and that constrains it in three specific ways.

It cannot reject frames retroactively. The live stack integrates as it goes. When a cloud drifts through at minute 40 of a 90-minute session, those frames are already in the average. A desktop processor gets to look at all 540 frames first, grade them, and throw out the bad ones before combining anything.

Its rejection is limited. Satellite trails, aircraft and cosmic rays need statistical outlier rejection across the full stack, which means having the full stack. Real-time integration can only do so much.

It stretches once, early. The live view is display-referred — the histogram has already been squeezed to look right on a phone. Once that happens, the faint end is compressed and you cannot get it back. The FITS subs are linear, which means the full dynamic range from sky background to nebula core is still intact and still separable.

The practical result: on the same data, a proper stack of the subs typically shows fainter outer nebulosity, cleaner star colour and a noticeably better noise floor than the live JPEG. Not a different photograph — the same photograph, further along.

Getting the files off

In the Seestar app, go to the settings gear and enable Save every frame before you start imaging. It is off by default, and it cannot be applied retroactively.

Files land in MyWorks on the device, organised per target, with names like:

Light_M42_10.0s_IRCUT_20260304-213512.fit

Everything you need is in that name: the target, the exposure, the filter, and the timestamp. Pull the folder over Wi-Fi or by USB. A 90-minute session at 10 seconds is around 540 files and roughly 10 GB, so give it time.

You will also see a Stacked_*.fit in there. That is the device’s own result. Keep it for comparison, but do not feed it into a stack of subs — it is already an average, and averaging it with individual frames weights it wrongly.

What is in the headers, and what is missing

This is where Seestar files have one specific quirk worth knowing about.

The headers carry the useful basics: EXPTIME, GAIN, INSTRUME naming the Seestar, the filter, the date, and — importantly — RA and DEC, because the device plate-solved to find the target. That pointing information is genuinely valuable; it is what makes photometric colour calibration and annotation possible later.

What they do not reliably carry is focal length and pixel size. Which is a problem, because plate solving needs a pixel scale, and a pixel scale needs both of those numbers.

The fix is that a Seestar is a sealed instrument. It has one optic and one sensor, and you cannot change either. So the model name is the specification:

	Seestar S50	Seestar S30
Focal length	250 mm	150 mm
Aperture	50 mm	30 mm
Pixel size	2.9 µm	2.9 µm
Sensor	Sony IMX462	Sony IMX662
Pixel scale	≈ 2.39 ″/px	≈ 3.99 ″/px

Recognising Seestar S50 in the INSTRUME card supplies both missing numbers, and the scale follows. Akastroid does this automatically — it fills in only fields the header left empty, never overriding what the file actually recorded, on the principle that the instrument knows its own configuration better than a lookup table does.

That 2.39 ″/px figure also tells you something useful about your data: at that scale, with typical seeing, the Seestar is slightly undersampled. Stars land on very few pixels. This matters for what you can and cannot recover later.

The debayering trap

Seestar FITS files are raw Bayer data — a colour filter mosaic, not a colour image. The mosaic is GRBG.

Two ways this goes wrong. Debayer with the wrong pattern and colours come out swapped, usually with a strong magenta or green cast that no white balance fixes. Debayer twice — once by an intermediate tool, once by your stacker — and you get a soft, checkerboarded mess.

The stacked file the Seestar produces is already debayered. The subs are not. Any tool that treats them the same way is going to get one of them wrong.

Stacking short subs

Ten seconds is short, and that shapes the right approach.

Expect a lot of frames. 500–1,000 is normal for a decent session. That is good — it is what makes aggressive outlier rejection safe.

Use rejection that suits the count. With a deep stack you can afford sigma clipping, which assumes every frame samples the same distribution and rejects what falls far from the mean. But that assumption breaks when transparency drifted through the session — high cloud, the target sinking towards the horizon, dew forming. Then the frames genuinely differ, the spread is real rather than noise, and sigma clipping starts discarding frames at the ends of the range, which are often the clearest ones you have.

Linear-fit clipping handles that case properly: it sorts each pixel’s values across the stack and fits a line through them, so a smooth drift is expected and costs nothing, while a satellite trail still stands out as one value far off the line. Akastroid measures the spread of per-frame sky levels and picks between the two automatically — above about 8% drift it switches.

Do not expect drizzle to help much. Drizzle recovers sub-pixel detail from dithered frames. The Seestar’s alt-azimuth mount produces field rotation, which does provide some sub-pixel variety, but it is not deliberate dithering. Check whether your set actually has the sub-pixel spread before enabling it — reconstructing on a finer grid from undithered frames just gives you a larger, softer file.

Field rotation is the real constraint

The Seestar is an alt-azimuth mount without a field derotator. Over an hour, the field rotates. Frames taken 40 minutes apart are rotated relative to each other, sometimes by tens of degrees.

Any stacker you use must handle rotation, not just translation. Simple translation-only alignment will fail on Seestar data, and it fails in a way that looks like poor focus rather than an obvious error — everything comes out slightly smeared and nobody can say why.

Rotation also means the corners of your final stack are covered by fewer frames than the centre. The overlap region shrinks as rotation accumulates. Expect to crop, and expect the outer edge to be noisier than the middle. This is not a defect in your processing; it is geometry.

The 10-second limitation, honestly

The Seestar caps exposures at 10 seconds for a reason — it is unguided, and longer subs would trail.

The consequence is read noise. Every exposure adds a fixed noise penalty from reading the sensor, and a stack of 540 ten-second frames carries 540 helpings of it. The same 90 minutes in 18 five-minute subs would carry 18. This is why a tracked, guided setup pulls ahead on faint targets even with identical total integration.

What that means practically: the Seestar is excellent on bright and medium-brightness targets — Orion, the Lagoon, the Andromeda core, most of the Messier list. Very faint extended nebulosity is where the read noise floor shows, and no amount of processing invents signal that never got above it.

Knowing that is worth more than any processing tip. It tells you which targets will reward another two hours and which will not.

What to actually do

1. Turn on Save every frame before the session, not after.
2. Pull the whole target folder. Keep the device’s Stacked_*.fit aside for comparison.
3. Let the stacker read the FITS headers rather than telling it the pattern by hand — GRBG, and it should not be debayered twice.
4. Use a rejection method matched to whether your transparency held steady.
5. Crop the rotation-thinned edges.
6. Compare against the device’s own stack. If yours is not clearly better in the faint regions, something in your workflow is undoing the advantage.

That last step is the one people skip, and it is the only one that tells you whether the extra effort earned anything.