APPM + ASTAP - Inaccurate FOV


Sébastien Doré
 

Hello,

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 



CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007



From ASTAP documentation: 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.


Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

Sébastien


ap@CaptivePhotons.com
 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


Sébastien Doré
 

I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...

Here's what I get with it : 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov 0.402802441751637 -s 1000 -r 5 -t 0.007

Which would do the trick too in the real run. Unfortunately, it doesn't.


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


ap@CaptivePhotons.com
 

You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does say fov 0.


But it also solved in 2 seconds.

 

I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first image (assuming it does not remember between sessions).

 

NINA’s own plate solve looks like the below (under this section from APPM) (different target).

 

 

0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5

0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait

0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.

0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.

0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.

0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.

0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.

0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.

0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.

0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.

0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.

0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename = C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.ini

0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T

 

 

NINA:

 

2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'

2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32; Dec: 85° 08' 04"; Epoch: J2000

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...

 

Here's what I get with it : 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov 0.402802441751637 -s 1000 -r 5 -t 0.007

 

Which would do the trick too in the real run. Unfortunately, it doesn't.

 


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


Sébastien Doré
 

I am using Nina camera too.

Same here with Nina, which uses the correct FOV:

COMMENT 7  Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
COMMENT 30 -ra 20.581111 -spd 150.153611


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:34
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 

You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does say fov 0.


But it also solved in 2 seconds.

 

I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first image (assuming it does not remember between sessions).

 

NINA’s own plate solve looks like the below (under this section from APPM) (different target).

 

 

0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5

0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait

0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.

0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.

0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.

0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.

0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.

0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.

0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.

0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.

0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.

0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename = C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.ini

0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T

 

 

NINA:

 

2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'

2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32; Dec: 85° 08' 04"; Epoch: J2000

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...

 

Here's what I get with it : 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov 0.402802441751637 -s 1000 -r 5 -t 0.007

 

Which would do the trick too in the real run. Unfortunately, it doesn't.

 


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


Ray Gralak
 

Hi Sebastien,

Do you have image scale set correctly in NINA? APPM will try to read the image scale from the FITS header.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Monday, October 4, 2021 6:51 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

I am using Nina camera too.

Same here with Nina, which uses the correct FOV:

COMMENT 7 Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
COMMENT 30 -ra 20.581111 -spd 150.153611


________________________________

De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@CaptivePhotons.com
<ap@CaptivePhotons.com>
Envoyé : 4 octobre 2021 21:34
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV


You are correct. I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does
say fov 0.


But it also solved in 2 seconds.



I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first
image (assuming it does not remember between sessions).



NINA’s own plate solve looks like the below (under this section from APPM) (different target).





0000222 2021-10-04 21:28:26.723: Info, ASTAP Plate Solve, StartSolve: arguments: -f
"C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5

0000223 2021-10-04 21:28:26.793: Info, State Machine, Entering State=PlateSolveWait

0000224 2021-10-04 21:28:26.797: Info, ASTAP Plate Solve, ASTAP is still running.

0000225 2021-10-04 21:28:27.002: Info, ASTAP Plate Solve, ASTAP is still running.

0000226 2021-10-04 21:28:27.206: Info, ASTAP Plate Solve, ASTAP is still running.

0000227 2021-10-04 21:28:27.408: Info, ASTAP Plate Solve, ASTAP is still running.

0000228 2021-10-04 21:28:27.616: Info, ASTAP Plate Solve, ASTAP is still running.

0000229 2021-10-04 21:28:27.831: Info, ASTAP Plate Solve, ASTAP is still running.

0000230 2021-10-04 21:28:28.035: Info, ASTAP Plate Solve, ASTAP is still running.

0000231 2021-10-04 21:28:28.238: Info, ASTAP Plate Solve, ASTAP is still running.

0000232 2021-10-04 21:28:28.442: Info, ASTAP Plate Solve, ASTAP has exited.

0000233 2021-10-04 21:28:28.444: Info, ASTAP Results, Results Filename =
C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
DEC_26.570.ini

0000234 2021-10-04 21:28:28.444: Info, ASTAP Results, PLTSOLVD=T





NINA:



2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program
Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov
2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'

2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32;
Dec: 85° 08' 04"; Epoch: J2000



