Taming the Pelican, with PixInsight and Claude Code: a four-panel, five-filter IC 5070 mosaic, from WBPP to a seamless master

1. The data

The target is IC 5070, the Pelican Nebula, shot as a four-panel mosaic with a mono camera. Every panel has five filters: Astronomik Deep Sky R, G, B (30 s subs) and 6 nm Hα (656.30 nm) and OIII (500.70 nm) at 180 s. The camera ran at gain 105, offset 70 and −15 °C. The plate solutions give an image scale of about 0.65″/px. (The focal length and pixel size written in the FITS headers are not used here: they do not agree with the camera’s specification.) Data were collected over eight sessions, each with its own flats (mostly taken with the Flat Wizard).

These are the frames that actually went into WBPP, counted from the WBPP log:

Calibration inputs: 1,010 flat frames across the sessions, plus a master bias and 23 master darks (10 s to 1200 s) prepared beforehand.

2. Frame review before WBPP

Before WBPP, every light frame went through a small home-made review tool (a Python script that reads each FITS file and computes HFR, FWHM, star count, roundness, ADU statistics and an overall quality score from 0 to 100). It builds a panel × session matrix so a weak session stands out immediately, and a local review page lets me preview a frame and mark it for deletion.

The tool can also calibrate with darks and flats, so the frames are judged on what WBPP will actually see rather than on raw data. Pointed at the folder with the master bias and master darks, it matches each light to the dark of the same exposure time, builds a master flat from each session’s own flats (a night’s flats only ever calibrate that night’s lights), subtracts and divides, and measures the calibrated frame. The “Cal” column in the tables says what was applied (D+F means dark and flat), and calibrated copies can optionally be saved. In the viewer a Raw / Calibrated toggle switches between the sensor data and the calibrated frame, which makes hot pixels, dust shadows and flat-field problems visible before any batch run.

Clicking a filter row opens every frame of that panel and filter across all sessions as a thumbnail grid, all stretched with the same settings, so a drifting, trailed or cloud-affected sub is obvious next to its neighbours. Each tile shows the quality score, the median HFR (the “A2.85” figure) and the star count.

Opening a single frame shows a live auto-stretched preview with its histogram and numbers, and the Delete button moves the file to a _deleted folder instead of erasing it, so a rejection can be undone.

The review state file records 94 frames marked as deleted (R 29, G 35, B 17, H 5, O 8). That matches exactly the difference between the frame counts in the report (326 R, 317 G, 321 B, 155 H, 151 O) and the frame counts WBPP received, so the review step happened before WBPP and its rejects never reached calibration.

3. What WBPP did

The WBPP log (Weighted Batch Preprocessing 3.1.0, PixInsight 1.9.5) covers 128 calibration groups, 20 registration groups, 20 local-normalisation groups and the final integrations. By the log timestamps the whole run took about 43 minutes. The settings, as recorded in the log:

4. Everything after WBPP, at a glance

Orange steps were scripted and run headless in PixInsight by Claude Code; the other steps were done by hand in the PixInsight GUI. Each stage wrote to its own folder, so nothing was ever overwritten.

5. SPFC and MGC

Spectrophotometric Flux Calibration compares the measured star fluxes in each panel against Gaia DR3/SP spectra, so it needs to know what each filter and the sensor actually pass. For the broadband panels I used the built-in Astronomik Deep Sky R/G/B transmission curves and the Sony IMX533 quantum-efficiency curve. For Hα and OIII I used narrowband mode with the exact centre wavelengths (656.30 and 500.70 nm) and a 6 nm bandwidth.

Straight after SPFC, each image went through MultiscaleGradientCorrection with the MARS DR1 database and the MARS filter matching the data: R, G, B, Hα, OIII. Because the camera is mono, each file is treated as a single gray channel with its own filter.

6. BlurXTerminator, full

The earlier Correct Only pass fixed the optics; this second pass is the full deconvolution with default settings (sharpen stars 0.50, sharpen non-stellar 0.50, automatic PSF). One trap for scripters: the process’s own scripted default has correct_only = true, so it must be switched off explicitly or you silently get another Correct Only run.

7. Registration onto one canvas

All the panels were already plate-solved, so instead of matching stars I reprojected every image with the engine behind the MosaicByCoordinates script. The important detail is that all 20 images went through a single run, so the output canvas, scale and rotation are computed once and are identical for every filter: 5884×5884 px at 0.65″/px. Each image is placed on that canvas in its own file, and the five filters overlay pixel for pixel.

