Nature study with AstroDMx Capture for Linux

A Zoom TV lens was fitted to a DFK mounted on a small tripod and the camera was aimed at an active bird nesting box.

DFK with a zoom TV lens

AstroDMx Capture was used to capture a SER file of the nesting box.

Te Debian laptop capturing data

Screenshot of AstroDMx Capture for Linux capturing data

SER player was used to cut out the frames containing action. A SER file and AVI were made as high quality recordings and an animated GIF was made to show the results here on the blog.

Animated GIF

Full size

The software has the capacity for time-lapse imaging down to 0.1s intervals, but for the fast flight of the blue-tits, a 30fps SER file was the best way to capture the data

ChromeOS, Android and the SVBONY SV105 camera

There are two operating systems based on the Linux kernel that are not usually thought of as Linux. This is because, whilst they are both based on the Linux kernel, they are both, by design, unable to run Linux desktop applications. With ChromeOS, most of the applications run in the Chrome browser environment. In Android, a whole ecosystem of applications run in the Android environment, and cannot be run on a normal Linux desktop.

ChromeOS

The low cost SVBONY SV105 camera and a Chromebook.

There is no good imaging software for ChromeOS, however, there is a simple camera application that can be used in camera auto mode, and is suitable for outreach. It is even possible to grab images. Here is the setup with a Samsung Chromebook and SVBONY SV105 with a Skymax 127 on an iOptron AZ, GOTO mount, along with an image grabbed by the camera application.
Click on an image to get a closer view.

The Setup with scope, camera and Chromebook

An image captured by the camera software

Android

The SVBONY SV105 camera and Android:

The SV105 comes with a 1.8m USB cable which has a short fly-out USB lead to provide extra power to the device which has a power consumption of 150mA at 5volts. This was essential for using the camera with a Samsung 10.1 inch Galaxy Note tablet. The tablet was not able to supply sufficient power to operate the camera. A 5v 2.1A mobile phone portable charging device was used as an auxiliary power supply, connected via the fly-out lead. A powered USB hub could be used alternatively to provide extra power. My Samsung tablet was temperamental so far as detecting the camera, possibly because it is quite an old device. It helped to have the device fully charged.

Auxiliary power supply

The SV105 camera was placed at the Cassegrain focus of a Skymax 127 Maksutov and was connected to the Android tablet computer.
There is, available in the Google Play store, a USB camera capture application called USB Camera. This is a particularly good application because it presents the main controls of the camera, enabling the correct exposure etc. to be set. It works with UVC cameras.

Photograph of Android tablet streaming images from the SVBONY SV105 camera

Screenshot of USB Camera streaming video

USB Camera can capture mp4 Movies or still images.

Controls for Video formats

A drop-down menu allows the selection of the camera controls which can be hidden.

Drop down menu for camera controls

Single captured image

The combination of the SV105, Android and USB Capture provides a very credible observing, eyepiece sharing and even imaging platform.

At the moment, Android seems to be the superior of the two platforms for astronomical viewing and imaging, with one caveat; that the aging tablet used for these experiments was temperamental, even with an auxiliary power supply, with respect to detecting the camera (any camera). However, once detected, everything worked fine.
There are available Android notebooks, and depending on the version of Android they are running, they could be more suitable devices than a tablet (or phone), if they can run the capture software.
The weakness of ChromeOS is the lack of suitable capture applications.
Both platforms would benefit from the development of applications that are capable of capturing movies in the SER format, a superior format for astronomical imaging. This would produce data that could be transferred to another computer for processing.

High Definition Lunar image with SVBONY T7 W2568A camera and AstroDMx Capture for Linux

A low-cost SVBONY T7 W2568 high speed camera was placed at the Cassegrain focus of a Skymax 127 Maksutov mounted on a Celestron AVX, EQ GOTO mount. 3000 frame 8 bit SER files were captured of 4 largely overlapping regions on the terminator in the Clavius Tycho region using AstroDMx Capture for Linux. The best 50% of the frames in each of the SER files were stacked in Autostakkert!3 running in Wine and the 4 panes were stitched into a mosaic using Microsoft ICE also running in Wine. The mosaic image was wavelet processed in Registax 5.1 running in Wine. The final image was post processed in the Gimp 2.10 and RawTherapee.

Full Size

This low cost camera is definitely worth having for this kind on high definition work.

Deep Sky with the SVBONY T7 W2568A camera, AstroDMx Capture for Linux and a 10 inch, f/4.8 Newtonian

An SVBONY T7 W2568A camera was placed at the Newtonian focus of an Orion Europa, 10 inch, f/4.8 Newtonian. Exposures were captured in RAW 8, with real-time dark-frame and flat-field correction using AstroDMx Capture for Linux on a Debian laptop. The exposures were saved as Tiff files. M13 (50 x 15s exposures), M57 (30 x 45s exposures) and M82 (30 x 60s exposures). The exposures were stacked in Deep Sky Stacker running in Wine and Post processed in the Gimp 2.9 and Neat Image.

M82

Screenshot of AstroDMx Capture for Linux capturing M82 data with real-time dark-frame and flat-field correction

