A further seasonal Feature release of AstroDMx Capture for all platforms.

A further seasonal Feature release of AstroDMx Capture for all platforms.

This release brings on board a new planetary and guide camera from SVBONY, the SV905C.

The SB905C features a USB2.0 data connection via a Type C interface.

This new camera is now implemented in AstroDMx Capture for Windows, macOS and the Raspberry Pi.

There are problems with the Linux x86 64 SDK and when this is resolved by SVBONY, the camera will also be implemented in x86 64 Linux.

An issue with the DMX Auto WB has also been resolved in this release, as have issues with UVC cameras in macOS.

AstroDMx Capture can be freely downloaded HERE

Christmas Feature Release of AstroDMx Capture for all platforms.Version 1.3.14.0

 Christmas Feature Release of AstroDMx Capture for all platforms. Version 1.3.14.0

Nicola has released a new version of AstroDMx Capture for Windows, macOS and Linux (including the raspberry Pi)

Readers may remember from my previous post entitled ‘Why do they do these things’ That Apple had made changes such that astronomical image capture software was unable to connect to UVC cameras in macOS 12, Monterey. Cameras impacted were devices such as the SV105 and the SV205. 

Nicola has made a solution to this problem and this is available in the new feature release of AstroDMx Capture for macOS. The number of reports that came in from users indicates that there is a significant number of macOS users of these UVC cameras. Thankfully Nicola has solved this problem. It is to be hoped that Apple will undo the damage they have caused if it was unintentional. If however, it was intentional then at least Nicola’s solution circumvents the problem, The problem only affects UVC cameras and does not affect proper USB astronomical cameras, or even enhanced UVC astronomical cameras such as DMK, DFK and DBK cameras from The Imaging source. However, UVC webcams and devices like the SV105 and SV205 are affected.

The problem associated with the Pi cameras for Raspberry Pi computers running the Bullseye version of Raspberry Pi OS has not been resolved, and can’t be resolved until suitable support in terms of software and documentation are provided. However, the Raspberry Pi Foundation are keeping the Buster version of Raspberry Pi OS as a legacy version for people to use until the Pi Camera problems are resolved.

Notable changes in version 1.3.14.0

• Added: Touptek Camera Support -- all thermal controls implemented including dew heater control.
• Added: Omegon Pro Camera support for all thermal controls implemented including dew heater control.
• Added: Bresser Camera support.
• Added: Dew heater setting to capture log.
• Added: Fan control setting to capture log.
• Added: Target sensor temperature setting to capture log.
• Added: Function to capture and save Bias frames along with the Master Bias frame.
• Added: DMx white balance imaging dimming compensation.
• Changed: Complete rewrite of the Capture log.
• Changed: Master calibration frame now called Master instead of Average.
• Changed: DMx White Balance value is now written to the capture log.
• Fixed: Frame calibration output format is now remembered when stopping a capture run.
• Fixed: SVBONY and Altair exposure cancellation bug.
• Fixed: UVC camera connection problems caused by MacOS Monterey.
• Updated: Altair SDK.
• Updated: ZWO SDK.
• Updated: QHY SDK.
• Updated: Atik SDK.
• Updated: Lumenera SDK.
• Updated: wxWidgets from 3.1.4 to 3.1.5
• Updated: Other important dependencies.
• General improvements to exposure cancellation. Exposures can now be cancelled from the Capture dialog without a frame being saved.
• Internal code changes to facilitate ongoing maintenance.
• AstroDMx is now versioned with four digits. The first digit is the major version number, the second is the minor version number, the third is the micro version number and the last digit represents if AstroDMx is an internal build or a release. A zero means release, higher than zero means an internal or test build.
• Changes to the Windows build environment.
• Support for older CPUs that don't have SSE3 or SSSE3 instruction-sets on Linux has been reintroduced, however, performance (frame rates) may be limited on such CPUs.
• Changes for DSLR usage on Windows has had to be implemented. Details can be found HERE
• Bug fixes.

Testing the Bresser implementation 

The Bresser GPCMOS01200KPF camera implementation was tested by mounting the camera at the focus of a William Optics Zenithstar 66mm, f/5.5 ED, Apochromatic Doublet refractor. The scope was mounted on a Skywatcher Star Discovery, Synscan AZ mount.

AstroDMx Capture for Windows was used to capture two overlapping, 2,500 frame, RGB24 SER files of areas to encompass all of the 98.5% Moon. 

Click on an image to get a closer view.

Screenshot of AstroDMx Capture saving SER files of lunar data

