Markarian’s Chain with AstroDMx Capture and some interesting tools.

It has often been said that if you have a Windows computer that is at, or coming to the end of its supported life; don’t discard it, install a Linux operating system and you will have a computer that is more secure and still very familiar to use.

For this session we used a Lenovo X270 Thinkpad with 8GB of RAM, a 6th generation i5 processor and a 256GB SSD drive. The computer was obtained via Amazon UK as a refurbished machine at a total cost of less than £150.

We installed Linux Mint; Wine that would enable us to run some Windows software; other software such as the Gimp 2.10 and AstroDMx Capture for Linux.

The telescope used was a William Optics Super Zenithstar 81mm ED Doublet APO refractor at f/5.5 with x 0.8 reducer/flattener, using an SVBONY SV605CC 14 bit, cooled, OSC CMOS camera and a Pegasus IR/UV cut filter. The scope was mounted on a Celestron AVX GOTO auto-guiding was done by PHD2 running on a separate computer using an SVBONY SV165 guide-scope fitted with a QHY-5II-M guide camera.

The equipment capturing flat fields

AstroDMx Capture capturing 30 x FITS flatfields

Stacked median flat field captured by this setup.

This image shows why it is important to capture flat fields.

As usual, the mount was placed on marks on the concrete base which give a fairly good polar alignment. AstroDMx Capture passed the time, altitude and location coordinates to the hand controller via the INDI server. The hand controller which now contained all of the correct information was set to its previous alignment and was unparked by AstroDMx Capture.

AstroDMx Capture was used to send the scope/mount to a bright star to check focus with a Bahtinov mask. 

Focusing on Regulus

AstroDMx Capture, via the INDI server, sent the scope/mount to the main Copeland’s eyes galaxy NGC4438. AstroDMx Capture plate-solved the field of view and centred the object in the field of view.This galaxy is central to Markarian’s Chain of galaxies. This allowed a good framing of the chain.

AstroDMx Capture capturing 45 x 2 minute FITS exposures of Markarian’s Chain

Copeland’s Eyes can be seen in the centre of the image.

The data were calibrated and stacked in Siril and the stacked image was stretched and the background extracted to remove the gradient using GraXpert.

GraXpert showing stretched image with the gradient.

GraXpert showing the extracted background

GraXpert showing the gradient removed by background extraction

The Stretched, background extracted image was then denoised in Neat Image and post processed in Fitswork and the Gimp 2.10.

Markarian’s Chain

The image was submitted to Astrometry.net to identify a plethora of galaxies within the image.

The background extraction could have been done in Siril, but GraXpert was chosen to stretch the image and background correct all at once.

 

Feature release of Version: 2.1.0 of AstroDMx Capture

We are pleased to announce that Nicola has released Version 2.1.0 of AstroDMx Capture.

Mutatis mutandis

Version: 2.1.0

Added: Negative preview screen transform.

Added: New exposure controls for capturing flat fields. The exposure values in the flat field UI are now entered using a text based notation in a similar way that exposures are entered in the main exposure control area. For example, typing 30ms sets a 30 millisecond exposure, typing 40s sets a 40 second exposure and typing 1m30s sets an exposure of 1 minute and 30 seconds. This allows arbitrary exposure lengths to be set whereas previously, the maximum exposure was 1 second.

Improved: The time-lapse mode has been significantly improved. Previously, the time-lapse mode allowed one exposure to be saved during a given time interval. The new functionality allows for an arbitrary number of frames to be saved during a given time interval. The timer can be either stopped or left running while data are being saved. Leaving the timer running means that data can be aligned to precise time points. The software calculates the estimated amount of time required to save the data and if that time is greater than the interval timer, then a warning is given to the user.

Improved: Significant improvements have been made to how AstroDMx handles time zones and daylight saving. Time zones and daylight saving are now calculated automatically. This new functionality applies to setting the time on mount hand controllers and for the object database, for example, rise, set and transit times specific to a given geographical location.

Improved: The geographical location UI now has North, South, East and West parameters. This frees the user from having to enter negative latitude (for south of the equator) or negative longitude values (for west of the prime meridian).