A first GradientMergeMosaic run on these tiles produced five mosaics that looked seamless at a glance. Zooming in told another story.

8. The bright-star border problem

In the first mosaics, bright stars at the edge of a panel had left dark holes, dark shadows and one-sided bright smears. The cause is simple once you see the data: at one join, Panel 1 ended right through a bright star’s core, while Panel 2 held the whole star about 100 px inside its own edge. The merge algorithm works on image gradients, and a star truncated by a tile edge is a violent gradient step.

The fix, in three steps

1. Scan every tile edge. Bright stars were detected on the union of all tiles, with a threshold scaled to brightness, and each star’s halo disc was tested against every tile’s valid region. The scan found 55 locations across the five filters where an edge cuts through a bright star’s halo. An early version with a fixed brightness cutoff missed fainter stars, so the threshold had to come down.
2. Fill with black. Where a neighbouring panel contains the whole star, the clipped copy gets a black disc (radius roughly 60–80 px, scaled to the star’s brightness). Zero counts as “no data” to the merge, so the clean copy fills in. This is the same idea as eroding the tile edge, but over a much larger area than the merge’s own 1 px edge shrink.
3. Shrink the edge by 0 px. A second, separate artifact looked like a dark wedge at the left edge between two panels. There was no star there at all: the two panels overlap by only 6–18 px, and the default one-pixel edge shrink erodes that strip away at the corner.

I then compared the final result at ten different star locations on the B mosaic (the pair at the join, the left-edge wedge and several other panel joins), and the corners of the R and B mosaics. All were clean. I checked six locations on R and ten on B; G, H and O use exactly the same recipe, but I looked at them at lower magnification only.

9. Final mosaics and crop

Stars on the outer border of the mosaic have no neighbouring panel to take over, so they cannot be masked. Instead, all five mosaics were cropped to one common rectangle that lies at least 160 px inside the valid data everywhere, which removed every outer-border star on the list. The crop is x 376–5664, y 224–5600, leaving 5288×5376 px, with no pixels at or near zero left in any of the five.

The five cropped mosaics, each given its own gentle midtones stretch (the same kind of automatic screen stretch PixInsight applies, with a target background of about 22 %); the stretch is for viewing only and the data are still linear. There are no visible seams or brightness steps between the panels. The red filter shows the Hα nebulosity too, because its passband includes 656 nm.

10. RGB, H and O masters

The next steps were done by hand in the PixInsight GUI on the cropped mosaics: RGB combination, a default BlurXTerminator pass, a plate solve (the mosaic had no astrometric solution of its own, and cropping drops any that exists), and SpectroPhotometric Color Calibration. The results are saved in output/masters/ as RGB.xisf, H.xisf and O.xisf (the last two with BlurXTerminator applied), all 5288×5376 px. These are ready for further integration.

11. Two paths that meet again

From here the data naturally splits in two. The broadband channels carry the colour and the star shapes; the narrowband channels carry the faint nebular detail. They are best processed separately and only joined late, once each has been brought to a comparable state. Below is the plan from this point; the first attempts at all three merge options are kept at the end of this post, under Paths not taken, since the real iterative work picks up again right after this plan.

Why the two paths can be combined so easily

RGB, H and O are all exactly 5288×5376 px on the same canvas and the same crop, because every filter went through one registration run. No further alignment is needed; a quick blink of the three is enough to confirm it. Also, the narrowband data are much deeper than the broadband data: about 7.5 h of Hα and 7.2 h of OIII against about 2.5 h per colour channel. That is the argument for letting the narrowband provide the detail and the broadband provide colour and stars.

An overlap to handle first

The Astronomik R filter passes the 656 nm Hα line, and the G filter passes most of the 501 nm OIII line. If Hα is simply added to the red channel, the nebula’s red light is counted twice and the stars get boosted too. The fix is continuum subtraction: scale the broadband channel to the narrowband one using the stars (which are in both) and subtract it, leaving only the pure emission. PixInsight ships a ContinuumSubtraction script and an NBRGBCombination script for this kind of work, along with NBtoRGBStars.

Three ways to merge, and what I would pick

