Global Warming

No, I'm not putting that title on this entry just to garner some hits. I'm writing this because of a fine interview article that appeared today in a local online news source, MinnPost. The interview was with Paul Douglas, a nationally known entrepreneur, weather expert, broadcast meteorologist--and conservative.

For years I taught an intro meteorology class at a local college, and my message to the students was always much the same as Douglas's: AGW is real and represents both challenges and rewards to those savvy enough to help society cope with the coming changes. Both sides of the political debate have stepped away from reality; some conservatives continue to deny and denigrate the science, while some liberals refuse to accept possible solutions.

Both sides strut their ignorance (feigned or real) by using weather events to deny or confirm their beliefs. For some trolls every cold snap is an opportunity to scoff at the reality of AGW, while for others every heat wave or drought is an excuse to trumpet what they see as the impending "heat death" of the planet.

The reality is both simpler and more complex at the same time.

In the no-brainer category: Significant atmospheric warming, sea level rise, and oceanic PH change are all happening now. Very likely on the way are shifts in local climate causing changes in rainfall, growing seasons, and availability of water. Things that are not so clear: Stronger storms, hurricanes, droughts, floods, heat waves. A great deal of work remains to be done to understand some of the side effects of AGW.

Back in the mid 1990's I told my classes that AGW wouldn't be accepted by the American public until around 2030. The current dysfunctional political climate leads me to think that statement remains about right.

I have no ax to grind on this issue. I no longer teach, so I'm not under any pressure to promote the company line. (I never was, actually.) I have no children or grandchildren who may be impacted by AGW. My days of chasing atmospheric science research funding from the National Science Foundation and NASA are far in the past. I don't sell educational, weather-related software any more, so I have no customers to keep happy.

---

Back to the usual stuff: Astronomy! Tonight looks like it might be the last below-zero night of the winter. After this the forecast is for a run of days warming to almost 50 next week! What little snow we have on the ground (and it's not much) will disappear in the next 10 days, well in advance of the Messier Marathon. With a little luck (and I've used that phrase too many times lately) I may be able to pick up some straggler winter Bright Nebulae images. If that happens I have a real chance of completing the 100 this year (I'm currently at 79). Last time I mentioned a good night was about to happen. It did, and I got #79:

Sh 2-264

This is the big Sharpless object at the head of Orion. I only got two hours of Ha under red zone + first quarter moon skies, so it's kind of ratty. I love the big field of the 135mm Tamron lens, almost 5.7 by 7.6 degrees in this image!

---

I'm now working on a gradient removal program that makes use of some of the meteorological code I created for some of the educational software mentioned above. (In some ways vignetting and light pollution gradients resemble atmospheric pressure fields.) This program is still in its infancy, so there's nothing to show at this point.

NFeeder Progress; A Good Imaging Night at Last?

I added more to the Nebulosity script generator/feeder program NFeeder:

• It now recognizes the time lapse setting, although I really don't understand the implementation of this in Nebulosity. (If you specify an exposure time of 15 seconds and a time lapse of 120 seconds, consecutive exposures start at 150s intervals. Time lapse is usually taken to be the time between consecutive frame starts. An alternative would be to treat it like a delay, setting the time between when a frame ends and the next starts. In the example this would give 135s between consecutive frame starts. I can't think of a rationale for 150s between frame starts given a time lapse setting of 120s.)
• The status indicator now tries to show you when you're within a time lapse delay, although the above problem messes it up.
• It can now parse a loaded script and set all the GUI widgets accordingly.
• It now provides the total amount of exposure time the script will require and includes it in the script as a comment. At present it doesn't distinguish between light, dark, and bias frames; they all count as exposure time. I may change this. Nor does it take into account the time lapse setting. I assume total time when time lapse imaging is not as important as the clock time span of the session.
• Auto-cooldown is now implemented. You specify the ambient temperature (to within the nearest 5 degree multiple), the set point, and the size of the temperature and time steps. You can also specify a final time interval to allow the camera to come to thermal equilibrium once it's been set to the set point temperature. The values of time delays must be found empirically. The following issue with the Delay command may impact how well this works--if it works at all.
• I eliminated the possibility of delays after filter changes because of strange behavior by Nebulosity. Invoking the Delay command from clipboard commands seems to cause Nebulosity to ignore the clipboard for quite a bit longer than the delay itself. It's possible I may have to apply a workaround in which NFeeder itself provides the delays.

It's now in its fourth incarnation so it has a version number of 0.4! If you choose to download and try it, be aware that the help information is not up to date and won't be until the development of the beta is almost done.