The Raspberry Pi builds of AstroDMx Capture have been re-branded to ARM to reflect the fact that a significant number of users are now using generic ARM SBCs. ARM32 is used for armhf 32 bit builds and AMR64 is used for aarch64 builds.

Fixed: Significant bugs associated with time zones other than UTC and other daylight saving bugs (see the fourth point above).

Fixed: Ubuntu 22.x libstdc++ bugs for AMR64 builds of AstroDMx Capture.

Updated: ‘fxload’ for QHY cameras on Linux x86-64 and ARM

Updated: QHY SDK on all platforms other than macOS. For macOS please see known issues.

Updated: PlayerOne SDK on all platforms.

Updated: Atik SDK on all platforms.

Other bug fixes and improvements

AstroDMx Capture for all platforms can be downloaded HERE

The Moon with new tools

A Player One Mars-C II OSC CMOS camera was attached to a William Optics 81mm APO refractor with 0.8 reducer/flattener and an IR/UV cut filter. The scope was mounted on a Celestron AVX mount that was controlled by AstroDMx Capture via an INDI server.

AstroDMx Capture  was used to capture two 1500-frame SER files that overlapped to cover the whole 95% lunar disk.

Autostakkert! Was used to stack the best 80% of frames from each SER file. The resulting images were wavelet sharpened in the new, cross-platform wavelet processor waveSharp by Cor Berrevoets the author of Registax in close collaboration with Grant Blair; Michael Owen; Filip Szczerek; Cheng-Yang Tan and Don Capone.

waveSharp wavelet sharpening a stacked lunar image

The two wavelet sharpened images were combined into a single image, rotated and cropped using PhotoPad Image Editor. There is a free version by NCH Software.

Combining the two images into a panorama mosaic in PhotoPad Image Editor

Panorama (mosaic) produced by PhotoPad Image Editor.

Image rotated in PhotoPad Image Editor

The image was then cropped and post processed in PhotoPad Image Editor.

Final image of the 95% waxing Moon

PhotoPad Image Editor is not a new program but it is not one that one naturally associates with Astronomical image processing. It is a Windows program by NCH Software and mostly works in Wine. The free version does everything that was done here and the license is low cost.

On the other hand, waveSharp is new software that extends the Registax wavelet processor into a new form and very importantly, as cross platform software that has versions for Windows, Linux and macOS.

waveSharp and AstroDMx Capture are just two examples of software for Astronomical imaging being made natively available for platforms such as Linux and macOS without having to use Wine.

Stacking over a meridian flip under bright moonlight

AstroDMx Capture was used to capture FITS images before and after a meridian flip in bright moonlight. This article describes the problems and the workflow for this imaging session.

Equipment used

A William Optics 81mm Apochromatic ED doublet refractor with an 0.8 reducer/flattener was fitted with an Altair Quadband filter and an SVBONY SV605MC monochromatic cooled CMOS camera.

The Quadband filter was used as a contrast-enhancing, light-pollution filter, we could have used no filter or a UV/IR cut filter.

The same equipment capturing flats, using a variable brightness illuminated tracing panel, after the imaging session was completed.

Stretched, stacked flats showing the regions of varying brightness

Image with no flatfield calibration.

This shows that flatfield calibration is absolutely essential

Click on an image to get a closer view

AstroDMx Capture capturing 3 minute FITS images of M86 and surrounding galaxies

AstroDMx Capture capturing 3 minute FITS files following a meridian flip

Having captured images on the east side of the meridian, AstroDMx Capture flipped the mount and re-centred M86. Then images on the west side of the meridian were captured.

Three stacking programs; Affinity Photo, Siril and Deep Sky Stacker were used to calibrate, register the images from each side of the meridian in a single batch. They all performed as expected and rotated the images where required to match the reference frame decided by the program.

There was an 82% waxing Moon nearby and a marked gradient was produced across the image. Fitswork 4 was used to flatten the background and remove the gradient.

Fitswork 4 removing the gradient across the image

Animation showing the image before and after the gradient was removed

The flattened image was post processed in the Gimp 2.10 and Neat image

Final image of M86 and surrounding galaxies

