Plate Solving, Pointing Correction & Auto Mapping (A laymen's explanation)  

Plate Solving
Plate solving is a technique by which a computer and a catalog of known stars are compared to a CCD  image of the sky. If a pattern of stars is matched (a solution is found), the plate is consider "solved". The term plate referrers to a photographic plate that is used to capture an image of the sky. The plate glass is covered with a emulsion of silver salts that is light sensitive.  Plates for the most part are no longer used in professional observatories, the images are captured using CCD chips.  

After the digital image is acquired it is downloaded from the camera in to the computer, and the solving process can begin.  In order for the plate solving software to be successful some parameters must be defined:
- The telescope's focal length
- The camera's pixel size (x, y)
- The image's bin factor

Once these parameters are known the image's scale can be computed.  A correctly defined image scale is one of the key parameters required for successful pattern matching. Software is used for the process of comparing the scaled image against a catalog of stars the computer has access to.  The more catalogs the computer has access to the better the chances of the software finding a match. The more stars used in the solution the more accurate the match will be.  The time and date the image was taken along with the longitude and latitude of the where the image was taken  are usually embedded in the header of image. This software uses the header info in order to help speed up the time it takes to find a solution.  By using  the time and location data the software only has to search the areas of the sky that were visible to the scope's location at the time and date the image was acquired. The sky is a big place so not having to search all of it is a real time saver.

Since the catalogs contain the stars positions, once a good  plate solution is found, the computer now knows the coordinates of the center of the image. The center of the image corresponds to the exact location in space the scope was pointing when the image was taken.  That coordinate data is inserted into the image. That location data is known as the World Coordinate System (WCS).  The WCS data along with the image scale and pixel size allows the computer to assign coordinates to each of the pixels.  That in turn allows the computer to know the coordinates of any location in the sky captured by the image.

Pointing Correction
Now that the system has a process for acquiring knowledge of sky that process can be used any time to determine exactly where the scope is pointed.  If the system determines the scope's  plate solved position is different from where it was commanded, the computer will slew the scope to where it should be pointed based on the previous plate solve. It will then capture another image, perform a plate solve and again compare the coordinates at the center of the image to the scope's commanded position. It will continue the process until the plate solved coordinates and the commanded coordinates are within the user's specified tolerance.  

There are a number of reasons the scope might not end up pointed to the targeted position. Generally the most common reason is poor polar alignment. Other reasons are unbalanced mount or optical tube assembly (OTA), misalignment between the mount and the OTA, or flexure within the system components.  

While the plate solving process does work to correct the mispointing, it is inefficient as a stand alone tool because it has no knowledge of the particulars that caused the scope's pointing, issues. Therefore it has to repeat the iterative pointing correction process every time the scope is commanded to a new position.  

A better solution would be to correct the telescope's pointing errors at the time the scope is pointed.  That correction would take into account issues mentioned above,  poor alignment,  imbalance, cone error, as well as other mechanical issues that contribute to mispointing. Only repeatable errors can be correct. pointing error caused by things like mirror flop on SCTs can't be corrected because mirror does not always shift to the exact same position. To correct the pointing errors the computer needs to know exactly how far from the commanded location the scope actually is. To do that a telescope pointing model of the sky needs to be made. The model is made with the help of the pointing correction software. The process involves the scope being slewed to a target in the sky such as a star. Hopefully the scope is capable of placing the object within the field of view (FOV) of the eyepiece or the  CCD chip before the correction. The target is then centered and the delta between the commanded location and the centered location are measured and the corrected point is mapped by the correction software. The next time the scope is commanded to that location in the sky, the software will automatically correct the pointing so the scope is slewed to the proper location.  The pointing and centering  process is repeated until the scope's visible sky is mapped. Now when the scope is commanded to slew to a point, the map of the correct sky is used to make an adjustment to scope's final location. 

In order for the correction map to be effective it needs cover the area of the sky in which the scope will be used and, the point density of the model has to be enough to capture any pointing issues the scope may have. Obviously the better aligned and the more mechanically stable and reliable the mount is the less dense the model needs to be.  However it is not uncommon for a model to contain  hundreds of corrected points.  

The problem is many astronomers make this model manually, as previously described by pointing the scope at a star and then centering the star in a reticule eyepiece.  If you are only modeling a few points (less than  20 or so) performing this task manually might be a viable option. But if you need to build a model that contains a few hundred points performing that task manually would be rather time consuming .

Auto Mapping
The most efficient way to build a dense pointing correction model is by using a CCD camera and a software program that automates the process. The procedure performs the initial slew of the scope to a set of coordinates. After the slew is complete the auto executes  the plate solving to determine the scope's exact location, it then calculates delta  from current location and the commanded position just as the manual process above did. The offset is then mapped into the pointing correction software.  The process continues until all the predefined list of coordinates have been mapped. This automated process is called auto mapping.  

I know of a couple of software packages that can perform the auto mapping process.  They are MaxPoint by Diffraction Limited Automapper II by Ron Wodaski and AAG TPointMapper by AAGWare. The last 2  programs are free. Automapper II is free courtesy of the Software Bisque. AAG TPointmapper free, courtesy of the author. 

Automapper2 was designed to use TPoint, CCDSoft and TheSky6.  It has the ability to either use mapping points created with TheSky6 and then imported as a file, or it can generate is own lists. 

AAG TPointMapper was also designed (as the name implies) to use TPoint, CCDsoft and TheSky6, but it also supports MaxImDL 4 and 5. This is a plus for users that don't own CCDSoft. Another major difference is TPointMapper requires the use of the full version of  Pinpoint as the astrometry engine instead of the Bisque astrometry engine.  The downside of this is the full PinPoint version is not free and costs around $149US just for the license. (This assumes you are going to download the pinpoint program and already have a star catalog). 

Summary
I have used both programs and have had a better results with AAG TPointMapper.  One of the problems I have experienced with Automapper2 is frequent "out of memory errors". When that occurs the run is aborted and the remainder of the points to be mapped are lost. Since my system is operated mostly without user interaction a failed mapping run in the middle of the night is unacceptable.  The other issue is if you have a slow rotating dome and don't use the Bisque's dome control program (Automadome) you will have to add a delay to the start of each image taken. This needs to be done to allow time for the dome to be positioned before the image acquisition begins.  That delay can be as high as 60+ second on some systems.  AAG TPointMapper avoids this by commanding the dome's position at the same time the scope is commanded and then waits for the dome slew to complete.  I have executed runs of  200+ points with only about 2 to 3 errors on the first pass.  AAG TPointMapper will make up to 3 passes all of my errored points were successfully mapped on the second pass. The only time that errored points were not successfully mapped on the initial or subsequent run is when the sky was obscured by clouds.

The image below is a screen shot of  an automated mapping run using the TPointMapper software in use on my system. The screen is rather busy as I am monitoring a number of things while the software is running.


A larger screen capture is available by either clicking on the image above or clicking here .

Description of the windows above:
Upper left - This the dome control software, which monitors both the scope and dome's position. 

Upper middle - The TPointMapping program as it steps thought the points to be mapped. It tells you where the scope was slewed to, if the plate solve was successful, and if the point was mapped.

Right side - Grey area: The scatter of the points mapped from the TPoint model within TheSky6. As more points are mapped and the scopes pointing is corrected the radius of the circles should decrease.  The lower area on the right side represents the virtual sky.  The darker gray star filled area is the plate solved image that was taken with CCDSoft. It has been linked, scaled and overlaid into TheSky's  virtual display.

Center Middle - This window is the target information window. It give details of object where the scope is pointing or cursor is. It this case the cursor and scope position are the same.

Lower middle -  The partially blocked window is camera status window from CCDSoft. The blue progress bar is showing the time left  in the image download from the camera. During the image acquisition  the bar will show the time remaining in the exposure.

Lower left - Display from the scope mounted camera. It keeps an eye on the dome's slit and allows me to see where in the sky the scope is currently pointing. For the mapping run it lets me know if there are any obstructions such as trees or a house that might be blocking the object and cause failed points.

Go to the JATObservatory Home page

Updated 07/04/2009 - Please report broken links
webmaster@jatobservatory.org