The blending weights, the stretch and the colour choices are artistic decisions, so those will be done by eye in PixInsight. The mechanical parts are another matter: the star removal, the continuum subtraction and the scaling of the channels to a common level can be scripted and run in a batch like the earlier stages, which makes it quick to try several variants. The first attempt at each option is kept at the end of this post, under Paths not taken; the weights and the choice of option were still a starting point there. The next section picks up the real work.

12. Second round: the way I usually do it

The first drafts (kept at the end of this post, under Paths not taken) were stretched too hard: the black was black, and no sky is that black. For the second round I changed two things, and both come from how I normally work in PixInsight.

1. A gentle stretch with the sky at about 0.15. Each narrowband image is stretched only as far as needed, with the dark areas lifted to a background of 0.15 instead of being clipped to black.
2. Stars stretched by the same amount as the RGB image. I auto-stretch the linear RGB in PixInsight, note the settings, and go back to the linear image. StarXTerminator then splits off the stars, and that stars image is stretched with exactly those settings. Here that was a linked auto-stretch with shadows at 0.000387 and midtones at 0.00034, the amount STF gives this RGB (median 0.0005). The stars are merged into the nebula image afterwards with a screen blend.

Option 2 again: HOO, gently stretched, with a few star variants

Hα goes to red, OIII to green and blue, as before, but the stretch is now a gentle midtones stretch on starless images that were first brought to a sky level of 0.15. The two narrowband channels share one curve, with OIII scaled up by 1.8 so the weak line shows. I also blend a little Hα into the blue channel (15 %, not too much), which warms the nebula slightly. Below are four versions that differ only in star colour: the stars image from the linear RGB, stretched by the STF amount, with its colour saturation raised in steps.

The star colours are all small differences at this scale, so here are two bright stars at 100 % for each version:

Option 1 again: RGB boosted, but gentle

Background level: 0.10, 0.125 or 0.15

0.15 can be a little bright, so here are three background levels side by side. The top row is the HOO (option 2) and the bottom row the RGB boost (option 1), at 0.10, 0.125 and 0.15 from left to right. Everything else is identical, including the stars, which are stretched with the linked auto-stretch applied as a histogram transformation.

The narrowband boost raises the dark areas of the RGB image a little, so its lift was corrected for that; without the correction the RGB boost sat about 0.02 above its target.

Checking the stars against the stretched RGB

For the stars I followed the usual routine exactly. The linear RGB gets an automatic, linked STF; PixInsight reports shadows 0.00038690 and midtones 0.00034430 (my own calculation gave the same numbers). StarXTerminator splits off the stars, and the same values are applied to the stars image as a histogram transformation. The halo-reduction option makes no difference to the stars image: both extractions came out identical.

The stars-only version is not brighter than the star in the stretched RGB; its average value in rings around the core is lower (0.63 against 0.79 at the centre, 0.31 against 0.67 at 40 px). What is different is the colour: without the neutral sky behind it, the halo of the stars-only image is a saturated blue ring with a white core, and it ends sooner.

What I see

• The gentle versions look much more like real sky: the dust lanes are dark brown rather than black and the red Hα glow still stands out.
• The HOO has a noticeable teal glow around the bright star in the OIII region, which is real OIII emission near the star.
• The blue halo around the two brightest stars is still there in both options and gets stronger with more star saturation. In the RGB boost the brighter star still has a large blue blob.
• The brightness step along the left half of the top/bottom panel join (see the experiments above) is still in the data.

The first versions are in output/merge2/, and the background variants (option2_HOO_bg0.100…0.150, option1_RGBboost_bg0.100…0.150) and a 0.125 version with more saturated stars are in output/merge3/, together with the stars image from the default extraction. The merge2 files are: the four HOO versions (option2_HOO_userstyle_A…D), option1_RGB_boost_gentle, the StarXTerminator stars image, the STF-stretched stars image and params.json. They are 32-bit XISF in the original orientation, with full-size JPEGs.

13. Third round: the same recipe, in the right order

The second round still had two weaknesses: the stars looked overexposed, and then, once that was fixed, there were far too few of them. The order that works is the one I normally use:

1. Build the HOO in linear space. Hα goes to red, OIII to green and blue, and a little Hα (15 %) is mixed into the blue channel. The OIII is scaled up by 1.8, because the line is weak.
2. Blend in some RGB, still linear. The starless RGB, scaled to the HOO level, is mixed in at 0 % or 30 %, which makes the colours more natural.
3. Stretch that composite with one linked stretch, so it looks natural and the colours keep their relations. The dark areas are lifted to a background of 0.125.
4. Prepare the stars. Stretch the stars image, then apply SCNR (green, average neutral, luminance preserved) to remove the green cast.
5. Add the stars with a screen blend, combine(starless, stars, op_screen()), as the last step.

