Wednesday, August 26, 2026

Finally, A Few Nights Under the Stars

August 19

The router I talked about in my last post worked well, and I should be able to monitor my imaging remotely from now on. Other things happened this night that made it less than successful.

Imaging started with NINA doing a slew, center and rotate, or trying to. I use NINA's manual rotator, which has always worked well for me in the past. This night it did not. My first rotation resulted in NINA requesting an even greater rotation in the same direction, and so did the next. I didn't want to sort it out, the image wasn't going to amount to much given the omnipresent overhead smoke, so I redid the sequencer script to just slew and center and pause so I could do a rotation by eyeball. Not at all optimal but it started the collection of light frames.

After a while I noticed that the images were coming in fuzzy-looking. It wasn't a focus issue; the stars were sharp but diffuse. It was a very dewy night so that was my first guess. I put everything on pause and looked at the objective. It was dry. I could have examined all the other optical surfaces but instead I looked at the camera settings. The camera was at the correct temperature (-5 C) but the dew heater on the sensor window was off. I set it back on and decided to wait and see if it would clear; I could monitor this on my tablet indoors. The images slowly improved, but I was running out of time. I decided to call it a night and started breaking down the setup.

The next afternoon I found that there was a setting in the manual rotator that allowed me to reverse the sense of corrections. Having it set the wrong way would have produced exactly the symptoms I saw the night before, so I was confident that things would work next time. 

Both issues were probably a consequence of my having to restore NINA after a full lobotomy of my laptop earlier this year; the clean reinstall had put everything back to default settings.

August 20

So, two problems, both probably fixed, and a clear night. The moon was at first quarter and there was an too much overhead smoke, but I wanted to see if things were fixed so out I went to the club's Eagle lake site. Everything worked and I decided to do a quick and dirty two-pane mosaic of the Veil Nebula. I had planned for a minimum of two hours, one for each pane, and started collecting light frames. The northern pane finished with 60 x 60 s frames, then the sequencer did its thing and went to the southern pane. 45 frames into that the clouds swept in and the night was over; the second pane got short-changed. 

An hour per pane was not really enough to for a decent image, but it did give me data to practice mosaic-making. Here is the result:

Veil Nebula 2-Pane Mosaic (1/2 scale, click to enlarge)

Comments:
  • This needs more time on target!
  • Shooting 60 s subs really helps preserve star color and allows essentially total eradication of satellite tracks, Yay!
  • I would like to thin out the stars better during the next reprocess.
  • I don't know if the variations in background brightness are representative of reality. In particular, that lighter area to the right of the Western Veil: is it real or is it an artifact of how I flattened the field? It compares very well to this image in which it shows structure. Since the veil is often imaged using LP filters, generally colorless features might be taken as light pollution and filtered out.
  • The image was calibrated using dark frames, flats, and flat darks. Lights were dithered, but not sufficiently for drizzling. I had about a half dozen runs at processing this before I found a good way to merge the panes. The workflow I found that worked best is given below.
  • Can you find the two seams? I can't despite knowing right where they are!

August 22

The next night was cloudy, but the one after that was clear. The moon was now two days past first quarter, and there was still too much smoke aloft; the sky looked very bright. My first target (Sh2-114, the "Flying Dragon Nebula") was such a lost cause that I stopped collecting data early hoping to have enough time for a quick and dirty image of the Cocoon. I got 45 x 60 s of light frames: here's how that turned out:

Cocoon Nebula (1/2 scale, click to enlarge)

This would be gorgeous from a dark sky site with no moon and no smoke! There's a lot of entrained gas/dust around the dark lane that extends to the left, and it's only hinted at in my image.

One other glitch did arise this third night of four. The mount stopped unexpectedly well before it should have and signaled it had reached its safe limit. The next day I set it all up and made sure the mount had proper limits and was also correctly configured for meridian flips. I also made sure NINA was ready for flips, too. I'm going to attribute the glitch to the usual guilty party: operator error.

Verifying the change will need to wait for the next new moon, though. I'd also like to see if my setup can do a proper meridian flip.

Mosaic Workflow

This was all performed within PixInsight 1.9.4 build 1695, and I've provided most of my non-default settings for each process or script. PixInsight settings are meant to be explored, and you should find those that work best for your imaged objects and esthetics.

If you don't have the same scripts and processes installed as I use here, you will need to obtain them or find suitable substitutes. I also assume you have at least a rudimentary knowledge of PixelMath; there are two points at which PixelMath will come into play.

Calibration

