Tuning PinPoint for Moving Object Auto-Detection

With its default settings, PinPoint reliably auto-detects over 80% of the asteroids that appear in images taken at 701 and 933. With a regression set of 600 images taken at 933, PinPoint finds 86% of the asteroids in the images with zero false positives, at the default settings. For many users, this will be good enough, and that level of detection is several percent higher than the default auto-detections performed by similar software that we've run the images through.

For the more demanding, spending some time tweaking the settings can allow detection of close to 100% of asteroids by PinPoint. This tuning process is only necessary for getting the last drop of performance out of PinPoint.

Tuning PinPoint for highly efficient auto-detection of moving objects can go much faster if you take a methodical approach. Here's my method for detection tuning with PinPoint 3. We will assume you are using the Visual PinPoint applet for this purpose.

The Raw Material

The first step to getting PinPoint to reliably auto-detect asteroids and comets is to feed PinPoint high-quality images. It is true that PinPoint is tolerant of non-flat images. It has no trouble solving images that are brighter in the center or that have 'donuts' in them (the shadows of dust specks on the optical window cast onto the chip). It is also forgiving of poorly tracked or guided images. It can easily solve images in which the stars are several times longer in one image axis than in the other. And it doesn't mind dark noise - it is able to easily solve images that are not dark calibrated.

Nevertheless, for the most reliable autodetection in PinPoint, you should be feeding it the highest quality images your system can take. In almost all cases, this means:

• Calibrating your images with bias, dark, and flat fields. We recommend taking a series of dark and bias frames at the end of the night and applying their median to all images in your set. For flats, we recommend using the 'sky flat' method of constructing a flat field image using the median of all images in your set.
• Insuring that your images are well tracked or autoguided. For short exposures of under a minute with a high quality mounting, tracking can probably be taken for granted. With high quality commercial mountings, star size as measured by the FWHM swells significantly after a minute or two of unguided tracking; clearly these images should be autoguided. For custom made mountings (e.g., OGS), you can normally depend on a longer window in which to do unguided images. Since Maxim DL/CCD has given us automated autoguiding capability since mid-1999, and since we can pick our guide stars programmatically from a star catalog, probably everyone should be autoguiding no matter what mounting they have.
• Insuring that your images are well focused. We recommend the robust and working autofocusing routines offered as freeware in early 2001 and by Maxim DL/CCD in late 2001 as the most reliable way to get the sharpest possible focusing on any given night. The use of periodic refocusing, or of a temperature-compensating focuser such as the Optec TCF, is very valuable in this regard.

Software Tuning: Plate Solve

The first step in reducing images is to do a plate solution. In simple terms, PinPoint matches star positions from a catalog with the stars found in the images that you feed it. Once it has matched these up, the stars define a series of 'known positions' in the image. A map of the positions in the image is constructed mathematically, and this is saved to the FITS header as World Coordinate System (WCS) data.

For plate solving, PinPoint asks for several pieces of information (we're only going to cover the important ones):

• MinSize, the minimum size of a "real" celestial object. Although star images are optically extremely small, various factors contribute to a finite apparent size at the image plane. You'll want to tell PinPoint to ignore hot pixels, but to key in on real stars. For plate scales from 0.1 to about 4.0 arcseconds per pixel, a value of 2 works just fine. If you have a plate scale of more than 4.0 arcseconds per pixel and also have a world-class site (with very good seeing) as well as an excellent telescope, you might need to tell PinPoint that real objects can be as small as one pixel in size. Experimenters with camera lenses will find that camera lenses smear out star images, so even if you have forty or more arcseconds per pixel, your star sizes are going to be around 2 or three pixels FWHM.
• MinBright, the minimum brightness of a "real" celestial object. You probably won't ever need to change this. It is the sum of the pixel values of all pixels in the star, normalized to the background values of the image. The resulting units aren't in any accepted astronomical system, but are very handy for engineering. Start out with the default. If you have trouble, change this setting last.
• MinSigma, the minimum brightness ratio above background before the star is "seen" by PinPoint. If this is set to 4, PinPoint will never "see" a star that is only three sigma above mean. By ramping this down, you will increase the number of stars that PinPoint sees in a given image. Unfortunately, thanks to noise, after you get below 2 many of the "stars" will merely be random clumps of background noise. For plate solutions, you want nice, strong star images - four or five would be indicated here.
• The approximate image scale.
• The reference catalog you want to use. (We recommend using only the USNO A2, the Gray GSC-ACT, or the Tycho II catalog.) If you have a small field of view, i.e., around 10 arcminutes or so, you will probably need to use USNO A2.0 for reliable solving in all areas of the sky. If you are using USNO A2.0, you will get a big performance boost by telling PinPoint to throw out stars fainter than the faintest stars in your image.

One note: If your optical system produces lots of distortion - and this is the case for most telescopes using focal reducers - it can be beneficial to use low sigma and low min brightness for plate solving. This allows you to match more stars, and distribute them more evenly across the image, and allows you to make the most use of PinPoint's distortion terms (which will allow you to make ever more-accurate astrometric measurements).

For the most part, plate solving is straightforward and direct. You put the images in, PinPoint crunches some numbers, and a few seconds later you have a plate solution. If your images are large - more than five megabytes, for example - then the solution may take a minute or so. We've successfully solved 200 megabyte images with relatively few stars (ten thousand or so), as well as 30 megabyte images with large numbers of stars (thirty to fifty thousand stars, from E. E. Barnard's "Atlas of Selected Regions of the Milky Way").