From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV



I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...



Here's what I get with it :



CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-
Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov
0.402802441751637 -s 1000 -r 5 -t 0.007



Which would do the trick too in the real run. Unfortunately, it doesn't.



________________________________

De : main@ap-gto.groups.io <mailto:main@ap-gto.groups.io> <main@ap-gto.groups.io> de la part de
ap@CaptivePhotons.com <ap@CaptivePhotons.com>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV



What camera settings do you have? I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-
Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -
s 1000 -r 5



I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.





From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV



Hello,



I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...



When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
created along each solve, for every point :



WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm



I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.



When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
Solve Settings :







CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
fov 0 -s 500 -r 5 -m 1 -t 0.007







From ASTAP documentation:



If the FOV (image height in degrees) is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
will use the FOV as set in the program, stack menu, tab alignment.





Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV is already
correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?



When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).



Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.



Sébastien


Ray Gralak
 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV is already
correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?
When "Refine image scale" is enabled, APPM uses the result of each plate-solve to set the image scale for the next image.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Monday, October 4, 2021 6:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

Hello,

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
created along each solve, for every point :

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm


I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
Solve Settings :





CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
fov 0 -s 500 -r 5 -m 1 -t 0.007




From ASTAP documentation:

If the FOV (image height in degrees) is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
will use the FOV as set in the program, stack menu, tab alignment.



Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV is already
correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

Sébastien


Sébastien Doré
 

Hi Ray,

AFAIK there is no "image scale setting" in NINA so to speak, only pixel size and FL which are both set to the correct values of course.

See WCS file attached (from APPM folder) for an example of fits header from tonight's run. I can't see any specific XSCALE/YSCALE populated field anywhere, but FL and PXSZ are there.

Thanks,

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Ray Gralak <iogroups@...>
Envoyé : 4 octobre 2021 22:21
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 
Hi Sebastien,

Do you have image scale set correctly in NINA? APPM will try to read the image scale from the FITS header.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
> Sent: Monday, October 4, 2021 6:51 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
> I am using Nina camera too.
>
> Same here with Nina, which uses the correct FOV:
>
> COMMENT 7  Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
> COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
> COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
> COMMENT 30 -ra 20.581111 -spd 150.153611
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@...
> <ap@...>
> Envoyé : 4 octobre 2021 21:34
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
> You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does
> say fov 0.
>
>
> But it also solved in 2 seconds.
>
>
>
> I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first
> image (assuming it does not remember between sessions).
>
>
>
> NINA’s own plate solve looks like the below (under this section from APPM) (different target).
>
>
>
>
>
> 0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f
> "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5
>
> 0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait
>
> 0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.
>
> 0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename =
> C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.ini
>
> 0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T
>
>
>
>
>
> NINA:
>
>
>
> 2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program
> Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov
> 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'
>
> 2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32;
> Dec: 85° 08' 04"; Epoch: J2000
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:26 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...
>
>
>
> Here's what I get with it :
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-
> Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov
> 0.402802441751637 -s 1000 -r 5 -t 0.007
>
>
>
> Which would do the trick too in the real run. Unfortunately, it doesn't.
>
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <mailto:main@ap-gto.groups.io>  <main@ap-gto.groups.io> de la part de
> ap@... <ap@...>
> Envoyé : 4 octobre 2021 21:16
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:
>
> Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-
> Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -
> s 1000 -r 5
>
>
>
> I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.
>
>
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:07 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> Hello,
>
>
>
> I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...
>
>
>
> When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
> am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
> created along each solve, for every point :
>
>
>
> WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm
>
>
>
> I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.
>
>
>
> When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
> always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
> Solve Settings :
>
>
>
>
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
> APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
> fov 0 -s 500 -r 5 -m 1 -t 0.007
>
>
>
>
>
>
>
> From ASTAP documentation:
>
>
>
> If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
> will use the FOV as set in the program, stack menu, tab alignment.
>
>
>
>
>
> Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already
> correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?
>
>
>
> When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
> solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
> same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).
>
>
>
> Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.
>
>
>
> Sébastien
>
>







Sébastien Doré
 

Just for disambiguation and because it is confusing in my case is that my image scale is 0.4 (arc-sec/px) and my fov is also 0.4 (degrees).

So, note to self:

image scale = px sz / FL * 206.265 = 0.4"/px
fov (deg) = image scale * sensor height (px) / 3600 = 0.4 deg

That said, I think I just found the problem. Not sure if it originates from NINA or APPM though. 

In the FITS header of the FITS file, I see the following, which is required for the fov calculation :

NAXIS   =                    2 / Dimensionality                                
NAXIS1  =                 5208 /                                                
NAXIS2  =                 3476 /  

but in the FITS header of the WCS file (that came along the same image fits file), I only see this:

NAXIS   =                    0 / Dimensionality

The sensor size if missing, so it would be impossible to compute the correct FOV.

So my guess is the issue is related to that...

Sébastien

De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Seb@stro <sebastiendore1@...>
Envoyé : 4 octobre 2021 23:09
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 
Hi Ray,

AFAIK there is no "image scale setting" in NINA so to speak, only pixel size and FL which are both set to the correct values of course.

See WCS file attached (from APPM folder) for an example of fits header from tonight's run. I can't see any specific XSCALE/YSCALE populated field anywhere, but FL and PXSZ are there.

Thanks,

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Ray Gralak <iogroups@...>
Envoyé : 4 octobre 2021 22:21
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 
Hi Sebastien,

Do you have image scale set correctly in NINA? APPM will try to read the image scale from the FITS header.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
> Sent: Monday, October 4, 2021 6:51 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
> I am using Nina camera too.
>
> Same here with Nina, which uses the correct FOV:
>
> COMMENT 7  Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
> COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
> COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
> COMMENT 30 -ra 20.581111 -spd 150.153611
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@...
> <ap@...>
> Envoyé : 4 octobre 2021 21:34
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
> You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does
> say fov 0.
>
>
> But it also solved in 2 seconds.
>
>
>
> I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first
> image (assuming it does not remember between sessions).
>
>
>
> NINA’s own plate solve looks like the below (under this section from APPM) (different target).
>
>
>
>
>
> 0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f
> "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5
>
> 0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait
>
> 0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.
>
> 0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename =
> C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.ini
>
> 0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T
>
>
>
>
>
> NINA:
>
>
>
> 2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program
> Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov
> 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'
>
> 2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32;
> Dec: 85° 08' 04"; Epoch: J2000
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:26 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...
>
>
>
> Here's what I get with it :
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-
> Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov
> 0.402802441751637 -s 1000 -r 5 -t 0.007
>
>
>
> Which would do the trick too in the real run. Unfortunately, it doesn't.
>
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <mailto:main@ap-gto.groups.io>  <main@ap-gto.groups.io> de la part de
> ap@... <ap@...>
> Envoyé : 4 octobre 2021 21:16
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:
>
> Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-
> Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -
> s 1000 -r 5
>
>
>
> I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.
>
>
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:07 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> Hello,
>
>
>
> I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...
>
>
>
> When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
> am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
> created along each solve, for every point :
>
>
>
> WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm
>
>
>
> I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.
>
>
>
> When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
> always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
> Solve Settings :
>
>
>
>
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
> APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
> fov 0 -s 500 -r 5 -m 1 -t 0.007
>
>
>
>
>
>
>
> From ASTAP documentation:
>
>
>
> If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
> will use the FOV as set in the program, stack menu, tab alignment.
>
>
>
>
>
> Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already
> correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?
>
>
>
> When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
> solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
> same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).
>
>
>
> Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.
>
>
>
> Sébastien
>
>







ap@CaptivePhotons.com
 

Seb@stro wrote :

 

  • but in the FITS header of the WCS file (that came along the same image fits file), I only see this:

 

  • NAXIS   =                    0 / Dimensionality

 

For what it is worth, the wcs files from nina to astap (internally, not involving APPM) also have 0 here.

 

That part that confuses me about this is why APPM’s call to ASTAP has fov 0 for a run, and the correct fov for a “plate solve and recal”, since both originate from NINA in (presumably) the same path when NINA controls the camera.

 

Incidentally: The NAXIS for both the solve-now and the run both have zero, indeed the data from NINA looks the same to my eye. 

 

It would appear (speculating) that APPM is using the header to calculate FOV (it has pixel and focal length) for the solve now, but not the regular points in a run?

 