These previews were made by taking every third pixel, without any smoothing, so that faint stars are not averaged away.

Why the stars looked overexposed

The auto-stretch (STF) is strong: with midtones of 0.00034, every star pixel above about 0.03 linear is mapped to nearly white. The brightest star only peaks at 0.08 linear, so it was not clipped in the data; the stretch clipped it, and about 3,800 pixels ended up pure white. That is acceptable next to an equally hard-stretched RGB, but once the nebula underneath is stretched more gently, every star becomes glaring. The stars need a stretch that keeps the highlights: a colour-preserving arcsinh with the white point at 0.2 linear leaves the bright stars with visible colour (about 410 pure-white pixels remain, which are stars that are genuinely saturated in the data).

Why there were too few stars

My stretched version showed about half the stars of the stretched RGB. The cause was a shadows clip. In the full RGB every star sits on a sky level of about 0.0005, so the STF shadows value of 0.000387 lies below the sky and clips nothing that matters. In the stars-only image the sky is zero, so the same clip removes every star whose own peak is fainter than 0.000387, which is most of the faint ones. The StarXTerminator stars image did contain them. With no shadows clip on the stars image and a strong arcsinh (k = 2000) the stars are back: 8,889 stars brighter than 0.30 in the stars image, against 10,638 for the full STF stretch.

Why a blue star turned green

The brightest star is blue in the stretched RGB, but in the pure HOO it sits in a teal-green glow. The H and OIII images were made starless before the merge (StarXTerminator, then NoiseXTerminator), and the star itself, its spikes and its core are gone. What remains is a smooth, round brightening of the OIII centred on the star, about 10 % above the sky and fading out by about 150 px. It is not in the Hα. StarXTerminator’s aureole removal made no difference at all (identical numbers), so it is not leftover halo that can be removed; it is in the data.

In the HOO the OIII feeds both green and blue, so that glow shows up as teal. Measured as hue around the star (120° is green, 180° teal, 210° blue): the stretched RGB is 196–207°, the pure HOO is 176–189°, and the HOO with 30 % RGB blended in is 195–203°. So the RGB blend brings the hue back, and letting the RGB take over more strongly around the brightest stars (a soft disc of about 90 px, 90 % RGB in the middle) gives 197–204°.

The saturation near the star is still higher than in the RGB (about 0.42 against 0.18–0.30), and the white core is smaller, because the stars are stretched with an arcsinh that protects the highlights rather than the STF.

Files: output/merge4/ has the linear-order HOO with 0 % and 30 % RGB; the versions ending in _SCNR_noclip are the current ones, and HOOlinear_RGBlocalblend_starsK2000_SCNR_noclip is the one with the RGB taking over near the bright stars. The earlier versions in that folder had the shadows clip and are missing the faint stars. output/merge3/RGB_stars_default.xisf is the stars image.

14. Fourth round: a matrix to review

The merged image was good, but it was still missing the last finishing steps on the starless nebula. The order I use is: starless HOO (stretched) → NoiseXTerminator → a very gentle unsharp mask → and only then the slightly saturated stars on top. Instead of choosing the settings blind, I prepared a matrix of 27 full-frame images to review: three NXT strengths (none, 0.4, 0.7) × three unsharp-mask amounts (none, 0.10, 0.20) × three star saturations (×1.0, ×1.4, ×1.8). A review page with 100 % crops sits next to the images in output/matrix/.

Decision: no unsharp mask

I measured the noise in a dark patch of sky (the standard deviation of the image minus a slightly blurred copy) for the combinations that matter:

Even a very gentle unsharp mask turned the sky into salt-and-pepper speckle, made the noise about four times higher than with NXT alone, and also lifted the sky from 0.149 to 0.17–0.18, away from the 0.15 target. It was left out. (If sharpening is wanted later, it would have to be done through a luminance mask that protects the dark sky.)

NXT strength and star saturation

Review matrix: output/matrix/index.html. The 27 full-frame JPEGs are in output/matrix/full/, named nxtNN_usmNN_satNN (NXT ×100, USM ×100, saturation ×10). Since the unsharp mask is dropped, the useful ones are the nine with usm0.

