This weekend I had a lot of plate solve failures using PinPoint, so this morning I did some testing to see just how accurate the “hint” needed to be for PinPoint to successfully solve an image. Using images taken with 2.4.1 and solved with Astrometry.net, Visual PinPoint (stand alone version of PinPoint) solved the images quickly. Then I used the FITS header utility in PixInsight to remove the RA and DEC entries (all of the various forms in the header) and then tested PinPoint’s ability to solve the image. Visual PinPoint would prompt for the RA / DEC hint and I found that entering a value with an error as small as 10 arcminutes would cause PinPoint to fail (timeout) even if I set the timeout to 5 minutes. I ran the experiments with both GSC and USNO libraries.
This is making me rethink the usefulness of PinPoint within the SGP environment.
I haven’t tested quite as methodically, but observationally speaking I’d agree. Astrometry.net seems the most resilient to inaccurate hint data – it may be the only solver that can reliably do blind solves with no hint data at all.
Perhaps the best combination is PinPoint with Astrometry failover, for a combination of speed and reliability.
Following up on my own post – the tests I did may have failed due to the J2000 -vs- JNow issue. I could not find any info in the PinPoint help file about whether the popup hint dialog box expects to get J2000 or JNow values. I was entering values based on the existing entries in the FITS header. I have always assumed the RA / DEC entries in the FITS header were JNow so if PinPoint was expecting me to enter J2000, that would have made my hint be off by even more than the 10 arcminute error I was entering.
Also, I was using fail over to astrometry.net but sometimes that, too, would fail (in some unknown way) and would never timeout requiring me to restart SGP.