Forum Replies Created
-
Posts
-
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.
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
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!
Images from La Palma last night are being analyzed right now but I’m still learning how to do that. Results (possibly preliminary) will be edited into this post. Nova certainly very obvious on the 3000s stacked image but the background from M31 is very bright and precision photometry will need to take that into account.
FWIW, I’m about to download GAIA-DR2 positions and magnitudes for analysis purposes as I don’t have a finder chart and comparison magnitudes. I’m hoping this is satisfactory …
Results are undoubtedly preliminary because I’m still learning how to drive the tool set and much data reduction has been done by hand.. Comparing my V-band mags with GAIA’s G-band gives satisfactory results (less than 0.05 mags at mag 16) so I’m fairly confident that the nova was at mag 16.50 +/- 0.05 at 2018-11-30 02:40UT.
Now to improve my skills and tools.
I don’t (yet) know the answer to the question as asked but have you considered running a local astrometry.net server? It’s markedly faster and more reliable than using nova.astrometry.net in my experience and relatively easy to set up. There’s a Windoze version called ansvr (Google is your friend!) but it’s a large download because you get a cygwin installation thrown in for free so all the required Linux programs are available. The data files are another big download, especially if you use the latest 5000 series indexes which are based on GAIA-DR2, but all this lot only has to be done once. If you already run Linux life is markedly easier in this regard as only base software and the indexes need downloading. I’ve not regretted installing ansrv for MaximDL’s benefit.
I also use AIJ (though I’m now more enamoured of APT) so I’ll research your actual question.
I’m also happy to provide (free, best-efforts) consultancy via email.
Paul
Welcome aboard! I’m a newbie on the forums and only re-joined the BAA a few months ago after a 30-year hiatus.
Your image looks pretty impressive to me. Much better than I could produce given my (present) incompetence at driving my newly acquired equipment.
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. 😎
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.
Personally I’d go for the aperture if it’s within your budgetary and mechanical limitations. Most of the time the image will be seeing limited but the resolution of the larger will be better than the smaller in the brief intervals when the atmosphere in front of your telescope is steady. The extra light grasp will be invaluable if your tastes change and deep sky becomes more important, or if you branch out into fields such as VS and cometary observing.
As for focal length, note that 13*102 = 1326 and 9.5*127 = 1206.5 so the longer focal length is only 10% greater than the shorter.
Added in edit: (127/102)^2 = 1.55, so the light grasp is 55% greater, or roughly half a magnitude.
Google Maps Platform rejected your request. This IP, site or mobile application is not authorized to use this API key. Request received from IP address 80.38.183.17, with referer: https://adguard.com/referrer.html
Does anyone else get this, or is it just because I run an ad-blocker? No big deal.
a) I would recommend NOT using median stacking. Averaging and summing are essentially the same operation, just that the first divides by the number of images stacked. Median stacking is not a linear operation and (almost?) all photometry assumes a linear detector response.
b) The exposure of the stacked frames is the sum of the exposures of the individual frames.
c) I believe you should use the weighted mean of the mid-point times of the individual frames, where the weights are the exposure times of each frame. If your stack consists of equally spaced exposures of equal exposure times, the mid-point of the central frame (assuming it exists, what if you have an even number of frames?) is the same thing.
Something to be aware of if you want the highest accuracy: all the above assumes that the focus and the sky background do not vary greatly throughout the stack. If you are in doubt, perform the photometry on each frame to give a flux measurement (not the magnitude, which varies as the logarithm of the flux) and its corresponding variance. Then add up all the fluxes weighted by their corresponding variance . The stacked variance is the root-mean-square of the individual values.
All the above assumes you are doing differential photometry — that you are measuring the relative brightness of a target and a supposedly constant comparison star.
I was thinking about this problem overnight. There are several metrics which could be considered (and the considerer not to be considered to be too silly).
One is that which minimizes the person-kilometres traveled. A few people who have to travel a long distance balance a larger number who need only travel a short distance.
Another is that which minimizes the person-expenditure outlay. A few people who must take expensive routes, for example on a ferry or over a toll bridge, balance a larger number who do not need to pay for the infrastructure such as public highways over which they travel.
I have very little idea about the locations which minimize the above metrics. If forced to guess I suspect that the location would be somewhere fairly near Nottingham.
“If you stick a pin in the centre of the UK?”
https://en.wikipedia.org/wiki/Centre_points_of_the_United_Kingdom gives a point in Lancashire.
Fair point.
I was more thinking that having a price list here would be helpful to all concerned.
P.M. already sent.
“something weird associated with frame stacking”. Ah, I wonder if perhaps some frames have become rotated with respect to the others? If your stacking performs only rectilinear shifts then those near the center of rotation will be stacked perfectly but those further away will be smeared into short arcs. Removing a circularly symmetric synthetic star from the center of an arc will result in wings.
Could you try stacking, say, half the images and see if the result changes? Repeat with a differently chosen half, and again.