15. Fifth round: noise reduction once, and hot pixels

The order now is:

1. Starless H and OIII from StarXTerminator, with no noise reduction.
2. Starless RGB: NXT (denoise 0.90, detail 0.15, one iteration), then hot pixel detection and repair. This RGB is blended in at the bright stars, as before (RGB blend still in).
3. Linear HOO (H→R, OIII→G+B, 15 % H into blue, OIII ×1.8) with the RGB blended in, one linked stretch, sky at 0.125.
4. NXT on the stretched HOO (denoise 0.90, detail 0.15, one iteration), then hot pixel detection and repair.
5. Stars-only image: arcsinh stretch (no shadows clip), SCNR, hot pixel detection, saturation.
6. Screen the stars on top. No unsharp mask anywhere.

How the hot pixels are handled. A pixel counts as hot when it is brighter than its brightest neighbour by more than six times the local noise (and, for the stars-only image, also more than 2.5 times that neighbour and brighter than 0.03). Only those pixels are replaced, by the median of their eight neighbours; nothing else in the image is smoothed. The data turned out to be very clean:

Out of 28 million pixels per channel, that is a few dozen at most, so WBPP (with its darks and rejection) had already removed nearly all of them. The detector is conservative on purpose: lowering the threshold from six to three times the noise would flag 61 pixels, and to two times the noise 1,116, most of which are noise peaks rather than hot pixels.

Files: output/matrix2/ has six full-frame JPEGs (local30_sat10/14/18 and pureHOO_sat10/14/18, in full/), the matching crops, and the 32-bit XISF files final_local30_sat14.xisf and final_pureHOO_sat14.xisf. The NXT values were set explicitly because a fresh headless PixInsight remembers the settings of the last run, so its “defaults” are not stable.

16. Sixth round: noise reduction before the merge

After looking at the comparison I settled on the HOO with the RGB blended in. One more change to the order: NoiseXTerminator goes on the HOO before it is merged with the RGB, and the RGB already has its own NXT. That also matches how NXT is meant to be used, on linear data. The final chain:

1. Starless H and OIII (StarXTerminator, no noise reduction).
2. Build the linear HOO (H→R, OIII→G+B, 15 % H into blue, OIII ×1.8) and run NXT on it (denoise 0.90, detail 0.15, one iteration).
3. Starless RGB: NXT with the same settings, then hot pixel repair.
4. Merge: the RGB is blended into the denoised HOO (30 %, up to 90 % around the brightest stars), then one linked stretch to a sky level of 0.125.
5. Hot pixel detection on the stretched result.
6. Stars-only image: arcsinh stretch, SCNR, hot pixel detection, saturation ×1.4.
7. Screen the stars on top. No unsharp mask, and no second NXT pass.

Measured on the same dark patch of sky (fine-scale noise, as before), the two orders come out about equal: 0.0049 for NXT after the stretch and 0.0055 for NXT before the merge. So the order is not a big difference in noise. In 100 % crops the nebula looks equally smooth in both; the one visible difference is the OIII glow around the brightest star, which has a fine speckled texture in the old order and is smoother in the new one. I kept it because the denoising now happens on linear data, as intended, and because it is the order I normally work in.

Hot pixels: 5 / 8 / 23 on the stars (R / G / B) and 7 / 0 / 1 on the stretched merge, so the merge needed very little repair.

Files: output/matrix2/v2/ has the full-frame JPEGs (local30_sat10/14/18 and pureHOO_sat10/14/18), the crops, and the 32-bit XISF files final_local30_sat14.xisf and final_pureHOO_sat14.xisf. The linear HOO before and after NXT is output/matrix2/hoo_linear.xisf and hoo_linear_nxt.xisf.

17. Seventh round: separating star luminance and colour

An idea to improve the star colour: treat the luminance and the colour of the stars separately, the way an LRGB image is built.

1. Make a luminance version of the stars (kept sharp, never blurred).
2. Make a colour version (the colour ratios R/Y, G/Y, B/Y).
3. Blur the colour slightly with a Gaussian (sigma 1.5 px; flux-weighted, so the faint halo of a star does not bleed its colour outwards).
4. Raise the saturation a tiny bit (×1.25 around grey).
5. Reduce greens and purples: SCNR on green (average neutral, amount 0.8) and a purple/magenta reduction that lifts green towards the lower of red and blue (amount 0.6); the colour is renormalised so it carries no brightness.
6. Recombine the colour with the original sharp luminance.
7. Screen the result onto the HOO/RGB image as before.

