Skip to content
user29A edited this page Jun 26, 2022 · 21 revisions

Introduction

Fastrometry is a Python implementation of the fast world coordinate solution solver for the FITS standard astronomical image. It is designed for use by professional astronomers who have an expected basic knowledge of the telescope and detector system that they work with or are otherwise receiving astronomical images from: If the user can supply the approximate field center (+-25%), and the approximate field scale (+-10%), then they can expect WCS solutions almost instantaneously.

The fastrometry solver is based upon the trigonometric algorithm as described here:

https://iopscience.iop.org/article/10.1088/1538-3873/ab7ee8

The algorithm is also originally implemented with parallelism enabled in the Windows FITS image processor and viewer here:

https://github.com/user29A/CCDLAB

Theory

The world coordinate system for the FITS standard is solved in intermediate coordinate space, where spherical sky coordinates are transformed into a planar coordinate grid such that planar image coordinates might then be scaled, rotated, and shifted through a transformation matrix relative to some reference point to align with the intermediate coordinate grid. This transformation solution can then be used to transform 2D image locations to spherical sky coordinates.

The coefficients of the transformation matrix are what determine the scale, rotation, and reference point in the image, and thus these are what need to be solved for in a least-squares solution between the intermediate sky coordinates and the image coordinates. The problem is, one first requires a set of corresponding coordinates from a catalogue in sky coordinates and coordinates from the image, for the least squares to then function upon.

To solve that problem, we look for patterns which are invariant to rotation, shifting, and tolerance within the scale estimate, between the intermediate sky coordinates and the image coordinates. By searching for matching patterns under such conditions, one may then determine which coordinates from a sky catalogue must match to which coordinates from the image sources, and then perform the WCS least-squares solution upon these matching coordinates.

Troubleshooting

The following list should help the user where they find that they cannot get a fast solution:

  1. Wavelengths: There is no WCS solver which could ever be created for the situation where the source coordinates in an image have no correspondence to source coordinates in a catalogue. How could such a situation arise? By wavelength differential between your image and whatever detector created the catalogue. Different wavelengths see different objects on the sky. If the wavelengths are close then they should see the same objects, otherwise with even moderate wavelength differential the sky can appear completely different. How can a WCS be solved when image sources have nothing to do with catalogue coordinates which are required to solve the WCS against? Wavelength differential is the only reason why the number of points -npts would need to be increased to a higher number, and this can make the difference between finding a solution or not. If everything else (below) is OK, then increase -npts to, say, 125, or at worst, 200. If you can't get a solution with 200 points, then there is likely something structurally wrong with what is being attempted.

  2. Pointing: Related to the above, the region of the catalogue extracted must actually correspond to where in the sky the telescope was pointing.

  3. Scale: Don't forget to provide the correct scale estimate for the image...it can be easy to provide the wrong scale for a new image when you're used to working with a given detector system.

  4. Saturation: It is very typical for CCD/CMOS images to suffer from saturation as a result of over-exposure of the bright sources in a region. If many sources in the image are saturated, then their profiles become island plateaus as opposed to ~Gaussian peaks. Saturation then messes with with the point source extraction algorithm can cause a failure to find a solution, unless you let the solver know about it before hand. You should know at what ADU level your image saturates. For example, a 16-bit ADU will have a maximum value of 65,535, but the pixel-wells may physically saturate at 50,000; therefore specifying the option -pixsat at about 45,000 would help and can make the difference between finding a solution, or not.

5 Rotation: Was this option provided? Is it wrong?

6 Souces: Are there any sources visible in your image? How many?

Clone this wiki locally