When stars start to get over exposed during data collection, their core may become a different colour than the normally exposed outer halo. When the stacked image is stretched using MaskedStretch in PixInsight, stars are stretched less than dimmer parts. This means that stars in the stretched image are not saturated, and can display an odd colour. PixInsight has a script that can correct star cores of partially saturated stars. It is called "Repaired HSV Separation", and can be found under Scripts -> Utilities. The script should be applied just before the first stretch. It will decompose the colour image into H, Sv, and V colour components, and repair the colour values of the stars.
The different components are then to be combined using the ChannelCombination process (which is under ColorSpaces).
The upper part of the dialog box is used to determine which images are to be created, while the lower part is used for repair of the H, Sv, and V channels.For best results, mainly the Repair level parameter needs to be adjusted.
Alejandro Tombolini (who brought this script to my attention), recommends to use the unrepaired V channel when combining the channels. But experiment to find out if the repaired or unrepaired V channel works best. Be sure to select the HSV colour space.
Here's how it affected one of my most recent images, a before and after shot of the Pleiades (M45). Look at the core of the brightes stars. In the original image, the cores arepink in colour, while in the repaired image, they are blue, the same colour as the outer haloes.
lördag 14 januari 2017
tisdag 3 januari 2017
Correcting dark lines in dslr astro images
My Pentax DSLR suffers from dark horizontal lines when I photograph bright stars. I'm not sure about the cause of this, but it may be some reverse blooming or ADC related issue. This issue isn't uncommon for digital cameras, but it sure is a nuisance.
Alejandro Tombolini showed in one of his processing examples how to deal with these lines. Here's my adaptation of his process.
I will use the CanonBandingReduction script to correct the lines. This script works only on entire images, and can introduce an uneven background and other artefacts when used on images which do not have bands across the entire width.
I therefore start with making a preview that contains the area I want to correct. I leave some margin, because later on I will clone the preview and shrink the clone.
By dragging the preview onto the workspace, I create a new image, which I apply the CBR script on.
The next step is to make this preview the same size as the original image. For this I use the crop tool.
Set the margins such that the image becomes the correct size, with the corrected image now in the same place as the preview in the original. If the result is ok, the image is saved as xisf file.
Next I shrink the preview in the original image and create a hole in the image where the preview is. For this I use pixelmath.
A new image is created with a black patch where the (smaller) preview was.
This image is also saved.
Finally the two saved images (the corrected preview, and the uncorrected image with the black patch) are merged using GradientMergeMosaic.
And this is the corrected image
Alejandro Tombolini showed in one of his processing examples how to deal with these lines. Here's my adaptation of his process.
I will use the CanonBandingReduction script to correct the lines. This script works only on entire images, and can introduce an uneven background and other artefacts when used on images which do not have bands across the entire width.
I therefore start with making a preview that contains the area I want to correct. I leave some margin, because later on I will clone the preview and shrink the clone.
By dragging the preview onto the workspace, I create a new image, which I apply the CBR script on.
The next step is to make this preview the same size as the original image. For this I use the crop tool.
Set the margins such that the image becomes the correct size, with the corrected image now in the same place as the preview in the original. If the result is ok, the image is saved as xisf file.
Next I shrink the preview in the original image and create a hole in the image where the preview is. For this I use pixelmath.
A new image is created with a black patch where the (smaller) preview was.
This image is also saved.
Finally the two saved images (the corrected preview, and the uncorrected image with the black patch) are merged using GradientMergeMosaic.
And this is the corrected image
söndag 27 november 2016
Removing hot pixels in a stacked image
Sometimes even an aggressive hot pixel filter won't remove all hot pixels. Here's a technique that can remove any residual hot pixels in a final stacked image. I use PixInsight's Morphological Transformation with a starmask to remove these nuisances.
Here's a crop of an image, showing what I'm talking about. The image was taken with a DSLR and consists of a stack of 10 sub frames exposed for 15 minutes each at ISO 800. My camera, a Pentax K20D, is getting old, and I always have lots of hot pixels in my images. Calibration removes most, but frequently a number remain after image integration. The technique which I describe here will dim the remaining pixels.
I start with making a Luminance copy of the image in its linear state, and apply STF to this grayscale image. Then I use the StarMask tool with a low value for Scale (typically 3 works ok) and a noise threshold of 0.5 (to be experimented with). I decrease large-scale, small-scale and compensation (1, 0, 1) and smoothness (about 6 - 8). Then apply the mask tool to the luminance copy. It may be necessary to tweak the parameters. No stars should be in the "Star-Mask" that is created.
When I'm satisfied, I apply the mask to the original colour image.
For pixel removal I use Morphological Transformation with Morphological Median as operator. Amount to about 0.5, iterations to 4 - 5, and Structuring Element to 9 pixels with a circular pattern.
Apply the tool to the image. If hot pixels of a certain colour remain, I split the RGB channels and use the channel that has the remaining hot pixels to repeat the process. The result is this.
Further tweaking of the star mask and morphology parameters can improve this result even more, of course.
Here's a crop of an image, showing what I'm talking about. The image was taken with a DSLR and consists of a stack of 10 sub frames exposed for 15 minutes each at ISO 800. My camera, a Pentax K20D, is getting old, and I always have lots of hot pixels in my images. Calibration removes most, but frequently a number remain after image integration. The technique which I describe here will dim the remaining pixels.
| hot pixels after stacking |
When I'm satisfied, I apply the mask to the original colour image.
For pixel removal I use Morphological Transformation with Morphological Median as operator. Amount to about 0.5, iterations to 4 - 5, and Structuring Element to 9 pixels with a circular pattern.
Apply the tool to the image. If hot pixels of a certain colour remain, I split the RGB channels and use the channel that has the remaining hot pixels to repeat the process. The result is this.
| Same crop after hot pixel removal |
Etiketter:
hot pixel,
PixInsight,
PixInsight Byte,
running noise,
streaks,
walking noise
söndag 20 november 2016
First steps in guiding
Finally I have taken the plunge and invested in a guiding setup. I decided for the SkyWatcher ST80 scope with ZWO ASI120MM camera. The camera is the older USB2 version.
As I don't want to take my laptop out in the field, I intend to use a RaspberryPi as a guiding computer.
The last couple of days and nights, I have been trying to get this to work. My configuration at the moment is this:
ASI120MM connected to RaspberryPi, running Ubuntu Mate as an operating system.
The Pi also holds an INDI server and the lin_guider software. The camera connects to the Pi and receives guiding pulses which it sends on to the mount (SW AZ-EQ6 GT) via the ST4 port.
Installation was quite straightforward, despite warnings that the camera driver may not be stable. Setting the exposure time to 1 sec in Lin_guider seems to work fine though.
Last night, despite partial cloud cover, I was able to test the guiding, and it worked fine.
Lin_guider connected to the camera, and frames started to flow in. Focussing was a bit of a hassle. I had to take my laptop out (despite the dew), and because there is no live view, it took a while to get focus right. In the end I had my setup guiding on Vega (which was grossly overexposed at any gain setting), and later on a nearby much fainter star. This worked fine until the stars disappeared behind my neighbour's trees and clouds rolled in.
I haven't tried imaging yet, and I still have to figure out the best settings for PID gain, but so far so good.
As I don't want to take my laptop out in the field, I intend to use a RaspberryPi as a guiding computer.
The last couple of days and nights, I have been trying to get this to work. My configuration at the moment is this:
ASI120MM connected to RaspberryPi, running Ubuntu Mate as an operating system.
The Pi also holds an INDI server and the lin_guider software. The camera connects to the Pi and receives guiding pulses which it sends on to the mount (SW AZ-EQ6 GT) via the ST4 port.
Installation was quite straightforward, despite warnings that the camera driver may not be stable. Setting the exposure time to 1 sec in Lin_guider seems to work fine though.
Last night, despite partial cloud cover, I was able to test the guiding, and it worked fine.
Lin_guider connected to the camera, and frames started to flow in. Focussing was a bit of a hassle. I had to take my laptop out (despite the dew), and because there is no live view, it took a while to get focus right. In the end I had my setup guiding on Vega (which was grossly overexposed at any gain setting), and later on a nearby much fainter star. This worked fine until the stars disappeared behind my neighbour's trees and clouds rolled in.
I haven't tried imaging yet, and I still have to figure out the best settings for PID gain, but so far so good.
Etiketter:
guiding,
hardware,
INDI,
Lin_guider,
Raspberry Pi
lördag 3 september 2016
Creating a customized "Batch Process" in PixInsight
Some processes in PixInsight are adapted for large batches of images. But sometimes you want to do a sequence of process steps, for which there is no batch process, on several images. Opening each image and applying a number of processes is quite tedious.
Fortunately, PixInsight has a solution for this. It involves an image container and a process container.
For any process in PI, if you drag the small triangle in the lower left corner to an image, it will apply that process to the image. This can also be applied to a collection of images, if these are in an image container. And the process doesn't have to be a single process, it can be any number of processes that are in a process container. How is this done?
Now open the image's history explorer, which should be located on the left edge of the workspace. Drag the small triangle at the bottom left to an open area in the workspace. This will create an instance of the process history of that image as a process container in the workspace.
Now you can close the image without saving.
This will create an image container in the workspace. Open the container and add the image files you want to batch process. Also supply a name for the output directory where you want the processed images to be saved. Finish by dragging the small triangle to an empty spot in the workspace. This will create a new instance of your image container, with all the images in it.
Apply the processes in the process container by simply dragging the process container onto the image container that contains the images.
That's it. You've just applied several process to a batch of images.
Fortunately, PixInsight has a solution for this. It involves an image container and a process container.
For any process in PI, if you drag the small triangle in the lower left corner to an image, it will apply that process to the image. This can also be applied to a collection of images, if these are in an image container. And the process doesn't have to be a single process, it can be any number of processes that are in a process container. How is this done?
Prepare the process container.
Open an image and apply the processes you want to batch to that and other images.Now open the image's history explorer, which should be located on the left edge of the workspace. Drag the small triangle at the bottom left to an open area in the workspace. This will create an instance of the process history of that image as a process container in the workspace.
Now you can close the image without saving.
Create an image container
Next create an image container by right clicking anywhere in the workspace, or press Ctrl+Alt+I.This will create an image container in the workspace. Open the container and add the image files you want to batch process. Also supply a name for the output directory where you want the processed images to be saved. Finish by dragging the small triangle to an empty spot in the workspace. This will create a new instance of your image container, with all the images in it.
Apply the processes in the process container by simply dragging the process container onto the image container that contains the images.
That's it. You've just applied several process to a batch of images.
tisdag 16 augusti 2016
Vibration damping the EQ3 aluminium tripod
The EQ3 mount with the aluminium tripod is generally considered not to be suitable for astrophotography. Still, it's a nice, portable mount that, under the right circumstances, can produce relatively good images.
There is an article on cloudynights.com that describes how the tripod can be beefed up. The author of that article increases the weight of the tripod by putting rebar in the upper legs, and a rectangular wooden dowel in the lower legs.
The problem with the tripod is not just a weight problem, but rather a vibration problem.
Filling up the hollow legs with dowels and rebar, doesn't necessarily improve the vibration characteristics of this mount. A person commenting on the cloudynights article, suggested that the legs can also be filled with sand. This will result in both a heavier tripod and different vibration characteristics.
I decided to modify my tripod by inserting wooden dowels in the upper and lower legs. But I also secured these dowels to the plastic and aluminium structure. Hopefully, this will improve the vibration damping of the tripod, without it becoming too heavy.
Starting with the lower parts of the legs, I removed all the plastic parts and inserted oak dowels into the aluminium tubes. I noticed that the plastic feet of the tripod are hollow and extend a bit up into the legs. By making the dowels somewhat thinner, and drilling a hole, where the hole in the plastic is, I could fasten the wooden dowel to the plastic foot and later the aluminium leg, and even the top lid of the leg.
I then inserted two round beech dowels (12 mm diameter) into the lower parts of the legs, making sure there was a tight fit at either end. Unfortunately, it's not possible to fasten these dowels, other than through a tight fix and the small screws that hold the leg spreader in place.
It doesn't take long to get all three legs done.
Finally, reassembling the tripod, it looks as before.
The tripod now weighs 3.6 kg, not much more than before, but it feels steadier.
For a short while I also thought of filling the tripod with sand. I found out that the tripod legs are not sealed at the lower ends, and most of the sand will run out after a while. Filling the tripod, will also make it much heavier. Hopefully, the wooden dowels will improve the damping.
Now all that remains is a clear night to test the tripod.
There is an article on cloudynights.com that describes how the tripod can be beefed up. The author of that article increases the weight of the tripod by putting rebar in the upper legs, and a rectangular wooden dowel in the lower legs.
The problem with the tripod is not just a weight problem, but rather a vibration problem.
Filling up the hollow legs with dowels and rebar, doesn't necessarily improve the vibration characteristics of this mount. A person commenting on the cloudynights article, suggested that the legs can also be filled with sand. This will result in both a heavier tripod and different vibration characteristics.
I decided to modify my tripod by inserting wooden dowels in the upper and lower legs. But I also secured these dowels to the plastic and aluminium structure. Hopefully, this will improve the vibration damping of the tripod, without it becoming too heavy.
![]() |
| Wooden dowel cut to size, ready to be inserted in the lower leg |
![]() |
| Wooden dowel will be secured to the plastic fott and the aluminium leg |
![]() |
| Top part of the lower leg |
![]() |
| One half of an upper leg |
![]() |
| Dowels inside the upper leg |
![]() |
| All three legs completed. Time for reassembly |
![]() |
| Done! |
For a short while I also thought of filling the tripod with sand. I found out that the tripod legs are not sealed at the lower ends, and most of the sand will run out after a while. Filling the tripod, will also make it much heavier. Hopefully, the wooden dowels will improve the damping.
Now all that remains is a clear night to test the tripod.
lördag 13 augusti 2016
First experience with INDI on Raspberry Pi - part 2
Last week , when I tried to control my mount through indi on a Raspberry Pi, I managed to install the server and connect from my laptop to the indi server on the RPi. However, the mount didn't respond. It turned out that the USB serial cable didn't work anymore.
Yesterday I received an EQDIR cable from FLO, and connected it to the mount. After some adjustment of the parameters in linux and the Indi client, it all worked perfectly.
Now I can control my mount from PixInsight or any client that can run the indi protocol.
The next step will be to install and test servers.
Short recap of the installation so far.
Of course, this assumes that the mount is aligned, and so far PixInsight can't do a 2-star alignment.
I just hope that this will be implemented soon.
For the time being, my intended workflow is as follows.
Yesterday I received an EQDIR cable from FLO, and connected it to the mount. After some adjustment of the parameters in linux and the Indi client, it all worked perfectly.
Now I can control my mount from PixInsight or any client that can run the indi protocol.
The next step will be to install and test servers.
Short recap of the installation so far.
- Install an Ubuntu Mate image on a SD card for the RPi
- Connect the RPi to the home Wifi network and set parameters to connect to PuTTY
- Connect to the indi repository, download and install the indi server
- Set $USER for dialout permission
- Create a permanent USB entry for the connector
- Start the server
- Start the client and connect to the server
- Configure the site and the mount in the client
Of course, this assumes that the mount is aligned, and so far PixInsight can't do a 2-star alignment.
I just hope that this will be implemented soon.
For the time being, my intended workflow is as follows.
- Haul out the mount and set up
- Level mount
- Start mount with SynScan
- Do a polar and a 3-star alignment
- Park the mount and power off
- Disconnect the SynScan
- Connect the RPi and boot
- Connect the client
Prenumerera på:
Inlägg (Atom)



