Now why despite FOV=0 mine works and yours doesn’t…

 


Sébastien Doré
 

that's interesting... I guess we'll have to let Ray and Dale sort this one out.

BTW, my solves are successful too, only they are slower, by about 4-5 seconds per solved point (vs about 1-2 sec) because of this "-fov 0" thing. I have no problem directly in Nina or APT or ASTAP. Always super fast.

If you can't tell the difference, I suppose it might be due to more horsepower in your PC than mine. 

just try to solve one of the files APPM was able to solve but using the command line and append "-log". take a look at the log file (same dir as the solved file), you'll see what ASTAP does try a bunch of preset fov internally, whereas it does not when the correct Fov is specified or when the -fov switch is omitted.
 


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 5 octobre 2021 00:14
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 

Seb@stro wrote :

 

  • but in the FITS header of the WCS file (that came along the same image fits file), I only see this:

 

  • NAXIS   =                    0 / Dimensionality

 

For what it is worth, the wcs files from nina to astap (internally, not involving APPM) also have 0 here.

 

That part that confuses me about this is why APPM’s call to ASTAP has fov 0 for a run, and the correct fov for a “plate solve and recal”, since both originate from NINA in (presumably) the same path when NINA controls the camera.

 

Incidentally: The NAXIS for both the solve-now and the run both have zero, indeed the data from NINA looks the same to my eye. 

 

It would appear (speculating) that APPM is using the header to calculate FOV (it has pixel and focal length) for the solve now, but not the regular points in a run?

 

Now why despite FOV=0 mine works and yours doesn’t…

 


Ray Gralak
 

For historical reasons, Plate Solve and recal uses the image scale set on the plate solve tab.

When doing an APPM run, the image scale is calculated from the values in the FITS image.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Monday, October 4, 2021 9:38 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

that's interesting... I guess we'll have to let Ray and Dale sort this one out.

BTW, my solves are successful too, only they are slower, by about 4-5 seconds per solved point (vs about 1-
2 sec) because of this "-fov 0" thing. I have no problem directly in Nina or APT or ASTAP. Always super fast.

If you can't tell the difference, I suppose it might be due to more horsepower in your PC than mine.

just try to solve one of the files APPM was able to solve but using the command line and append "-log". take
a look at the log file (same dir as the solved file), you'll see what ASTAP does try a bunch of preset fov
internally, whereas it does not when the correct Fov is specified or when the -fov switch is omitted.


________________________________

De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@CaptivePhotons.com
<ap@CaptivePhotons.com>
Envoyé : 5 octobre 2021 00:14
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV


Seb@stro wrote :



* but in the FITS header of the WCS file (that came along the same image fits file), I only see this:



* NAXIS = 0 / Dimensionality



For what it is worth, the wcs files from nina to astap (internally, not involving APPM) also have 0 here.



That part that confuses me about this is why APPM’s call to ASTAP has fov 0 for a run, and the correct fov
for a “plate solve and recal”, since both originate from NINA in (presumably) the same path when NINA
controls the camera.



Incidentally: The NAXIS for both the solve-now and the run both have zero, indeed the data from NINA looks
the same to my eye.



It would appear (speculating) that APPM is using the header to calculate FOV (it has pixel and focal length) for
the solve now, but not the regular points in a run?



Now why despite FOV=0 mine works and yours doesn’t…




ap@CaptivePhotons.com
 

Ray wrote:

For historical reasons, Plate Solve and recal uses the image scale set on the plate solve tab.
When doing an APPM run, the image scale is calculated from the values in the FITS image.
I realize they are all related but let me pin down the terminology a bit. He was asking about field of view, the -fov parameter to astap.

The FITS headers from NINA do not contain FOV in any case, but they contain the FOCCALLEN and XPIXSZ/YPIXSZ which allow calculation of image scale (which is also not there explicitly), and with image dimensions you can calculate field of view.

But both image scale and field of view have to be calculated from the fits headers, they are not present in it, right?

Or maybe you are expecting them there.

Can you tell us what specific FITS keys you are expecting to calculate the FOV that is being passed to ASTAP in the run?


Ray Gralak
 

Hi Linwood,