The best 85% of frames in the SER files were stacked in Autostakkert! The two resulting panes were stitched together with Microsoft ICE and wavelet processed in Registax 6. The resulting image of the 98.5% Moon was post processed in the Gimp 2.10.

98.5% Moon

98.5% Moon, chroma enhanced to reveal mineralogical variation on the surface of the Moon

The following night a Skymax 127 Maksutov was mounted on a Celestron AVX GOTO mount and the Bresser GPCMOS01200KPF camera was placed at the focus of the telescope.

2,500 frame, RGB24 SER files were captured of various regions of the 99.9% Moon using AstroDMx Capture for Windows.

Screenshot of AstroDMx Capture for Windows saving SER data of the Kepler region of the Moon.

The best 85% of the frames in the SER files were stacked in Autostakkert! The resulting images were wavelet processed in Registax 6 and Post Processed in the Gimp 2.10.

The Reiner Gamma, Kepler and Copernicus panes were stitched together in Microsoft ICE and post-processed in the Gimp 2.10.

Reiner Gamma, Kepler and Copernicus region of the Moon

Reiner Gamma, Kepler and Copernicus region chroma enhanced to reveal mineralogical variation in the surface of the Moon.

Other regions of the Moon were similarly imaged and processed.

Screenshot of AstroDMx Capture for Windows capturing SER data of the Palus Somni region of the Moon with a Bresser GPCMOS01200KPF camera

Palus Somni region

Palus Somni region chroma enhanced

Plato, Sinus Iridum region

Plato, Sinus Iridum region chroma enhanced

Tycho region

Tycho region chroma enhanced

A number of cameras have been brought on board with this release of AstroDMx Capture. The tests of the Bresser camera here demonstrated the camera's abilities as a planetary, solar system imager, and also showed the colour capture of the camera to produce good results.

AstroDMx Capture can be downloaded here: https://www.astrodmx-capture.org.uk

It never Rains but it Pours

It never Rains but it Pours

This proverbial expression originated in 1726 in an article by Jonathan Swift and Alexander Pope where they wrote in  “Prose Miscellanies”, "It Cannot Rain But It Pours"; the progenitor of our title here.

They were referring to the observation that when one bad thing happens, it often seems that other bad things accompany it.

It is sometimes tempting to believe that the cluster of bad events is somehow functionally related. Whilst this can sometimes be true, it is also true that clusters of events (bad or otherwise) can just be the result of randomness. This is illustrated in the diagram below:

One hundred random Y coordinates were plotted against random X coordinates.

Being randomly placed, there is absolutely no relationship between the position of any point and any other point. In fact, a good definition of random positioning of points or events (in space, time or both) is that the position of one point (or event) is not influenced by, nor does it influence, the position of any other point (or event).

Examining the scatter diagram, we can see that if we consider, for example, the two equal areas marked in yellow that are quite close to each other, one contains no points (events) and the other contains six points (events). The cluster of six points (events) has absolutely no significance just as the area containing no points (events) has no significance; they are simply random. There are other clusters and gaps in the diagram that are also not significant and are also just the natural result of randomness.

I mention all of this because I have recently written an article entitled “Why do they do these things” in which I describe actions taken by Apple and the Raspberry Pi Foundation that have repercussions for UVC cameras (Apple) and Pi Cameras (Pi Foundation), that impact astronomical imagers; that can be read HERE.

It never rains but it pours, because I now also have to report that in Distributions of Linux with a kernel of 5.15 (and above at the moment), for example Fedora Linux, changes in the userland interface in the kernel means that the way that applications detect the names of UVC cameras has changed, and not for the better.

Linux has always assigned UVC cameras on the USB bus as Video4Linux video capture device numbers. However, it has always been possible to discover the names of these cameras, to facilitate the choosing of the correct camera to connect to the imaging program. With the release of the latest kernel as mentioned above, it is no longer straightforward for imaging programs to identify cameras by their names. They now have to be identified by their Video4Linux video capture device numbers.

This is the way that a DMK 21AU04.AS camera (which is an enhanced UVC camera) is presented to the user in the Windows (which does not have the problem) version of AstroDMx Capture:

This is also the way that the same camera appears in Linux with lower kernel numbers than 1.15.

However with kernel number 5.15 this is how it appears in Linux:

This is not a deal breaker, but it is an inconvenience that at the moment affects all Linux imaging software including AstroDMx Capture for Linux.

It is entirely possible that this situation will be rectified in the future, but at the moment there is no sign of this. It may be that Nicola will produce a solution for this problem whether or not it is rectified by the Linux kernel developers.

