Stark Labs Affordable, Powerful, and Easy to Use Astrophotography Software




PHD Guiding

PHD, subpixel guiding, and star SNR

Q: I've seen some quote the accuracy of the guiding available in their software with numbers like 1/20th of a pixel accuracy. a) How is this possible, and b) How accurate is PHD?

There are a whole bunch of things that will go into how accurate your guiding is. Your mount, the wind, flex, etc. all go into this. Here, we'll go over finding the star's position to an accuracy well below a pixel and how the star's signal to noise ratio (SNR) affects this accuracy. Since the SNR of the star (which is determined by the amount of light hitting the CCD and by the camera's noise) affects the accuracy, I won't quote a single hard and fast number as to how accurate it can be. I could quote an extreme (1/200th of a pixel) but I doubt it would mean much and would sound more like marketing hype. Since PHD is free, there tends to be little incentive for marketing hype.

In an article I wrote for Astronomy Technology Today on PHD Guiding, I went over the basics of how you find the middle of a star to accuracy well below a pixel. Here's an image that may help. Below we have stars hitting three different 2x2 areas of a CCD. In the first case, the star is hitting the exact intersection of these four pixels, so the star's light is evenly distributed among all four. In the next, we have the star still centered vertically but shifted to the right just a bit. More of the star's energy is now on the right two pixels than the left, so these two are brighter than the left two. For both the left and the right, the top and bottom pixels have gotten the same amount of energy, so there is no top/bottom difference. In the last panel, the star is now centered a bit down and to the right of the intersection of the four pixels. Most of its energy hits the lower-right pixel with equal amounts hitting the lower-left and upper-right and the least hitting the upper-left. Thus, so long as the star lights up more than one pixel, we can estimate small shifts in its position.


Here's another way to look at this. In this surface plot, I'm showing the energy of a simulated star that is perfectly centered.


Here is that same star shifted just a touch -- 0.2 pixels one way and 0.7 pixels in the other:

Note now now the star's profile is no longer symmetric. We can use this shift to estimate just how much the star has moved. When using perfect images such as these, it's easy to pick up small shifts. The real question is how well it does on real-world stars. I can't exactly go and take pictures of stars that have moved 0.001 pixels or anything of the sort because I'd have no way of knowing how much the star really moved. (I don't even know if the Hubble could hit that...). What I can do is to simulate real stars with real noise and see how well it works.

Here are profiles of the same star from two different cameras (there are actually two stars and one camera is rotated 180 degrees relative to the other so the second star you see clearly to the right on the image on the right is to the left in the noisy one on the left). Clearly, the one on the left has more noise and a lower SNR than the one on the right. These are real profiles from real stars with real cameras (mag 11.7 star, 2 s exposure, Celestron CPC 1100 XLT at f/6.3-ish).


Here, for reference, is an image of the star on the left. This is certainly not a very clean star to guide on, but PHD will lock onto it and guide off of it.


To simulate this, I can get something pretty close by modeling a star with variable amounts of Gaussian noise:

I apologize for the fact that the size of the X and Y axes differ between the simulations and the actual stars. The simulations show a more "zoomed out" view than the actual star profiles, but the SNRs of the two setups are comparable. The big question is how accurately can PHD locate the center of the star in each kind of image?

To get at this, I moved the simulated star by 0.05 pixel steps in both directions so I would know the true distance the star moved (using good old Pythagoras) and I would have a bunch of samples to get a good estimate of PHD's error with no noise, low noise (right image), and high noise (left image). Shown here is the average error in location for the three noise conditions (error bars show standard error of the mean)



Without any noise, PHD is accurate down to (on average) 0.004 pixels or 1/250th of a pixel. With a low amount of noise, the accuracy goes to 0.018 pixels or 1/56th of a pixel and with high amounts of noise it goes to 0.18 pixels or 1/5.5th of a pixel. Better stars and/or better guide cameras will get you more accuracy, but even with this very noisy star, we're still at 1/5th of a pixel accuracy.

What about noise reduction? Does smoothing the image help? Well, it helps in terms of increasing the odds that PHD will lock onto the star, but it doesn't help the accuracy of localization at all. At best, it does nothing and at worst, it hurts your accuracy a bit. Again, it will help PHD find the star in the first place, so if this plot included "lost stars" as errors (and they are errors), it would have a nice effect. But once found, smoothing does nothing to help the localization.



So there you have it. Can we get to sub-pixel levels? Sure. Under perfect conditions, PHD Guiding gets you down to an insane level of 0.004 pixels worth of error showing that the basic math in sub-pixel error calculation works. Done well (and yes, it can be done poorly - I know from first-hand experience a few ways to do it poorly and/or to introduce systematic biases in the star-finding routine), it can get you more accurate star localization than you'd ever really need. The SNR of your guide star will affect your accuracy, however. Under more real-world conditions, accuracy drops, but still can be very good. I have seen many stars in my guide frame with SNRs like the Low-noise SNR star used here that led to a 1/50th pixel accuracy. One notable implication of this is that with higher SNR stars, you can afford to use wider FOV guide setups since the higher SNR leads to increased precision in localization.

In practice, the High Noise star here is about as noisy a star as you can successfully guide on with PHD. Much worse than this and you're going to be suffering lost locks occasionally. With even this level of noise, we're still below a quarter of a pixel worth of error. Odds are, your mount, the wind, flex, etc. will be causing more trouble than even this error unless you're using a very wide FOV guide setup.





Is my poor guiding the result of flex?

Q: My guiding doesn't seem great and I get stars that aren't round. How can I tell if this is flex in my guide setup?

Unless you're using an SBIG camera with two sensors that both get the light from the same OTA, you're bound to have some differential flex between your main imaging camera and your guide camera. Let's say the main OTA is solidly locked onto the mount and the guide scope is attached by rubber bands to the top of the main scope. Since gravity tends to always pull down, as the whole rig rotates, the deflection of the guide scope relative to the main scope changes. With the guide scope atop the main scope, the guide scope will aim a bit too far down. Rotate the whole rig so that the guide scope is now to one side but keep the cameras fixed and the flex in the guide rig makes it aim "left" or "right" on the image (i.e., gravity is now "camera-left" or "camera-right" rather than "camera-down").

All rigs will have some flex. The question is, how much? Is it a big enough factor to hurt your imaging?

Here's a simple way to measure and hopefully rule out flex. Let's assume that PHD (or whatever package you use) isn't loosing the star and that it's guiding somewhere between perfectly and off by, oh, 3-5 arcsec. So, your mount has some error it just can't keep up with, it overshoots, etc (settings being off, mount being crud, etc.). If that is the case, over time, the star should wobble back and forth but on average be in the same place. We overshoot, we undershoot, we oscillate back and forth past the star - whatever. On average, the star is in the right place, but we have line segments instead of points.

Go out some nice, still night (please don't attempt this with 40 MPH gusts...) and shoot, say an hour of anything at something less than say 1 min exposures. We want something short enough that your mount isn't coughing up furballs during the exposure. Be guiding of course during this.

Now, take those images and do two stacks of them:

1) Do an Align and Combine without any aligning (i.e., fixed alignment). Do this for say 1 min worth of shots, 5 min worth of shots, and for the whole shebang. Does the 1 min stack look pretty clean? How much worse is the 5 min? Now, the big question - how much worse is the whole shebang? If the big stack is a lot worse than the 1-5 min stack, you've got flex. Why? The guide scope kept the guide star on target, plus or minus a few arcsec. That error may show up in the 1-5 min (which can show flex too) but if an hour is a lot longer trail, the only explanation is flex (assuming PHD kept a good lock). A 50 arcsec trail there isn't PHD wobbling.

Note, you can use the Measure Distance tool in Nebulosity to see just how many pixels long your trail is. See how wide a star is in a single shot and see how long the trail is, subtract the two (e.g. 117 pixels - 5 pixels = 112 pixels per hour = 1.8 pixels per minute = you'll not be exposing for 10 minutes with clean stars).

2) Do an Align and Combine with Translation (or Translation + Rotation) in Nebulosity. You'll find in your directory an align.txt file with the dx and dy (shifts in x and y) needed to bring that frame into alignment. You can open this up in something like Excel and plot the total distance the stars moved. Ideally, dx and dy would always be 0. If you're having issues, they won't. Use good old Pythagorus to determine the total distance the stars moved: sqrt(dx*dx + dy*dy). If this is a horizontal line on average with some bumps up and down / some noise, you've got no flex. If there is a real drift component, you've got flex.

Now, how bad is it? The easiest way to check is to fit a straight line to your plot. If you're in Excel, you can just have it add a "trend line". Make sure to have it put the equation on the graph if you do this. That equation will tell you just how bad things are. If you're not in Excel and can't automatically add a trend line, print out your plot and just put a ruler on there and draw a line. Your eye is amazingly good at this fit.

The key number that you need is the slope. In Excel, you'll see an equation like "y = 0.4683x - 1.0786" or some such thing. That 0.4683 is what you need. If doing by hand, the slope is the "rise over the run". That is, how much do you move up on the y axis (pixels) over some amount on the x-axis (time). You may find that your line goes up 10 pixels in 15 minutes, making your slope 10/15 or 0.667 pixels per minute.

Here is a sample from two guide rigs I used:



The first slope of 0.4683 pixels per minute means that if I want a max of 1 pixel worth of extra elongation, I can go for about 2.1 minutes in the first setup and 17 minutes in the second. 1 pixel is pretty harsh, so if we double that to 2 pixels (which will still seem pretty round), I'm talking ~4 minutes and over 30 minutes that I can go before differential flex has become an issue for me.