M57

M13

Quite acceptable deep-sky images from this low cost SVBONY W2568A high-speed camera. An ideal starter camera.

High resolution Lunar imaging with an SVBONY T7 W2568A high speed camera, a 10" Newtonian and AstroDMx Capture for Linux

An SVBONY T7 W2568A high speed camera was placed at the Newtonian Focus of an Orion, 10 inch, f/4.8 Newtonian. AstroDMx Capture for Linux running on a Debian Linux laptop, was used to capture 6 overlapping, 1500 frame SER files of the 24.8% waxing, crescent Moon. The best 50% of the frames in each SER file were stacked in Autostakkert! 3 and stitched together into a single image with Microsoft ICE both running in Wine. The resulting image was wavelet processed in Registax 5.1. also running in Wine. The final image was post processed in the Gimp 2.9.

24.8% waxing, crescent Moon

The SVBONY T7 high speed camera can produce High resolution images worthy of more expensive devices.

ZWO Gamma Gone! but not quite!

Gamma has been removed from the ZWO SDK!

This means that ZWO cameras will no longer provide a control for gamma.
At first sight this might seem like a strange thing to do, but in reality, it is not.
There is a powerful argument that image processing should be done after the data have been captured.

In general, image processing involves the selective discarding of information in the image data in the effort to recover as much information about the underlying structure of the image, such as the bands on Jupiter, or the arms of a spiral galaxy. If any of the information is discarded at capture time, it is lost forever, whilst if it is discarded post capture, it is still available in the original image data.

Gamma is such a function that involves the selective changing of the mid-range values of the brightness of an image, whilst leaving the darkest and the lightest values untouched. Many cameras allow the control of gamma at capture time, as it can produce a more pleasing view of the subject being captured. However, it must never be forgotten that the brightness values that are changed (and thus lost) will not be available in the captured data.

Experienced planetary imagers such as Christopher Go, eschew the control of gamma at capture time. What is important is to get the exposure, including gain, right at capture time. Some advanced imaging cameras only allow the control of exposure and these are often true 16 bit devices.

In order to mitigate this loss of control over gamma, Nicola has incorporated gamma control in software, in AstroDMx Capture for Linux. In addition to gamma, she has also implemented contrast and brightness in software. This allows the user to control and see a pleasing view of the subject being imaged as usual. However, the changes are not propagated through to the saved image. This means that no information is discarded at capture time and is therefore available for extraction during post processing in software such as the Gimp 2.10.

For many users, this is a paradigm shift that will require a little getting used to. However, it is likely to lead to better results in the long run.

These changes are implemented in the next release of AstroDMx Capture and have been responsible for the slight delay in release. However, the gamma camera control will be retained in addition to the implementation of the software, non destructive controls.

First Light testing of the SVBONY version of the T7 W2568A high speed astrocamera as a Linux astro-imager with AstroDMx Capture for Linux

This is a low priced astronomy camera that is a suitable introduction to astronomical imaging; not only of the Solar system but also some of the deep sky objects.
The camera is marketed as a high-speed camera and, by implication, a planetary camera.
It can be obtained from the SVBONY official AliExpress store.
I have tested the camera specifically as a Linux astronomical camera using AstroDMx Capture for Linux. The camera supplied by SVBONY was packaged well and includes a number of items.

The box contains
    • The T7 W2568A astrocamera
    • A wide angle lens
    • An auto-guiding cable
    • A USB 2.0 cable
    • An IR/UV cut filter assembly
    • An extension nose-piece
    • Two dust caps
    • A par-focal ring with three thumbscrews. place

The camera with the par-focal ring in place

The par-focal ring is of a superior design with the three thumb screws engaging on an internal O-ring so the screws don’t actually make contact with the camera (or eyepiece) body.

One of the first things to do with a camera of this design is to place a patch of insulating tape over the auto-guiding port. This will ensure that the camera USB cable is not accidentally plugged into the guiding port in the dark. Some manufacturers provide a blanking plug for this purpose but many do not.

The auto-guiding port protected by insulating tape

The substantial par-focal ring can be seen clearly with its three retaining screws.

There are very handy calibration marks on the side of the camera body, making re-positioning much easier.

Calibration marks on the camera body

The camera reports itself as a ZWOASI120MC although it contains a MT9M034 sensor rather than the AR0130CS of the ZWO. The camera will stream 8 bit images and it will stream 16 bit (12 bit in a 16 bit container) images for short exposures. The camera will not reliably deliver 16 bit long exposures. This is not a serious limitation for a camera of low cost. (Moreover, a similar issue is evident in the USB 2.0 ZWO with 16 bit long exposures if the compatibility firmware is used.) In this experiment, the standard camera firmware was used, and a Linux machine with the kernel patched to eliminate the maxpacket limitation in the USB data stream was employed. Note! with the Linux Kernel 4.16.8-300.fc28.x86_64 released by a Fedora 28 update on May 15, 2018, no kernel patch is needed. 16 bit short exposures could be advantageous with solar imaging where the capture of subtly different levels of brightness is important. With 8 bit images, 256 distinct levels of brightness can be recorded, whereas, with 12 bit output (into a 16 bit container) 4096 distinct levels of brightness can be recorded.