These three events that affect UVC cameras and also Pi Cameras are an unrelated cluster, but they add simultaneously to the problems of capture software developers. They are random events, but for developers, it seems that It Never Rains but it Pours!

Apple/Pi: Why do they do these things?

Why do they do these things?

In the space of a month or so, Apple and the Raspberry Pi Foundation have done two things that can potentially impact astronomical imagers.

Apple

In the latest version of macOS 12 Monterey, Apple has done something that they possibly regard as an enhancement to security; however, it has not been thought through properly, or maybe it has… Apple has always had the attitude that they know best and that they will tell their users what they should have and need.

That is all well and good unless you happen to be an astronomer and you wish to use a UVC device to capture images or video of astronomical objects. 

A UVC device is a USB Video Class device. These are devices capable of streaming video over USB,  like webcams, digital camcorders, transcoders, analog video converters and still-image cameras. Many of these devices are used by astronomers as devices to capture astronomical data.

Cameras such as the SV105 and the SV205 are sold as astronomy cameras and electronic eyepieces though they derive from webcam type devices. However, other, higher-end astronomical imaging devices such as The Imaging Source DMK, DBK, DFK series of cameras however, are also basically, enhanced UVC devices.

What Apple have done in the latest version of macOS 12 Monterey, is to remove permissions for applications to access UVC cameras, with the exception of course of apple-included apps such as Photo Booth. It would, of course, be possible to pay Apple money and jump through hoops to free an application from this restriction, but this would never be practical for any astronomy imaging software.

Of course, this policy will make it very difficult for malware to access the built in UVC webcam or attached webcam, because it would not have permission to do so.

Unfortunately, all astronomical imaging software available for imaging with a Monterey Mac is unable to access UVC imaging devices.

Happily this restriction does not apply to astronomical cameras that are not UVC devices.

A result of this is that AstroDMx Capture for macOS will not now support UVC devices. Of course, Nicola will research any possible way around this problem.

If you have a proper astronomy imaging camera such as an SV305, a ZWO an Altair, Bresser, Tuptek etc. or a supported DSLR for example, there will be no problem with using AstroDMx Capture for macOS as usual.

Raspberry Pi

If you are running the Raspberry Pi OS Buster version, then nothing has changed. However, if you have upgraded to the latest Raspberry Pi OS Bullseye version, the Pi cameras will no longer work. Without deprecating the camera system, The Raspberry Pi Foundation has completely changed the way that the Pi Cameras work. In fact, this leaves everyone, including the Python users, without support. 

This is a strange and atypical behaviour for the Pi Foundation, who, hitherto have gone to pains to ensure back compatibility. They have produced a completely new API depending on libcamera libraries. This means that things will have to be re-written from scratch. 

The Pi Foundation’s attitude is that for the moment, the Buster version of Raspberry Pi OS is still available as a legacy version and one can use that version if one wishes one’s Pi camera programs to work. 

However, the Bullseye version is here with its new way of doing things and until decent API documentation is produced, the Pi cameras are going to be in trouble.

A result is that for the moment, AstroDMx Capture for the Raspberry Pi will no longer support the Pi cameras unless the Buster legacy OS version is used. This will be work for the future.

M42/43 with an LeNhance filter, AstroDMx Capture for Windows and an Atik 314 OSC

M42/43 with an LeNhance filter

An f/5.5, 80mm, ED refractor was mounted on a Celestron AVX GOTO mount. The mount was pulse auto-guided with PHD2 using an SV165 guide-scope and an SV305 as the guide camera.

An Atik 314E OSC camera was fited with an Optalong LeNhance dual-band narrowband filter and was placed at the focus of the refractor. This filter excludes all wavelengths but H-alpha, H-beta and Olll.

AstroDMx Capture for Windows, running on a Windows 11 laptop, was used to capture 15 x 5min FITS exposures of the Orion Nebula along with Bias frames and matching dark frames.

Screenshot of AstroDMx Capture capturing 5 minute exposures. The preview was set to 150% and the non-destructive16-bit brightness was set to x2 to facilitate viewing the data being captured.

Screenshot with the same settings except the 16-bit brightness control has not been increased.

This illusstrates another mechanism for brightening the preview of the object being imaged to make it more visible. Note that the Trapezium region of the nebula appears less burnt out because the extra brightness has not been imposed on the preview. It must always be remembered that the preview of the captured images is not intended to show how the final image will apear after post processing, it is intended simply to show that the object has been located and that data are being captured.

The images were stacked in Deep Sky Stacker and separately in Affinity Photo and post processed in the Gimp, FastStone and Topaz Sharpen AI.

Final image of M42/43

Full Size