Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak

Hi Dale,

Since APPM works with a number of different camera applications, including some old applications like CCDSoft and AstroArt, APPM
cannot assume that the necessary keywords to calculate image scale will be placed in the FITS header.

So, I asked Han what APPM should send if it cannot be sure if all FITS keywords will be present, and his answer was "-fov 0".

Still, it would be easy to include a checkbox in APPM's ASTAP config to exclude the -fov argument in the command line for use with
applications like NINA that provide the necessary FITS header values.


-----Original Message-----
From: [] On Behalf Of Dale Ghent
Sent: Tuesday, October 5, 2021 2:29 PM
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

On Oct 5, 2021, at 16:45, Ray Gralak <iogroups@...> 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 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.


Join to automatically receive all group messages.