What the Processing Log Is Telling You

Every session Akastroid processes ends with a log: a list of what was decided, in order, with the reason for each. It is in the Details tab. Most people never open it, which is a pity, because it is the fastest way to learn what processing actually does - and the only way to know whether the software did something you would have done differently.

This is that log, line by line, with what each entry means and when it is worth a second look. Lines are quoted from real sessions.

Calibration

Calibrating with 37 darks, 17 flats, 17 bias.

The frames it found in darks/, flats/ and biases/ beside your lights. If a set is missing that you know you shot, the folder name is probably the reason - it reads dark/darks, flat/flats, bias/biases/offset.

No calibration frames detected. Continuing with light-frame optimization.

No calibration folders. Hot pixels are repaired from the lights themselves; vignetting is left to the gradient model. Fine for a smart telescope; on a DSLR with a fast lens, flats would have been worth shooting. (What each calibration frame fixes.)

The darks do not match the lights: the darks were exposed for 30s and the lights for 120s …

A warning, and one to act on next time: darks at the wrong exposure leave part of the sensor’s pattern in the stack. They were applied anyway because a mismatched dark is still better than none.

Reference frame and registration

Reference frame: IMG_7491.CR2 (quality 65)

The frame everything else is aligned to - the highest-scoring one, unless you chose another. Its score in brackets is relative to the session, so 65 on a rough night is the best of that night, not a mediocre frame in absolute terms. (How the scores work.)

Not registered - IMG_7162.CR2: no matching star pattern found

A frame whose stars could not be matched to the reference. Usually cloud, a bumped mount, or a frame from a different pointing that ended up in the folder. It is excluded; the count of these appears as a warning. One or two in a hundred is normal. Ten in a hundred is a session worth looking at.

Matched the background shape of 41 frames to the reference before integrating - the sky gradient moved during the session.

The light dome or the Moon shifted through the night, so the gradient across each frame was not the same shape. Those frames had their gradient shape matched to the reference’s so that the rejection stage would not mistake a brighter corner for a satellite. Informational; it is doing the right thing.

Drizzle

Dither: 183 frames dithered across 96.5 px with a sub-pixel spread of 0.95 - enough to recover detail below the pixel grid. Stars span 3.2 px, so this field is already sampled finely enough - drizzling it would enlarge the file without recovering detail.

Two separate tests. The first asks whether your frames landed on different sub-pixel positions (they did). The second asks whether the pixel grid is coarser than the optics (it is not - stars three pixels wide are already well sampled). Drizzle only helps when both hold, and here it declined. If you want it anyway there is an override, and the log will tell you it was used against advice. (Drizzle and undersampling.)

Integration

Integration: Sigma clipping - 183 frames - deep enough for sigma clipping to remove trails cleanly

The stacking method, chosen from the frame count and the session. Sigma clipping rejects, at each pixel, the samples that sit far from the others - which is how a satellite that crossed one frame vanishes from the stack. It needs enough frames to estimate “far” from; below about fifteen a gentler method is used and the log says which.

Integration: Linear fit clipping - 112 frames whose sky level drifted through the session - fitting each pixel’s stack rejects outliers without mistaking the drift for one

The same idea for a night whose sky brightened or darkened steadily. A plain sigma clip would see the earliest and latest frames as outliers - they are the darkest and brightest - and throw away good data. Linear-fit clipping fits the drift first. You did nothing wrong; the app noticed something about your night.

Integrating without a cache, in streaming passes.

The registered frames did not fit on the disk, so instead of writing them out the app decoded every frame two or three times. Slower, and every frame was still used. Free up space if you see it often.

Stacked 183 of 183 selected frames; 2.0% of pixel samples were rejected as outliers.

The rejection rate. One to three percent is a normal night. Eight or nine percent means a lot of hot pixels (a DSLR without darks), a lot of satellites, or drift. Above that, look at the frames.

Border

Trimmed the frame edge where field rotation left partial coverage - 48 px left, 46 right, 69 top, 77 bottom.

Where fewer than half the frames overlapped, the edge was cut - to where the thin region actually was, side by side. Uneven numbers are normal on an alt-az mount, whose field rotates.

Gradient

Removed a linear gradient of amplitude 0.0008 from 2259 background samples. Removed a quadratic gradient of amplitude 0.0008 from 2121 background samples.

The light-pollution gradient, modelled and subtracted. “Linear” is a tilted plane; “quadratic” can bend once, and is chosen when a plane would leave a colour residual in the corners - a fast lens vignetting red and blue differently from green does that. “Cubic” appears on strongly gradiented skies. The amplitude is in linear units and is small by construction; the number of samples is how many sky tiles the fit used after rejecting the ones with nebula in them.

On a nightscape the model is held to a plane on purpose, and the log says so: a curved surface would follow the Milky Way and subtract it.

Colour

Colour: background neutralised, white balance from 1473 stars (R x1.30, G x0.83, B x0.98)

Two corrections: the sky shifted to grey, then the channels scaled so the typical star in the field is neutral. The factors are shown; on a one-shot-colour camera green is always scaled down and blue usually up, because that is the sensor. If red is far from one, the field may be dominated by a nebula the star finder mistook for stars - rare, and photometric calibration is the fix. (Why the reference star matters.)

Photometric: … Plate solved at 2.39”/px, 41.2° rotation, 388 stars matched.

If you turned it on and the frames record where the telescope pointed, the field was matched to a star catalogue and the balance set from stars of known colour. This is the better calibration and it overrides the heuristic one.

Deconvolution

Deconvolved 3 iterations against a 3.18 px PSF measured from 392 stars.

The blur was measured from your own stars and partly undone. Iterations are set from the stack’s signal-to-noise; a noisy stack gets fewer or none, and the log names the gate that declined it:

Deconvolution was not applied - the stack’s noise is 31% of its sky level, so iterations would amplify grain faster than they recover structure.

That is a stack that wants more frames, not more processing.

Framing and scene

Framed on the subject: 986x1059 from 986x1774, which takes it from 15.8% of the frame to 26%.

A small object in a wide field was cropped toward. Off for nightscapes, the Moon and the Sun, which are composed already; there is a toggle.

Scene: a small object in a wide field, a clean stack (280 stars per megapixel).

The measurement everything below is tuned from.

Finishing

Tuned background - 94% of the frame is empty sky, so the background is set darker to keep it from washing out Tuned exposure - the brightest structure reaches 79x the sky noise, so the exposure is set to suit it Tuned denoise - the stack is clean, so denoising is eased to keep fine detail Tuned stars - the field has few stars, so they are left at full size

Each of these is a slider in the Adjust tab, on AUTO. The log is the explanation of where AUTO put it. If you disagree with one, that is what the slider is for - and the reason given is usually enough to know whether you should.

Which lines to act on

Most of the log is the app telling you it did the right thing. Three kinds of line are worth a response:

• Warnings about the data - mismatched darks, many unregistered frames, a high rejection rate. These are about the next clear night.
• A declined stage - drizzle, deconvolution, photometric calibration. Each says why. Sometimes the why is “your frames don’t record the pointing”, which is a capture setting.
• A tuning you disagree with. The reason is right there; if it does not match what you see, move the slider.

Everything else is the receipt.