RE: Common and uncommon goals and software

[<aah@nofs.navy.mil>]

Jamie,  Mike G. specified that the header to the FITS starlist
table would be a copy of the image header, which would then
include date, time, exposure, etc.  The Julian Date should be
part of that header rather than tacked on to each star's data
since it does not change.
  I've mentioned this before when dealing with the Mark III,
but I'd like the following parameters to be included beyond
what Mike mentioned:
  roundness
  sharpness  (that is, some additional shape parameters)
  peak DN  (I use it when deciding whether a star is saturated, etc.)
  sky DN
Also, a big question is what kind of magnitude?  Aperture (if so,
I'd list several and also include where the sky annulus is taken)
or psf?  My preference would be to include one aperture magnitude
(probably about a 5 pixel radius) and a psf magnitude.  Jure, the
fwhm is an important parameter as it tells you how good the tracking
was, whether you are dealing with a blended image, etc.
  Michael -- IRAF is well documented and details the algorithm
used for each task.  You can even look at the source code if you
are concerned about how the algorithm is implemented.  Andrew,
IRAF is about as non-proprietary as they come.  There are
few programs that are as well-tested.  You have full scripting,
can write additional algorithms in SPP (C-like) or even Fortran,
etc.  I recommend that all Linux/Unix users strongly consider
using IRAF for their pipeline.  I'll volunteer to provide a
fully documented set of scripts to process the data.
Windoze users are on their own; perhaps Star, sextractor or SPS
would be good alternatives, but someone needs to experiment.
Remember, it is not just the star extraction problem, but also
image processing and the creation of the output FITS tables.
Probably the merging tasks, transformation tasks, database tasks,
variable discovery and other analysis tasks will be homegrown,
but that is plenty of work to do for participants.
You don't need to develop everything.
  Michael complains about the steep learning curve for iraf and
its command shell with 'its own peculiar syntax and conventions'.
I'm sorry, but *every* program has a command shell that takes
time to learn.  You feel uncomfortable with it because you are
used to PCVISTA.  I'd feel just the opposite.  Don't ding any
software unless you are an experienced user.  With the proper scripts,
one does not need to know what package is doing the processing.
The main points are: does the package properly do what you need, or if not,
how long would it take to modify it to accomplish the task?
  I agree with Andrew that the astrometric reference catalog can be a problem.
Certainly for the short exposure images, Tycho2 is a good choice
since it does have proper motions.  For the deep exposures, I'd
recommend UCAC since it also has proper motions and is a modern
epoch catalog that goes much deeper than Tycho2.
Both are on the ICRF and so you should not have
any systematic difference switching between them.  However, with
68M stars in the final UCAC catalog, you will not want to make a big
flat ascii file to use as input.  I can provide a USNO-A style
binary version of UCAC with 7.5 degree boundaries.
  As I've mentioned a dozen times, my first goal is to provide accurate
photometry to support UCAC.  I recommend we standardize on this
catalog for any 'seeding' operation when merging lists.  As we've
seen from my tests, UCAC should contain almost every star we find on
a Mark IV image.
  So here are my proposed guidelines for Mark IV processing:
      (1) IRAF is to be used for image processing and
          starlist creation for Linux/Unix
      (2) all starlists will be in FITS table format, the
            actual data format TBD.  We should spend the time now
            to decide what parameters should be included.
      (3) UCAC be used for astrometry for all fields south of the equator
      (4) Tycho2 be used for astrometry for all fields north of the equator
      (5) Someone take the initiative to compare the various Windoze
          packages and decide which gives the best results so that
          similar guidelines can be proposed for Windoze.
      (6) Leave the remainder of the processing until we get these
          initial steps done properly.
Arne
--------------------------------------------------------------------
Arne Henden                               Instruments/software/CCDs
US Naval Observatory Flagstaff Station    Cepheids/photometry/IR
P.O. Box 1149                             ftp://ftp.nofs.navy.mil  
Flagstaff, AZ 86002-1149                  Voice: (520)779-5132
aah@nofs.navy.mil                         FAX:   (520)774-3626