WeightedBatchPreProcessing (WBPP) is used to do the calibration, and for these images I used the default settings. When it finished I had two master light frames, Pane1 and Pane2. I chose to have WBPP do autocropping even though it can insufficiently crop out edges with weak signal. By the way: I've now stopped using bias frames as part of calibration; they're mainly useful for scaling dark frames with mismatched temperature or exposure time, and I never have those.

Linear Image Cleanup

Run BlurXterminator to take care of any aberrations. 

Use the ImageSolver script to solve the images and give them the solutions.

The Veil field is packed full of stars to the extent that I considered using DynamicBackgroundExtraction to be iffy, so I used AutomaticBackgroundExtractor with degree set to 1 and the subtraction as the correction. Why degree 1? This eliminates the mean and gets rid of the overabundance of green often seen in One-shot color masters along with the field-uniform light pollution. During relatively brief imaging sessions, the light pollution may also have a significant spatially linear component, so that's removed, too. 

Preparing and Merging Panes

I use star alignment to create registered panes ready for merging. There are other ways to do this, but it worked best for me for this particular data. This mainly entails creating an image full of synthetic stars that is larger than the eventual mosaic will be and then registering the Panes to it.

I make a rough guess at the RA and DEC of the eventual mosaic's center. With only two panes it's simple to just average the RA and DEC of the panes. I also guess the eventual size of the mosaic in pixels, and add some "elbow room" to make sure the panes will fit into it with black margins. The center coordinates and estimated dimensions are used by CatalogStarGenerator; it produces a star map image named CatalogStars. If this image appears black to you, apply autostretch.

As noted above, the automatic crop feature of  WBPP sometimes leaves some data-poor edges uncropped. Use DynamicCrop to trim these off. Note that this destroys the previous solutions so we will need to re-solve as needed. 

The pane backgrounds must be matched, so use DNALinearFit. This can be obtained at David Ault's website, and more specifically here.

Use StarAlignment to register the panes (the correct settings are reference image = CatalogStars, Registration mode = Two-Dimensional Surface Splines, Radial basis function =  DDM Thin Plate Spline.) This results in two registered panes.

Next is more cropping! Use PixelMath with one line max(pane1,pane2) where pane1 and pane2 are the identifiers of the two registered panes. Remember to tell PixelMath that you want to create a new image, not overwrite one! This will produce a quick and dirty mosaic image. Use DynamicCrop to crop away all the black portions of the quick mosaic, then apply the crop to both registered panes. Save these newly cropped images.

Merge the newly cropped panes using GradientMergeMosaic with type of combination = overlay, Shrink radius = 1, Feather radius = 10, and Blackpoint = 0. If you see pinched stars, you can rerun it with an increased feather radius or you can black out offending stars. At this point you will have a merged mosaic image we will call MyMosaic.

Traditional Single-Pane Post Processing

At this point processing follows your usual workflow for a single linear image.

Do serious color calibration by using ImageSolver followed by SpectroPhotometricColorCalibration.

Do serious background extraction by running SpectroPhotometricFluxCalibration followed by MultiscaleGradientCorrection. I use MGC as it usually gives nice results.

Now you have a choice to continue post processing on the mosaic as it is, or to split it into starless and star images. I went with the latter by applying StarXterminator.

At this point I did see some mild star pinch effects in the starless image, but decided that they weren't worth correcting in this preliminary processing. If I had wanted to correct them I would have just gone back to the application of  GradientMergeMosaic and increased the setting for feather radius or blacked out some stars.

Because I was seeing some residual green in the star image, I applied  SubtractiveChromaticNoiseReduction.

The star image I basically left unchanged.

Stretching

Starless image: I used MultiscaleAdaptiveStretch with target background = 1.25 and scale separation = 256.

Stars image: the usual STF-HT method wildly overstretched the stars, so I used StarStretch with the stretch amount = 4 and color boost = 2. The stretch amount is where you can get very fiddly. It's worth exploring the entire stretch range of 4 to 6.
Combine Starless and Star imagesCombine the nonlinear starless and star images with a PixelMath line ~((~$T)*(~stars)) where stars is the identifier of the stars image.

Final Tweaks

At this point you're free to adjust saturation, apply curves, get fiddly with dynamic range; it's up to you.

-------------------------------------

Next time: imaging at the September new moon. Will it be clear? Will it be smoke-free? Will I be local or camped at Lac qui Parle state park? 



Tuesday, August 25, 2026

Setting up Remote Desktop on a Windows 10 Home Version Laptop

If you've ever camped at Minnesota's Lac qui Parle state park after mosquito season has begun, you know one thing for certain: the park has mosquitoes. Lots of them. Gnats, too. 

