SGPro can't connect to my FLI camera anymore!!!

I finally cleared up and I wanted to take the remaining data for my Heart Nebula image. Set everything up. Checked everything (so I though during the day) and when I wanted to start imaging...

... SGPro couldn't connect to my FLI camera anymore!!!

I clicked the connect button, it would turn to green and then after a while would disconnect again. In the SGPro logs I could see:

[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] Connecting camera in main thread...
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] Connecting FLI camera...
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] Querying for FLI USB cameras...
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] FLI Camera Name: MicroLine ML16070(HW: 256; FW: 292)
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] FLI Library Version: Software Development Library for Windows 1.104
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] FLI CCD Dimensions: 4954x3300
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] FLI Visible CCD Dimensions: 4864x3232
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] FLI Pixel Size: 7.39999995857943E-06x7.39999995857943E-06
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] FLI Camera Mode: 0
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] FLI Avaialble Camera Modes: 
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] - 0: 11 MHz
[12/17/2016 7:08:41 PM] [DEBUG] [Main Thread] - 1: 4MHz
[12/17/2016 7:08:41 PM] [DEBUG] [TEC Thread] SGM_CHANGE_COOLER_TEMP message received...
[12/17/2016 7:08:41 PM] [DEBUG] [TEC Thread] TEC Change: Starting...
[12/17/2016 7:08:41 PM] [DEBUG] [TEC Thread] TEC Change: After camera connect change, waiting ~5 seconds...
[12/17/2016 7:08:46 PM] [DEBUG] [TEC Thread] TEC Change: Attempting to turn the camera cooler on...
[12/17/2016 7:08:46 PM] [DEBUG] [Main Thread] Turning camera cooler on...
[12/17/2016 7:08:46 PM] [DEBUG] [Main Thread] Turning camera cooler on...
[12/17/2016 7:08:47 PM] [DEBUG] [Equipment Connectivity Thread] SGPro thinks the camera is connected, but it's not, syncing UI...
[12/17/2016 7:08:47 PM] [DEBUG] [Equipment Connectivity Thread] Adding sequence level notification: External disconnect of camera detected...
[12/17/2016 7:08:47 PM] [DEBUG] [TEC Thread] SGM_CHANGE_COOLER_TEMP complete...
[12/17/2016 7:09:12 PM] [DEBUG] [Main Thread] Turning camera cooler off...
[12/17/2016 7:09:12 PM] [DEBUG] [Main Thread] Disconnecting FLI camera...
[12/17/2016 7:09:13 PM] [DEBUG] [Main Thread] Turning camera cooler off...

Tried various things (restart SGPro, restart computer, different cable...) with no effect. The weird thing was that other apps (FLI Grab, TSX) could connect and use the camera.

I posted on the SGPro mailing list and it seems as if this is a regression in one of the latest builds. I tried 2.5.2.8 and 2.5.2.6 without luck. Only when reverted back to 2.5.2.3 (quite old!) it that worked. Phew!

Remote Control of the MicroTouch focuser

I started with the MicroTouch Controller app:

It had quite a number of issues:

1. Setting the Target Position
   When I tried that, I got an error message "Value Entered Out of Range. Must be between 0 and 0".
   Upon checking the "Setup" tab, I noticed that both the "Min Value" and "Max Value" were set to 0. When I tried to set the "Max Value" to a larger number, it seemed to do something (app was blocked for a second or two). But when control returned, it was still set to 0. Tried many things, always with the same result.
   It then wasn't surprising that I couldn't set the "Min Value" - it always gave an error: "Min Position must be less than Max Value".
   I also checked the Diagnostics tab, but it showed 0 corrupted packets and 0 packets dropped.
2. Updating Firmware
   Next thing I tried was to update the Firmware of the controller. Mine was at 3.8, the last version was 4.4. I used the MicroTouch Flash Loader app
   
   I selected the MicroTouch_4_4.bin file. But when I press "Program", the Status changed from "Idle" to "Opening USB Port" ... and then nothing happened. Always the same result
3. But I could change the focuser position with the IN and OUT button on the handcontroller, so I thought that I should be able to change it with the up and down arrows in the Controller app. But nothing happened when I pressed those.
   ... until I plugged in a mouse (instead of using the Asus touchpad)! Then the buttons suddenly worked!!! I have absolutely no idea what this is about. The touchpad click should trigger the exact same even then a mouse press...
   Well at least I know now how I could use it.