The idea is sound, and it is standard practice. Two remarks: the blur must only touch the colour, never the luminance, or the stars soften; and the reduction of purple needs its own step, because SCNR on green does nothing about magenta fringes. The hue of the star pixels that carry colour shows what changed:

What changes: the purple tinge on the diffraction spikes largely disappears, and the spikes become cleaner blue and orange. The purple share of the star pixels with colour drops from 3.4 to 1.3 %. The greens were already gone after SCNR. The stars stay as sharp as before, since the luminance is unchanged. The differences are subtle in the star field and at this scale; the diffraction spikes of the brightest star are where it shows. Not yet decided: whether to adopt it, and the exact values (blur sigma, saturation, purple amount).

Files: output/matrix2/v3_starcolour/ (final_local30_yourrecipe_stars.xisf, the full-frame JPEGs and the comparison image); script docs/scripts/03_hoo_rgb_merge/starcolour.py.

18. Eighth round: adjustments by hand on the starless image

Before the stars go back on, the starless HOO+RGB image (output/adjust/HOORGB_starless_stretched.xisf, stretched, NXT on the linear data, hot pixels repaired) was adjusted by hand in PixInsight. This is the one stage that is not scripted. The order was: curves, then histogram, then unsharp mask.

The curve points are read off a screenshot, so they are approximate; the histogram and unsharp-mask values are exact. The saved result of these three steps is what the stars will be screened onto.

The stars added, and what the adjustment did to the noise

The adjusted starless image was saved over the original file; a backup copy is output/adjust/HOORGB_starless_adjusted_BACKUP.xisf. The stars were then screened on with combine(starless, stars, op_screen()), in four versions: the previous stars at saturation ×1.0, ×1.4 and ×1.8, and the luminance/colour version. The results are in output/adjust/final/ (32-bit XISF, original orientation, plus rotated JPEGs and a crop comparison).

Measured against the version before the hand adjustments:

So the unsharp mask (amount 0.76, sigma 1.3) brings out structure and also amplifies the noise by about a factor of three to four; it is no posterisation, since the file has hundreds of thousands of distinct levels. The sky level also moved from about 0.14 to 0.10. Possible ways to keep the sharpness and lose some of the grain: a lower amount (for example 0.3–0.4), a larger sigma, or a lightness mask so that the smooth sky and glow are protected. The versions without any unsharp mask are still available.

Two things to watch (before the result was checked): the histogram step clips 0.2 % of the pixels in the shadows and 0.1 % in the highlights, and the sky level drops from the 0.125 it was built at. And the unsharp mask here is much stronger (amount 0.76, sigma 1.3) than the 0.10–0.20 tried earlier on the whole frame, which already put speckle into the dark sky. This time it is applied to the lightness of an image that already has NXT and a contrast curve, and the speckle may behave differently, so the dark sky is worth checking at 100 % before the stars are added.

19. Decision log

Astrophotography is a matter of experimenting, so here is every decision taken since WBPP, with the reason.

Not yet decided and left open on purpose: NXT strength (0.4 or 0.7), star saturation (×1.0, ×1.4 or ×1.8), and whether to fix the brightness step along the panel join.

Still open: the star saturation (×1.4 is used for now), the slight brightness step along the join between the top and bottom panels, and the strong teal OIII glow around the brightest star on the left.

20. Lessons for scripting PixInsight

• Headless works. A second instance started with PixInsight -n --automation-mode -r=script.js --force-exit runs a script and exits, while the GUI instance stays untouched.
• Add #engine v8 as the first line for anything that uses modern JavaScript (classes, #include of the stock astrometry scripts). Without it, -r runs the legacy engine and such scripts fail silently: no output, no file, no error.
• Capture the console. Wrap a process call in Console.beginLog() / Console.endLog() and write the text to a file; that is how the real SPFC error message (“at least 5 items are required…”) became visible.
• Union-mode StarAlignment cannot run on files. Register/Union modes only work on open views, which is why the reprojection route through the plate solutions was used.
• Read back what you wrote. Per-image statistics before and after each step and a before/after crop of a known-bad spot caught more problems than any log line.
• Do not reuse a full-image STF on a stars-only image. The shadows clip assumes a sky level that the stars image does not have, and silently deletes the faint stars.
• PixInsight’s AnnotateImage can be driven headless. Define USE_ANNOTATE_LIBRARY and SETTINGS_MODULE before including the script, build an AnnotationEngine, and call Render(). It needs an astrometric solution. The final image had none, so the solution of the plate-solved RGB (same pixel grid) was copied over. The fast-rotation process drops the solution, so for the 180° rotated copy the linear part of the solution was transformed by hand and checked against a known star (within 0.1 px).
• One folder per stage. It made it trivial to compare stages and to restart from any point.

