- This topic has 10 replies, 4 voices, and was last updated 5 years, 11 months ago by
.
-
Posts
-
Not sure whether this belongs here or in the General Discussion forum. If the latter presumably one of the resident demigods can move it over there.
Most people, for very good reasons, run only MSFT Windows software. A significant minority live in a MacOS or Linux environment. Most everything I do is under Linux. As the saying goes: there are no problems only opportunities. I’ve encountered some opportunities when trying to find out how to submit VS observations, hence the location for this post.
Anyone here not using Windows software and would like to form a mutual self-help group? Topics might include how to get Excel spreadsheets with macros working reliably in OpenOffice and/or LibreOffice, how to convert Linux or MacOS photometry output into the required VSS format, and so on. If this post is moved to the General forum there are numerous other topics which could be considered.
Of course, if I’m the only weirdo here, please ignore the above and I’ll soldier on alone.
Paul
Hi Paul,
you are not the only weirdo on here – I use mainly Macs and also a couple of Raspberry Pis with Linux – and i’ve dabbled with other Linuxes in the past.
For convenience, though, I do use Mac version of MS Office…
Maybe you looked at the ImageJ photometry tutorial currently on the front-page – ImageJ is cross-platform and should run well on Linux/MacOS.
But sorry not able to provide much in the way of practical help on any VSS questions. But you certainly have my moral support!
Clear skies,
Callum
I found, downloaded and installed APT — Aperture Photometry Tool — from http://www.aperturephotometry.org/aptool/ today. It looks very promising! Because it is wrotten in Java it runs (well, walks sedately) everywhere. The same can be said of AstroImageJ for that matter.
Next plans are to evaluate it thoroughly and if it passes muster, write a Perl script to convert its output into BAA-VSS and/or AAVSO format.
Source Extractor is available under Linux – and also in a limited form (no WCS support) under Windows. Would that or IRAF/Starlink be of any use for initial data extraction?
After a few happy hours playing with APT I have to say I rather like it. It’s easy to use after a little reading of the fine manual and works well even on a small laptop screen. Configuration is straightforward, though it took me a while to learn how to set the zero point so that the instrumental magnitudes are somewhere near those of the comparison stars.
I think I”m going to put some real effort into this one, with a few scripts written to convert AAVSO CCD photometry files into that required for APT, to mung the CSV output file into ensemble photometry and AAVSO and BAA-VSS format, and generally make it even easier to use so that non-Windoze users have a viable alternative.
All this will take some effort and very careful attention to detail so although beta testers would be made welcome, don’t expect a polished tool set just yet!
I’m a happy bunny. 😎
The photometry tools which run everywhere and with which I have some familiarity are APT, AstroImageJ and IRAF/DAOPHOT. Those are the ones which I will target. AIJ will be familiar to many here; I’m climbing its learning curve with the assistance of the excellent BAA-VSS guide. As noted above, I like APT. DAOPHOT is the grand-daddy from which most other tools have been developed, including munipack/muniwin (another excellent tool but not one with which I’m currently playing).
DAOPHOT is a real professional’s tool. I’ve scripted it to analyze approximately 10k images taken over the last several months by Kevin Hills. It’s a refugee from the 1980s and doesn’t fit particularly well with the GUI paradigm. I’m an old fogey so that doesn’t worry me too much. What I really like is that although it uses only circular apertures, the star PSF is evaluated directly from the data (that is it doesn’t assume any particular shape and so can handle trailed or otherwise munged images) and can vary from point to point in the image. Coupled with very effective de-blending of closely neighboring stars, it gives very accurate results even in very crowded fields.
As far as I can tell (please correct me if I’m wrong) AIJ employs only circular apertures and assumes that the star images are circularly symmetrical. If so, a trailed star has to be included inside a relatively large circular aperture and so encloses rather a lot of sky as well, leading to poorer estimates for the magnitude and its error.
APT (again, AFAICT) doesn’t allow for a spatially-varying PSF but does allow apertures which are ellipses of arbitrary orientation. As well as modelling non-circular stars nicely, this also fits well with the requirements for performing photometry of galaxies (and perhaps comets?).
Software written so far will parse a downloaded AAVSO CCD photometry file and produce target lists for APT and a RADec file for AIJ. Still to come is code which replicates the BAA-VSS Excel spreadsheets which (again, AFAICT) run only on MS Office.
Code to drive IRAF/DAOPHOT and Munipack is likely to take some time because I’m probably only the person interested in them
To early to ask for beta testers but your time will come!
Paul,
I’ve sent an email to your gmail address regarding a free virtual machine package of various astronomy software configured to work and is described in this years proceedings of the Society for Astronomical Sciences (SAS). Includes, DAPHOT, IRAF, PYRAF, AIJ various spectroscopy software and a stand alone photometry package.
Looks very useful.
Eric
It looks like I may now have a portable photometry toolkit which should run most anywhere as the components are written in Java and Perl.
The raw input data is a FITS image to be analyzed and an AAVSO CCD-photometry chart downloaded from aavso.org then saved in HTML format. The latter is first parsed into a couple of plain text files, one of which is a list of sources to be found and analyzed by APT, the other a summary of the data for the comparison stars.
APT is then instructed to perform the aperture astronomy and write a CSV file of its findings. The latter is then processed by a Perl script to produce a TSV file suitable for submission to the BAA-VSS — or so I believe.
Would anyone like to be a beta-tester of this stuff? It’s limited but apparently functional. It should run anywhere with a Perl installation and a Java Virtual Machine but that hasn’t yet been proven.
Extensions to use AIJ (and possibly other photometry engines) are planned, as is smoothing out rough edges.
Please mail me for source code and hand-holding. You’ll need the latter as the documentation for my stuff is non-existent at present (that will change), though the code is well commented. APT is very well documented.
Paul
There is a version of DAOPHOT available for Python too – I always found IRAF as user friendly as a punch in the mouth and poorly debugged. The Python DAOPHOT seems to work okay for me. The major difference over the Fortran version is that it doesnt handle a bad pixel mask. Execution times similar (having no bad pixels to worrry about makes life lots easier).
I must admit I was under the impression DAOPHOT assumes a Gaussian profile so it can get unhappy with distorted images – theres a parameter for limiting how eccentric it will tolerate.
I did a quick study a year or two back and looked at Source Extractor, PISA and DAOPHOT. Each had its quirks. DAOPHOT was primarely aimed at stars while Source Extractor and PISA could do both stars and galaxy photometry. Source Extractor was very good but the documentation a little incomplete and PISA was by far the most memory efficient. When the source was star shaped they all did similarly in terms of the detections, but Source Extractor could use the WCS (I don’t think PISA did, but I might be wrong). Bottom line was they all had efficient detection approaches and if you already had code to handle the pixel space coordinate to Ra/Dec conversion, each was well worth having.
In The Fine Manual for DAOPHOT, available as http://www.astro.wisc.edu/sirtf/daophot2.pdf , the PSF question is covered in detail. A quote from page 32 reads:
For all the different analytic first approximations, the first two parameters are always the half-width at half-maximum in x and y. Any other parameters the model may have differ from function to function, but the first two are, as I say, always the half-width at half-maximum in x and y.
Accordingly, the PSF is invariably elliptical.
See, also, the ALGORITHMS section of daophot> help psf where it is explained that if varorder >= 0, the residuals from the fit are stored as a lookup table, meaning that all but pathologically weird shapes can be handled with ease. In particular diffraction spikes from secondary mirror supports cause no difficulty whatsoever.
I freely accept that DAOPHOT isn’t user-friendly by modern standards but it does a superb job.
- You must be logged in to reply to this topic.