Re: APPM + ASTAP - Inaccurate FOV


Dale Ghent
 

On Oct 5, 2021, at 16:45, Ray Gralak <iogroups@siriusimaging.com> wrote:

Hi Linwood,

I see you posted a question on this topic on the ASTAP forum. Thank you for doing that. I was going to post there this evening, but you beat me to it. It will be interesting to see what Han says.
Heh, ok. So hopefully not a case of too many cooks in the kitchen, but Han is also on the NINA discord so I asked him directly there about this question.

(I've been catching up on my email and day job work and have only been able to glance at this thread so far)

Here's what Han says regarding the "-fov 0" option:

-fov 0 was invented to find the fov. Sharcap is using it. If the last solve was good no -fov will be specified for next image. If it fails it tries again with -fov 0. So it is a little tricky. I would suggest to use it only the first time. After that test, i would prefer to keep it fixed. Furthermore it is good for (using with) unspecified PNG/Jpeg files. I would suggest using -fov 0 only for a setup. Once the correct fov is found keep it fixed so specified in the header or specified by -fov x
it was created because I got all kind of images from users with didn't solve due to the wrong fov. The -fov 0 interation loop was faster then dropping the image at nova.astrometry.net. The next step in direction of fully blind solving was to simply to specify 180 degrees search.
So, running astap.exe with '-fov 0' should be done only if the FOV of the image is truly unknown. It's a kind of half-blind solve where you might know the general coordinates of the image but not the FOV.

Han mentioned:

Fully blind solving is "-fov 0 -r 180".
Which would make sense, as a "full" blind solve means that one doesn't know the FOV of the image or its coordinates, so one would ask ASTAP to figure out the FOV as well as search the entire hemisphere for a solution. It's expected that the discovered FOV is saved for future use in that case.

In NINA, we build the FOV from the pixel size, image dimension, and the user-supplied effective focal length of their setup. We supply the height component of this as the argument to the -fov option every time we run ASTAP. This same information is put into the FITS headers of the image files NINA generates, so the information is available to APPM as well if it reads those keywords. This means that APPM could always supply the correct FOV value provided that the user specified a reasonably accurate focal length. ASTAP will actually put a WARNING keyword into the .wcs file it generates to notify the user that, given an accurate pixel size and image dimension, that their focal length is actually different from what they specified.

The relevant keywords are XPIXSZ/YPIXSZ, NAXIS1/NAXIS2, and FOCALLEN. Binning shouldn't need to be considered because any binning is going to see the XPIXSZ and YPIXSZ values multiplied by the bin factor.

/dale

Join main@ap-gto.groups.io to automatically receive all group messages.