Automation on a Budget - Part 3: Operation

Submitted by AstroPhoto Insight on Mon, 11/30/2009 - 19:41.

This article was original published in the December 2009 issue of AstroPhoto Insight™ Magazine. No portion of this article may be copied, reposted, duplicated or otherwise used without the express written approval of the author and AstroPhoto Insight. © 2009 Professional Insight

Automated Imaging on a Budget: Part 3 -- Operation
by Joe Ulowetz

In the previous articles of this series, I described my hardware and software, and how I’ve used it to automatically image targets, including conducting a survey of all potential targets available from my location. Working at a focal length of 2350mm gives me sufficient image scale to go after numerous smaller targets.

After one year my survey is nearly complete, covering approximately 1700 objects brighter than magnitude 14 and north of declination +20 (the part of the sky I have access to). I’ve now moved on, choosing interesting targets from my list to image in more detail. In this article I’ll explain how targeting lists are set up and executed with my automation software, plus fill in some additional details of my system.

But first, an aside about mosaics.

While large CCD cameras like the SBIG STL-11000 or the QSI-583 are popular and can produce great results, I think it is fair to say that there are still many people who use smaller cameras like the Meade DSI, or the SBIG ST-402, like I do. Obviously, the larger the CCD chip, the more of the sky that can be imaged at one time. But there is another aspect here that I don’t see pointed out very often, which can have a huge impact on the quality of an image.

Take a look at my image below of Arp 81; it is typical of one of the better images taken with my ST-402 camera and C9.25 telescope at 2350mm focal length.

In particular, notice the stars; they’re okay, but certainly aren’t pinpoints. At this focal length, the image scale is 0.8 arcseconds per pixel, and with a CCD size of 765x510, the seeing limit of the atmosphere is visible in the star sizes in the image.
Now take a look at an image of M27 that I took recently:

Look at how much better the stars and nebula are here, even though I’m using the same equipment as in the previous image. The difference is that this image of M27 is a 2x2 mosaic; I photographed four overlapping fields and assembled the result, simulating the use of a larger CCD chip.

Here’s my point: images from larger CCD’s and smaller ones are often compared at the same final size, such as the two images reproduced here. The image from the smaller camera looks worse because it is shown at a higher image scale. There are more pixels per inch in the image from the larger chip compressed into the same apparent view, so stars and any guiding errors end up shrunken. The image from the larger chip will appear better.

If you can’t afford a large CCD, you can get the same benefit by taking mosaics!

Of course, it does take longer to acquire all the data for a mosaic. For example, a 3x3 mosaic takes nine times as long to expose all the raw images. On the other hand, by using mosaics I have access to targets that were previously too large for my equipment. It was a “eureka” moment when I realized this, that a whole new area of imaging has been opened up for me! For example, with the half degree field-of-view of my guide camera, the best I could do previously with M31 was just image its core. Now, using the same equipment for a 3x3 mosaic, I was able to produce this recently.

I’ve now built mosaic support into my automation software. The only tricky part was the calculation to compute the center of each tile of a mosaic based on the desired size of the final mosaic. For anyone interested in how this was done, the code is included in this article. If you set up your own system for mosaics, remember that the width and height specified for the tiles should be smaller than the actual dimensions of your CCD chip, in order to allow sufficient overlap when assembling the mosaic.

The only part of this code which might not be clear is a reference to “NextMosaicTile.” The idea is that the mosaic components may be collected over several nights, so I keep track of the last tile I imaged each night using a text file, and the function returns the tile number for the next one to image.

#Return coords for center of "next" tile in mosaic of the target
def CalcMosaicCoords(target,columns,rows,width,height):
# target = catalog name of base object for the mosaic
# columns = number of tiles across (in RA) for the full mosaic
# rows = number of tiles vertically (in Dec) for the full mosaic
# width = arcminute width for one tile
# height = arcminute height for one tile
#return tuple: (decimalRAJ2000, decimalDecJ2000, tilenamestring)

Log2(6,"CalcMosaicCoords: target=%s columns=%d rows=%d width=%5.2f height=%5.2f" % (target,columns,rows,width,height))

#Look in mosaic tracking file for this target, we take the tiles in order;
# this call also increments the tile value in that tracking file for next time.
nextTile = NextMosaicTile(target,columns*rows)

#look up catalog coords of name
pos = LookupObject( target ) #this returns a Position object
if not pos.isValid:
raise SoundAlarmError,'Unable to get position for this target'

RABase = pos.dRA_J2000() #(I could use JNow here instead for different return epoch)
DecBase = pos.dDec_J2000()
Log2(6,"baseCoords = %s" % (pos.dump3()))

