Saturday, 22 January 2022

Alt-azimuth and Equatorial mounts for observers and imagers

Alt-azimuth and Equatorial mounts both have their strengths and both have their weaknesses. Which is best depends on the use to which you currently want to put it.

Alt-azimuth mounts are the easiest and quickest to set up. The prime requirement is that the mount should be level. The provision of a level observing/imaging area is a great help for either kind of mount. Marks on the floor facilitate the placing of the mount legs for either kind of mount.

iOptron Alt-azimuth mount with a CaK solar telescope mounted for imaging

Some Alt-azimuth mounts such as the Meade ETX need to be level and the scope facing north. Some, such as the iOptron Cube Pro that we often use requires the mount to face south, but the scope to point to the zenith. A magnetic compass is normally sufficient to acheive adequate north or south alignment. Mounts such as the Skywatcher AZ mounts for example, the Star Discovery, can be set up level and facing north. When started in this configuration, they can be sent immediately to the required objects without further alignment. The accuracy depending on how good the level and north are set up.

GPS can either be built into a mount as it is with the iOptron Cube Pro, or it can be an optional accessory for an Equatorial mount. GPS can reduce the amount of time required to set up a mount as when the GPS has aquired enough satellites the system knows the date, time, Latitude, Longitude and altitude and these parameters don't need to be entered manually via the hand controller.

Equatorial mounts have a requirement for accurate polar alignment and this can be done in several ways. In the northern hemisphere, if polaris is visible and a polar scope is fitted and correctly collimated, the mount can be polar aligned using Polaris and the polar reticle. In the southern hemisphere other target stars are used for polar alignment with a polar scope.

Skywatcher HEQ5 mount with a Bresser 102mm refractor mounted

Celestron AVX Equatorial mount with a Skymax 127 mounted

It can be seen that the tripod has been placed on marks on the level concrete base. Moreover, it can also be seen that the building obscures polaris so, polar alignment cannot be done by means of the polar scope or polar alignment camera. In this location (the only location that this particular mount is used), Celestron's Any Star Polar alignment was used to adjust the altitude and the azimuth of the polar axis to achieve a good polar alignment. Using the marks on the ground, the mount can be placed and alignment using alignments stars and calibration stars can be acheived that gives excellent tracking. Using auto-guiding, long exposures of several minutes can easily be achieved.

In northern latitudes it can be quite uncomfortable bending, kneeling and peering throgh a polar scope. Fortunately there are alternative methods using cameras such as the QHYCCD PoleMaster which can get the polar alignment within 30 arc seconds of the NCP.

 A QHYCCD PoleMaster fitted to an HEQ5 mount in our observatory

For visual observing, the Alt-azimuth system is the most covenient and comfortable system to use. We can set up the iOptron Cube Pro mount within about 5 minutes and an equal time to put away the equipment. 

If we are capturing a lunar SER file or a couple of overlapping Solar SER files, the whole process of setting up, imaging and putting away can take as little as 20 minutes. 

Setting up the Equatorial system takes about 30 minutes to set up and a similar amount of time to put the equipment away. Setting up takes comensurately longer if autoguiding is to be used.

For quick imaging of the Moon, Sun or a planet, the Altazimuth system is the quickest and easiest to set up. That being said, the AVX EQ mount is rock solid and there is very little shake if the scope is being manually focused, whereas with the iOptron AZ being on a less substantial tripod, experiences shake when manually focusing the scope resulting in longer focusing times. The issue disappears if motor-focusing is used.

The iOptron AZ system is not suitable for heavy equipment, but there are much more heavy duty AZ systems available that can work with heavier scopes.

Field and image Rotation

For visual observation this is not a problem, but it is a potential problem for imaging.

The Sky rotates through the night and with it, the objects that we observe and image. As a thought experiment, imagine a vertical rod with a ball on top of it rising in the east. By the time it reaches the meridian in the south, it will be horizontal and by the time it sets in the west, it will be vertical again but with the ball at the bottom.

This will be true for any astronomical objects rising, moving across the sky and setting; rotating slowly as they go. If binoculars were mounted on an Alt-azimuth mount, they would always be parallel to the horizon and a viewed object would slowly rotate as the night passes. However, binoculars mounted on a Equatorial mount would gradually rotate with the sky presenting the same view of the astronomical object viewed through the binoculars.

Stellarium simulation of the Moon viewed through an Alt-azimuth system between the hours of 1am and 4am on January 21, 2022.


Actual view of the Moon captured at 0:20 by AstroDMx Capture for Windows and  a ZWO ZWO ASI 178MC with a 66mm, f/5.9, APO, ED doublet refractor mounted on an iOptron Cube Pro AZ mount.


The image is a stack of the best 50% of the frames in a 2000-frame SER file, stacked in Autostakkert! wavelet processed in Registax 6 and post-processsed in the Gimp 2.10.