Deep Sky imaging

The SVBONY T7 astrocamera was placed at the Newtonian focus of an f/5, Skywatcher Explorer 130 P-DS Newtonian mounted on a Celestron AVX, EQ, GOTO mount. 30 x 20s exposures of M3 were made with real-time dark-frame correction, saving the images as TIFF files using RAW 8 capture with high quality de-bayering on the fly.

Screenshot of AstroDMx Capture for Linux streaming images of M3 without real-time dark-frame correction

Note the background noise in the displayed image.

Screenshot of AstroDMx Capture for Linux streaming images of M3 with real-time dark-frame correction

Note the removal of the background noise by the real-time dark-frame correction.

Animation alternating between the real-time dark-frame corrected and uncorrected views

The real-time dark-frame correction is ideal for outreach and ‘eyepiece sharing’ observing and imaging.
The images were stacked in Deep Sky Stacker running in Wine and post processed in The Gimp 2.10

M3

40 x 35s exposures of M104 were made with real-time dark-frame correction using AstroDMx Capture for Linux, saving the images as TIFF files using RAW 8 capture with high quality de-bayering on the fly.
The images were stacked in Deep Sky Stacker running in Wine and post processed in The Gimp 2.10 and Neat Image.

M104

Planetary imaging

The camera was then tested in its high speed planetary camera mode. The lens from a x2 Barlow was screwed onto the nose-piece of the camera which was then placed at the Cassegrain focus of a Skymax 127 Maksutov. A region of interest of 320 x 240 was selected and a 2min SER file of Jupiter was collected (under poor seeing conditions) using RAW 8 capture with high quality de-bayering on the fly. 10,000 frames were captured. The best 40% of frames were stacked in Autostakkert! 3 and wavelet processed in Registax 5.1 both running in Wine. The final image was post processed in the Gimp 2.10

Jupiter with the GRS

First impressions of the SVBONY T7 camera are that is is a very good value device, ideal  as an introductory camera for Solar System and brighter deep sky object astrophotography. It is an impressive device and has capabilities that will produce pleasing results. Depending on the exposure, with a region of interest of 230 x 240, a frame rate of up to 250fps can be achieved. It should also be noticed that relatively small aperture telescopes have been used for the current tests. Later testing will involve the use of much larger aperture telescopes.

Deep sky with a QHY 5L-ll-M and AstroDMx Capture for Linux

A Bresser Messier-AR-102-AS ED refractor was mounted on a Celestron AVX, EQ, GOTO mount. A QHY 5L-ll-M camera was placed at the prime focus. AstroDMx Capture for Linux was used to capture 16 bit FITs files with matching dark frames.
M104 ans M64 were captured with 20 x 50s exposures M3 was captured with 40 x 16s exposures.
The Fits files were stacked with dark-frame correction in Deep Sky Stacker, running in Wine. The resulting images were processed in FITs Liberator and post processed in The Gimp 2.9.
With M3, the stacked image was processed by four transformations in FITs Liberator (arcsin, root, log(root) and log(log)). The images were converted to BMPs and combined with weighting in Andrew Sprott's Flexible Image Combine (FIC).

M3

M64

M104

FULL SIZE
M3

M64

M104

Jupiter with an SVBONY SV105 camera, a Skymax 127 and AstroDMx Capture for Linux

An SVBONY SV105 camera was placed at the Cassegrain focus of a Skymax 127 Maksutov. AstroDMx Capture for Linux was used to capture a 3 min SER file of Jupiter. The best 25% of the 2292 frames captured were stacked in Autostakkert!3 and wavelet processed in Registax 5.1, both running in Wine. The final image was post processed in The Gimp 2.10. Ganymede and the Great Red Spot are both visible.

Considering the fact that the seeing was poor and the telescope only has a 5" aperture, the detail in the image is acceptable from this low cost camera.

Bug in the recent Linux kernels affecting Video 4 Linux

There is a bug that has been introduced into the Linux kernel since April 12, 2018.
The bug manifests itself as each V4L camera on the USB bus being presented twice. This is the information I have at the moments on the versions involved:
This problem has been found on Fedora kernels but may be present in other kernels.

Fedora Linux kernel version

4.15.17    Apl 12    works correctly
4.16.4      Apr 24    kernel bug displaying 2 devices
4.16.5      Apr 27    kernel bug displaying 2 devices

In AstroDMx Capture for Linux, the bug shows itself at connect time:

Screenshot of the camera connect dialogue showing the cameras presenting twice

Everything will work fine if the first instance of the device is chosen.
It should be noted that this is a bug in the Linux kernel, not in AstroDMx Capture for Linux.
The bug has been reported to the kernel developers and we shall have to see how long they take to fix it. At the moment one can solve the problem by booting into an earlier version of the kernel, or by simply choosing the first device when two are presented. Cameras that are not V4L cameras are not affected.
Nicola has implemented a workaround to eliminate this problem. It will be present in the next release of AstroDMx Capture for Linux.