4. From SGPro
   In SGPro, I selected "MicroTouch Focuser 1" as my focuser (the app / handset is able to control 4 focusers in parallel). Then I clicked setup ... nothing changed. Until I noticed that SGPro opened a new window UNDER its own window (I think I noticed that with other popups before). This was the "MicroTouch Focuser Setup" popup:
   
   I opened the drop down menu of "Focuser 1" and selected the entry 1532 - I guess that's the serial number of my focuser ...
   Then everything worked in SGPro! Could move focuser in and out and also set absolute positions!!! (unlike in the MicroTouch Controller app)
5. From TheSkyX
   There were some instructions in the MicroTouch drive/app package to copy certain files into the TSX directories. But when I tried that, the same files were already there. Seems as if TSX is packaging these up right now. But when I then tried to connect to the focuser I always received an error "No connection to the device. Error = 215."
   And when I then read the instructions again, they said that I would need firmware version 4.4 in my controller to connect to it. So, back to #2.

I sent an email to Starlightinstruments and asked for help with #1 and #2...

PC-USB Pressure Tuner Controller for Lunt Scope

In addition to focusing, I also want to control the pressure tuner from the computer. Luckily, Lunt offers the PC-USB Pressure Tuner Controller. I ordered it and after a few weeks it arrived.

It consists of:

1. AC/DC adapter (15V)
2. Air Pipe
3. Large and Small O-rings
4. New cover cap (with a hole in the middle)
5. A different Piston
6. A USB stick with the software
7. Instruction sheet
8. The PC-USB unit

Most notably absent were proper installation instructions ...

I searched and found one that I stored in my Google Drive.

1. Unscrew the pressure tuner

2. Unscrew the cover cap
3. Take the little screw out and remove the piston. I found that it was easiest by putting the pressure tuner on a paper towel as the piston inside was very greasy:
4. Now insert the new piston
5. And now insert the new screw (with a hole in it) and tighten the piston

6. Finally put the new cover cap (also with a hole) on it:

and put the pressure tuner on the scope again (tighten it all the way)

Now, we connect the pressure tuner with the air pipe to the PC-USB unit

Powering on the PC-USB unit shows:

And once done, we can set a target pressure and the unit will adjust accordingly (you can hear the pump in the unit working!) It usually sets the pressure slightly higher and once the pressure drops, it will increase it again to stay around the target value.

---

PC-USB Pressure Tuner Controller Manual

Micro Touch Focusing System for the Lunt scope

Of course, I wanted to focus my new Lunt scope also from the computer. Luckily, I still had a Micro Touch Focusing System that I once tried to use on my Edge scope. I checked with Wayne from Starlight Instruments and it turned out that I could even use the MSM20 stepping moter from the EDGE scope.

... but when I tried it, the motor didn't work well - got stuck from time to time, so I had to order a new one.

Installation of the motor on the Feathertouch Focuser is fairly simple. The motor gets attached on the side of the red micro focusing cog:

1. we unscrew the red cog:

2. we unscrew the black wheel:

3. Take the little cog that came with the MSM20 motor

push it flush on the axis and tighten the screw

Finally, take the motor

Push it onto the axis. Might have to wiggle it a little to make sure that the two cogs interlock

until it is completely on the axis and you can't see any silver anymore

and finally tighten the screw:

And now we connect the motor to the Micro Touch Focusing unit and can either more the focuser in out with the control box

Next was to control the focuser from the computer - which turned out to be very tricky.

Bubble Nebula and around

I took a narrowband image of the Bubble Nebula and surroundings (a two image mosaic):

(click on image for full resolution)

Because of the image scale, there is a lot of detail here:

     

Bubble Nebula

NGC 7510 - an open star cluster

     

Outer arm of Sharpless-157

Core of Sharpless-157

NGC 7538

Apart from the long exposure time (23+ hours), it took me a long time to process this image:

• I used a more elaborate preprocessing in Pixinsight, using weights, drizzling (and ran into some issues that turned out to be a bug in the ImageIntegration script)
• merging the images to a mosaic (and an issue to align the individual frames)
• I needed to use both HRDMultiscaleTransform to get details in the brightest areas of the image, and also LocalHistogramTransformation to get details in the other parts of the nebulae
• and finally using LayerMasks in Photoshop to fix local issues of a process (instead of trying to create a specific mask in Pixinsight) - for which I had to figure out how to transfer images from Pixinsight to Photoshop and back

But it was worth the effort!