> The FITS headers from NINA do not contain FOV in any case, but they contain the FOCCALLEN and
XPIXSZ/YPIXSZ which allow calculation of image scale (which is also not there explicitly), and with image
dimensions you can calculate field of view.
FOCALLEN, XPIXSZ, and XBINNING are used to calculate approximate image scale. NAXIS1 and NAXIS2 are used to get the image dimensions
and to calculate the field of view.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Monday, October 4, 2021 10:28 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV


Ray wrote:

For historical reasons, Plate Solve and recal uses the image scale set on the plate solve tab.
When doing an APPM run, the image scale is calculated from the values in the FITS image.
I realize they are all related but let me pin down the terminology a bit. He was asking about field of view, the -
fov parameter to astap.

The FITS headers from NINA do not contain FOV in any case, but they contain the FOCCALLEN and
XPIXSZ/YPIXSZ which allow calculation of image scale (which is also not there explicitly), and with image
dimensions you can calculate field of view.

But both image scale and field of view have to be calculated from the fits headers, they are not present in it,
right?

Or maybe you are expecting them there.

Can you tell us what specific FITS keys you are expecting to calculate the FOV that is being passed to
ASTAP in the run?




ap@CaptivePhotons.com
 

Ray wrote:

 

  • FOCALLEN, XPIXSZ, and XBINNING are used to calculate approximate image scale. NAXIS1 and NAXIS2 are used to get the image dimensions and to calculate the field of view.

 

Ok.  So here's the log from my brief test last night (I stopped it after two successful solves in 7).

 

https://drive.google.com/file/d/1Jnqlr46jc0JaMS_ngvt9ZGuNpfvXuMlE/view?usp=sharing

 

The APPM log ending in 846 was a plate-solve-and-recal, so may be less of interest, but it does include the correct fov.  Included but ignore for the moment since you say it has a different calculation approach.

 

The APPM log ending in 734 has two plate solves from a RUN session, which has the astap command with fov set to zero (auto).  Which appeared to be causing the issue reported (though it succeeds).  The images for them are also in the log (almost identical file name but very slightly different RA values in the name).

 

In that log this error appears from APPM prior to calling ASTAP:

 

     ASTAP Plate Solve, Failed to get FITS dimensions (NAXIS1/NAXIS2)

 

However, I am looking in the FITS header, and it shows:

 

    NAXIS   =                    2 / Dimensionality

    NAXIS1  =                 4784 /

    NAXIS2  =                 3194 /

 

Does this imply there is some formatting issue in the FITS header that APPM is unable to extract these properly?

 

That they are absent from the wcs output file is a bit of a puzzle, but they are absent there even if fov is provided, and more relevant if I run ASTAP GUI and load the file, it properly shows them in the fits header, and the alignment tab shows the right calculated field of view (begging the question why the command line doesn’t do the same calculation and override the -fov 0).

 

But back to the original issue -- any chance you could see what exactly caused APPM to fail to get the dimensions from the header?  Is it formatting in the header?   Or something in APPM?

 

Thanks for hanging in there.  This would only pick up a few seconds per solve, but with thousands of users, hundreds of points each... think of all the time we save collectively.  😊

 

Linwood


Ray Gralak
 

The log message is slightly misleading, as APPM can generate that message even if NAXIS1 and NAXIS2 are correctly retrieved. The other way for APPM to log that message is if the image scale for X and Y are zero, because APPM multiplies the image scale (arc-sec/pixel) by each axis dimension. That is, the error message is presented if the multiplication of (image scale * NAXISx) in either axis is 0.

So, I would need an unmodified FITS image to see what the problem was.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Tuesday, October 5, 2021 8:24 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

Ray wrote:



* FOCALLEN, XPIXSZ, and XBINNING are used to calculate approximate image scale. NAXIS1 and
NAXIS2 are used to get the image dimensions and to calculate the field of view.



Ok. So here's the log from my brief test last night (I stopped it after two successful solves in 7).



https://drive.google.com/file/d/1Jnqlr46jc0JaMS_ngvt9ZGuNpfvXuMlE/view?usp=sharing



The APPM log ending in 846 was a plate-solve-and-recal, so may be less of interest, but it does include the
correct fov. Included but ignore for the moment since you say it has a different calculation approach.



The APPM log ending in 734 has two plate solves from a RUN session, which has the astap command with
fov set to zero (auto). Which appeared to be causing the issue reported (though it succeeds). The images for
them are also in the log (almost identical file name but very slightly different RA values in the name).