So while you're imaging it would be nice to be in a place of relatively safety; it's not fun having your blood simultaneously drained and replaced by several diseases. Some of you have RVs with doors the mosquitoes haven't yet learned how to open, so you're good. Me, I have my car, a 10x10 netted enclosure, and my sleeping tent. Not quite as comfy as an RV, but it serves.

Regardless of our particular camping style we need something that will let us talk to our gear from our safe places. In the past I've done this using a USB data cable (a tripping hazard and possibly unreliable). If there's a local wi-fi network available that's much preferred. The unfortunate truth is that, at the time I'm writing this, Lac qui Parle does not have any wi-fi at its campground I can tap into. Nor do the remote places where I like to image: the Nebraska and Iowa star parties, and a friend's semi-rural back yard.

The good news is that Chad over at Patriot Astronomy has a series of instructional videos for obtaining, configuring, and using a system that will act as a wi-fi network and enable you to use a mobile device to control your gear. Basically you connect your mount-attached minicomputer to a stand-alone wi-fi router, and then connect your mobile device to the router and remote desktop into the minicomputer. Easy-peasy.

But not if you're me: I have a couple of problems.

PROBLEM 1: Chad makes the reasonable assumption that I am using a Windows 11 minicomputer. Instead I have an old Windows 10 Home version laptop that sits on a table near my gear. Win 10 Home lacks the remote desktop feature that will be needed. My laptop is fine, and I really don't want to drop $600+ on a new one just now, so I'll need to find something to give me remote desktop access. This means finding software for the laptop and my Android devices.

PROBLEM 2: I don't have a standalone wi-fi router.  Chad recommends a GL.iNet GL-AR300M16-mini) that's mainly suitable for an area the size of hotel-room, which is fine if it can push signal though your RV's cabin wall or the distance to my tent. (GL.iNet also sells one that has dual antennae for a little better range. If you decide to buy the router Chad suggests, go to his YouTube video and use his Amazon link to make the purchase. That way he gets a little slice of the action.)

I solved problem 2 by rescuing my old ASUS RT-N12 D1 router from the family Goodwill donation pile. The ASUS is nice because it runs off 12 VDC using a standard power jack, only needs about 1.7 W, and provides 2.4 GHz wi-fi. That last bit is good because 2.4 provides better range. Despite being 2013 technology the ASUS was up to the task. You buy this router used on eBay for under $20.

I should add that technically the router can double its range if it sits halfway between my laptop and my safe area. It will just need a dedicated power supply like a small 12 V lithium battery. A single 7 Ah 12.8 V battery can power the ASUS for over 50 hours.

If it has a failing it's that it is not rated as waterproof. All its air vents are on the bottom, though, and I doubt a heavy dew will bother it.

The mighty ASUS RT-N12 D1 router

As for software, searching with Google AI mode is wonderful -- if you like having to pick between options. Word your question in different ways and you'll get different recommendations. When it came to remote desktop software for Win 10 it gave me a choice of titles, Real VNC, UltraVNC, NoMachine, and TightVNC. Let's take those in the order I tried them.

Real VNC. The "free" version turned out to be a 14 day trial that would require purchasing a plan to continue using -- making it a non-starter.

Ultra VNC. It was impossible to find the correct download link among all the ads for scams. It wasn't just me, their forum was loaded with similar complaints. I eventually clicked a bad link and had my browser hijacked by a phony shopping site. In other words, DO NOT USE Ultra VNC.

NoMachine. This one seemed promising at first. I installed it on my laptop and my Android tablet. This was said to be free for personal use but it insisted on my setting up a no-cost account with them in order for it to run. I created an account but regardless of how I tried to get it running it insisted that I enter a license key which I did not have. Google AI said this was a problem that was sometimes solved by creating a local user on Win 10, so I did that, and it did not help. At this point I'd wasted the better part of a day beating my head against NoMachine, so I said No to NoMachine.

TightVNC. This is open source so it doesn't keep trying to get you to sign up for a plan; it installed and ran simply. I wish I had started with it.

For the Android side, there were two suggestions, VNCViewer  and avnc. I could not find VNCViewer in the Android play store, but avnc was there; it installed and worked nicely. avnc is also open source.

Adding a stylus and small bluetooth keyboard gives me convenient and accurate input control. Configuring everything mainly involved setting up passwords for protection. Using built in password managers really helps!

What this means is that my laptop will now sit out by the telescope with the ASUS next to it. I will sit in my screened shelter, or maybe just nap in my tent. The only times I'll be out feeding the pests will be when polar aligning, a meridian flip is happening (must watch those cables!), or when the time comes for shooting flat frames. Hopefully when those last two happen it will cool enough that the bloodsuckers will have already called it a night.