---

Imaging tonight? Beautiful clear sky and a temperature around 30F now, but it will be falling through the upper teens and remain quite breezy when it gets dark.  Almost a first quarter moon, too. But fine for a 135mm Ha image of Sh 2-264, the big patch of nebulosity around Orion's head. It will be nice to get another winter object done.

Some odds and ends for a Friday the 13th...

AL Bright Nebula Imaging Planning
I took some time to plan my imaging for March and the Messier Marathon night. The tentative lineup, all to be imaged using the AT65EDQ, includes four objects. The Cone Nebula (NGC 2264) and Hubble's Variable Nebula (NGC 2261) in a single frame. Both of these are Lynds brightness 1 objects and available from the onset of darkness until about midnight (3 hours or so) meaning I can probably do a nice LRGB of them. After that it's on to LBN 10, high enough for imaging until about 3 A.M., and  then LBN 1122, good from then until dawn about 2 1/2 hours. LBN 10 is a brightness 6, so it may only be L; 1122 is a 4, so maybe that will get the LRGB treatment. Dan Crowson's scheme is usually 12x600s for L and 8x300s binned 2x2 for each color channel, giving a total exposure time of four hours. I'll probably go with a much shorter plan; 12x300 L and 8x180 RGB (132 minutes) for the two bright nebulae; 20x300L and 8x180 RGB binned 2x2 for LBNs 10 and 1122.

If a miracle happens and we get some good weather in March, these plans could change to include more objects. Let's hope.

Good Luck
While planning the imaging around the Cone Nebula area I noticed that another AL Bright Nebula, LBN 943, was nearby. In fact, 943 is essentially a part of the Rosette Nebula, and it shows up in the image I had of the Rosette. I had overlooked this and failed to enter it in the "done" list. It's included now, pushing my total to 78. I wish they were all this easy!

NFeeder Progress
Not much in the last couple of days. I've designed the interface for setting up the camera, using the PHD command, and providing temperature control (including a programmed drop to the setpoint).

I've decided to split scripts into three pieces: general setup  before image capture; the imaging commands; follow-up commands (such as a slow warm up, disconnecting from the camera, and shutting down Nebulosity). I'm not sure if this is a good idea at this point.

The weather continues to misbehave
Cloudy and warm evenings punctuated by rare clear and cold nights. The long range forecast suggests no imaging for at least the next week, by which time February will be 3/4 past. Good riddance.

Nebulosity Feeder continues development

My little project continues. A lot of changes have been made since last time, thanks to suggestions from a club member who tried it out.

For the most part, the changes are intended to make the program a little smarter about how it does things. The program keeps track of the last download image folder used and the last folder used to save or load a script. The default filter wheel information is now stored in the Windows Registry. (Non-default filter wheel sets can be saved as text files.)

Scripts now allow for external filter wheels. And thanks to a suggestion from the program tester the program now lets you know more about capture status: Which filter is being used, which frame is being captured, and about how much time the frame has remaining. Nebulosity does this, but only in small print on the status bar. Look just above the script:

The box showing the script now automatically scrolls to keep the current command in sight. The status even indicates when the latest image is being downloaded.

The Script Editor now looks like this:

A big change is that the duration and frames can be selected using drop-down lists (you can still enter other values manually.) 

Because it's possible to manually edit the created script (and thereby introduce errors), the script gets parsed and error-checked as it's sent to the Feeder screen.

Lastly, the Filterset Editor is now a part of the main program instead of being a pop-up dialog:

It's been simplified to emphasize working with the default set. On the left is something new: Preferences. There's only one setting at this point, but I've left room for more. A new object I call the Preference Manager is now running nicely and ready for more work. Preferences are stored in the Registry.

Speaking of the Registry, I've made sure that an uninstall of NFeeder removes everything it put into the Registry.