If you want the best possible plate solutions, you should aim to have 80% or more of the catalog stars available in your image used for the solution. (Note: the number of catalog stars that PinPoint will actually report will be larger than the number of catalog stars that are available in your image.)

Software Tuning: Detecting Moving Objects

Step two in the tuning process is generally the most difficult. Getting PinPoint to detect asteroids that are more than about 3 sigma above mean is very simple. The default settings seem to handle this task reliably. However, many users want to use PinPoint to auto-detect asteroids down to the limits of visibility in an image. No software accomplishes this goal, nor can present technology "see" an asteroid in an image as well as a human doing the blinking. But with some tuning, you can get the detection threshold down to about 2 sigma or a little less, without unacceptably high false positives. This assumes you are feeding PinPoint nice clean images!

The parameters that you can adjust for moving object auto-detection include:

• Min Size, the minimum size of a "real" celestial object. See the section on plate solving above for a more detailed explanation and settings recommendations.
• Min Brightness. This is also covered in the plate solving section, above.
• Min Sigma, the signal-to-noise that a source must have to be considered "real" and be seen by the software. Again, see the plate solve section above for details.
• Limiting Mag is the limiting magnitude of the longest exposure you will ever take while looking for asteroids. For example, at 701 Junk Bond Observatory, the limiting magnitude of the longest exposure that will ever be used is around 23 (for a 32" telescope). For someone stuck with a twelve inch - such as myself, at 933 Rockland Observatory - a realistic value might be 19.5 for a ten minute exposure. This value should be determined empirically on a very clear night, but nothing prevents you from guessing.
• @ exposure is the exposure time that is needed to get as faint as Limiting Mag (see above). For example, if the longest exposure you ever take is ten minutes, put in 600 seconds.
• Min X-Y Dist is the minimum amount of motion that a supposedly "genuine" moving object must exhibit before PinPoint will consider it to be real, given in pixels. Fractions of a pixel are acceptable here, since the software can detect motions of less than one pixel based on the centroiding. The default for this setting seems to be 0.25 pixels. In typical cases, telescopes are looking at NEOs or main belt asteroids which have fairly rapid motions, and they are being looked for away from the stationary points. If this is the case, it is safe to set this value to one or several pixels.
• Max Fit Residual is the amount of deviation from straight-line, continuous rate sky-plane motion that an object is allowed to exhibit before PinPoint considers it "real." At the time scales that asteroids are observed at - over the course of perhaps two or three hours on a single night - any but the most unusual NEO will show apparent straight-line motion against the background stars, which will be at a constant rate. Because of measurement errors, there will always be some deviation from perfection in this assumption. This setting lets you tell PinPoint how much error, in arcseconds, to tolerate. A small number means that PinPoint is going to demand small measurement errors. A large number means PinPoint is going to find things that don't even remotely line up and report them as real.

The goal is to get all of these to optimal values, to allow the detection of the faintest possible asteroids through automatic methods. Here is what I do.

I use MinSize of 2. I want the faintest asteroids to be seen. But if an asteroid only shows up on one pixel - despite seeing blur and asteroid motion - then I won't be able to tell the asteroid from a hot pixel any better than PinPoint could. So I don't ever use 1.

I try to determine the optimal value for Min Brightness empirically, through regression testing. This means that I take a large sample of images - perhaps 100 triplets with asteroids of various brightnesses - and process them. I compare the results using various values for Min Brightness to a list of asteroids that are known to be in the lot that is being regression tested. But to start, I set this to 500.

For MinSigma, I start out with 2. This is under what Bob Denny, the software author, recommends, but I do it anyway. If I get too many false positives, I will raise it by 0.1 and do another test.

Limiting Mag and @ exposure are constrained by the actual capabilities of the system. The better idea you have of the system the better off you are. If these values are set improperly, then you will miss detections or you will have a lot of false positives. False positives will be caused by using values for these settings that are deeper than your telescope's actual capabilities.

For Min X-Y distance, I use a somewhat higher setting than the default - typically 4 or 5. The setting means that an object must change its position on the chip more than n pixels or else it will be considered a chip defect. If an "object" has a position of x=10, y=30 on each image, then obviously the "object" is really some flaw on the chip. By raising this value from the default of 0.25 to a high value like 5, we insure that x=10, y=30 is seen as the "same" object as x=12, y=29. NOTE WELL: My acquisition software automatically offsets all images slightly, in such a way that the second image is taken slightly to the SE of the first image and the third image is taken slightly to the SW of the first image. This means that fixed stars in the image will have three different x,y positions on the chip - the pointing will never be so precise that stars always appear in the same x,y position. Since the offsets are triangular, there is also no chance of a moving asteroid appearing within the same three x,y pixels on any set of images. In other words, if you blink the images, hot pixels dance in a pronounced triangular pattern. Why do this: Because dark noise tends to be clumpy near the noise threshold. If you have a fixed 'clump' of dark noise, it might cover nine pixels (three pixels on a side). There will be random variations in the noisiness of these individual pixels. These random variations can make the centroid of the noise clump appear to move by several tenths of a pixel or even by a whole pixel or more. By setting the Min X-Y distance to a high value of 4 or 5, then this 'phantom' motion is ignored by PinPoint. By offsetting the aiming point of the images triangularly with our acquisition software, we insure that real objects do not get caught in this trap.

For Max Fit Resiudal, I raise the default just slightly - to 1.2. My reasoning is that I would like, at worst, to submit astrometry with 0.6 arcsecond scatter. If an asteroid can't be measured to better than that, I frequently don't want to submit the positions at all. So in this case, the setting enforces an operator-decision rule. If the asteroid is unknown, or if it is well off its predicted position (a high ephemeris uncertainty asteroid), then I will go ahead and report the position. If the asteroid is known and is where it is expected to be, there is no point in my submitting lousy astrometry on it, and no point in making PinPoint work to detect it.

You'll notice that the only setting that I mess with extensively are Min Brightness and Min Sigma. I start with a sigma of 2 and a Min Brightness of 500. I then test these settings on a bunch of images that are a known quantity. This is called a "regression" test.

The test might return data on 200 moving objects that PinPoint thinks it has detected. If more than 2% of these are false positives, I raise Min Sigma by 0.1 and try again. I keep doing this until false positives are down to 2% or thereabouts. However, if I reach a point where PinPoint is detecting 98% of the asteroids known to be in the images, I'll also stop adjusting sigma at that point.

From here, there is a decision to be made:

• If you have reduced false positives to 2% or less, but are still not detecting all the asteroids in the image set, begin to lower Min Brightness. A change of 25 in this value can be significant, so I usually start lowering it by increments of 50 and as I feel I'm getting close to 98% detection, I'll change by 25. If I find I've gone too far, by getting bunches of false positives, then I'll back up.
• If you are detecting 98% of the asteroids in the image but still getting false positives, you can do one of two things. First, see how the false positives are sneaking in. You might need to tweak your magnitude and exposure settings, but more than likely, you can limit the X-Y motion or residual settings to get rid of a lot of problems. The second thing you could do, and you should if there are no apparent problems with the acceptance tests, is to raise Min Brightness.

If you never got to the point that you could detect about 98% of the asteroids that are really in the images, nor reduce false positives below 2%, then you should work on your acceptance tests some more. Or, get your telescope to take better images for PinPoint to snack on.

At the end of this somewhat tedious process, you should be detecting most asteroids in the images with very few false positives. I aim to detect 98% of known asteroids in a regression test and to limit false positives to 2% or fewer the number of true detections. Often, I can better this if I really take the time to set things up properly.

Shocking numbers:

Not surprisingly, all systems are different. At 701, using the 0.4 meter telescope, we can get away with a Min Brightness of only 100 and a Min Sigma of 2 and still have reliable auto-detection during the dark part of the month. Another station I've helped out at does well with sigma 1.5 and Min Brightness 100.

But yet another station requires sigma 3 and Min Brightness 700. So you have to be willing to play around a bit to find your sweet spot.

Limitations:

• Tuning will be valid for, basically, a single sky brightness. If you fine-tune for the dark part of the month, count on having a lot of false positives when you are observing with the moon in the sky.
• Neither PinPoint nor any other software tool can detect asteroids that are involved with stars in one or more of the three images, so if this is your goal, forget it.
• Only very primitive tools can detect asteroids close to the frame edges. By "primitive," I mean tools with unreliable acceptance tests.
• Neither PinPoint nor any other tool can see asteroids that are at or below the noise threshold. However, the eyeball sometimes can. PinPoint will never auto-detect these asteroids. Furthermore, it won't allow you to select them for manual measurement. Read an explanation of why this must be so.
• Once you've completed the tuning described here, PinPoint will no longer reliably detect very bright asteroids. Presumably these are well observed anyway and are uninteresting.