Is my Seestar image real?

Short answer: yes, the light is real. The stacked image your Seestar builds is made of photons that came through the lens from the sky, added up over many short exposures.

What makes it look the way it does on your phone is processing on top of that light. Stretching brightens the faint parts far more than the bright parts, and denoise and sharpening in editing tools move pixel values around to look cleaner. None of that invents a galaxy, but after an edit like that, a pixel's value no longer tells you how much light arrived. It is still a picture of the sky; it is no longer a measurement of it.

This Note walks through both halves: what stacking does to the light, what a stretch does to the numbers, and what I found when I tried to fake the whole thing.

A thin line beside a passage says how far its claim is proven: measured, implemented, prototyped, planned, illustrative, inferred. Colored numbers carry the same mark. A passage with no line is stated. How claims are marked.

What live stacking does

A sub is one short exposure, often 10 seconds on a Seestar. One sub is noisy. Live stacking turns a pile of subs into one deeper picture, and in general it does three things to each new sub:

1. Align

   Find the stars in the new sub and shift and turn it so they land on the same pixels as in the stack so far. On an alt-az mount (one that moves up-down and left-right) the field slowly turns through the night, so this step matters.

2. Reject outliers

   At each pixel, compare the subs and drop a value that disagrees badly with the rest: a satellite trail, a plane, a cosmic-ray hit, a hot pixel.

3. Average

   Average what's left. The sky's light is the same in every sub and adds up; the random noise partly cancels.

I haven't checked exactly how the Seestar app weighs or rejects subs; the three steps above are how live stacking works in general.

The noise drops with the square root of the number of subs: four times the subs, half the noise. So 752 subs should carry about √752 ≈ 27 times less noise than one sub. (illustrative)

That's what I saw on my own night of NGC 7000, the North America Nebula: a single 10-second sub carried about 27 times the noise of the stack of 752 such subs, on the same crop with the same white balance and stretch. The comparison is on the Experiment Can we recreate the night sky? (2026-10-11). (measured)

Even the files the app writes aren't untouched pixels. From a fine pattern in the darkest brightness codes of real Seestar S30 Pro files, I worked out that the app subtracts its own master dark (an average of dark exposures, which records the sensor's own glow and pattern), then scales by the white balance and its own flat field (a correction for the lens's uneven brightness across the frame), which brightens the corners by 7 to 8 %, and patches about 0.15 % of pixels from a fixed bad-pixel map. (inferred) Drawn that way in synthetic files, the pattern's fine spacing matches the real files within 2 % and its slower repeat within 3 % on frames held back from the fit, but the code-by-code match still misses within about 25 codes of black, so it isn't exact yet. That is on the same Experiment, under What it gets wrong. (measured)

What a stretch does to a number

A stacked image is linear: twice the light makes twice the number. Almost everything faint sits in the bottom few percent of the range, so on a screen a linear stack looks nearly black with a few bright stars. A stretch is a curve that lifts the dark values a lot and the bright values a little, so the nebula shows up.

Here is one common curve (a midtones transfer function) applied to four made-up pixels in a 16-bit image, where values run from 0 to 65,535. Star B got exactly twice as much light above the sky as star A. (illustrative)

After the stretch, star B reads only about 1.26 times star A above the sky instead of 2, and the faint nebula's share went up. Change the curve and those ratios change with it. (illustrative) That's the whole problem in one table: the picture looks better, but brightness ratios, which are what a light curve or a magnitude is built from, now depend on a curve someone picked.

Could we fake it?

If the processing were doing most of the work, a convincing Seestar image could be faked from scratch. So I tried. For the Experiment Can we recreate the night sky? (dated 2026-10-11, marked Exploratory) I built a program that renders Seestar S30 Pro subs from star catalogs and sky surveys, with none of my own pictures going in, then handed them to my own processing engine to see whether it would treat them like the real thing. (prototyped) The page's own headline:

Close enough to fool our engine, mostly.

On 18 synthetic subs, none of them used while building the generator, the engine plate-solved all 18 (worked out where each one points by matching its stars to a catalog) and confirmed 1,079 to 3,106 stars per frame. In the page's words: “Not one confirmed star was a star the frame didn't contain.” Measured on the same 1,617 stars, the synthetic frame's star brightness over the real sub's came out 1.00 in green, 1.03 in red and 0.95 in blue; those are medians, and star to star they scatter by 0.28 to 0.40 magnitudes. (measured)

The qualifiers travel with those numbers. The page says: “Most of this was measured on nights the generator was built and tuned on. On a night it had never seen, it partly held up: stars, positions and sizes yes, star color and sensor noise not yet.” On that held-out night (M 27, the Dumbbell Nebula, 22 August 2026, six real-and-synthetic pairs of subs), the verdict is “Not confirmed yet.” The synthetic subs solved like the real ones, drew stars the same size within 2 % and matched the overall star brightness within about 0.1 magnitude, but missed on blue star color, on the noise from a hot sensor and on the green clip level, and M 27 itself is missing from them, because the only nebula map the generator has covers the NGC 7000 region. (measured)

The page also has a real-or-fake quiz you can take: five rounds, each a real stack beside a fake one. It publishes no score from readers, so the result I can quote is the engine test above. Its fakes are a different kind too: survey images projected onto my own stacks, not the full camera model the engine was tested on. (implemented)

What that says about your image: a fake only gets close by modeling the real sky, the real optics and the real sensor, and where the model is missing something (dust lanes, thin cloud, the camera's color), the fake gives itself away. The real image is the one that has all of it. (inferred)

Where a pixel stops being a measurement

The Starlight, Measured exhibit puts it in one card, “Edited pixels stop being measurements”, on its opening page under “The problem with editing pixels”: “After curves, masks and white-balance sliders, a pixel value no longer says how many photons arrived, so nothing can be checked against the sky.”

My rule of thumb: an edit that treats every pixel the same way and keeps “twice the light, twice the number” (subtracting a dark frame, dividing by a flat, averaging subs) keeps the measurement. An edit that bends the curve, or treats one part of the frame differently from another (a stretch, denoise, sharpening, masks, star removal), turns it into a picture. Both are fine to do; they're for different things.

Measure first, then make the picture

So the order matters. Measure positions and brightness on the untouched pixels first, then make the pretty picture from a copy.

SkyCruncher's 1.3 old engine works that way: star shapes are cut from the untouched pixel grid; lens distortion is corrected on the star positions as numbers, not by warping the image; and if a picture is made, its pixels are resampled at most once, at the end, and never for the stars. (implemented) The new app is planned to work the same way. It is in development, with no release date; the app page has what you can try today. (planned)

Why every number here carries a label

Every value is measured, labeled approximate, or absent, and anything unmeasured says NOT MEASURED, so a number never looks more certain than it is; how claims are marked has every marker. (implemented) The frame receipt format shows the record behind it: a frame receipt is what SkyCruncher writes when it processes one frame, listing every star it measured with its position, brightness and error bar. (implemented)