On its first night in the field, the ASUS bridged the 140 feet and one outside wall to connect laptop to tablet; 20 feet from laptop to router, then another 120 to the tablet. 

----------------------------

Trivia Time

I hope the name Ed Ting means something to you. Starting around 2000 he started reviewing telescopes...lots of telescopes! You can still read all his reviews here, and see more modern videos here. Many of us found his reviews quite educational. In my case his review of the INTES MK67, though short, influenced me just enough to buy one.  Alas, that's one of my "I wish I never sold it" scopes now. 

But that's not why I mention him. Did you know that he also solves New York Times crossword puzzles? And that he sometimes comments on them in Rex Parker's NYT Crossword Puzzle blog?

Wednesday, June 17, 2026

Opening Night 2026: First Light for a New Camera; A few Glitches and One Dumb Mistake


 June 14, 2026. 

It was a long wait but finally everything aligned: personal availability, cloudless sky, hardware readiness. The location was the M.A.S.'s Eagle Lake facility. The goal was to see if everything worked well. I think it mostly did, but there were several distinct glitches.

First was PoleMaster. Normally PM delivers amazingly accurate polar alignment quickly and easily. When I compare first and last frames of a full imaging session it's almost always difficult to see any field rotation due to misalignment. This night, at least for a while, it misbehaved.

Because of my laptop's problems (see previous post) I had to reinstall PM, and I used the current version, an update from what I had been using. This new version seemed not to want to run for me. Four times it failed to generate the celestial pole marker needed for adjusting the mount's polar axis. I finally got it working by using very large calibration rotations. This never happened with the older version, so I've stepped back to that.

Once the mount was polar aligned, it was time to calibrate PHD2. I used the Calibration Wizard; it slewed the scope to its preferred orientation and did its thing. At calibration conclusion it reported the quality of the calibration was poor and that it should be repeated after changing some of the settings. This is something I'll have to research for next time. 

As it turned out, the stars in all 53 light frames were nice and round, so PHD2 seemed to be working fine.  PHD2 reported sub-pixel guiding error. Maybe with the focal length I was using (about 387 mm) it's not a discernable problem. It's worth noting that during the 2+ hours of imaging there should have been approximately 8 dithers and 5 autofocuses. PHD2 behaved perfectly across all of those.

The next problem was an odd behavior of NINA's manual rotator. It was giving wildly varying recommended rotations, as if it were making random guesses.  Plate solving was giving correct results and the mount had slewed and centered the target without any issues. After a few tries I simply did manual rotations until it looked about right and finished with a final slew and center. This was fine for a simple single-session image, but won't do for collecting multi-session data or data for a mosaic. I have no idea what might have caused this problem.

All those things were eventually overcome, but I still managed to mess up the image!

At about 1:20 AM a band of high clouds came through and I decided that rather than wait for it to clear again, I would call it a night.  Then in my impatience I decided to defer shooting the flats until the next day. Big Mistake! There was a largish dust mote on the flats that ended up being misaligned when I finally shot the flats. My finished image has a nice dark crescent on one side of that mote, and a light crescent on the other. 

It's not much of a loss: I knew going into the evening that the image was not going to be a "keeper." I was imaging into the sky glow over Minneapolis and 106 minutes of total exposure was inadequate for the object (Sharpless 129). 

A so-so image ruined by awful flatting; note the lovely donut just below center

On the plus side, I did learn how to process one shot color data in PixInsight. And now I have a NINA sequence for shooting flats so I won't have an excuse to skip that. 

The July new moon less than a month away!


Saturday, June 13, 2026

Catching Up

It was an interesting spring!

January and February

Cloudy and cold. But that's what late winter is like here, so it was hardly a surprise.

Mid march into early April

Covid. Yes, after six years of somehow avoiding the thing, we're no longer possible Novids. My wife came down with it first, and because she wasn't showing the classic symptoms we assumed it was just a head cold. Then five days after she started showing symptoms it was my turn, and it was a fun five day run with it. I had the latest variant's calling cards: minor fever and wicked sore throat. Despite not resorting to the Paxlovid thing by day six I was feeling pretty much back to normal. Unfortunately I kept testing positive for a couple of weeks longer, keeping me in a self-imposed quarantine because I wouldn't wish that sore throat on anyone!

Mid April and May

I splurged and purchased the ASI2600MC, the near-identical twin to my MM model. This year I'll concentrate on imaging with it on my FSQ-106EDX4 and a couple of cameral lenses. I'm curious to see how the results compare with LRGB imaging.

