Re: FITS tables

[Jure Skvarc <jure.skvarc@ijs.si>]

Let me review yesterday's advancements in the defining of the FITS star list
format:
Michael G. proposed a minimal format suitable for data interchange.  I suggested
to put the Julian Day into header and to remove some quantities which I did not
consider relevant.  The minimal header and table under such concept would look
something like this:

Header 
--------------
JD  Julian Day
FILTER
EXPOSURE exposure time
DATE-OBS start of observing (date + time)
OBSERVER observatory code or information how to get observatory coordinates

Table
-----------
RA, DEC
MAG
MAGERR
AIRMASS
QUALITY

Note that I added here a quality flag (or flags), which was not present
yesterday but would probably be useful.  By "minimal" I mean the set of data
which MUST be provided by all software packages.  Other quantites can be still
in the table but not obligatory, so I do not write them here.  The charm of FITS
tables is that you can address them by name.  This means that the order of
information is not important and, as Chris pointed out, that you can add any new
columns without affecting existing table readers.  

The idea of table format above is that the users can use the information
directly as it is represented without the need to know any details of previous
computation and with the assumption that the quantities were computed correctly.

Arne proposed quite an opposite approach.  The idea is to store into table only
image-related quantites and to put into header sufficient information about the
processing and the external quantities such as the image central coordinate
etc., so that the final quantities such as star coordinates, magnitudes and
error estimates can be calculated easily.  The purpose of such approach is
twofold: (i) to have the ability to recalculate things again in (ii) to save
space in the tables.

Taking my yesterday's summary and Arne's further suggestions (hopefully all)
into account, we come to the following scheme:

Header
-----------
JD  Julian Day
FILTER
EXPOSURE exposure time
DATE-OBS start of observing (date + time)
OBSERVER observatory code or information how to get observatory coordinates
RA-CENTER
DEC-CENTER
CRVAL1, CRVAL2, etc..
PLATE constants 
APERTURE_SIZE (diameter in pixels)
PSFFUNCTION ? (I guess this would be needed)


Table
------------
XT, YT image coordinates
SXT, SXT  error estimates for the above
PSFMAG, PSFMAGERR magnitude and error estimate obtained by PSF
APERTUREMAG, APERTUREMAGERR magnitude by aperture method
FWHMX, FWHMY  star shape useful for quality control
ROUNDNESS, SHARPNESS  (additional shape parameters)
PEAK_DN  (to decide whether a star is saturated, etc.)
SKY_DN



Some questions still arise here.  If we adopt the concept of not having any
derived quantities in the table, shouldn't we only store star intensity in ADU
units and not the magnitude?  After all, the magnitude is also derived from the
intensities of the star in question and comparison star(s).  

Having in mind that TASS is mostly about photometry than the possibility to
reevaluate the magnitudes seems to me much more likely to happen than the
reevaluation of coordinates which are only used for the identification of stars
and are not the purpose of TASS.


					Jure Skvarc