hoping you can help me. I am using ASTAP as my plate solver. It works in all my software except APPM. I have gotten suggestions from the author if APPM to no avail. Ray has suggested diacussing this with you. Any suggestions you can offer would be greatly appreciated. As I said I can plate solve in other programs with no issues so its not a camera, pixel ratio issue. I must be missing some fundamental but simple setting.
Thanks
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Chris. Must be something trivial. Can you retrieve the file used by Appm? Secondly Astap also writes a result file with .ini extension. That file is also interesting. Finally for wide searches Astap will show a yellow Popup notifier. Can you make screenshot of that notifier. Furthermore logs would help.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The M74 image solves without problem in ASTAP. The size is 0.28 x 0.42 degrees.
Size is 1044 x1562 pixels. In the header there is the following indication:
YORGSUBF= 1566 / subframe origin on Y axis in binned pixels
XORGSUBF= 2336 / subframe origin on X axis in binned pixels
So I assume it is a 1/4 or the original image. Why is that done? A full size would result in a more reliable solving.
Is the original image also in portrait rather then landscape mode?
Cut an image has consequences for the "Field of view" not for the pixel size. The pixel size 0.96 arcseconds which matches with the setting 0.98. The question is now what command is give to ASTAP to solve this image. There should be a .ini file at the same location containing the command. Can you find that file? This command is required to understand whats happening.
There is not much other info in the file. That is a pity. The file is 32 bit. That is waste. A 16 bit is smaller in size and would make solving faster.
In your setting the tolerance is set at 0.000. That is normally not good. Should be something like 0.005.
Later this is not a problem:
Tolerance: Tolerance used to compare quads. Typical value 0.007. A value "0" will result in using the default value set in ASTAP.
I will see if I can run APPM in simulation.
Han
Last edit: han.k 2022-10-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To find the cause of your problem, the way forward is to find a .ini file containing the solve instruction. It should be at the same location as the file "SolveNow-2022-10-21-221320.fit" So the file "SolveNow-2022-10-21-221320.ini" The .ini is a text file containing the solve instruction for ASTAP. It doesn't matter is the solve failed. The .ini is always created.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Han - yes, ASTAP can solve the files outside of APPM as a standalone solve, but not while being directed by APPM. The file is 1/4 x 1/4 simply due to size of the full image being too large to attach either as is or compressed.
I left the default as zero as there is very little direction that I can find as to what are good values to set to in any of these criteria. If default is a problem, that seems a bit contrary to the term "default", like don't use default.
I left it as 32 bit as I don't really care at this time whether it is slow, I just want it to solve at some point. If 32 bit is an issue, I will for sure change it.
I did engage Ray some time ago but didn't get any suggestions that would allow me to be successful. It would be great if you can run APPM to figure it out.
It only specifies use maximum 1000 stars (500 would be better)
Search radius 10 degrees max.
Binning auto (-z 0)
Speed auto (-speed auto)
There is no mount RA, DEC position or image size in degrees specified in the command line. ASTAP can then only take that from the FITS header but that is missing in the image header. Then ASTAP will use the position and size of previous solve. That could be totally wrong. What you could do is to set search range to 180 degrees. If the image size in degrees is set correctly the image should solve in a few minutes. The timeout should be set accordingly.
This will not work well. I cannot understand why this is setup this way unless the FITS header information is removed when reducing the image to 1/4.
You should be able to attach the original FITS file to this forum. Or share it via https://ufile.io/
or upload it to:
nova.astrometry.net
at give me the link
If the mount position and image size (or focal length, pixel size) are missing in the FITS header then the aquisition program is to blame. The FITS header specifies this:
SWCREATE= 'ASCOM Camera Test' / string indicating the software used to create t
Which software did create the FITS file?
Han
Last edit: han.k 2022-10-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No FOV (or focal length, pixelsize) and RA, DEC mount position are specified in the FITS header. So solving is only possible going fully blind. If you set the search range at 180 degrees, ASTAP will solve the image after some time but this can take minutes. Secondly ASTAP has to know the FOV. This can be stored in the ASTAP settings if you open ASTAP and set it in tab alignment and then save settings (by file, exit).
Not an ideal situation. It would be better if this is set/specified by the APPM software. Either using the command-line or in the FITS header.
I have got a feedback from Ray. The APPM software can't be used without a mount. So I can't test it.
Maybe Ray has a solution.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's really interesting as what you describe seems to be originating from APPM (missing crucial info in the header). I brought this issue to Ray before and he passed on it, essentially saying it was an ASTAP issue. He suggested I reach out to you.
It's kind of strange as I know that others are using ASTAP with APPM successfully. Perhaps they are just working around. Frankly, they only use APPM to set the model building and then it's off to other programs (no more plate solving with APPM). So maybe a longer solve is ok, just a temporary pain, so to speak.
I will set ASTAP up like you mentioned above. Am I missing anything else? I guess 8 bit is a good idea? What about full frame versus 1/4 x 1/4 frame?
Thanks,
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Han - is the FOV box in the tab "alignment" arc sec/pixel? I see a degree symbol as units. I've put in 0.98 which is the number I've placed in the APPM. Which begs the question if this number is already in APPM, why is it not transferred to ASTAP automatically?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes transferring the mount location to ASTAP would help and then the solve time will be a second or so. But maybe there is a setting somewhere and Ray can explain what to do.
Keep the files full size. 16 bit instead of 32 bit would be a little faster. With 8 bit format information is lost.
Your "portrait" orientation image has an FOV so a field-of-view (height) of 1.68 degrees. Load the image in ASTAP. Enter that in ASTAP, tab "alignment"(ctrl+A) this value 1.68 degrees. With a 180 degrees search this should solve the image. Once you hit the solve button this 1.68 degrees is saved and persistent stored in the ASTAP settings.
In APPM set the search radius at 180 degrees (and max time larger) and it should work.
If you change from portrait to landscape you have to change the 1.68 to 1.12 degrees
This should work. Hopefully the FOV and RA, DEC can be transferred in the future.
The "Field of view (height)" in ASTAP is in degrees. Why it is not transferred, I don't know. It can be transferred by the command-line or via the FITS header. The command-line is overruling the header values. But in APPM software both do not specify anything. So ASTAP will take the last value. This last value is intended for RAW of JPEG files. So once you enter 1.68 degrees and hit the ASTAP solve button or save settings this value is persistent. The RA,DEC mount position is also missing but the 180 degrees search will find it.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi Han
hoping you can help me. I am using ASTAP as my plate solver. It works in all my software except APPM. I have gotten suggestions from the author if APPM to no avail. Ray has suggested diacussing this with you. Any suggestions you can offer would be greatly appreciated. As I said I can plate solve in other programs with no issues so its not a camera, pixel ratio issue. I must be missing some fundamental but simple setting.
Thanks
Chris
Hello Chris. Must be something trivial. Can you retrieve the file used by Appm? Secondly Astap also writes a result file with .ini extension. That file is also interesting. Finally for wide searches Astap will show a yellow Popup notifier. Can you make screenshot of that notifier. Furthermore logs would help.
Han
I will Han, as soon as I get a clear sky.
Thx
Chris
I would expect files from the last solve will be still present and retrievable.
If settings are okay any idea about binning factor used?
I'm travelling but will be back home monday night.
Han
Hi Han - here is some data to look at. Thanks,
Chris
And another
and another
The last was the failed image 1/4 x 1/4 frame, but bin 1
Hello Chris,
The M74 image solves without problem in ASTAP. The size is 0.28 x 0.42 degrees.
Size is 1044 x1562 pixels. In the header there is the following indication:
YORGSUBF= 1566 / subframe origin on Y axis in binned pixels
XORGSUBF= 2336 / subframe origin on X axis in binned pixels
So I assume it is a 1/4 or the original image. Why is that done? A full size would result in a more reliable solving.
Is the original image also in portrait rather then landscape mode?
Cut an image has consequences for the "Field of view" not for the pixel size. The pixel size 0.96 arcseconds which matches with the setting 0.98. The question is now what command is give to ASTAP to solve this image. There should be a .ini file at the same location containing the command. Can you find that file? This command is required to understand whats happening.
There is not much other info in the file. That is a pity. The file is 32 bit. That is waste. A 16 bit is smaller in size and would make solving faster.
In your setting the tolerance is set at 0.000. That is normally not good. Should be something like 0.005.
Later this is not a problem:
I will see if I can run APPM in simulation.
Han
Last edit: han.k 2022-10-22
The seems no free trial for APPM software. I have posted something to Ray. I'm not sure he will receive it:
https://sourceforge.net/p/astap-program/discussion/general/thread/258852c513/?limit=25
To find the cause of your problem, the way forward is to find a .ini file containing the solve instruction. It should be at the same location as the file "SolveNow-2022-10-21-221320.fit" So the file "SolveNow-2022-10-21-221320.ini" The .ini is a text file containing the solve instruction for ASTAP. It doesn't matter is the solve failed. The .ini is always created.
Han
Hi Han - yes, ASTAP can solve the files outside of APPM as a standalone solve, but not while being directed by APPM. The file is 1/4 x 1/4 simply due to size of the full image being too large to attach either as is or compressed.
I left the default as zero as there is very little direction that I can find as to what are good values to set to in any of these criteria. If default is a problem, that seems a bit contrary to the term "default", like don't use default.
I left it as 32 bit as I don't really care at this time whether it is slow, I just want it to solve at some point. If 32 bit is an issue, I will for sure change it.
I did engage Ray some time ago but didn't get any suggestions that would allow me to be successful. It would be great if you can run APPM to figure it out.
Thanks,
Chris
The command line is as follows:
CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Dad's Astronomy\Documents\Astro-Physics\APPM\SolveNow-2022-10-21-221320.fit" -s 1000 -r 10 -z 0 -speed auto
It only specifies use maximum 1000 stars (500 would be better)
Search radius 10 degrees max.
Binning auto (-z 0)
Speed auto (-speed auto)
There is no mount RA, DEC position or image size in degrees specified in the command line. ASTAP can then only take that from the FITS header but that is missing in the image header. Then ASTAP will use the position and size of previous solve. That could be totally wrong. What you could do is to set search range to 180 degrees. If the image size in degrees is set correctly the image should solve in a few minutes. The timeout should be set accordingly.
This will not work well. I cannot understand why this is setup this way unless the FITS header information is removed when reducing the image to 1/4.
You should be able to attach the original FITS file to this forum. Or share it via
https://ufile.io/
or upload it to:
nova.astrometry.net
at give me the link
If the mount position and image size (or focal length, pixel size) are missing in the FITS header then the aquisition program is to blame. The FITS header specifies this:
SWCREATE= 'ASCOM Camera Test' / string indicating the software used to create t
Which software did create the FITS file?
Han
Last edit: han.k 2022-10-23
All the images (fits files) were created with APPM. I will send the larger file via the methods you noted. Thanks Han.
Is there a public link to download APPM? If not any idea where I can contact Roy for a copy of APPM software to play with?
Han
https://ufile.io/hxmeu5l4
Here is the full size file and .ini file. I will look for Ray's email address.
Thanks Han
...............
That is the email I use to contact Ray directly.
Last edit: han.k 2022-10-24
Thanks, I have the Ray's email. I removed it from the forum now.
Download of the full FITS doesn't work. I think the link is wrong. Can you try one more time?
https://ufile.io/
at give me the link
Han
Here it is - thanks Han
https://ufile.io/x3acgpo6
Thanks,
No FOV (or focal length, pixelsize) and RA, DEC mount position are specified in the FITS header. So solving is only possible going fully blind. If you set the search range at 180 degrees, ASTAP will solve the image after some time but this can take minutes. Secondly ASTAP has to know the FOV. This can be stored in the ASTAP settings if you open ASTAP and set it in tab alignment and then save settings (by file, exit).
Not an ideal situation. It would be better if this is set/specified by the APPM software. Either using the command-line or in the FITS header.
I have got a feedback from Ray. The APPM software can't be used without a mount. So I can't test it.
Maybe Ray has a solution.
Han
That's really interesting as what you describe seems to be originating from APPM (missing crucial info in the header). I brought this issue to Ray before and he passed on it, essentially saying it was an ASTAP issue. He suggested I reach out to you.
It's kind of strange as I know that others are using ASTAP with APPM successfully. Perhaps they are just working around. Frankly, they only use APPM to set the model building and then it's off to other programs (no more plate solving with APPM). So maybe a longer solve is ok, just a temporary pain, so to speak.
I will set ASTAP up like you mentioned above. Am I missing anything else? I guess 8 bit is a good idea? What about full frame versus 1/4 x 1/4 frame?
Thanks,
Chris
Han - is the FOV box in the tab "alignment" arc sec/pixel? I see a degree symbol as units. I've put in 0.98 which is the number I've placed in the APPM. Which begs the question if this number is already in APPM, why is it not transferred to ASTAP automatically?
Yes transferring the mount location to ASTAP would help and then the solve time will be a second or so. But maybe there is a setting somewhere and Ray can explain what to do.
Keep the files full size. 16 bit instead of 32 bit would be a little faster. With 8 bit format information is lost.
Your "portrait" orientation image has an FOV so a field-of-view (height) of 1.68 degrees. Load the image in ASTAP. Enter that in ASTAP, tab "alignment"(ctrl+A) this value 1.68 degrees. With a 180 degrees search this should solve the image. Once you hit the solve button this 1.68 degrees is saved and persistent stored in the ASTAP settings.
In APPM set the search radius at 180 degrees (and max time larger) and it should work.
If you change from portrait to landscape you have to change the 1.68 to 1.12 degrees
This should work. Hopefully the FOV and RA, DEC can be transferred in the future.
Tell me if this works for you
Han
The "Field of view (height)" in ASTAP is in degrees. Why it is not transferred, I don't know. It can be transferred by the command-line or via the FITS header. The command-line is overruling the header values. But in APPM software both do not specify anything. So ASTAP will take the last value. This last value is intended for RAW of JPEG files. So once you enter 1.68 degrees and hit the ASTAP solve button or save settings this value is persistent. The RA,DEC mount position is also missing but the 180 degrees search will find it.
Han
Below is what you typically find in a FITS header. This is all what ASTAP requires:
Han
Hi Han and Chris,
Sorry, I haven't had time lately to monitor posts here.
Chris, in your screenshot of APPM's it shows you have the the "Use FITS header..." checkbox set. Have you tried unchecking that option?
-Ray