A head cold forced me to cancel new moon reservations at Lac qui Parle state park. I missed one beautiful night of the three I had reserved. Two were cloudy.

I did manage to get out one night and test my backfocus adapters for the new camera. The results were great. Field tilt was essentially zero so the camera has the usual fine ZWO quality. I always use at least one pass of BlurXterminator while processing and its default values produced pinpoint starts all the way to the image corners. Can't really ask for more.

There was a minor disaster when my imaging laptop's Windows10 suddenly decided I needed to log into it and would not accept any of the passwords I had for it. After much research I found that my only recourse was to wipe the machine and reinstall Windows. This meant I lost all my imaging configurations. 

Several days of restinstalling software ensued. This wasn't a totally bad thing, as it fixed a problem I was having with getting NINA to recognized my mount. In fact, I can now use NINA's connect all button without it squawking about some sort of ASCOM error.

June

The last thing I needed to restore was the autofocus parameters for NINA; I've now completed that for imaging with the FSQ plus its focal reducer and with my Samyang 135 mm lens. 

Tomorrow night is forecast to be clear, so I'll be going out someplace modestly dark and imaging Sh2-129. Assuming that happens, I'll have the results next time.

Sunday, March 8, 2026

A Visual Aid to Understanding Backfocus; Revisiting My Adapters for a New Camera

Here's a set of several slides I made that helped me understand backfocus. Maybe you'll find them useful, too!

Basic prime focus imaging, where the objective directly forms an image on the camera sensor, relies on placing the sensor at the focal plane of the objective. To do this we need to know where the focal plane is relative to the optical tube assembly. In a refractor or reflector the focal plane location can be measured from the camera end of the focuser's drawtube when it's fully retracted, also called the reference point (Figure 1, top). For my FSQ-106EDX4 the focal plane is 178 mm beyond reference point. 

Figure 1. Definition of backfocus

I will call the distance between the reference point and the focal plane the True Backfocus. I call it "True" because it's commonly a number you get from the manufacturer, so you know it's realiable. The FSQ focuser travel is a very modest 30 mm (Figure 1, bottom). Notice that when the end of the drawtube is at the middle of its travel range the distance from it to the focal plane is 163 mm (Figure 1, middle).

Now examine Figure 2, where I've added all the hardware that sits between the end of the drawtube and the sensor. The purple adapters are supplied by Takahashi; they are four adapters that connect the drawtube to the manual rotator and extend a nice wide optical path out to a female M54 thread. Their total backfocus is 110.2 mm. These adapters are between the end of the drawtube and the camera sensor, so their backfocus must be included in the total backfocus. You may have something analogous to them for your telescope, so check your scope's documentation! 

The green adapters are the items I add: In my case they're mainly working the M54 down to an M42 male thread that will  connect with the EFW or camera's tilt plate.  In your case you may also have an OAG, a electronic field rotator, or a filter tray in this green area. Again, since these all sit between the drawtube end and the camera sensor, their individual backfocuses must count toward the total backfocus. 

The total backfocus will be the distance between the end of the drawtube and the sensor regardless of the drawtube's extension, as shown in Figure 2.

Figure 2. How Practical Backfocus positions the sensor

Figure 2 (middle) shows the drawtube half extended, and because I've chosen the total backfocus "correctly" the sensor is at the focal plane. So what's the numerical value of the correct total backfocus? It's going to be the True Backfocus minus half the drawtube's travel.  I'll call this value the Practical Backfocus. The following two statements now apply:

Practical Backfocus equals True Backfocus. minus half the drawtube travel 

The total backfocus of all the items sitting between the end of the drawtube and the sensor should equal the Practical Backfocus

It's that easy! Just add up all the backfocus values of your adapters and spacers (and camera, too) and make sure it equals the Practical Backfocus.

This is exactly how Takahashi calculates "best" backfocus (see steps 1 and 2):

Imagers should supply adapters with the following total backfocus (Numbers for my FSQ are in brackets):
  1. Maximum focuser back focus [the distance from the end of the fully retracted metal drawtube to the focal plane, 178 mm]
  2. Minus ½ focuser travel [half of 30 mm, or 15 mm]
  3. Minus necessary telescope accessories [the four adapters (645 RD, CAA Rotator, Aux Ring (S), and Coupling) provided by Takahashi that have a total backfocus of 110.2 mm]
  4. Minus Camera backfocus [17.5 mm for the 2600's with their tilt plate attached, 12.5 if it isn't]
Why is the Practical Backfocus the "best?" Mainly for safety. If you're using motorized focusing and autofocusing software, the drawtube will move in and out during autofocus. Being in the middle of travel makes it unlikely those motions will ever carry the drawtube to one of its stops, making the autofocus fail and possibly damaging your motorized focuser.

