I've noticed that when I run the batch solve in MAC 8/21/2024, it converts all of the batch files to the same AIRMASS. So targets at different altitudes are all registering the same AIRMASS. Can the batch solve only be used for a single target at a time?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a new Mac and so updated my program from the x86 mac version to the latest M processor version. I am still processing my photos one target at a time, but now when I batch process to add AIRMASS, the program adds AIRMASS as 999.000 and does not add ObjectAlt or Centalt to the FITS Header. Analyzing in the Photometry tab likewise shows airmass as 999.000 regardless of the target.
Thanks much Han, no rush, I hope you enjoy your travels.
Since I'm running a new (to me) Mac on a new operating system I decided to offload the M1 version of ASTAP and reload the x86 Mac version of the program. While it's slower than the M1 version reloading it did work to bring back AIRMASS, ObjectAlt, and CentAlt back into the FITS header. But the original problem remains. When running Batch Solve, the program converts all AIRMASS to the airmass of the first file in the list. Here are a couple of screen shots as an example.
I very much appreciate your help. Your program is very user friendly, thanks!
While the program converts all AIRMASS to the airmass of the first file in the list regardless of target, I mentioned some issues that I was having with the M1/M2 Mac version. Just so you know, I fould the error of my ways, and, other than the batch AIRMASS problem, the M1/M2 Mac version works fine, thank you! Also, you previously asked if I would share VPHOT processed photos and their AAVSO report. Would you still like a sample of that, and, if so, how should I send it? Thx.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes images processed by VPHOT and their corresponding reports are most welcome for accuracy testing.
I'm also working on the photometry tab and already introduced in the ASTAP 2024-09-25 version a possibility to use AAVSO VSP stars as comparison rather the Gaia stars ensemble. Next days I will work on option to select an ensemble of AAVSO VSP stars for comparison rather then a single star.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a new exectubles for the MacOS. It is a development version which fixes the airmass in the batch menu.
You could move the new executables inside ASTAP (right mouse button to see inside) or wait for the installer. The installer I will create in the next days after more testing.
Photometry has a new option for multi comp stars. Only briefly tested.
Thanks for working on the Han. I really appreciate it. I added the executable into the M1/2 MAC version. But I'm now getting an MZERO calibration failure error and it's reporting all AIRMASS under the Photometry tab as 999.000. I made sure that my coordinates were correct in the Asteroid and Comet annotation, and tried calibrating with the SQM report pedestal value at 100 and at 500 both with and without the darks and flats box checked. Calibration continues to return the MZERO calibration failure error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is strange. I have tested it here again but it looks all okay. Can you attach one file your using for testing the MZERO calibration?
Thanks for the VPHOT files. Little strange that the CNAME and KNAME are identified with a number of the chart. Makes reproducing the measurement a little difficult. For the CNAME ensemble is seems unclear which stars where used for the ensemble. Anyhow I get very similar values for V. For Filter B I need to work on the processing if both V and B images are in the list.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you. I have no doubt it's operator error. I just don't know where I made the error. I appreciate your help.
Here are a sample B and a sample V file with the MZERO error. I have also included the photometry table for my AK Cep reports. If you go to the AAVSO.org website and click on "plot a chart", you can enter the chart number from the AAVSO report and pull up the photometry table. The CNAME and KNAME are the star magnitudes (without the decimal). The photometry table includes detailed magnitude infomation together with the AUID identifiers of the comp stars. You don't need to be a member to get this information. Let me know if you need anything more.
I use the tools, batch menu and get this in the header:
PLTSOLVD=T/AstrometricsolvedbyASTAPv2024.10.19.COMMENT7Solvedin0.6sec.Offset15.6'. Mount offset RA=7.2',DEC=7.6' MZERO = 0 / Unknown. Set aperture to MAX for ext. objects MZEROR = 2.269784157715E+001 / V=-2.5*log(flux)+MZEROR using MZEROAPT MZEROAPT= 2.558621552710E+000 / Aperture radius used for MZEROR in pixels MZEROPAS= 'V' / Passband database used. LIM_MAGN= 1.550695624183E+001 / estimated limiting magnitude for point sources CENTALT = '71.13' / [deg] Nominal altitude of center of image OBJCTALT= '71.13'/[deg]NominalaltitudeofcenterofimageAIRMASS=1.0565/Relativeopticalpath.SQM=19.94/Skybackground[magn/arcsec^2]COMMENTSQM,used0aspedestalvalueEND
MZERO is zero because I have aperture set of about 3 pixels. The substitute is MZEROR allowing ASTAP to measure stars.
AIRMASS is 1.0565.
Maybe you placed the ASTAP in the wrong place. Check the version date under HELP, ABOUT. The executable should be placed in It should moved in the application at /Contents/MacOS
Check also your batch settings check marks. See attached.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attached the result. I didn't used the image using ensembles. The blue of TX Dra is off. ASTAP could not detect blue of T Dra. Differences are in red font
It will be good do do more testing before drawing conclusions. I will upload a new ASTAP version tonight or tomorrow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I think I've double checked everything, but still no joy. I have attached screen shots showing the version, file location, and settings. I ran a test and still came up with no airmass. But checking the fits header I see that there are no MZERO lines in the header. I have attached a txt file of the header.
No blue on T Dra doesn't suprise me. I stacked several minutes of 20-second frames to get even a very low SNR so that I could transform the result. The B SNR is only 12 and the ERR is almost 0.1. I reported it anyway since the process was good. I leave it to whoever wants to use the data to determine whether they want to accept that ERR.
I offloaded and reloaded both the MAC Intel and Mac M1/M2 versions. The MAC Intel works great. The unique AIRMASS values are added to each of the images. The M1/M2 version still has the same issues that I described above. But the MAC Intel version does run on my M2 machine so I'm good to go. Thanks VERY much!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed that when I run the batch solve in MAC 8/21/2024, it converts all of the batch files to the same AIRMASS. So targets at different altitudes are all registering the same AIRMASS. Can the batch solve only be used for a single target at a time?
I have a new Mac and so updated my program from the x86 mac version to the latest M processor version. I am still processing my photos one target at a time, but now when I batch process to add AIRMASS, the program adds AIRMASS as 999.000 and does not add ObjectAlt or Centalt to the FITS Header. Analyzing in the Photometry tab likewise shows airmass as 999.000 regardless of the target.
Thanks for the feedback. Should be easy to fix but his has to wait two weeks since I'm traveling.
Cheers, Han
Thanks much Han, no rush, I hope you enjoy your travels.
Since I'm running a new (to me) Mac on a new operating system I decided to offload the M1 version of ASTAP and reload the x86 Mac version of the program. While it's slower than the M1 version reloading it did work to bring back AIRMASS, ObjectAlt, and CentAlt back into the FITS header. But the original problem remains. When running Batch Solve, the program converts all AIRMASS to the airmass of the first file in the list. Here are a couple of screen shots as an example.
I very much appreciate your help. Your program is very user friendly, thanks!
While the program converts all AIRMASS to the airmass of the first file in the list regardless of target, I mentioned some issues that I was having with the M1/M2 Mac version. Just so you know, I fould the error of my ways, and, other than the batch AIRMASS problem, the M1/M2 Mac version works fine, thank you! Also, you previously asked if I would share VPHOT processed photos and their AAVSO report. Would you still like a sample of that, and, if so, how should I send it? Thx.
I'm now back and have time for programming.
I will fix the airmass problem.
Yes images processed by VPHOT and their corresponding reports are most welcome for accuracy testing.
I'm also working on the photometry tab and already introduced in the ASTAP 2024-09-25 version a possibility to use AAVSO VSP stars as comparison rather the Gaia stars ensemble. Next days I will work on option to select an ensemble of AAVSO VSP stars for comparison rather then a single star.
Han
I'm happy to upload samples, but my photos are about 26MB each and not much smaller when zipped. The forum appears not to permit uploads that large.
Zip them to one file and upload them somewhere on the web. E.g to (and share the link)
https://ufile.io/
Han
Thanks. Here you go. The photos were shot with B and V filters and the results were transformed. Let me know if you need anything else.
https://ufile.io/mj4nllk3
I have a new exectubles for the MacOS. It is a development version which fixes the airmass in the batch menu.
You could move the new executables inside ASTAP (right mouse button to see inside) or wait for the installer. The installer I will create in the next days after more testing.
Photometry has a new option for multi comp stars. Only briefly tested.
http://www.hnsky.org/astap.htm#beta_version
Thanks for working on the Han. I really appreciate it. I added the executable into the M1/2 MAC version. But I'm now getting an MZERO calibration failure error and it's reporting all AIRMASS under the Photometry tab as 999.000. I made sure that my coordinates were correct in the Asteroid and Comet annotation, and tried calibrating with the SQM report pedestal value at 100 and at 500 both with and without the darks and flats box checked. Calibration continues to return the MZERO calibration failure error.
That is strange. I have tested it here again but it looks all okay. Can you attach one file your using for testing the MZERO calibration?
Thanks for the VPHOT files. Little strange that the CNAME and KNAME are identified with a number of the chart. Makes reproducing the measurement a little difficult. For the CNAME ensemble is seems unclear which stars where used for the ensemble. Anyhow I get very similar values for V. For Filter B I need to work on the processing if both V and B images are in the list.
Han
Thank you. I have no doubt it's operator error. I just don't know where I made the error. I appreciate your help.
Here are a sample B and a sample V file with the MZERO error. I have also included the photometry table for my AK Cep reports. If you go to the AAVSO.org website and click on "plot a chart", you can enter the chart number from the AAVSO report and pull up the photometry table. The CNAME and KNAME are the star magnitudes (without the decimal). The photometry table includes detailed magnitude infomation together with the AUID identifiers of the comp stars. You don't need to be a member to get this information. Let me know if you need anything more.
https://ufile.io/f/l0s1f
Last edit: L Wentzel 2024-10-20
I use the tools, batch menu and get this in the header:
MZERO is zero because I have aperture set of about 3 pixels. The substitute is MZEROR allowing ASTAP to measure stars.
AIRMASS is 1.0565.
Maybe you placed the ASTAP in the wrong place. Check the version date under HELP, ABOUT. The executable should be placed in It should moved in the application at /Contents/MacOS
Check also your batch settings check marks. See attached.
This attachment.
I'm testing your 6 files. More later
Han
Attached the result. I didn't used the image using ensembles. The blue of TX Dra is off. ASTAP could not detect blue of T Dra. Differences are in red font
It will be good do do more testing before drawing conclusions. I will upload a new ASTAP version tonight or tomorrow.
The attachment
ASTAP version 2024-10-21 has just been released. Try the pkg installer.
Han
OK, I think I've double checked everything, but still no joy. I have attached screen shots showing the version, file location, and settings. I ran a test and still came up with no airmass. But checking the fits header I see that there are no MZERO lines in the header. I have attached a txt file of the header.
No blue on T Dra doesn't suprise me. I stacked several minutes of 20-second frames to get even a very low SNR so that I could transform the result. The B SNR is only 12 and the ERR is almost 0.1. I reported it anyway since the process was good. I leave it to whoever wants to use the data to determine whether they want to accept that ERR.
https://ufile.io/f/qnurk
I offloaded and reloaded both the MAC Intel and Mac M1/M2 versions. The MAC Intel works great. The unique AIRMASS values are added to each of the images. The M1/M2 version still has the same issues that I described above. But the MAC Intel version does run on my M2 machine so I'm good to go. Thanks VERY much!
Strange that the M1 version doesn't work the same way. The source code is the same, just a different version of the compiler.
I can't test the M1 version here since I have only an old intel Mac. Keep me informed about any other difference. It should not happen.
Cheers, Han
Will do, thanks.