Still to come (if there's interest) are

• Options for using a larger set of Nebulosity script commands.
• Night vision ability, which I'm finding difficult because it will require using Qt's stylesheets.
• Better help files.

Want to try it out? The Download is HERE. 

---

There was actually a nice night a little over a week ago and I managed to sneak in a couple of images using my 135mm Olympus lens. It captured three more images toward my AL Bright Nebula list!

---

The latest images were post-processed with the aid of Imagenomic's NoiseWare Professional Edition standalone noise reduction software. It's almost too inexpensive to not purchase. There's also a Photoshop plugin available at a higher price.

A freeware script generator for Nebulosity

After visiting a friend I decided to look into other image processing software packages. Some are more affordable than others, at least from my viewpoint.  I found that Nebulosity has a large number of fans. It comes from the same house that gives us PHD (for free!) and I downloaded the trial version.

I like how it works for the most part, but its image acquisition ability seems to me to be only average. I should clarify--it's not so much its capabilities as the interface. If you use a DSLR or a one-shot-color CCD, or your nightly imaging sessions tend to involve only one filter, the interface is perfectly fine.

If you use a monochrome CCD and multiple filters during a session it gets a little more complicated. You have the choice to use the GUI for each filter or a built-in script editor to program your filter sequence.
The script editor is helpful and easy to use. Some understanding of the commands will take you a long way.

What the Nebulosity script system lacks is a way to temporarily interrupt running scripts to perform other tasks such as refocusing when a filter is changed. The focusing tools provided by Nebulosity can only be accessed when a script is not being run. A running script can be aborted but you can't resume executing the script from the command at which it was aborted.

I've done some programming in the past, so I thought I'd try to build something that could make refocusing possible from within a script. The solution I adopted is to make use of Nebulosity's ability to listen to the Windows clipboard for commands--it's not an elegant solution, but it seems to work. I may or may not use this depending on what else I find available for image capture, but it was fun throwing it together!

The program is called (at the moment) NFeeder.

Here are some screen captures:

Script Editor tab of main screen (click to enlarge to actual size) 

The Script Editor is fairly simple. The usual stuff is defined: destination folder, object name prefix, the sequence of filters (including exposure time, binning, and number of frames to capture). Dark and Bias frames are considered as types of filters and can be chosen in the same way.

Filter wheel contents are defined using an editor:

Filterset editor

Repetitions of the filter sequence can be specified. If you want to refocus at appropriate times, that can be indicated. (Dark and Bias frames don't move the filter wheel or pause for refocusing.)

The generator parses the inputs and constructs a Nebulosity script, shown at right. You can edit this by hand if you want. The script can be saved and previously saved scripts can be loaded.

If you're not refocusing, you can save the script and run it from within Nebulosity just as it is. If you want the ability to refocus when the filter changes you need to move on to the Feeder tab:

Feeder tab of the main screen

The Feeder tab shows the same script that was created/edited on the Script Editor tab. NFeeder works like this:

1. Start Nebulosity, connect to the camera and do whatever is best done within the Nebulosity interface: I prefer to set cooling and configure dithering from outside a script.
2. Launch a stub script that puts Nebulosity into listening mode. The stub script can be created from this tab
3. Start feeding a script to Nebulosity with the click of  a Start button. As it works NFeeder shows you which commands have been sent to Nebulosity. 
4. When NFeeder reaches a point where refocusing should be done, it passes a command to Nebulosity to show a prompt dialog. Clicking cancel in the prompt dialog aborts the stub script and you're free to access Nebulosity's focusing tools.
5. When you're done focusing, launch the stub again and click NFeeder's Resume button
6. Repeat steps 3 and 4 until the session ends.
7. Click Nebulosity's Abort button to end the stub.

This may sound complicated, but it's not. I've tried the program with a Canon DSLR and SBIG ST-8300M + 8-cell filter wheel, and it worked correctly.

Want to give it a try? Here's the download. The application files and installer were scanned by Avast antivirus. Your comments would be appreciated. Still on my to-complete list are the night vision mode and better help information.

Please keep in mind that I made this for fun for a very small group of people (i.e., mainly myself) so it's probably lacking in features that may make it useful to you. It's free for your use because I enjoyed making it.

And yes, I'm aware of some other programs that serve similar purposes. Commercial products include Sequence Generator Pro ($99) which does far more than I need and Astro Photography Tool (APT) which is an amazing value (and one I'll probably purchase). Both are standalone programs worth considering.

The Importance of Bias Frames

The rule I came to understand for using bias frames was this: Temperature-regulated cameras don't need them when the dark frame exposure time and temperature match those of the light frames. In other words, bias frames are useful only when you're trying to match dark and light frames that differ in exposure time or temperature.

Is this really true? Some people say it's not, and that bias frames should always be used. My experience seems to agree. But is there a way to verify this? That's what I tried to do with some simple analysis using my SBIG ST-8300M CCD camera.

I started by shooting twenty three-minuted dark frames at a temperature of -25C. Ten of these I set aside for later testing. The remaining ten were combined using three different methods (average, median, min/max exclude average). The result was three master dark frames, one for each common method of combining dark frames.

I then shot twenty bias frames at -25C. The ST-8300M's shortest exposure time is 0.04 seconds, so that's what was used. These were averaged to create a master bias frame.

Next, the ten dark frames that were set aside (it's helpful at  this point to think of them as light frames) were calibrated with each of the master dark frames, both with and without the master bias frame. This created six sets of calibrated frames. 

Each set of calibrated frames was then stacked using average, median, min/max excluded average, weighted median and sigma clipping (at 2.55 standard deviations). These are some of the standard stacking methods offered by ImagesPlus. The result is thirty images. ImagesPlus was then used to calculate the noise in each image (represented by the standard deviation of each image's pixels, in this case), and the results are given in the tables below:

Noise in processed images. Top table: noise present when the master bias frame is used. Each column is for a different dark frame combining method (AVG = average, MED= median, MME = min/max exclude). Each row corresponds to a different "light" frame stacking method (WMED = weighted median,  S255 = sigma clipping at 2.55 standard deviations. The row of numbers below each column is the column average. Bottom Table: as in the top table, but the calibration was performed without the master bias frame.

The results show that the exclusion of the master bias frame roughly doubled the standard deviation of the pixel values!

The images below show a comparison between the lowest noise (using min/max for dark combine and light stacking and bias for calibration) and the greatest noise (using median for combine and stacking, with no bias information). ImagesPlus digital development was applied equally to both stacked images.

Best case: Min/max combine and stack, bias included in calibration

Worst case: Median combine and stack, bias not included in calibration.

The lowest noise levels corresponded to combining dark frames using either an average or a min/max exclusion method and then stacking light frames with the min/max exclude method. Because both dark and light frames can be contaminated by cosmic rays, it makes sense to use some sort of rejection combine method in their processing. Both median and min/max perform about the same when the bias information is included. When the bias frame information is not included the min/max method clearly outperforms the median method.

I think that from now on I'll always use bias frames!

Finishing the Astronomical League Bright Nebula list anytime soon? Not very likely.

The ALBN requires 100 objects to be imaged, and I'm in need of 26 more to finish. There are 62 listed objects that I can choose from according to the published list. Let's see how that shakes out.

First eliminate the bogus object on the list, IC 425, although I'm tempted to image its supposed location and count that as one. This leaves 61 Objects.

Next, eliminate all the objects that are too low to image from the locations I plan to use. The southernmost locations are the Iowa and Nebraska star parties at 41.8 and 42.6 degrees north, respectively. As a guess, these allow imaging to about 40 degrees south declination. This eliminates five objects: IC 4628, Gum 12, NGC 2736, NGC 6164, and NGC 6188. There are now 56 objects.

Now let's assume I want to avoid imaging objects that require very dark sites, namely those with Lynd's brightness 6. This includes eleven objects (Sh 2-218, LBN 619, 1064, 683, 8, 10, 1091, 19, 70, 140, and 434). There are now 45 objects available. (Tossing out the brightness 5 objects eliminates another 12 objects, leaving 33.)

Let's see how far I could get just doing the brightest objects. Brightness 1 has 4 objects, 2 has 4, 3 has 5, and 4 has 7. The total without dipping into the 5s is 20. There are some objects without assigned brightness that could add some to this: NGC 2174, Sh 2-264, LBN 962, NGC 2149, NGC 2296, NGC 6357, NGC 6729, and IC 4812. These lift the total to 28! Only two objects to spare!!

Actually, LBN 20 and 22 (brightness 5) share a field, so there are three to spare.

A first pass at the optimum months for imaging these can be found using SkyTools3.

January: IC 2169, LBN 943, Sh 2-280, NGC 2296, IC 468, NGC 2359
February:
March:
April:
May: LBN 1122
June: LBN 20, LBN 22, NGC 6357, Sh 2-12, Sh 2-13
July: IC 4812, NGC 6729, LBN 52, IC 4701
August:
September:
October:
November: IC 360, NGC 1555, NGC 1579
December: LBN 945, NGC 1931, Sh 2-264, NGC 1999, Sh 2-240, LBN 962, NGC 2149, NGC 2174, IC 2162

This is where the bad news rears its ugly head. Sixteen (nineteen minus the three spare) objects must be imaged during the winter months. Given the terribly cloudy (not to mention cold) winters we've had lately, this becomes problematic. It's probably going to be necessary to dip into the dimmer objects that are available in spring and summer. These include LBN 683, 1088, 10, 1091, 19, 11, 8, 70, and 490. That's only 9, though, which means that at least seven of those winter objects will need to be imaged.

Conclusion: I might be at this for a couple of years yet!