Hi Luca,
Can you say a bit more about this 1/10th of a pixel requirement? Is that a requirement on the pixel precision on each star, or on the absolute astrometric error on any point in the image, or ??? As you may know, you need a fairly bright star to get 1/10th of a pixel accuracy in measuring the pixel-space position of a single star, since positional accuracy goes like ~ S/N / PSF size, assuming well-sampled images. With short exposures and a super-wide-field, that might be a challenge.
Astrometry.net was originally designed to deal with pretty narrow-angle images where the distortion due to different projections isn't a major issue, but for your super-wide-fields, it must be a big concern. So it may be that you'll want to apply a distortion-correction to your pixel coordinates before running the
astrometry.net code. Or try using the --predistort option, after generating a good distortion solution.
The super-wide-field images you're processing should be fairly easy for the code to solve, because there just aren't very many stars at that brightness level. The biggest thing you can do to speed up solve-field is to give it accurate --scale-low and --scale-high bounds, and make sure the star detection is correctly finding and localizing the brightest stars in the image.
Currently the solver is single-threaded. If you're batch-solving many images, you could of course put a wrapper on it (eg, call it with xargs) to run many copies of the solve-field executable. It would be possible to extend it to run multi-threaded, but that would be real work.
I don't think GPUs are a good match for this problem, because the main compute cost in
astrometry.net is searching for nearby objects -- first, searching for nearby quadrangles of stars, then searching for nearby stars that should appear in the image. These are stored in k-d tree data structures, so they require a large number of branches, and GPUs don't do well on that kind of problem.
cheers,
dustin