The thing to notice is that there was no problem capturing the image data on the Moon during this session. This is because during the capture of the data (a period of 1m 16s) there was no significant rotation of the Moon at this image scale.

However, if we wished to image a deep sky object such as the Orion nebula, we would need to collect a large number of sub-frames to stack. The exposures just have to be short enough to ensure that there is no significant image rotation WITHIN the capture of an individual sub-frame.

On a night with no significant interference from the Moon A William Optics Zenithstar, 66mm, f/5.9, APO, ED doublet refractor was mounted on an iOptron Cube Pro AZ GOTO mount. A ZWO ASI 178MC camera was placed at the focus. 

AstroDMx Capture for Windows was used to capture 200 x 12s exposures of the Orion nebula with matching dark frames. The 200 frames were simply stacked in Registax 5.1.

An AZ mount tracks the sky in such a way that image rotation occurs over time. and this was evident in the stacked image. The image was post-processed in the Gimp 2.10.

Image of the Orion nebula showing rotation


The same data were stacked in Deep Sky Stacker which is able to derotate the images before they are stacked. The image was post processed in the Gimp 2.10.

Image of the Orion nebula derotated


The next image demonstrates that the stars in the derotated image are exactly coincident with the star trails in the rotated image.


Finally processed derotated image to reveal more nebulosity and also revealing the extent of derotation

The important point is that as long as the exposures are short enough so that rotation WITHIN an image is not significant, then an Alt-azimuth mount can be used for deep sky imaging as the data can be derotated when they are stacked.

Some Alt-azimuth systems have available mechanical derotators that remove the effect of rotation when collecting image data. Probably one of the best (but expensive) Alt-azimuth mounts is a Track The Stars TTS-160 PANTHER TELESCOPE MOUNT. For this system there is also available a telescope rOTAtor. With this unit installed on the mount head the telescope will track equatorially for long exposure Astrophotography. Yes, equatorial tracking with an Alt-azimuth system!

With an Equatorial mount, well polar-aligned, long exposure is easily possible. With auto-guiding we have achieved 20minute exposures with no star movement between exposures and 5minute exposures are routine. A recent imaging session with the same equipment on the AVX EQ mount can be seen HERE. That session was atypical for us as we were doing ST4 autoguiding to test the SV905nguide camera in that mode. Typically we would use pulse guiding but the ST4 auto-guiding worked well.

The message here is that whether you have an Equatorial mount or an Alt-azimuth mount, you will be able to do imaging of deep-sky objects. Whatever mount you have it is imperative that it is set up as well as possible in terms of level, orientation, polar alignment etc. Any deviation from the optimal situation will compromise the tracking required for the imaging. The shorter the focal length of the scope you are using, the more forgiving it will be.

Experimentation is required to find out for your system, the maximum realistic exposure you will be able to get results from. Based on this, you will be able to plan your imaging session with the best chance of success.

Sunday, 16 January 2022

Testing the SVBONY SV905C as an ST4 guiding camera

 Testing the SVBONY SV905C as an ST4 guiding camera

Plus an experiment with an Optalong LeNhance filter for imaging under a bright Moon.

A William Optics Zenithstar, 66mm, f/5.9, APO, ED doublet refractor was mounted on a Celestron AVX EQ GOTO mount. A 14bit ZWO ASI 178MC uncooled camera was placed at the focus. For the main test the ZWO camera was fitted with a dual narrowband Optalong L-eNhance filter that transmits light of H-alpha, Olll and H-beta wavelengths, whilst cutting out other wavelengths, including much of the continuum light from the Moon and the sky glow. This test was done under a 92% waxing Moon which was very bright in the sky and above Orion. The Orion nebula was the imaging subject of the imaging session although some preliminary auto-guiding tests were done with the Pleiades.

A 50mm F=190mm guidescope was mounted on the 66mm refractor and an SVBONY 905C camera was used for ST4 multi-star auto-guiding with PHD2.

Click on an image to see a closer view

Equipment used


Initially the L-eNhance filter wasn’t used and the scope was aimed at the Pleiades. The SV905C camera was used for multistar ST4 autoguiding with PHD2. The longest exposure tested was 5 minutes and absolutely no movement was seen between images in successive exposures. This was evidence that the camera functioned well as an ST4 guide camera. These days, most people, including ourselves, use the superior pulse guiding method. With pulse guiding, PHD2 ‘knows’ where in the sky the scope is pointing whereas with ST4 it doesn’t. There are consequences of this such as having to recalibrate the guiding if you stop guiding and slew to a new target in a different part of the sky. Nevertheless, there are many who do use ST4 auto-guiding, and this test shows that the SV905C would be a suitable ST4 guide-camera for them.

Stack of 5 x 5 minute exposures of some of the stars in the Pleiades. It was not intended to produce an image but rather for testing the ST4 auto-guiding prior to imaging the main subject, the Orion nebula when it rose into a suitable position.


