[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Astrometry errors



Andrew's latest results indicate that he is approaching
1/75 of a pixel centroiding.  We average around 1/100
pixel here for our parallax observations, on well exposed,
well-sampled, round, isolated stars.  He should be
congratulated for achieving nearly the same precision
with Mark IV images.
  If he has not already done these tests, I'd recommend
the following:
  (1) I think the disk set you are using has short and
      long images.  Look at the faint objects on the short
      set and see how well you do in detection, centroiding,
      and photometry as compared to the deeper images.
      That will tell you how well, for example, the
      psf fitting technique does for faint objects.
  (2) One of the major problems with Mark IV images is
      blending.  Does Andrew's technique do a good job
      of deblending merged objects and getting good astrometry
      and photometry of them?  One catalog to check against
      is the FASTT calibration regions at
      ftp://ftp.nofs.navy.mil/pub/outgoing/calibregions
      if I recall right, where the astrometric accuracy is
      around 50mas absolute and the pixel size is such that
      reasonably close objects are resolved; the FASTT catalog
      also goes fainter than any TASS image.  A further
      test is just how faint the program detects objects
      reliably.
  (3) How well does Andrew's program do on separating stars
      from other objects like galaxies, plane trails,
      cosmic rays, etc.?  Have you done any tests on fields
      that cross galaxies or that have trails to see how
      these features are treated?
  (4) One current problem is the slowness of the program
      (if the two images/day number I've seen is correct).
      Since we need to process ~200 images per day, some
      speed improvements may be necessary if Andrew's
      software is used.  Perhaps a rough examination of
      the code could determine where most of the time
      is spent and therefore some work could be put into
      optimization.
I'm not married to any software package.  I've proposed
iraf only because it does all of the necessary steps,
can be scripted, is available free of charge, and is thoroughly
tested.  If someone creates a better pipeline for Unix,
I'm all in favor of it since then I not only get better
results, but I don't have to do the scripting!
Arne