M36 - Open Cluster
M36 - Click here for full resolution
Messier 36, also known as NGC 1960, is an open cluster of stars in the somewhat northern Auriga constellation. It was discovered by Giovanni Batista Hodierna before 1654, who described it as a nebulous patch. The cluster was independently re-discovered by Guillaume Le Gentil in 1749, then Charles Messier observed it in 1764 and added it to his catalogue. It is about 1,330 pc (4,340 light years) away from Earth. The cluster is very similar to the Pleiades cluster (M45), and if as far away it would be of similar apparent magnitude.
source: Wikipedia
NGC/IC:
Other Names:
Object:
Constellation:
R.A.:
Dec:
Transit date:
Transit Alt:
NGC1960
n.a.
Open Cluster
Auriga
05h 36m 18.0s
+34º 08’ 24”
08 January
71º S
Conditions
M36, and its close neighbours M37 and M38, are typical winter objects and appear high in the Southern sky by around December/January. Imaging sessions were on February 13 and 14, 2023 at which visibility was good until around 03:00h. That was also the time when the moon (50%) rose, so no problems here. Unfortunately during the first session fog rolled in, shortening the period of usable images significantly. So the rest of the frames was shot a day later, where the conditions were actually pretty good.
Equipment
Recently a new mount was added to the observatory, a 10Micron GM2000HPS. It took a while before the intended pier had arrived. But on February 08 it did, and after a couple of days assembling the whole rig, February 13 was the first night of clear skies at which the new mount would be used. A good part of the evening went into setting up the system properly, aligning and testing. And when that was done, a straightforward target was chosen to make a first image with. M36 was that target.
The mount functioned very well. I have been using its smaller brother, the GM1000HPS, for many years. So I felt straight at home with the GM2000HPS. It is quite a lot heavier though and everything feels a lot more solid. This was also objectively confirmed. The pointing models had an RMS value of 1.8 arcsec. So far I’ve never had RMS values lower than 2.5 arcsec, so very happy with that.
It was also the first time for a new focuser that was used. The Sesto Senso focusers that were used so far are great focusers and have always served me well. But they have always been a bit demanding on their serial connections on a Mac. In fact the only way I could run this focuser on the Mac was using an older version of MacOS (Mojave). But the latest versions of KStars required a more recent version of MacOS. So I decided to solve the issue by installing a Pegasus Motor Focus Kit. The controller for this focuser is seated in the Ultimate Powerbox (UPB), making the focus motor itself a fairly cost effective solution. It connects through a single ethernet cable to the UPB, so no need for separate power and data cables. The focuser behaved extremely well, and perfect V-curves were achieved during the autofocusing routines.
Telescope
Mount
Camera
Filters
Guiding
Accessoires
Software
Takahashi TOA-130, FL67 flattener, Pegasus Astro Motor Focus kit v2
10Micron GM2000HPS, EuroEMC S130 pier
ZWO ASI533MM Pro, cooled to -15 ºC
Astrodon 1.25” LRGB mounted, ZWO EFW 8-position
Unguided
MacMini M1, macOS Ventura, Pegasus Ultimate Powerbox v2, Pegasus Uranus, Pegasus FlatMaster 150
KStars/Ekos 3.6.3, INDI Library 2.0.0, Mountwizzard4 3.0.0, PixInsight 1.8.9-1
The new GM2000HPS mount installed and ready for first use. Also the new Pegasus focuser is mounted.
Imaging
The stars in the cluster are pretty bright, so it is important to not burn out the centers too much. To this goal the gain was set to 0. First 120s luminance exposures were tested, but this was too bright. So I settled on 60s for the luminance and 120s for the three colour channels. A target like this is not very challenging, so a total of 5h of exposure is more than enough. But since the frist night I lost quite a few frames due to fog, a second run was done the following night, resulting in a total of 6h of exposure, more than enough.
As of late I keep the use of the FlipFlat motorised flatpanel to a minimum. For an open setting like our backyard, it is just too sensitive to wind, reflections, etc. So I am taking a bit of a deeper dive into taking flats, and look into other flat panel solutions. In a series of three blogs I share that journey. The second blog that was just released compares four different flat panel solutions. And the Pegasus Flatmaster comes out of that test with a lot of banding, so not the first choice. But at gain 0 it is a bit easier to go for longer exposures. So for this set of images, I ran flats of 5s, while KStars was adjusting brightness for each filter. This worked quite well and no banding was visible in the end results.
Resolution
Focal length
Pixel size
Resolution
Field of View
Rotation
Image center
3000 × 3000 px (9.0 MP)
1000 mm @ f/7.7
3.76 µm
0.773 arcsec/px
38’ x 38’
160 degrees
RA: 05º 36’ 18.095”
Dec: +34º 08’ 22.96”
Processing
All frames were calibrated with Dark (50) and Flat (25) and Flat Dark (25) frames, registered, integrated and automatically cropped, using the WeightedBatchPreprocessing (WBPP) script. This auto-crop function has been recently added to WBPP and is usually a practical way to save some time on something that needs to be done anyway. However, in this case it gave some issues. In the red channel a plane-trail was not completely eliminated during the integration. Also manually trying different rejection algorithms and applying strict rejection criteria did not get rid of it completely. So instead I decided to take the bad frame out. Since this was done manually, I could not find an easy way to apply the original crop to the re-processed red channel image. So instead, all uncropped images were used and a manual dynamic crop was applied. If anyone knows for an easy way how to ‘extract’ the auto-crop and apply it manually on another image, please leave your suggestions in the comments below. I guess with hindsight I could have run the whole WBPP again, with that one image removed. The new cache functionality would probably have made it a very quick process.
After the removal of gradients using DynamicBackgroundExtraction, the next step was deconvolution using BlurXTerminator (BXT). For the luminance this is a common step. For the RGB data this is historically not done. But because BXT also improves slight imperfections in star shape, there is value in doing this also for the colour channels. What I did not know was whether it was best to do it on individual channels and then combine, or first combine and then run BXT on the RGB image. So both routes were tried, and BXT on individual channels came out best. When applying it to the combined RGB image, there was a small tendency to some uneven star colours. This makes sense in a way, because the required corrections may be different for each channel. One could think of different diffractions at different altitudes, different seeing conditions, etc. So based on this one example it makes sense to apply BXT to individual channels first before combining them. The tool is simple enough to not make this complicated in any way.
Comparison on applying BXT to combined RGB (left) or to individual channels first (right)
The luminance channel could be stretched at this stage, the RGB image needed to be colour calibrated first. SpectroPhotometricColorCalibration (SPCC) was used for this. Then the linear images were stretched using GeneralisedHyperbolicStretch (GHS). For a stars-only like the current image, it is a bit more difficult to determine the right symmetry points. And I’m still trying to fully grasp the best way to use the tool. So after stretching, the final touches were done with regular CurvesTransformation. In order to maintain colours well, GHS has a colour mode, which uses similar algorithms to ArcsinhStretch. But like ArcsinhStretch the effect can become too much rather quickly. Instead of doing multiple smaller stretches on colour first and then on RGB, GHS also has an option to blend the two in one go. Using this RGBBlend option at 0.5 worked very well and gave a nice stretch with colours well maintained.
With GHS in ‘Colour’ mode, there is an option to blend in a regular RGB stretch. It combines two separate stretches into one, but with much better ability to predict the final result.
The luminance image came out very clean after stretching, probably because it was a stack of 180 images. The colour image was a bit more noisy, so a mild noise reduction was applied using NoiseXTerminator (NXT). A second run of NXT was done after the luminance had been blended into the RGB image. A few touch-ups were done to increase contrast and enhance saturation a little bit. In principle the image was pretty much ready now.
However, images of open clusters can be a bit flat overall. Emphasising the cluster itself can help to make the object stand out a bit more. And BXT is actually a very nice tool for that. Because it allows to manipulate the halos. Normally this is used to reduce the halos, but for an image like this enhancing the halo actually gives a rather pleasing result. So an extra run of BXT was done, turning every parameter off, except the halo, which was set to +0.30. This made especially the big bright blue stars stand out a bit nicer.
This completed the processing of M36.
Processing workflow (click to enlarge)
This image has been published on Astrobin.