This session tested the SV605MC camera which worked well. It demonstrated that flat fields were essential for the calibration of light frames to remove areas of reduced illumination probably caused by contamination of the sensor surface or the surface of the optical window in the camera.

It also showed that when a gradient is introduced into the image, probably in this case by a nearby bright Moon, the gradient can be removed by flattening the background in Fitswork 4. The resulting image reveals many galaxies in addition to the main 9 galaxies towards the centre of the image, centred on M86.

Result from Astrometry.net showing the numerous galaxies captured in this image

Running an INDI server on Windows

Running an INDI Server on Windows

We now routinely use an INDI server to control the mount and other devices with AstroDMx Capture for all platforms.

The INDI server always runs on a POSIX compliant operating system and we frequently use a Raspberry Pi running Raspberry Pi OS, a version of Debian Linux. With this system we can use AstroDMx Capture for any platform to control the mount and whatever other devices. However, we note that not everyone has a Raspberry Pi computer and due to supply chain shortages, they are, at the time of writing, hard to obtain.

We therefore explored installing an INDI server on the imaging computer which cuts down the amount of hardware required. This is fine for POSIX compliant operating systems such as Linux and macOS, but can't be done directly with Windows because Windows is not exactly a POSIX compliant operating system.

INDI was developed for the POSIX compliant operating systems: Linux, macOS, FreeBSD and  OpenBSD; all UNIX-like operating systems. Mac OS is largely POSIX compliant and has UNIX 03 certification by The Open Group® as conforming to the Single UNIX Specification. It is also noteworthy that two Linux distributions based on CentOS also have UNIX certification; these are K-UX®; K-UX and EulerOS®; EulerOS.

The Linux Standard Base (LSB) was established in 2001 to try to standardise the internal structures of Linux-based systems for increased compatibility. It is based on the POSIX specifications, the Single UNIX Specification and other open standards.  All of these facts make two important points, Firstly, that Linux (a UNIX-like OS) is basically UNIX, but without the expense (who would pay?) of UNIX certification. Secondly, because Linux ensures that it is compliant with the same standards as UNIX, and has from the very start, the distinction between UNIX and Linux is basically semantic. Unix seems to be on the decline, with more and more IT vendors moving their investments from UNIX to Linux. New technologies and applications are often not tested or certified on UNIX systems, but instead are developed for Linux platforms. So, Linux is now increasingly occupying the niche previously enjoyed by UNIX.

In the early 1980’s there were three branches of UNIX development: Firstly, UNIX system III from the Bell laboratories UNIX Support Group. Secondly, Berkeley Software Distribution (BSD®) from the University of California at Berkeley.  The third branch of UNIX development was Microsoft’s XENIX®, a version of UNIX that ran on the X86 family of processors’ and licensed from AT&T Corporation. In fact, in the early 80s, XENIX had the largest installation base of any UNIX system. UNIX fragmentation produced compatibility problems between UNIX versions which gave rise to the formulation of the POSIX® standard (Portable Operating System Interface for UNIX), which was an attempt to standardise the system-call interface in order to maintain compatibility between operating systems.

Microsoft with Windows NT, made moves towards being POSIX compliant. This is because they wanted to win an Air Force contract. The Federal Information Processing Standard FIPS-151 required that some types of government software purchases had to be POSIX compliant. In order to meet the requirements Microsoft got a company called Softway who were marketing a POSIX compliant subsystem called OpenNT to produce a solution that they released as 'Interix' that sat side by side with Windows as an environmental subsystem and called the NT Kernel directly. This meant that it was possible to compile and run POSIX code. Microsoft incorporated the Microsoft POSIX subsystem into the first versions of Windows NT. However, the Windows NT POSIX subsystem did not incorporate a POSIX shell or any UNIX commands. Nevertheless, the system was sufficiently POSIX compliant to allow Microsoft to win the contract. Microsoft eventually bought Softway and after a couple of re-namings 'Interix' became 'SUA' 'Subsystem for UNIX-based Applications. SUA was deprecated in Windows 8 and removed altogether from Windows 8.1. POSIX returned to Windows with WSL (Windows subsystem for Linux) in Windows 10; eventually with a Linux kernel and finally packaged as a Windows 11 application available from the Microsoft store. 