#NOTE: the width, height values should be slightly smaller than camera FOV
# to allow overlap for assembling the mosaic later.
# tile = number from 1..(colums*rows) for which tile to calculate;
# tile numbering goes starts from lowest RA,Dec and increases
# first in RA, and then in Dec. For a 4x3 mosaic, the tiles
# would be:
# <- E /\ N
# 12 11 10 9
# 8 7 6 5
# 4 3 2 1

# vert coord (the row number); value will be 1..columns
y = ((nextTile-1) // columns) + 1

#hozontal coord (the column number); value will be 1..rows
x = ((nextTile-1) % columns)+1

#Note that I use 'columns' for both of the above. That is correct. Since we
#increment across first, and count rows from the first row, it doesn't really
#matter here how high the mosaic is. (The mosaic height only is used
#when calculating the initial offset from the center of the mosaic to tile #1.)
Log2(6,"Tile coordinate: x=%d y=%d" % (x,y))

#Convert tile width into Hours of RA, and height into Degrees of Dec.
# Important: we DIVIDE width hours by the cosine of the Dec; we want to INCREASE
# the time increment as we get farther north because a fixed field width of the sky
# spans more RA at a higher declination.
rowInc = (width/60.)*(24./360.) / cos(radians(DecBase)) #width of field in HOURS, applied to RA
colInc = height / 60. #height of field in DEGREES, applied to Dec
Log2(6,"Tile width=%9.6f hours height=%9.6f degrees" % (rowInc,colInc))
Log2(6,"Tile width=%9s hours height=%9s degrees" % (UTIL.HoursToHMS(rowInc),DegreesToDMS(colInc)))

#Calculate offset from center of mosaic to center of tile #1
if columns%2 == 1:
RAOffset = -(rowInc * ((columns-1)/2)) #columns wide is odd number
else:
RAOffset = -(((columns/2)-1)*rowInc + (rowInc/2.)) #columns wide is even number

if rows%2 == 1:
DecOffset = -(colInc * ((rows-1)/2)) #rows tall is odd number
else:
DecOffset = -(((rows/2)-1)*colInc + (colInc/2.)) #rows tall is even number

Log2(6,"Tile#1 offset: %9.6f hours, %5.2f degrees" % (RAOffset,DecOffset))
Log2(6,"Tile#1 offset: %s hours, %s degrees" % (UTIL.HoursToHMS(RAOffset),DegreesToDMS(DecOffset)))

#Calculate RA/Dec center of desired tile, based on tile number used above.
tileRA = RABase + RAOffset + (x-1)*rowInc
tileDec = DecBase + DecOffset + (y-1)*colInc
Log2(6,"Tile #%d coords: %s %s" % (nextTile,UTIL.HoursToHMS(tileRA),DegreesToDMS(tileDec)))

#calculate a string for this tile that can be used to make the filename unique
tileStr = "_%d,%d_" % (x,y)

return (tileRA,tileDec,tileStr)

Target lists

OK, back to operations and target list creation. There are several methods to specify a target in my software. The different options reflect how I added features over time to make this easier for me to use.

First generation: specify target RA/Dec coordinates; scope moves to the specified location and takes an image. Watching this work for the first time was a blast!

Second generation: specify the object name and let the script look up the coordinates in a catalog. It had become tedious to look up and transcribe the RA/Dec coordinates for each target, so I added an electronic catalog (MiniSAC) to automatically insert the coordinates based on the name of the object I specified.

Third generation: specify a list of desired objects and let the script decide when to image them. As I began doing the survey of all my potential targets, it became tiring to edit the target list each night for a different set of objects, so I changed the software to read the target names directly from the spreadsheet I used to keep track of the targets I wanted.

Fourth generation: specify desired mosaic size in object list. I’ve had good success lately applying techniques I learned at MWAIC 2009 from Alan Erickson of Adobe; he explained how to assemble mosaics in Photoshop. My initial mosaics were collected using manual targeting, but now my software will do this automatically for me. I’m really excited about this feature because I feel it is showing the potential to make a dramatic improvement to my images.

When the software is running in survey mode and there are several potential targets available, it uses the following order to make a decision on which object to choose:

If there is a target anywhere in the visible sky that has not had its survey image taken yet, pick it. Survey images are 5 minutes long, with typically another 5 minutes overhead for positioning.
  • Else, if there is a target in the current sky that is marked to collect mosaic data, pick it. It will then take about one hour of exposures on this target.
  • Else, if there is a target marked for additional (non-mosaic) exposures to image in detail, pick it and take an hour of exposures.
  • Else, there are no targets in the visible sky that are marked in the target list as needing more exposure time currently. I don’t want to waste the dark sky time, so pick any target from the list that is currently near the meridian and use that one to take an hour series of exposures.

    • The control file that I feed to my software is a text file with a combination of environment settings plus specific target instructions, or a command to run in “survey” mode. Environment settings include things like what file path to use to save images, control whether guiding is used, and exposure times for the positioning images that are solved with Pinpoint.

    The categories for the types of commands are:

    • Movement to target: specify either a catalog ID (from MiniSAC database), or specific coordinates (RA/Dec), or specify that the scope is already positioned at the desired location so no movement needed for this step.
    • Camera: define if an image is being taken through my main imager (narrow field, 7x10 arcminutes), or though the guider (wide field 1/2 degree). When using the guider for imaging I obviously don’t guide at the same time, but at that focal length I can easily take 5 minutes exposures without trailing. To insure that I stay on target if taking multiple wide field exposures, I will Pinpoint solve each of these images. I then use this info to resync the mount and reposition it between each exposure to stay precisely on target.
    • Focus: I created a predefined list of stars of magnitude 5-6 that I can use for focusing. I can tell the software to find the nearest star to my current location, or the nearest to some specified target, or just specify a SAO catalog number and use that star. When the scope is positioned, FocusMax runs until it returns two similar focus results in a row.
    • Exposures: I specify exposure duration, count, binning, filter; or specify a pre-defined sequence of exposures. Pre-defined sequences can only be used with the main imager because the camera control interface in MaxIm does not support doing this with the guiding camera. (While I could reconfigure MaxIm and swap the cameras, I want everything to be as simple and consistent as possible to minimize any manual steps and help prevent mistakes.)
    • Repeat count: rather than specify a fixed number of exposures to take, I can specify the time to stop and let the software take as many images as it can during this time. This is useful in order to image a target only when it is near the meridian, and to stop when I know it will have moved too far to the west. By doing this for a series of targets I can insure they will all be imaged near the meridian.
    • Survey: In this mode, the software reads my list of desired targets and images whatever is currently on the meridian, and repeats this until the configured end-time. Plus, every two hours during this time, or more frequently if the temperature has changed too much, it picks a focus star near the meridian and runs FocusMax to insure that the imager stays focused.
    • Calibration: I can specify bias frames, dark frames, and dawn flats. For dawn flats, the software waits while calculating the sun’s altitude; the scope is parked while waiting, pointing at the north pole to insure it isn’t accidently pointed toward the sun. When the desired altitude is reached (I’ve found -2 degrees works for me at f/10), I slew the scope to a spot just west of the zenith and take a full series of flats with the imager. The exposure time is dynamically adjusted to keep the exposure ADU near 30,000 counts.

    Target list and survey project:
    As I mentioned previously, I have a very restricted view of the sky and can only reach northern targets. Turning this restriction into an asset, I decided to make a list of all potential targets that I could reach, and then conduct an initial survey of all 1700 of them, taking a five minute initial exposure of each.

    Here is a screen shot of the spreadsheet where I maintain my target lists, which includes a link to a completed survey images when available. I also use this list to specify which targets should get additional exposures, and the settings for those exposures. The software reads the values out of this spreadsheet during operation to decide what to target in survey mode.

    Below is a complete example command script that I would feed to my automation software. This one starts out focusing on a star near M57, then runs a pre-defined MaxIm imaging sequence on M57, and then runs in Survey mode for the rest of the night. As dawn approaches it takes bias and dark frames, and then runs the ‘flats’ routine which waits for the right solar altitude and then takes sky flats with both the wide field (guider) and narrow field cameras:

    #-- Configuration settings--------------------
    #Pinpoint settings: first number affects PP with main imager, 2nd number w/ guider
    PP=Active,1,1 #Pinpoint solve for imager,guider cameras (1=enabled)
    PP=Exposure,75,10 #exposures (seconds) for images used w/ Pinpoint solve
    PP=Retry,0,2 #retry guider solves 2x, but no retry if imager does not solve
    PP=Precision,1,2 #want imager(or guider) within 1 (or 2) arcmin of desired coords
    PP=Require_solve,0,1 #Must solve guider to image a target, but ok if imager does not
    PP=Binning,2,1 #bin the Imager for better sensitivity for Pinpoint images
    # (guider binning not supported by MaxIm interface)

    Set_Guide=1,4 #enable guiding, 4 sec guider exposures

    #-- Imaging commands --------------------
    CatFocusNear,M57 #pick a focus star near M57 and run FocusMax
    RunUntil,05:00,M57,_LRGB_300sec.seq #run MaxIm seq until 5:00 UT

    FocusNear #pick any star nearby current location and refocus
    AutoUntil #run survey for rest of night until dawn
    #this stops when the sun’s altitude is calculated to be -12 degrees

    Park #park mount while taking calibration images below
    Bias,30 #take 30 bias frames
    Darks,60,10 #take 60 second darks, repeat 10 times
    Darks,120,10 #take 120 second darks, repeat 10 times
    Darks,300,6 #take 300 second darks, repeat 6 times
    Flats #this waits for sun to reach programmed altitude before running
    Park #final park; end of script

    Note in this example that Survey mode (‘AutoUntil’ with no end time specified) will run the rest of the night until dawn starts. Survey mode typically takes about six survey targets per hour for initial imaging, or spends one hour per target for detailed imaging when no survey targets are available.
    The advantage of auto target selection is that even if I don’t have time to plan out imaging targets for an evening, I can just start my software and give it one command (‘AutoUntil’) and have it decide what to image from my target list. This way I can take advantage of any clear night, even if I’m otherwise tired or busy. Over time, raw image data is accumulated that I can later process at my convenience.

    Overall Workflow
    In addition to my main automation program, there are several other small software tools I’ve written to make things easier for me. Here is a rough overview of my imaging activities.

    • During the day I manually edit the spreadsheet of targets, marking objects that I want additional exposures for. I also maintain a history of the total exposures taken per object; the software uses the difference here to decide whether a target has reached the desired total exposure or not.
    • Also during the day I can run a program that reads a history of targets I’ve imaged and summarizes the total exposure for each one. This is the source of the exposure info that I manually edit into my target spreadsheet.
    • At the start of an imaging session, I run a script that creates a subdirectory for today’s date that will receive the image files. It also creates and opens a text file that I use to record notes during the imaging session. I then launch my automation software with a command list for targets for that night. If I don’t have some specific targets in mind for that session, I just specify that it should run in survey mode and pick its own targets.
    • At the end of an imaging session, I run a script that makes an archive copy of all the raw FITS images, and also runs all the images through calibration in MaxIm, as well as producing an initial JPEG of each image so I can preview the results easily. I typically launch this program and let it run while I go outside and cover up my telescope and close the shelter. This step also produces the summary information about which targets were actually imaged, not just which ones I had requested, and how long each was imaged during that session. I use this summary list while reviewing the JPEG files, deciding if an image is good enough to keep or should be discarded (bad tracking, clouds, wrong coordinates, etc.).
    • For targets that I image over several nights, I have individual directories for each target and will copy the calibrated images from the day’s folder into the target folder and process the combined results in MaxIm, and then Photoshop when I have enough data.

    Software and data files online
    You can examine my software in more detail via the accompany file attached to this article.

    My main interest is in imaging, not on distributing software, so I haven’t gone to much effort to make this software easy for other people to use, although a couple of people have managed so far and are successfully imaging with it.

    If you plan to write your own software for imaging, I hope my work gives you some ideas about what you could do yourself. If you’re not a programmer, I hope I’ve shown you what is possible using automation. You might want to look at the commercial products available which could help you do something similar.

    I’d like to close with one final image, taken using my automation software, showing a rather difficult but colorful object, as an example of what is possible even with modest equipment and suburban skies. Enjoy!

    PK 164+31.1 planetary nebula in Lynx, also known as Jones-Emberson 1;
    C9.25 at f/10 (2350mm), ST-402 camera, taken from Northbrook, Illinois (sky visual limit is 3rd magnitude);
    8 hours total LRGB exposures over 6 evenings between January 24 – March 13, 2009:
    L 39x300 seconds, bin 1x1
    R 19x300 seconds, bin 2x2
    G 18x300 seconds, bin 2x2
    B 18x300 seconds, bin 2x2
    Stacked in MaxIm DL; heavily processed in Photoshop CS2

    Joe Ulowetz finished his first telescope, an 8-inch Newtonian, two days before the close Mars opposition in 1971 and has been actively observing ever since. He has a Masters degree in Astronomy and Astrophysics from the University of Chicago and spent 2 years at Yerkes Observatory, but now works with computers to support his astronomy habit and family (although not necessarily in that order). He actively pursues planetary and deep sky astrophotography, especially Mars, whenever possible from his back yard in Northbrook, Illinois.
    AttachmentSize
    v5i6_Ulowetz_Automation_Software_Files.zip859.1 KB