... and finally I had to figure out how to upload this large image to Blogger ...

Uploading a large mosaic to Blogger

When I tried to upload the jpg from my latest mosaic to Blogger I always got an error message (image too large). I reduced the images size more and more until it was a few K (and a horrible resolution). But still the same error.

And then it dawned on me: maybe it's not the image size, but the image dimensions! I reduce the image dimensions by 50%, created a JPG (5.2M) ... and could upload it with no issues!!!

A more specific error message in Blogger ("image too large") would have been helpful here ...

Fixing slight cosmetic issues with Photoshops Layer Masks - instead of creating a mask in Pixinsight

As always, I tried to remove the magenta from my latest narrowband images. And while it worked well on all the stars it also left some cosmetic issues in some bright areas of the image:

I tried a couple of adjustments

• adjusted the formula to adjust green - but either the stars stayed magenta, or I created these artifacts again
• used an inverted star mask to protect everything but the stars - but because the magenta color is mostly in the fainter outer halos of the stars, it didn't work
• used a range mask that just selected the areas where these issues occurred - but I could adjust the mask fine enough

I ended up fixing it with a completely different idea from how we blended the milky way images:

1. I stored the image before running Pixelmath to remove the magenta and after.
2. I open both images in Photoshop as layers with the processed image on top
3. I create a "Reveal All" layer mask on the top layer
4. Carefully drawing with black brush over the areas with the cosmetic issues - thus revealing the unprocessed image underneath

And now I could load it again in Pixinsight for final processing.

From Pixinsight to Photoshop - and back

In the past I tried a couple of times to save an image in Pixinsight and process it in Photoshop. I figured that the best format would be TIFF. But every time I tried it, the image opened up in black and white or with very distorted color.
Turns out I have to chose "16-bit unsigned integer"!

Yei!!!

*** Error: Current image height differs from first image height. - When using GradientMergeMosaic

For my bubble nebula images, I followed again the tutorial from LightVortexAstronomy for creating mosaics. It worked all well until I wanted to merge the first two images and received the following error:

*** Error: Current image height differs from first image height.
<* failed *>

And upon closer inspection of my two Ha images, it turns out that one has a dimension of 9561x11410 and the other of 9561x11409 (i.e. one row less then the first one). I read about it and it turns out that this can happen when StarAlignment tries to align my images with the rough mosaic and through corrections, the resulting image "sticks" a little out. When looking at my rough mosaic:

You can see that the image on the lower bound and lower left and upper right comes right to the end. I.e. it's easy that individual pixels can be moved over resulting in two images that don't have the same dimensions.
Some people recommend to fixing it by just use the Resample process to adjust the dimensions of one image to the other. I didn't like the idea to needlessly shift the image by a column/row and loose some accuracy in the data.
After trying various ideas, I realized that I can fix this by just making the rough mosaic image a little larger:

Extended image (using DynamicCrop)

This is easy using the DynamicCrop process and dragging the borders outwards.

Now, when aligning the rough mosaic with the individual images, the dimensions are the same - plus some black borders around the image:

But the dimensions are the same! And now I can use GradientMosaicMerge to merge them together to one larger image:

And then I can crop all the dark borders out. Voila!

Comparing various Pixinsight preprocessing processes

So far, I used the Preprocessing script in Pixinsight with the default values (except for using different pixel rejection algorithms depending on the number of subs). Kayron Mercieca has on his Lightvortexastronomy blog a tutorial using custom weights, preprocessing, ImageIntegration with Sigma High and Low parameter optimization and DrizzleIntegration for this. This will take MUCH longer to preprocess my images, so I wanted to try out what the different modes do:

1. Preprocess Script with default values
2. Preprocess Script for calibrating and registering and ImageIntegration with Sigma High and Low parameter optimization
3. Custom Weights (using the Subframe selector script) plus everything in #2
4. Everything in #3 plus DrizzleIntegration

I then used the SubframeSelector script in Pixinsight to measure these images:

	FWHM (pixel)	SNRWeight
#1	1.766	3.427
#2	1.770	3.692
#3	1.754	3.710
#4	3.693	6.927

The FWHM increase in #4 is surprising. But remember that drizzling upsamples the entire image by 2. So, for a better comparison, I downsampled #4 by 2:

	FWHM (pixel)	SNRWeight
#4 - downsampled	2.016	7.249

The degradation in FHWM is unfortunate - but the increase in SNR is amazing!!!

---