Let me be perfectly clear about the subjective nature of the Practical Backfocus. Any backfocus that allows your sensor to get to the focal plane is perfectly fine, although it may not work well with autofocusing. 

This raises an interesting point: if your autofocuser movements away from focus are smaller than half the focuser travel, you can increase backfocus beyond Practical Backfocus by adding an extension tube. As a result the drawtube be less extended when focus is reached and possibly reducing dreaded "drawtube droop." This might be an adjustment that's worthwhile if your focuser has a great deal of range that you don't need.

Again using the FSQ as an example, if I know my autofocuser will never move the focuser more than 3 mm in and out, I can "live dangerously" by adding an extension tube that has a backfocus of 12 mm (half the focuser travel  minus 3 mm).  This effectively makes the total backfocus 175 mm, and the drawtube now needs only extend 3 mm for the sensor to be at focus. (3 mm + 175 mm = 178 mm, the True Backfocus. Effectively I've brought the sensor 12 mm closer to the OTA.)

I could also reduce the Practical Backfocus 12 mm giving me a total backfocus of 151mm. In this case the drawtube would need to extend 175 mm for focus, but I can't think of why that might be desirable.

-----------------

If you're using a focal reducer, tele-extender, or flattener, things may be different (Figure 3). The reference position is now a mark on the reducer or is perhaps the plane of its back plate; be sure to check its documentation. 
Figure 3. Reducer backfocus

When focus is correct the focal plane of the reducer will be the manufacturer-specified distance from the reference position. The total backfocus of your adapters and camera will need to equal or be very close to that. Most imagers try to get within 1 mm of the correct value. Given the software that now exists (I'm looking at you, BlurXTerminator) it's possible to correct star distortion caused by backfocus error if it's not too great.

For reducers et al., Practical Backfocus = True Backfocus. 

The CR 0.73X reducer I use has a required backfocus of 72.2 mm.

If you image using any of the following you may need to match a specified backfocus:
  • Camera Lenses
  • Telescopes with built-in flatteners or reducers
  • Coma Correctors
  • RASA astrographs
Anytime you put something that bends light into the optical path, read its documentation to see if it requires a specific backfocus.  

Note that in these cases we can't play around with the Practical Backfocus as we did for prime focus imaging. When using a reducer et al. with its own True Backfocus, you will need to get the total backfocus as close as possible to that -- within practical limits. 

------------------------------------------------ 

Several years ago I went into gory detail about what adapters were needed to connect my ASI𑽈2600MM and Canon DSLR to my FSQ-106EDX4 and Canon EF lenses. I've been imaging only LRGB since then and the adapters have worked fine. I'm going to switch to OSC this year despite this.

No, I'm not getting lazy in my advancing years. When I started CCD imaging it was almost all narrowband because that made it possible to image from my Bortle 7.5 backyard.  Back then I had sufficient open sky above me, but in the last fifteen years the trees have eaten up the sky. All I have now is the area around the north celestial pole, and I can tell you --- in narrowband, it's not exactly an area that's rich in narrowband targets!

I now travel to open sky sites where the sky is usually Bortle 5 or darker and I can LRGB image. Technically I could be using OSC! OSC data is easier  to process than combining three or four channels. So, ok, maybe I'm a little lazy.
So shortly I'll be diving into OSC by buying a ZWO ASI𑽈2600MC, the almost-identical twin of my 2600MM. I am going to hold onto the MM, though. I really do like its higher sensitivity and greater effective resolution, particularly when imaging with my FSQ at f/5. I'll definitely do some L-OSC imaging, and may want to augment some OSC images with H alpha. 

As in past years my primary imaging optics will be the Takahashi FSQ-106EDX4 in its native f/5 mode, the FSQ with a 0.73X focal reducer, and my Canon EF compatible lenses (at focal lengths of 200, 135, 70, and 50 mm). 

And now on to the adapters! First, some notes:
  • The FSQ modes need new adapters because (a) I won't use the 2600MC with an EFW and (b) When I did this last time I missed adding the Takahashi Rotator Adapter's 10 mm backfocus. This error seemed not to affect image quality in the least, and was possibly even beneficial (see earlier discussion)
  • I have an urge to reduce the vignetting when using the FSQ so I'll use M48 when possible instead of M42 adapters. Even better would be to use M55 extensions with the CR 0.73X reducer -- if I could find any
  • I've removed the M42 adapter from my Samyang and restored its original Canon plate, making it compatible with my other lenses. This will let me use the 2600MC with all of them
  • Modes that use the EFW have an added 0.6 mm (about 1/3 of the filter thickness) backfocus
  • The FSQ prime focus modes are within 1 mm of their Practical Backfocus value. They differ from each other by 0.6 mm so that they'll share the same focuser setting
  • There's a huge number of ways to combine adapters to get these results; what I show here is only one of them
  • Most (if not all) the items in "My Adapter" green come from AgenaAstro; The exceptions are noted below. A few are so old they may have been found at an archeological dig
Here are my adapters for each mode: 

Figure 4. How I'll achieve the desired backfocus

That rightmost mode (2600MM + EFW + Canon lens) is a very tight fit.  I found the thin Canon-M48 adapter on AliExpress; the thin (2 mm backfocus?!) M48 to M42 adapter is coming straight from Astromania Optics. Will it work as advertised? And if it doesn't, will BlurXTerminator be able to correct the distortions? Oh, the suspense!

Of course my optics may not exactly match Takahashi or Canon specs, which will only be important when imaging with the reducer or lenses. There may be some tuning necessary, so field testing will be high priority when the weather finally warms up.

And finally, yes, that's a lot of different adapters/extenders/spacers!


--------------

A fiscal side note: When I needed to connect my old SBIG ST-8300 to a Canon lens in 2012, the SBIG adapter cost $295 (this is also the current price!). this year I'll pay only $59 for the ZWO Canon-M42 lens adapter, and the AliExpress Canon-M48 adapter was even less at $35. Am I justified to feel that the SBIG adapter may have been a bit overpriced? 



Sunday, November 30, 2025

Using PixInsight PixelMath to Correct a Flat Frame Issue

In my last post I talked about a problem I had with flat frames collected at f/2. To correct the issue I used the processes AutomaticBackgroundExtraction and GradientCorrection. This worked very well for two of my images, but I recognized it might not with the huge nebula Sh2-264, (AKA the Lambda Orionis / Angelfish Nebula).

I tried the ABE+GC method on this and it failed spectacularly by obliterating the eastern half of the nebula. So my approach will instead be to use a method that employs PixelMath and an ad hoc model of the donut hole.

Here is the hole as seen in the green master frame from one the other images collected the same night:


Green Master Frame with the donut at center in all its glory


This donut appears in the master green frame of Sh2-264, if not as prominently. So I'll use the above photo as the basis for the correction's structure. It's worth noting that the master frames have already been flatted, so either my system is dust-free, or the flatting took care of any dust donuts. What I'm about to do is apply a simple correction that's limited to the central area of the image.

At the very center the brightness doesn't seem diminished and no correction is needed. As distance from the center increases the distortion progressively darkens to form a ring, then quickly brightens again. It's this ring that must be brightened. Because I'm correcting the master linear frames I'll use simple multiplication of the existing pixel values.

Eyeballing this led me to a polynomial model of the needed correction. Here it is in an Excel graph.

Sixth-order polynomial fit to estimated donut darkness

The horizontal axis is scaled distance from the donut's center, with the value 1 corresponding to radius of the ring's darkest values at about 700 pixels from center. The vertical axis is a dimensionless value for the darkness of the donut relative the image's true background.

This is a complex shape that is fit well by a sixth-order polynomial 

So, how to make use of that polynomial? Let's look at the PixelMath script!


Script for hole correction. Click for larger version


This is a simple script. Basically it looks at the distance a pixel is from the center of the hole, calculates the factor by which to increase the pixel's brightness, and multiplies the pixel's existing brightness by that factor. Pixels outside the donut (R > 1.38)  are left unchanged. 

The constants are essentially input parameters that can be played with to refine the correction. The main adjustment is Amplitude; too large a value and the donut becomes a light ring, too small and there's not enough improvement.

The multiplier is 

        1.0 + (polynomial value times Amplitude). 

I found the best result used Amplitude = 0.04, so at most the correction is a 4% increase in linear value.

So what did this do? Here is the Sh2-264 Green Master before and after the script is applied:

Uncorrected


Corrected


Note that these are given the "Boosted" PixInsight stretch to emphasize the hole; it won't be this evident in the final image.  The script did a fair job, I think. 
 
My post-WBPP workflow for this image uses ABE to subtract first order light pollution from each master light frame; the script is then applied to each channel. After that I return to my conventional workflow: CombineChannels, BlurXTerminator to reduce chromatic aberration prior to color calibration, and so on. 

The result:


Finished Image, corrected (1/4 scale)


North is up; The Angelfish swims nicely westward! I think the best way to validate any image is to compare it with clearly superior one by an accomplished imager, so I used Adam Block's superb image for this one. I think my processing does a very decent job of reproducing his in the central area of the nebula, so I'm happy!

This completes the rehabbing of the Iowa Star Party images.  Next I'll be revisiting some of my images from 2022. Also, Masters of PixInsight are doing a workshop on mosaics in December, so maybe I'll finally process that Veil Nebula mosaic data I've been sitting on.

Sunday, November 23, 2025

Iowa Star Party Images: Repaired!

To recap: I took one night's data at the October Iowa Star Party.  As was my usual (rather lazy) practice I deferred shooting flat frames until my return home. When I processed the data I got something of a shock. The stacked calibrated frames had very obvious dark "donut holes" in the middle. Here's what I mean:


Master Green after ABE


This was the result of not matching the exact focus used while gathering light frames. The remedy would be to obtain correct focus and retake the flats, so the next clear night when the temperature was close to what it had been in Iowa I set up in my back yard, got focused, shot flats, and hoped for the best. Something was off, though; the new result after recalibrating the light frames was an even larger donut hole than what you see above.

I've read that flatting at f/2 is a fiddly thing, and based on this I have to agree.

The only real solution is to collect future data and flats at a slower speed so that focus is less of an issue. And to take flats in the field at the time of data acquisition. But that's too late for the Iowa data, which I really don't want to throw away. So what can I do to salvage it?

How about creating a sort of secondary multiplicative layer of my own? One way to do this might be by using using the GAME script for PixInsight, which basically would create a round mask that I could use to stretch the hole area a bit, or even to create a synthetic secondary flat to use in recalibrating the already calibrated light frames. Nice thought, but I tried both methods and didn't get satisfactory results. 

More labor-intensive would be to create applications in a high level programming language that could directly adjust pixel values in the master frames. It's been maybe 12 years since I did any serious coding and had none of the needed compilers installed on my computer, so no -- that would be too involved. Much simpler would be to use PixInsight's PixelMath to do the same thing. I used Microsoft Excel to model the hole as a 6th-order polynomial and used a simple PixelMath script to transform the master images. This actually worked to some extent, but not well enough. I could have fiddled with that and eventually found the right polynomial, scale size, and amplitude to make a good correction, but I really didn't have the patience for that. There had to be a better way.

And in this case, there was. I wouldn't recommend this as a cure for any other flatting problem, but it seemed to work well enough for the Iowa data. The nice thing is that it used two standard PixInsight processes.

Because the data for two of the targets was low in the eastern sky over a rather conspicuous light dome, it suffered from a considerable light pollution gradient. I used PI's ABE to make a first pass at getting rid of that. This was a fairly typical application of ABE, using subtraction and a function degree of 4:

ABE settings

This essentially revealed the hole and whatever else the bad flat didn't correct. GradientCorrection was then applied with some non-default settings designed to work better on the hole's small-scale structure.  

GradientCorrection settings


Here is the result. The hole is almost completely gone, as are the edge issues left behind by ABE.





I applied this to all three channel masters and processed normally. Without the hole I could process a little more aggressively to bring out Barnard's Loop.



My image based on Iowa data


Wikipedia image (an RGBHa image by Hunter Wilson),
cropped and scaled to match my image above.


Below my image is the picture of Barnard's loop on its Wikipedia page for comparison. I've rescaled and cropped the image to match mine. Wilson's acquisition data is RGBHa, which probably accounts for the very red nebulosity.

Am I totally happy with my image? Not entirely. Theres still some weak signal suppression at the the very center of the image, and I wish the Running Man was bluer. Given that this is based on only half an hour of total exposure (ten minutes per color channel) I am pleased with is how it reveals a lot of the blue reflection nebulae in western Orion. It's a shame it didn't quite extend far enough to catch the Witch Head. It would be wonderful to devote hours to this area, but that's not going to happen.

Here's the other de-holed image from Iowa:


L to R, Soul Nebula, Heart Nebula,
and the Double Cluster (1/4 scale)

As with the Orion image, the hole is essentially eradicated. Too many stars, though. 

Reprocessing the third image, the huge Lambda Nebula, will be problematic as the hole is very entangled with the nebula. I may need  to use my PixelMath script method for that.

Next spring I'll try to get dithering working more reliably so that I can drizzle process and get better stars. With some luck I may get my long-sought wide field image of the Polaris-area IFN after all.

But now it's time for winter hibernation and reprocessing of old data. With what I'm learning from the Masters of PixInsight folks, I may even tackle that big old Veil Nebula mosaic data I've been sitting on for over a year!

Next time: the Lambda Orionis Nebula (Sh2-264) after de-holing!