In that log this error appears from APPM prior to calling ASTAP:



ASTAP Plate Solve, Failed to get FITS dimensions (NAXIS1/NAXIS2)



However, I am looking in the FITS header, and it shows:



NAXIS = 2 / Dimensionality

NAXIS1 = 4784 /

NAXIS2 = 3194 /



Does this imply there is some formatting issue in the FITS header that APPM is unable to extract these
properly?



That they are absent from the wcs output file is a bit of a puzzle, but they are absent there even if fov is
provided, and more relevant if I run ASTAP GUI and load the file, it properly shows them in the fits header,
and the alignment tab shows the right calculated field of view (begging the question why the command line
doesn’t do the same calculation and override the -fov 0).



But back to the original issue -- any chance you could see what exactly caused APPM to fail to get the
dimensions from the header? Is it formatting in the header? Or something in APPM?



Thanks for hanging in there. This would only pick up a few seconds per solve, but with thousands of users,
hundreds of points each... think of all the time we save collectively. 😊



Linwood


ap@CaptivePhotons.com
 

Ray wrote:

 

  • The log message is slightly misleading, as APPM can generate that message even if NAXIS1 and NAXIS2 are correctly retrieved. The other way for APPM to log that message is if the image scale for X and Y are zero, because APPM multiplies the image scale (arc-sec/pixel) by each axis dimension. That is, the error message is presented if the multiplication of (image scale * NAXISx) in either axis is 0.

 

  • So, I would need an unmodified FITS image to see what the problem was.

 

Isn’t that what is in the log zip I sent?

 

If not, help me understand what you need – that’s the image fits file saved by APPM during the run (I had it set to save all, not just failed).

 


Ray Gralak
 

Isn’t that what is in the log zip I sent?
I haven't looked at your link yet. You said you sent a log, but I didn't know it also contained a FITS image.

And ideally, it should be an image right out of NINA before the FITS header has been modified by the plate solver.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Tuesday, October 5, 2021 8:44 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

Ray wrote:



* The log message is slightly misleading, as APPM can generate that message even if NAXIS1 and
NAXIS2 are correctly retrieved. The other way for APPM to log that message is if the image scale for X and Y
are zero, because APPM multiplies the image scale (arc-sec/pixel) by each axis dimension. That is, the error
message is presented if the multiplication of (image scale * NAXISx) in either axis is 0.



* So, I would need an unmodified FITS image to see what the problem was.



Isn’t that what is in the log zip I sent?



If not, help me understand what you need – that’s the image fits file saved by APPM during the run (I had it
set to save all, not just failed).




ap@CaptivePhotons.com
 

Ray wrote:

Isn’t that what is in the log zip I sent?
I haven't looked at your link yet. You said you sent a log, but I didn't know it also contained a FITS image.
Your zipper is smart, it found the images also. 😊

And ideally, it should be an image right out of NINA before the FITS header has been modified by the plate solver.
Your call in APPM to ASTAP doesn't use the "-update" parameter (a good thing IMO), so ASTAP is not rewriting the header when it solves, so the file should be fresh from NINA.

See what you can find there, and let me know what you might need otherwise.


Ray Gralak
 

Hi Linwood,

After looking at the code, I recall what I did. APPM purposely sets "-fov 0" in some cases because that is supposed to tell ASTAP to use the FITS header information to calculate image scale.

Assuming the FITS images you gave me had not been modified in APPM's plate solve attempt, they had the necessary keyword/value pairs in the FITS header for ASTAP to extract and solve. Thus, explicitly setting a FOV value should not change anything unless the ASTAP documentation is wrong.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Tuesday, October 5, 2021 8:59 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

Ray wrote:

Isn’t that what is in the log zip I sent?
I haven't looked at your link yet. You said you sent a log, but I didn't know it also contained a FITS image.
Your zipper is smart, it found the images also. 😊

And ideally, it should be an image right out of NINA before the FITS header has been modified by the plate
solver.

Your call in APPM to ASTAP doesn't use the "-update" parameter (a good thing IMO), so ASTAP is not
rewriting the header when it solves, so the file should be fresh from NINA.

See what you can find there, and let me know what you might need otherwise.