#Astrometry search radius plus#
If you are "just" interested in new transients, doing photometry on each and every detectable star in a potentially wide field is perhaps overkill and will slow you down, plus it might even work poorly for transients that are blended within galaxies (SNs etc). Taking perhaps a step back, I wonder: what is the purpose of the survey system?ĭo you want to build a a massive catalog of stars with measurements of them, perhaps to find new variable stars among known (catalogued) stars, or do you want to detect perhaps new optical transients? If my reply did not help directly, hopefully it was at least somewhat interesting to read. In my case, disk I/O is clearly the limiting factor (reading index files and reading-writing data files).įew years ago, one of my colleagues wrapped all of that + automatic PSF photometry with Python and saved the photometry output of tens of thousands of frames into a MySQL database. Normally, solving our Planewave CDK12.5+Apogee Alta U42 frames having 37'x37' FoV (plate scale 1.09 "/pix) with search radius of 1 degree (major source of optimization!) with local, I get WCS solution in 3-10 seconds on 3.2 GHz Core 2 Duo computer with 8G of RAM and non-SSD disks. To solve large amount of images, I just call the script for all of them one by one from shell as:įor i in `ls my*.fits` do myscope.sh $i done I execute that Shell script from command line: myscope.sh myfile.fitsĪnd output in few seconds will be: myfile-wcs.fits New-wcs -i $1 -w $FILEBASE.wcs -o $FILEBASE-wcs.fits -d scale-low $SCL -scale-high $SCH -scale-units arcsecperpix -l $GIVUP $1 overwrite -skip-solved -crpix-center -ra $RA -dec $DEC -radius 1 \ Solve-field -t 2 -use-sextractor -S none -M none -R none -B none -U none -N none -no-plots \
#Astrometry search radius software#
# Get field center coordinates from FITS header in sexagesimal, needs wcstools software installed # Something is wrong, solution shouldn't take 1 minute # Field lower and upper scale limits in arcsec per pixel (if stable, shrink the range for speed) I'll paste my solver script below as a Unix Shell script:Įxport PATH=$PATH:/usr/local/astrometry/bin I found that Sextractor is faster for star detection than itself, so I'm using that, too. Plate solving with is also very fast if you know approximate center of your FoV, your plate scale, and have disabled all add-ons (pictures with overlays). Sterken & Manfroid "Astronomical photometry. FWHM-driven aperture selection can be also useful when field(s) are not crowded.ĥ) Some kind of background processes for data quality assessment would be desirable - were there passing clouds or fog when frame #123075 was taken? Was there a fly w(a/o)ndering on filter for that one exposure? How good was the sky, was it transparent, did transparency vary during the observations? Some assumptions of Ubercalibration procedure are useful for that (e.g. In fact, Sextractor does also gives good aperture photometry and allows highly customizable output (with world coordinates based on TAN-SIP solution, too). by using PSFex, however automatic quality control of PSF photometry can be quite challenging. But in that case you do photometry only on objects that are in your input list - are you interested in transients? Automatic PSF photometry (it is very difficult to measure Milky Way regions without PSF photometry) can be done e.g. Locating objects by WCS and re-centering apertures or having objects with pixel coordinates and matching those later using WCS works well.
What we learned quickly, is that placing apertures by world coordinates is unreliable and gives systematically deviating measurement results. Pinpoint is very fast, too.Ģ) Object detection can be tricky, because you may want to detect all objects from frames automatically, basically down to the noise.Ĥ) Doing aperture or (automatic) PSF photometry on detected objects in pixel coordinate system. Which ones are actually good? Are there any variable problems with scattered light etc etc?ġ) High-quality plate solution is a must: local solution with SIP (survey telescope probably has relatively wide FoV => plate scale over the entire frame is variable almost by definition) and/or Scamp are good options unless you can find good aperture photometry software for Windows(?) that understands Pinpoint's proprietary ( ) distortion description. It is a real headache - there can be so much data that you can't look at each individual flat frame. In general our workflow works as:Ġ) Preprocessing of the data in automatic way. We have done something similar in our observatory, using both in IDL in the past and now Python.
0 kommentar(er)