Vicent recommended to try Gaussian drops for DrizzleIntegration. He saw in my sample images a significant drop in FWHM. With that, I get:

	FWHM (pixel)	SNRWeight
#4 - downsampled Gaussian drop	1.953	5.674

First observation was: Drizzling with Gaussian samples is MUCH slower (several times slower then with square drops).

So, FWHM is significantly down. But so is the SNR. Vicent recommended to set the "Drop Shrink" parameter to 1 if I use Gaussian drops. With that, I get:

	FWHM (pixel)	SNRWeight
#4 - downsampled Gaussian drop - Drop Shrink=1	1.963	5.674

I.e. no improvement in SNR but a slight degredation in FWHM. My main challenge when imaging from our backyard is the noise from the light pollution. So, I think I stick with square drops. 

This is also visible in the (stretched) images:

DrizzleIntegration with Square drops

DrizzleIntegration with Gaussian drops

There is much more detail when using Square drops. So, I'll go with that one (for now).

Hot pixels in DrizzleIntegration

I wanted to use DrizzleIntegration in Pixinsight. I read a lot about it and how it improves the stacked images.

I processed my latest images of the Bubble Nebula and surrounding as I always do plus created Drizzle files. The ImageIntegrated image looks good. But the DrizzleIntegrated image shows some hot pixels:

I tried a number of things:

• lower the "Linear Fit High" value
• play with the "Drop Shrink" value in DrizzleIntegration
• <several other things that I can't remember>

always with the same outcome: left over hot pixels!

I left a message on the Pixinsight Forum asking for help. And received A LOT of feedback and help from Vicent Peris - he seemed to know a lot about this. We tried a lot of things (and I learnt A LOT) but always with the same outcome. Vicent finally tried my data and for him it worked!!! The main difference was that he used an older version of the ImageIntegration process. Apparently the latest version had a problem with rotated images (and some of my frames did of course rotate during registration).

...

Yesterday the new ImageIntegration process came out ... and it is fixed!!! No more hot pixels!!! So, now I can actually go back to processing my Bubble Nebula images.

Estimating gain of my camera

I wanted to try out using the subframeselector script to assign weights to all frames. For that, I needed the gain of my camera. I can't find the data sheet from FLI anymore, but Richard told me a quick way to estimate the gain good enough:

1. Take two flats.
2. Raise the level of one of the flats slightly.
   I am doing that in Pixinsight by using the Pixelmath expression $T[0]+0.2.
3. Subtract the other flat from this first flat
   Again, in Pixelmath: Ha_01270-Ha_01269. (these are the names of the flat fit files).
4. Measure the standard deviation in the middle.
   In Pixinsight, I create a preview in the middle of the new image and with the Statistics process measure 5.1259e-003 = 328.06 DNA (*64000)
5. Divide by sqrt(2) = 231.97 - this is the noise (or to be exact the quadrature sum of shot noise and read noise)
6. Now subtract a bias frame from one of the two flats
7. Use the same region (I drag and drop the preview that I created in step #4) and measure the average value: 6.1413e-001 = 39304.32 DNA (this is the signal)
8. Now, gain = signal / (noise^2)
   gain = 39304.32 / 231.97^2 = 0.7304

IC 1318 - Narrowband enhanced

I wanted to see if and how my image of IC 1318 could be improved with Narrowband (Ha and OIII) data:

Which is a big improvement compared to the original. When zoomed in, the improvement in color and detail are quite amazing:

Narrowband-enhanced

Pure LRGB

Narrowband-enhanced

Pure LRGB

I took 440 minutes of HA data and 720 minutes of OIII from our backyard. I then used a tutorial from LightVortexAstronomy to fold these in.

Fixing my vertical stripes - Fixing the darks! (not the individual frames)

My first approach was to use the measured differences to correct each light frame that I took. But that would have meant to do this over and over again every time I have new data...

Instead I decided to adjust my dark frame (subtract the difference in the respective columns). Then I would have to do it only once. Of course, I would only correct the dark frames that are used for lights. The much shorter dark frames that I use for calibrating flat frames I would leave as-is.

Using Pixelmath in Pixinsight, I could easily correct each column:

Doing this for both columns resulted in this dark frame:

Compare this to the original dark frame:

One can see that the columns are still there, but much more subdued.

With this dark, I calibrated and stacked my Ha frames again:

No dark columns - compare with the original stack:

I also checked other filters and they got corrected well too. So, from now on I'll use the corrected dark frames for calibrating and everything is fine!!!