It is important to understand that being UNIX does not depend on, for example, having a certain kernel; it depends on meeting a number of criteria, mainly POSIX compliance, to conform to the Single UNIX Specification. If Microsoft had gone all of the way in making Windows compliant, Windows too could have been classified as UNIX. This was obviously not what Microsoft wanted.

Putting an INDI server on a Windows 11 computer to run alongside AstroDMx Capture.

Using an Oracle VM VirtualBox

We have previously written HERE about installing on a Windows machine, Oracle VM VirtualBox running a Linux distribution. (That was back in the days before Nicola had ported AstroDMx Capture over to Windows, and this was a way of running AstroDMx Capture on a Windows computer) The procedure shown could be used to install Oracle VM VirtualBox with a Linux guest OS, but it is, of course, no longer necessary to install AstroDMx Capture into the VM , only the INDI server will be installed in the VM.

This is a quick and simple solution and is the one we prefer.

Using Windows Subsystem for Linux

We have tested installing WSL2 on Windows 11 and then installing an INDI server into it.

However, WSL is not as mature as Oracle VM VirtualBox and the application here is not really why Microsoft has put WSL into Windows. They have developers in mind: ‘The Windows Subsystem for Linux allows developers to run a GNU/Linux environment, including most command-line tools, utilities, and applications, directly on Windows’. Basically, because many, if not most developers work in a Linux environment and Microsoft’s Cloud systems largely use Linux systems, Microsoft believes that it is no longer necessary for developers to have separate Linux computers. This is all well and good, but Microsoft has neglected to make provision for USB devices to be passed through to WSL. When the Microsoft website is searched it is found that they suggest an Open Source solution to do this. We have done this and found the WSL solution to work.

We may write a separate article to describe exactly how this is done, but unless the user is already using WSL2 for other reasons, we suggest that the Oracle VM VirtualBox or possibly another virtual machine solution is the way to run an INDI server on a Windows machine.

Looking at the Hubble Palette

The data for this article were captured by AstroDMx Capture through a William Optics Super Zenithstar 81mm ED Doublet APO refractor at f/5.5 with x 0.8 reducer/flattener, using an SVBONY SV605MC 14 bit, cooled, monochrome CMOS camera and Altair narrowband filters.

The Hubble Palette is one of six palettes made by assigning monochrome images taken through SII, H-alpha or OIII narrowband filters to the Red, Green and Blue channels of a resulting false colour image.

The Hubble Palette has S mapped to Red; H mapped to Green and O mapped to Blue in the false colour image.

Palette mappings to RGB from H-alpha, OIII and SII

The Hubble palette is highlighted in the above table of filter mappings to RGB channels.

The false colour image is generated according to the additive properties of the primary colours of light. So for example, where green light and red light are combined the resulting colour is yellow; where blue light and red light are combined the resulting colour is magenta; where blue light and green light are combined the resulting colour is cyan and where red, green and blue light are combined the result is white.

The additive properties of light

How the elements’ emission lines in the Hubble Palette combine to produce different colours in the false colour image.

Out of the six possible palettes that are available, most astro-imagers choose the Hubble palette probably because it has an iconic ring to it; being named for the Hubble Space telescope.

The other named palette; HOS, is the Canada, France, Hawaii telescope palette. This palette name just doesn’t have the same ring to it!

All of the palettes are equally valid and any one could be used, and for interpretation purposes, the Venn diagram of overlapping colours would have to be re-labelled for that particular palette's element combinations.

Montage of the six available unprocessed palettes made from SII, H-alpha and OIII filtered monochrome images.

The problem with the Hubble palette is that it is so green. This is because H-alpha is usually the dominant element in a nebula and in the Hubble palette it is assigned to the green channel. Therefore green usually dominates a Hubble palette image. The same problem exists for each of the possible palettes; one colour or other usually dominates the raw image.

Astro-imagers usually proceed to reprocess the raw Hubble Palette image to replace much of the green with yellow and gold hues partly for aesthetic reasons. 

Of course, sensu stricto, once the hues of a Hubble palette image are changed, it is no longer a Hubble palette image, whatever we might call it; although it is derived from a Hubble palette.