21. Caveats and what’s next

• The border-star scan found 55 locations; the star masks come from an earlier, less sensitive pass that covered roughly six stars. I verified the ones I looked at, but not every one of the 55.
• SPFC and MGC changed the pixel values very little. I confirmed they ran correctly, not how much they improve the result.
• The brightness step along the left half of the join between the top and bottom panels is still in the data, and it is faintly visible in the final image.
• The strong teal OIII glow around the brightest star on the left is real signal in the data; its origin (emission or scattered light) was not determined. The RGB blend only moves it part of the way to the RGB colour.
• The annotation uses only the linear part of the plate solution (no lens-distortion terms) after the 180° rotation; positions are good to a few pixels. Only three catalogue objects fall in the frame (IC 5070, 57 Cyg, 56 Cyg). The Moon in the size comparison is scaled to 31.1′; on the date of the photo (25 September 2026) the real apparent size was between 30.7′ and 31.6′ (the exact time of the capture was not available), so the comparison is accurate to about 1.5 %.
• Star saturation (×1.4 is used for now) and the exact RGB share of the blend were chosen by eye from a small set of options.
• The 100 % crops and previews in this post were checked on a few regions only, not across the whole frame.

The next stage is the finishing: final colour and contrast adjustments on the merged image, a decision on the panel seam and the OIII glow, and an export. The files to start from are listed at the end of section 17.

22. Paths not taken

These did not make it into the final pipeline, but they are worth keeping: the very first exploratory round, before the real iterative process (rounds 2 onward) took over, and a list of smaller options that were tried or considered and set aside. Nothing here is part of the workflow above.

The three merges: first drafts

Astrophotography is a matter of experimenting. These were the first attempts at each merge option, kept here as they were; they were stretched much harder than I like, and the next section redoes two of them the way I normally work.

All three options were built from the same ingredients, so they can be compared fairly. The starless/stars split was done with StarXTerminator (with aureole removal switched on for the RGB, to take the big halos out of the starless image), followed by NoiseXTerminator at 0.6 on each starless layer, while the data were still linear. The continuum factors were measured from the stars themselves, about 6,000 unsaturated star pixels: Hα/R = 0.395 and OIII/G = 0.484. Stars were stretched separately and lightly, then screen-blended back on top of every variant.

Option 1 · RGB boosted with continuum-subtracted narrowband

Option 2 · HOO starless blend with RGB stars

Option 3 · Narrowband as luminance, RGB for colour

What I saw, and what still needed work

• A brightness step across the left half of the join between the top and bottom panels. It is visible in all three results under this stronger stretch, and it comes from the mosaic itself. There the two panels overlap by only a few pixels, so the merge cannot smooth out the sky-level difference between them (I measured about 15 % earlier). Fixing it means balancing the sky level of the two panels along that join, or reworking how those two panels are blended.
• Blue halos around the two brightest stars. Removing aureoles made them much smaller than in my first attempt, but they are still bluer and larger than in the red channel. A second pass with reflections removed, or a local colour correction, would tame them.
• These are first drafts. The stretch is a simple colour-preserving one with a black point at the 4th percentile, and the boost weights, the OIII scale and the luminance mix are my own choices, not tuned by eye. They are meant to show how the three options differ.

All intermediate and final files are in output/merge/: the starless and stars images, the three results as 32-bit XISF (option1_RGB_boost.xisf, option2_HOO_starless_RGBstars.xisf, option3_NB_luminance.xisf) with full-size JPEGs, and a small JSON file with the weights used.

What was tried or considered, and not chosen

Not yet decided and left open on purpose: NXT strength (0.4 or 0.7), star saturation (×1.0, ×1.4 or ×1.8), and whether to fix the brightness step along the panel join.