The ST4 auto-tracking using the SV905C was flawless on these test stars.

In order to image the Orion nebula which is bright and easily ‘visible’ to the guide camera, it is best to angle the guide-scope so that it is not parallel to the imaging scope. In this way, the bright nebula being imaged does not interfere with the guiding process.

The Guide-scope is set at an angle to the direction in which the imaging scope is pointing


The SV905C camera can be seen mounted on the guide-scope.

This shows the advantage of a six point suspension of the guide-scope within the guide-scope rings, allowing the scope to be directed in an optimal direction for the guide stars.

AstroDMx Capture for Windows was used to capture 100 x 30s exposures and 15 x 60s exposures of the Orion nebula, with matching dark-frames, using the 14bit, uncooled ZWO ASI 178MC camera fitted with the Optalong LeNhance dual band, narrowband filter.

Screenshot of AstroDMx Capture saving Fits data on the Orion nebula


Screenshot showing PHD2 controlling ST4 auto-guiding with the SV905C guiding camera


The auto-guiding performed quite well during the collection of data on the Orion nebula.

The FITs files were calibrated and stacked in Deep Sky Stacker and post processed in the Gimp 2.10, FastStone, and Neat Image.

The Orion nebula with an Optalong LeNhance filter and a 14bit ZWO ASI 178MC camera 



These experiments showed that the SV905C camera functioned well as an ST4 guiding camera.

They also demonstrated that the 14bit ZWO ASI 178MC uncooled camera, with the LeNhance narrowband, dual band filter, could image the Orion nebula in bright moonlight.


Thursday, 6 January 2022

The SV905C camera now fully supported in 16 bits

The SV905C camera is now fully supported in 16 bits on all Operating Systems in AstroDMx Capture


SVBONY have now produced a firmware upgrade for the SV905C camera that fixes the issue we  discovered with 16 bits. 

The upgraded camera now works correctly in AstroDMx Capture for Windows, macOS, Linux, Raspberry Pi OS and Chrome OS. 

AstroDMx Capture can be freely downloaded HERE

Sunday, 2 January 2022

New Year feature release of AstroDMx Capture with full support for the SV905C

New Year feature release of AstroDMx Capture



Mutatis mutandis

AstroDMx Capture now supports the new SVBONY SV905C planetary and guiding camera on all Operating systems including Chrome OS.

The following Changes have been made.
  • The SDK issue for x86 64 Linux has been resolved by SVBONY, which means that the SV905C camera is now supported in AstroDMx Capture for Linux (including the Raspberry Pi and Chrome OS) in addition to the Windows and macOS versions.
  • Another SDK issue for all operating systems means that for the moment, the SV905C only works correctly in 8-bt mode for planetary type imaging.
  • A button enabling automatic display stretching for 16-bit data to be turned on and off has been implemented. Previously, this was on by default. However, when capturing very short 16-bit exposures, the automatic stretching caused the preview to appear very bright and/or apparently noisy. This also enables easier combination of some of the 16-bit controls.
  • The dew-heater control (when present) has been relocated to a better position in relation to the cooling function control (when present)
  • Binning issue resolved.

It is interesting that so far, the only astronomy cameras that we have found to work with Chrome OS are the SVBONY cameras:
  • SV305
  • SV305 Pro
  • SV305M Pro
  • SV905C
As Chromebooks are in general, less powerful than other computers, having slower central processors, less RAM and less storage (apart from the very high end Chromebook models); the SV905C camera may be a better choice for planetary, lunar or solar imaging with a Chromebook as it produces an image of only 0.6 the size of those produced by the SV305 family of cameras and may achieve a better frame rate.

AstroDMx Capture can be downloaded freely HERE

Friday, 24 December 2021

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

Monday, 20 December 2021

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















Sunday, 12 December 2021

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!


Wednesday, 8 December 2021

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.


Thursday, 2 December 2021

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


Saturday, 6 November 2021

AstroDMx Capture in a Chromebook via Crouton

In recent months I have written a number of articles about using AstroDMx Capture in a Crostini Linux virtual machine on a Chromebook. The Crostini Linux environment is now stable on Chromebooks. We have shown that it is easy to set up Linux under Crostini and to install a number of important Linux programs for astronomical imaging. We have also shown how to install the Windows compatibility layer Wine so that we can run Windows programs such as Autostakkert! And Registax on a Chromebook.

Crostini

Installing AstroDMx Capture for Chrome OS on the Crostini virtual Linux container allows us to capture images and movies. There are, however, limitations: 

One limitation is that responsiveness is slow, but the program is still very usable. The slow responsiveness is not surprising considering the fact that Chromebooks are, in general, low powered computers with little RAM and Storage, and with low end processors. On top of this, the Linux environment is running inside a virtual machine running in Chrome OS. All of these facts lead to performance penalties. Of course, there are some Chromebooks now available with much higher all round specifications and coming at commensurately higher prices. No doubt the software will be more responsive on these machines. 