Below is a basic Hubble palette image of the Horsehead-flame nebula region. It also contains luminance data acquired by capturing monochrome data through an Altair Quadband narrowband filter which is a narrowband filter with two bandpass zones:

1st band,  Centred on 495nm FWHM 35nm, range 477.5nm - 512.5nm.

2nd band, Centred on 660nm FWHM 35nm, range 642.5nm - 677.5nm.

These two bands are wide enough to include the emission lines of H-beta and OIII in the 1st band, with H-alpha and SII in the second band.

The luminance layer simply provides structural luminance information but does not change the hue of the image.

Raw Hubble palette image

One way to look closely at the information in the image is to increase, globally and selectively, the saturation of the colours in the image. The hues remain unchanged by the increasing saturation, so this is still a Hubble palette image.

Hubble palette image with enhanced saturation

In this image it is possible to see  green regions dominated by H-alpha; yellow regions where there are both SII and H-alpha; magenta regions where there are both OII and SII; blue regions where there is a lot of OIII, red regions where there is a lot of SII and cyan regions where there is both OIII and H-alpha.

However, in this example, whilst enhancing the saturation of the colours in the image does reveal more of the composition of the nebula, it neither produces an image that adequately distinguishes the regions of different composition, nor does it produce an image that is any more aesthetically pleasing than the original Hubble palette image.

This is why astro-imagers post-process Hubble palette images as mentioned previously.

Another method is where the individual monochrome images are colourised with the appropriate colours of red, green or blue and they are then combined together as layers with different % opacities. I shall call this the method of fractional channel blending.

This Hubble palette image was produced by layering 25% H-alpha, 50% SII and 100% OIII opacity; followed by global and specific colour saturation enhancements. The Quadband luminance layer was also incorporated for consistency with the previous images.

Hubble palette image by fractional channel blending

Strictly this is still a Hubble palette image and shows clear distribution of the composition of the nebula as well as being aesthetically pleasing.

Processing that selectively changes the hues of various colour components of the image can yield the required rendering of the image.

Hubble Palette image post-processed differently, including selective hue changes to reveal more differentiation in the compositional structure of the nebula.

Whilst this is strictly no longer a true Hubble palette image, it is derived from that palette and does show clear differentiation between the colours (derived from the composition) of the nebula. Moreover, it is an aesthetically pleasing rendering of the Hubble palette image.

It could be argued that one should allow the individual element channels to speak for themselves as monochrome images of the Hubble palette.

SII image

H-alpha image

OIII image

These three monochrome images tell the compositional distribution story perfectly, but not quantitatively. The reason for this is that the images have had to be stretched individually until they are ‘similar’ in their intensity, for composing into an RGB Hubble palette image. This also tells us that the ‘true’ Hubble palette image is not a quantitative image, but only a compositional structure image.

This is the luminance monochrome image captured through an Altair Quadband filter that was used to add luminance information to the original image

Various images could be used for luminance if it is to be incorporated at all  into the image. Here we have used an image from a filter that passes all of the wavelengths of interest. However, H-alpha or H-alpha + SII could also be used and will influence the luminance in different parts of the image.

I believe that it is desirable to explore the other five palettes that result from mapping H-alpha, SII and OIII to the red, green and blue channels of false colour images.

By using the Hubble palette produced by fractional channel blending , all six possible palettes can be constructed by reassigning the colour channels:

Instructions for using AstroDMx Capture V2

 AstroDMx Capture version 2 has advance functionality and is substantially larger than earlier versions.

Nicola has placed instructions for using version 2 HERE.

The new documentation takes the form of an overview of the new AstroDMx GUI followed by a walk through all of the INDI functionality of version 2 using the INDI simulators.

The INDI simulators behave exactly like real mounts, cameras etc and are used in exactly the same way. In this way it is possible to get to practice the advanced functionality before you try it on the night sky with a real mount, scope and camera.

The project is under active development and for example, the INDI cameras, while they do work, are still a work in progress.

We shall report here as new features are implemented or other changes are made.

AstroDMx Capture for all platforms can be downloaded HERE