Another limitation is that the only cameras that we have found to work properly in the Crostini virtual Linux environment on Chromebooks have been the SVBONY SV305 family of CMOS astronomy cameras. It is not immediately obvious why these cameras work well and others do not. Possibly it is due to the adherence to standards, but the reason could lie elsewhere. The fact remains that at the time of writing, cameras have not been implemented by Google in Crostini. The cameras to which I am referring to are UVC cameras, and most astronomy cameras are not UVC devices.

Crouton

For several years there has been a different way of running Linux on a Chromebook. This system is called Crouton.

Crouton was originally created by Google employee David Schneider. When you use Crouton, you're actually just running one operating system: Linux. However, you are running two environments with Chrome OS.

Crouton stands for Chromium OS Universal Chroot Environment

Crouton is a set of scripts that form a Chrome OS  chroot generator.

What's a chroot?

Chroot stands for Change root. The chroot call originated in Unix 7 in 1979 so it is not a new concept. Unlike Crostini, a chroot is not a virtualisation system.

However, like virtualisation, a chroot provides the guest OS (In this case Debian Linux) with its own, isolated file system to run in, allowing applications to run natively in a different environment from the host OS. Unlike virtualisation, you are not booting a second OS; instead, Debian Linux is running using the Chromium OS system and kernel and effectively uses the Chrome browser as its X-server as a GUI for the running application. The benefit to this is that there is no speed penalty since everything is run natively, and you don’t use lots of RAM to boot two operating systems at the same time.

To visualise this we must be aware that the Chrome OS has its own file system with its own root. It is, basically, an operating system with a Linux kernel and using the Chrome browser as its desktop environment. 

Crouton sets up another totally isolated file system with its own root on the computer and installs Debian Linux  into it. This Debian does not have its own kernel, it uses the Linux kernel of Chrome OS. The chroot changes the root to the Debian OS and it is within this system that programs are installed and run natively, without the performance penalties associated with virtualisation.

We have set up Crouton on a Lenovo Chromebook with an AMD A6 processor, 4GB RAM and 64BG of eMMC storage; a fairly modest Chromebook.

We installed AstroDMx Capture for Linux into the Debian system and were able to run it natively with no performance penalties.

There are three limitations that are not too important at the moment:

First, it is not possible to take a screenshot that includes the preview screen of AStroDMx Capture due to the way it is rendered by the Crouton system.

Second, it is important NOT to try to close the software in the usual way by clicking on the cross at the top right of the display. In fact, this is NOT a control to close down AStroDMx Capture; it is a control to close down the Chrome browser in which AstroDMx Capture is being displayed. It is necessary to close the software via the file menu.

Third, we have found that the QHY series of cameras will not work with the Crouton system. QHY cameras have to have their firmware uploaded each time they are started, and it is probably this process that is currently inhibiting the use of these cameras. Nonetheless, Crouton allows the use of many cameras that are just not possible to use under Crostini.

This is a work in process and it is not considered that these three  limitations are important at the moment

Unlike with the Crostini virtualisation system, we are not limited to using the SVBONY SV305 series of cameras, and in the current test we used a Touptek Toupcam GPCMOS01200KPF camera. 

Testing AstroDMx Capture for Linux using Crouton

An f/5.5, 80mm, ED Ekinox Eklipse refractor was mounted on a Celestron AVX mount and a Touptek Toupcam GPCMOS01200KPF camera was placed at the focus.

A Lenovo Chromebook with an AMD A6 processor was used running a Crouton chroot with Debian Linux, a way of running Linux on a Chromebook that does not involve the Crostini virtualisation system.

AstroDMx Capture for Linux was run natively in the chroot and was used to capture 60 x 15s exposures of M15 using the RGB48, 16-bit format along with matching dark frames.

The data collected were processed on a separate computer as this was simply a test of AstroDMx Capture with Crouton. However, it would be possible to install all of the software required to do the stacking and post-processing if this was to be a system that would be used for imaging on a regular basis.

Equipment used


Final image of the globular cluster M15


To set up Crouton on a Chromebook, you have to do a Powerwash and set the Chromebook in Developer mode. It is therefore important to back up any files you may have stored locally. Developer mode is less secure than the normal mode and Chrome OS reminds you of this when you turn on the computer by making some beeping sounds. (These can be avoided by pressing ctrl and d during power on). However, remember, that you are working with Linux which is pretty secure in its own right, and you are doing this in order to get more out of your Chromebook and use it to run AstroDMx Capture for Linux natively. Moreover, if you don’t invoke Crouton, you still have the full functionality of your Chromebook albeit in the slightly less secure Developer mode.