% @(#)file_fmts.tex	19.1 (ESO-IPG) 02/25/03  13:28:26

\documentstyle[11pt,twoside]{article}
\topmargin=-36pt
\textwidth=16.5cm
\textheight=23.5cm
\oddsidemargin=0pt
\evensidemargin=0pt
% fudgy formatting by ATY:
\parindent=0pt
\parskip=6pt

%	CONVENTIONS:
%
%	Table descriptors:	{\bf CAPS} in text
%	Column labels:		ALL CAPS in text	{\tt CAPS} in tables
%				(or try \sc{smallcaps}?)
%	String values:		{\tt 'IN QUOTES'} everywhere
%
%

\begin{document}
%  Use the title command in LaTeX article style for the title of the
%  paper. This title will both be used for the paper and in the table
%  of contents and may therefore NOT contain the newline command \\.
%
\title{File Formats Required for Photometry}

%  Use the \author command in LaTeX article style to give the list
%  of authors and their affiliations (footnotes may be used).
%
\author{A.T. Young\\
        European Southern Observatory\\
        Karl-Schwarzschild-Stra{\ss}e 2\\
        D-8046, Garching, Fed. Rep. of Germany}

%  Use the special \authorlist command for the list of authors to
%  appear in the table of contents. This command is only defined in 
%  the ESO proceeding style and must therefore be commented out when
%  you use the article style.
%
%\authorlist{A.T. Young}

\maketitle

\begin{abstract}
This document describes the information about
stars, individual telescopes, and instruments, that is needed to plan 
photometric observations and reduce the
resulting data, and the file formats required to store this information.
\end{abstract} 

\section{Introduction}
Photometrists obviously need lists of standard and extinction stars, both to
plan observing sessions efficiently and to reduce the observational data.
It is not so obvious that planning and reducing photometric observations
also require information about the telescope used.

For example, the telescope aperture, which affects both photon and
scintillation noise, must be known, both
to select good extinction stars, and to
weight the observations properly according to stellar magnitudes.
Furthermore, the dome or telescope enclosure
determines the sky area 
from which the Moon may shine on the telescope mirror, raising the
apparent ``sky'' brightness.
This information is needed both for planning observations and reducing data.
The telescope's coordinates are required to determine when the Moon is
likely to influence observations, as well as in determining the airmass of a
star as a function of time.

Similarly, information is needed about the instrument.
One must avoid stars that are too bright for a given instrument on a particular
telescope.
Many instrumental details influence the methods that must be used in reducing
photometric observations, because the data-reduction process must accurately
model the instrument's performance.
Because instrumental configurations tend to change from one 
observing run to the next,
it is appropriate to separate the instrumental data from the more 
permanent data that refer to the telescope alone.

Some of these data are already available at the NTT, and will become available
at other telescopes, as part of the ESO archiving system.
Unfortunately, the archiving system is designed around individual image frames,
which do not correspond to the natural elements of photometric data.
Therefore, it is necessary to extract the required information
from the archive, and re-package it in a form more suited to photometry.
So far as possible, individual data formats will be similar to those
laid out in the ESO Archive Data Interface Requirements \cite{E92}.
For example, column labels for the table files described here will
(when possible) match the FITS-header keywords used for the same information
in archiving.

The data needed in photometry can be grouped into MIDAS table files, each of
which contains a natural set of data that belong together.
Each table will be described in detail in the following sections.
However, here is an overview of the types of tables needed for photometry:

\subsection{Stars}
Tables giving the identifications and positions of both standard and program
stars are obviously required.
The positions are required for air-mass calculations.
In addition, the standard-star tables must give the standard magnitudes and
colors or other indices.

\subsection{Observatory data}
A table file (called by default esotel.tbl)
should contain more or less permanent information
about the telescopes at an observatory.
This includes sizes, positions, and other stable information.
Each observatory should have its own file; the one for ESO telescopes will 
be called esotel.tbl.

\subsection{Telescope obstruction data}
Nearly every telescope seems to have some parts of the sky that are
inaccessible.
Trees, mountains, and even other telescopes obscure some areas above the
horizon.
Furthermore, many telescopes have peculiar mountings or other mechanical
limitations on where they may look.
In a surprising number of cases, the inaccessible regions extend into
the parts of the sky one would normally use to measure extinction stars.
Such restrictions should be placed in a separate ``obstruction'' table
for each telescope.

\subsection{Instrumental data}
Instrumentation tends to change from one run to the next.
Filters get broken or lost, or deteriorate and are replaced.
Detectors change with age, may be destroyed by careless users, or just
die for unknown reasons.
Instruments suffer ``improvements'' that change their characteristics.

Only data taken with a fixed configuration can be reduced together.
Usually, this will include all of the data taken during a run; occasionally,
an equipment change is necessary during a run.
Data describing a fixed instrumental configuration can naturally be
grouped together in a table describing each particular run, or part of a run.

\subsection{Observational data}
Finally, we have the observations themselves.
Here, the natural element is a single stellar (or sky, or dark)
intensity measurement;
and the natural set of these elements to put in a file is the whole group of
measurements made on a single night.


\section{Star tables}
\label{sect-std-star}
An important ingredient of both planning and data reduction
is a set of standard stars.
These can serve double duty as extinction stars, and are used for this by the
planning program.
They are obviously essential in data reduction.

If more than one table is used, the user must be careful {\it not}
to intermix data that are not on the same system.
For example, the Cousins E-region standards are clearly not on the same
``UBV'' system as the Landolt equatorial standards.
Likewise, several distinct ``RI'' systems are in use.

Sometimes it is useful to include ``catalog'' stars in an observing program.
These are stars that have been observed in (supposedly) the same system as the
standard stars, but are of lower quality and are not suitable for use as
standards.
However, they are not obviously variable, and may be useful both as extinction
stars and for checking transformations.

In addition, we need tables of program stars.
These usually will contain at least a magnitude, which is used to confirm
identifications but is not used in data reduction.

Different types of star (standard, catalog, and program) should be put in
separate table files.
You can have several tables of each type, but you should not try to mix
different types in the same file.

These star tables all {\bf require} the following data
({\it above} the line in Table~\ref{tbl:star-cat-cols}):

\subsection{Required stellar data}

\subsubsection{Object name}
The reference column of a star table contains the primary identification
for the star.
The column label, OBJECT, follows the archiving standards.
As in the archive, this is a string of up to 32 characters.
Shorter strings should be left-justified.

Standard IAU names should be used.
Proper names are acceptable for bright stars, as are Bayer and Lacaille
letters and Flamsteed numbers used with the constellation abbreviation.
HR numbers can be used for bright stars.
Telescopic stars should be designated by HD numbers.
Stars lacking HD numbers should be named by BD or other DM number.
Still fainter stars are identified by HST Guide Star Catalog
names, if available.
Nicknames like ``Przybylski's star'' should go in the COMMENT
column (section~\ref{sect-comment}).

In clusters and around variable stars, one often finds field standards
or reference stars denoted by letters of the alphabet.  Some charts have
used both capital and lower-case letters, so it is necessary to be
case-sensitive in names.
In such crowded areas, it is common practice to use
one (or a few) common reference position(s)
to measure sky, for the whole group of stars.
In this case, the sky position(s) should also be recorded in the
star-catalog table file; the only requirement is that the string in the OBJECT
column begin with the word {\tt SKY} (see discussion in 
section~\ref{sect-data}, ``Observational data''.

Very often the observer will use a shortened form or abbreviation at the
telescope.
However, full names should be used in the star tables, to avoid ambiguity.
The correspondence between full and abbreviated names will be resolved
by programs only with the interactive consent of the user.

\subsubsection{Right Ascension}
Right Ascensions are tabulated in decimal degrees in the archive.
This may be used with the column label RA, which conforms to the
archive convention \cite{E92}.
While this is a convenient machine-readable form, it is not very user-friendly,
as most astronomical catalogs use sexagesimal time units.

Fortunately, the MIDAS table commands 
will accept sexagesimal input (see the on-line HELP for {\tt CREATE/COLUMN} and
{\tt NAME/COLUMN}), in almost any human-readable form.
By using the R11.6 format specification
for the Right Ascension columns in the *.fmt file, existing ASCII tables can
easily be converted to MIDAS table format.
This {\it stores} the column as an angle in degrees, though it is
{\it displayed} as
hours, minutes, and seconds by the {\tt READ/TABLE} command.

CAUTION: your ASCII file {\bf must} have the {\tt .dat} extension,
or it will not be read correctly!

\subsubsection{Declination}
As for
Right Ascension, Declinations are tabulated in decimal degrees in the archive.
The column label DEC conforms to the archive convention.
Here again, any sensible human-readable form may be used instead,
if the ASCII data are read in with an s12.6 format in the *.fmt file.
The result is stored as decimal degrees (as a Real*4 number),
but displayed as degrees, minutes, and seconds.

\subsubsection{Equinox}
Because precession is a large effect, we must know the equinox to which these
coordinates refer.
Although this is usually a constant for a whole table, and so might be
stored in a descriptor, observers may want to use lists of
program stars compiled from heterogeneous sources.
Therefore, the year of the equinox must be stored in a separate column
of Real*4 values, with the label EQUINOX.
This column is easily created for a star catalog with a single equinox date
using the
{\tt COMPUTE/TABLE} {\it tablename}\ \ {\tt :EQUINOX =} {\it year} command.
A format of F7.2 is satisfactory.

\begin{table}[htb]
\begin{center}
\begin{tabular}{|l|c|c|l|l|c|}           \hline
 Column Label & Contents & Units & Variable Type & Format & Req'd? \\ \hline
{\tt OBJECT}    &  Object name   &         & C*32 string & A32 & Y \\ 
{\tt RA}        &  Right Ascension & degrees & R*4 real & R11.6 & Y \\ 
{\tt DEC}       &  Declination   & degrees & R*4 real   & s12.6 & Y \\ 
{\tt EQUINOX}   &  Equinox date  & years   & R*4 real   & F7.2 & Y \\  \hline
{\tt MUALPHA}   &  Annual p.m.\ in R.A. & sec/y & R*4 real & F6.4 &N\\ 
{\tt MUDELTA}   &  Annual p.m.\ in Dec. & arcsec/y & R*4 real & F6.3 &N\\ 
{\tt EPOCH}     & Position date  & years   & R*4 real   & F7.2 &N\\ 
{\tt SPTYPE}    &  Spectral type &         & C*12 string & A12 &N\\ 
{\tt MAG}       &  Approx.\ mag. &         & C*16 string & A16 &N\\ 
{\tt COMMENT}   &  Comment       &         & C*32 string & A32 &N\\ 
	\hline
\end{tabular}
\end{center}
\caption[]{Columns for star-catalog table files}
\label{tbl:star-cat-cols}
\end{table}


\subsection{Optional stellar data}
In addition to the essential stellar data given in the previous subsection,
it can be very useful to include supplemental information.
For example, a program devoted to nearby dwarfs or low-luminosity stars
would need proper motions to obtain accurate airmasses for some program stars.
Spectral types are often adjoined to photometric catalog data.
In many cases, rough photometric information that can aid in identification
is available, such as a photographic magnitude from the HD.
Finally, comments can be useful.
These fields may be included in the table if the user wants them.
They are described {\it below} the line in Table~\ref{tbl:star-cat-cols}.

\subsubsection{Proper motions}
Proper-motion information requires three columns: the separate components, and
the epoch of the catalog position.
We follow the SAO Catalog in using
annual proper-motion units of seconds of {\it time} per
year in R.A., and seconds of {\it arc} per year in Dec.
The epoch is given in decimal years.
The respective column labels are MUALPHA, MUDELTA, and EPOCH.
These are all Real*4 data.

\subsubsection{Spectral types}
Spectral types are stored in a column with the label SPTYPE.
The contents of this column are character strings.
You may make these strings as long as you want, but only the first 12
characters will be carried by the programs and formatted into output listings.

\subsubsection{Rough magnitudes}
Because approximate magnitudes are more useful when qualified by a terse
description of their nature, the column labelled MAG
should contain a character string rather than a number.
For example, you might specify {\tt 'mpg=10.5 (HD)'}, or
{\tt 'V=12.15'}.
Up to 16 characters can be carried in this field.

\subsubsection{Comment column}
\label{sect-comment}
Up to 32 characters can be carried in an additional column, with the label 
COMMENT.


\subsection{Standard values}
The above information suffices for program stars.
Standard-star files, however, must also have the standard photometric values
(in place of the rough MAG column).
The column label should be the usual name of the magnitude or index in the
column, e.g., V or U-B or c1; see Table~\ref{tbl:band-list}.
The data themselves are Real*4 numbers.
Magnitudes are displayed in F5.2 or F6.3 format, which leaves room for two
digits before the decimal point.
Color and other indices are displayed in f6.3 format; this
displays leading + signs.

\begin{table}[htb]
\begin{center}
\begin{tabular}{|l|c|c|}           \hline
 System & Index & Col.\ label \\ \hline
UBVRI	& V	& {\tt V}  \\
UBVRI	& B-V	& {\tt B-V}  \\
UBVRI	& U-B	& {\tt U-B}  \\
UBVRI	& V-R	& {\tt V-R}  \\
UBVRI	& R-I	& {\tt R-I}  \\
UBVRI	& V-I	& {\tt V-I}  \\
uvby	& b-y	& {\tt b-y }  \\
uvby	& u-v	& {\tt u-v }  \\
uvby	& ${\rm m}_1$	& {\tt m1 }  \\
uvby	& ${\rm c}_1$	& {\tt c1 }  \\
H-beta	& ${\beta}$	& {\tt beta }  \\
	\hline
\end{tabular}
\end{center}
\caption[]{Standard column labels for photometric indices}
\label{tbl:band-list}
\end{table}

In addition, standard-star files should specify the system they employ,
and the source of the standard values.
The system should be placed in a
character descriptor called {\bf SYSTEM}.
This may be up to 32 characters long, because of the need to distinguish
between such alternatives as
{\tt 'JOHNSON-MORGAN UBV'},
{\tt 'LANDOLT UBV'},
and
{\tt 'KRON-COUSINS UBVRI'},

Catalog stars may have not only columns specifying values in the system of
observation, but also other systems.
However, data from other systems,
except for V magnitudes, will be ignored.

There is a potential problem in the use of indices like U-B as column labels
that users should be aware of.
MIDAS table files do not distinguish between upper and lower case in column
labels.
Thus, while it is possible to use 
{\tt 'u-b'}
as a column label for the uvby system, it cannot be distinguished from
{\tt 'U-B'}
by programs or MIDAS procedures that read these files.
However, the string may be entered in the proper case when the label is
created, and will appear correctly on plots, table listings, etc.

Furthermore, because the provision for column arithmetic was built into the
table system before the need for color index-names as column labels was
apparent, it will be necessary to use the double-quote mark ({\tt "})
around such indices when referring to them as column labels.
For example, in a MIDAS command line, the B-V column must be referred to as
{\tt :"B-V"}.
Although this is inconvenient, it does allow such names to appear on plots,
etc.
The alternative (which will be automatically applied by MIDAS in the absence of
the double-quote marks) is to convert the minus sign to an underscore, so that
we would have B\_V instead of B-V.
This appears to be even more inconvenient for photometrists than to put up with
the quotes.


\subsection{Moving objects}
For moving objects such as asteroids, comets, or planets,
it is useful to include ephemeris information, both to provide predicted
coordinates for planning observations,
and to allow accurate airmass calculations
in the reductions.
Each such object requires several positions, each associated with a time.
These times can be given either as Modified Julian Dates
($MJD = JD - 2400000.5$),
or as ordinary date strings like {\tt 1995 Jan 23.0}.
To allow good interpolation, include two ephemeris entries before and two after
the interval of observations.
The tabular interval need not be one day, but can have any constant value from
one table entry to the next.

\subsubsection{UT date --- column label: DATE}
Dates can be read by the programs in a variety of formats.
To avoid ambiguity, use the first three letters of the month name
instead of numerical month designations.
The UT date should be stored in a C*16 (or shorter) string.
The usual format in ephemerides is that shown above: year, month, day;
11 characters are enough in this case.
However, the month, day, and year can be placed in any desired order.

\subsubsection{MJD --- column label: MJD\_OBS}
Occasionally, one finds an ephemeris given with Julian Dates as argument.
Only the Modified Julian Date is used here.
This must be a double-precision (R*8) variable, in F12.5 format.
Modified Julian Dates are discussed further in section~\ref{sect-data}
on data files.

The object name must be repeated on successive rows of an ephemeris file that
refer to the same object;
the repeated name tells programs to look for ephemeris data, and to
interpolate positions as required.
One table file can contain several objects, which may be convenient for some
observing programs.

If the tabular positions are referred to the
equator and equinox of date, as in some of the tables in the
{\it Astronomical Almanac}, the EQUINOX column can be omitted.
If astrometric positions are given, as in {\it Ephemerides of Minor Planets},
the EQUINOX column is required.
In general, ephemeris data for moving objects should be kept in table files
separate from star-position files.



\section{Permanent telescope parameters}
Data for all the telescopes at an observatory can be stored in a single MIDAS
table file, called (by default) esotel.tbl.
A standard path needs to be established for this file.
Observers who use different observatories may need to keep files for two or
more observatories.

Each observatory file should contain a C*72 descriptor {\bf OBSERVATORY}
that contains the name of the observatory, preferably as it is given in
\cite{H91}.
If effect, this descriptor takes the place of the standard descriptor 
{\bf IDENT} in *.bdf files.

Each individual focus of each telescope has a single row in this table.
The duplication of most information for the telescope itself is not a problem,
as this will be a short file in any case.
Each column described below should be present in the table, although some
columns do not apply to some individual instruments, and will contain null
entries.

Each column label can be a standard FITS keyword, if an appropriate one is
available.
The following sections describe the columns of the table in detail
(cf. Table~\ref{tbl:tel-tbl}).

\subsection{Column label: TELESCOP}

This is the name of the telescope focus, using the standard ESO
archive notation \cite{E92}.
The name begins with an abbreviation for the telescope's governing organization.
The next part of the name is the aperture in decimeters (preceded by letters
A, B, etc. if there are multiple telescopes with similar apertures).
The name ends with the suffix
P for prime focus,
A for Cassegrain focus,
C for coud\'e, 
and N{\it x} for Nasmyth foci.

Thus, for example, the Cassegrain focus of the ESO 1.5-meter
telescope is designated ESO15A.
But this telescope has an asymmetrical mounting that is difficult to switch
from one side of the pier to the other.
In this case, it is necessary to operate on one side only during the night;
this is indicated by appending the letter E or W to show which side of the pier
the telescope is actually used on.
So, for the 1.5-m telescope used east of the pier, the designation
of the Cassegrain focus is ESO15AE.

\subsection{Column label: DIAM}

This is the actual diameter in meters of the telescope entrance pupil.
For small telescopes, it provides significantly more precision than the
rounded value embedded in the telescope name.
For large telescopes with segmented apertures, it will suffice to
specify the equivalent diameter corresponding to the total collecting area.
(This will give the right value for the photon noise, but not
for the scintillation noise.  Most segmented apertures are on large telescopes
whose scintillation noise is negligible anyway, so this is not a significant
problem.)

\subsection{Column label: LON}

This is the longitude of the telescope, measured in
decimal degrees {\it east} from
Greenwich.  Note that the sign convention for longitudes changed in 1984!
The older versions of the Astronomical Almanac gave {\it west} longitudes.
For photometric data reduction, an accuracy of about 0.003 degree
(about 20 arcsec) is required.
Current volumes of the Astronomical Almanac give positions to 0.1 arc minute,
which is adequate for our purposes.

Astrometric observations, including occultation timings that may be measured
with photometric equipment, require much better accuracy.
You can find precise positions of telescopes in the pre-1984 volumes of the
Astronomical Almanac.
You should try to provide as accurate a value as possible.

\subsection{Column label: LAT}

This is the longitude of the telescope, measured in decimal degrees.
The usual convention of + for north and -- for south of the Equator
should be observed.
The same accuracy is required as for longitudes, so you should supply an
accurate value.
 
  
\begin{table}
\begin{center}
\begin{tabular}{|l|c|l|l|l|}           \hline
 Column Label	&	Contents & Units & Variable Type & Format \\ \hline
{\tt TELESCOP}    &  focus name   &         & C*8 string & A8 \\ 
{\tt DIAM}        &  diameter     & meters  & R*4 real   & F7.3 \\ 
{\tt LON}         &  longitude    & degrees & R*4 real   & s12.5 \\
{\tt LAT}         &  latitude     & degrees & R*4 real   & s11.5 \\
{\tt HEIGHT}      &  height       & meters  & R*4 real   & F6.0 \\
{\tt TUBETYPE}	&  tube type	&	  & C*6 string	& A6 \\ 
{\tt TUBEDIAM}	& tube diameter & meters  & R*4 real	& F8.3 \\
{\tt TUBELEN}	&  tube length	& meters  & R*4 real	& F7.3 \\ 
{\tt DOMETYPE}	& enclosure type &	  & C*4 string	& A8 \\ 
{\tt DOMEDIAM}	& dome diameter & meters  & R*4 real	& F8.3 \\
{\tt SLITWID}	& slit width	& meters  & R*4 real	& F7.3 \\
	\hline
\end{tabular}
\end{center}
\caption{Column specifications for esotel.tbl file}
\label{tbl:tel-tbl}
\end{table}
 

\subsection{Column label: HEIGHT}

Height above sea level (meters).
This need only be known to the nearest 10 meters.
After a lapse of a few years, it is again listed in the ``Observatories''
section of the Astronomical Almanac,
where you can find it for most established observatories.
Topographic maps will provide good enough values for the newer sites.


\subsection{Column label: TUBETYPE}

This is a string, either '{\tt OPEN}' or '{\tt CLOSED}'.
(Only the first letter is actually used.)
Use '{\tt OPEN}' if the tube is an open framework, and '{\tt CLOSED}' if it is 
an opaque cylinder.
If (as in some telescopes) the part near the declination axis is closed, but
the front end of the tube is open, use '{\tt OPEN}'.
This information is needed to determine when the Moon can shine directly
on the objective.

If the telescope is a refractor used with{\it out} a dewcap, use '{\tt OPEN}'.
A refractor used {\it with} a dewcap should be marked '{\tt CLOSED}'; the dewcap
information will be used in the TUBEDIAM and TUBELEN columns
(see below).

\subsection{Column label: TUBEDIAM}

If TUBETYPE is '{\tt OPEN}', ignore this field, and go on to DOMETYPE.

If TUBETYPE is '{\tt CLOSED}', TUBEDIAM should contain the
{\it inside}
diameter (in meters) of the telescope tube (or dewcap, if a refractor).

\subsection{Column label: TUBELEN}

If TUBETYPE is '{\tt OPEN}', ignore this field.

If TUBETYPE is '{\tt CLOSED}', TUBELEN should contain the length
(in meters) of the telescope tube (or dewcap, if a refractor), measured
from the front edge of the objective to the front end of the tube
(or dewcap).
Thus, for a reflector, TUBELEN is just the length of the telescope tube
measured from the front surface of the primary mirror.
For a refractor, it is the effective length of the dewcap.

\subsection{Column label: DOMETYPE}

If TUBETYPE is '{\tt OPEN}',
DOMETYPE should contain the type of enclosure that surrounds the telescope.
Use {\tt 'DOME'} for a conventional dome with a slit, or for a turret with
a slit of constant width.
Use '{\tt ROOF}' for a building with a roll-off roof.
Use {\tt 'NONE'} for a roll-off building or any other disappearing enclosure 
that leaves the telescope unshaded from moonlight.
As for TUBETYPE, only the first letter is significant.

If TUBETYPE is '{\tt CLOSED}', ignore this field.

\subsection{Column label: DOMEDIAM}

If DOMETYPE is {\tt 'DOME'},
and the telescope is a reflector,
this is the dome diameter, in meters.
If the telescope is a refractor, enter the distance from the objective to the
surface of the dome, in meters.

If DOMETYPE is '{\tt ROOF}' or {\tt 'NONE'}, you are done;
the remaining fields can be left empty.

\subsection{Column label: SLITWID}

If DOMETYPE is {\tt 'DOME'},
this is the width of the shutter or slit opening, in meters.

Some domes are equipped with upper and lower windscreens that
could, in principle, be used to shade the mirror from moonlight.
In practice, these screens
always move too slowly to be used routinely in photometric programs.
Therefore, wind screens are ignored, even though they might occasionally be
used in particular programs.


\section{Horizon obstructions}
Information on horizon obstructions and limitations to telescope motion
should be in a table file, which we can call the ``horizon'' file.
Usually, the same restrictions apply to all foci of a telescope, and the
same table file can be used for all of them.

The default name of the file is the ``telescope'' variable name described
above, but with the suffix ``hor.tbl'' in place of the focus designation.
Thus, for the ESO 1.5-meter telescope, the file name would be ESO15hor.tbl.
If mechanical considerations make separate tables necessary for different foci
of the same telescope, the ``hor.tbl'' should be appended to the full name of
the focus.

For most telescopes, it is most natural to provide the hour-angle limits
(east and west) as functions of declination.
However, for telescopes with alt-azimuth mountings, the data may most easily
be gathered in the form of altitude limits as functions of azimuth.
No provision is made at this time for alt-alt mounts, although some are in use.

Notice that telescopes with German equatorial (cross-axis)
and other asymmetrical mountings require two groups of columns:
one for telescope east of the pier, and one for telescope west.
Also, notice that ``telescope east'' is the position usually used in observing
the {\it western} part of the sky, with the telescope above the polar axis.

Finally, two kinds of columns are required.
The first subset specifies the observing limits (i.e., the
accessible region of sky in which
the telescope pupil is {\it completely} illuminated by a star).
In this region, no part of the telescope pupil may be shaded by an obstruction.
Photometric observations can be made only in this part of the sky.

The second subset specifies the region from which {\it any part} of the pupil
may be illuminated by the Moon.
As the Moon can only appear between limits of about $\pm 30^{\circ}$
declination, the ``moonlight'' part of the table need only include this range.

Users should remember that trees have a tendency to grow larger, so that
the ``horizon'' file should be re-checked from time to time if nearby trees are
significant obstructions.
Compilers of these tables should also bear this in mind, and leave a little
margin for safety near trees.

\subsection{Getting the data}
If the photometer has an eyepiece,
one can easily check whether the pupil is clear or obstructed by
examining the exit pupil formed by the eyepiece.
If you have a choice between eyepieces, choose the lowest power 
available to get the largest pupil.
You may need to examine the pupil image with a magnifier;
another eyepiece will do.

Telescopes without eyepieces can be checked by removing the instrument, and
examining the focal plane by eye.
The image of any distant obstruction will appear in the focal plane.
Nearby obstructions more than a focal length away will be imaged behind
the focal plane.
The edge of the dome will be visible as an out-of-focus blur seen on the far
side of the primary.

In either case, simply fix the telescope at a given declination (or azimuth, if
it has an alt-az mounting), and move it in the other coordinate toward the
horizon until an obstruction appears.
The ``observing'' limit is a position at which the obstruction is near, but
{\it completely outside of}, the usable field.
The ``moonlight'' limit is the position at which the last speck of sky
disappears behind terrestrial obstructions.
If the ``observing'' limit is set by mechanical obstructions, you may have
to estimate the ``moonlight'' limit, or just adopt the true horizon to be
safe.

The measurements can easily be made in daytime, or during the brighter part of
twilight.
It will be most convenient to determine the ``observing'' and ``moonlight''
limits on the same side of the sky together, and then to move to the other side
of the sky.
The necessary data can be gathered in a few hours, and will prevent
many unpleasant surprises while observing or in reducing observations.

Near $\delta = 90^{\circ} - \phi$ and $\delta = \phi - 90^{\circ}$,
the limits change rapidly with declination, and should be gathered 
at $1^{\circ}$ intervals.
If there are no irregular obstructions, an interval of
$10^{\circ}$ is probably sufficient near the equator.
You should assume that programs using the information in this table will
interpolate linearly between the adjacent points, and adjust your spacing
accordingly.
(A program should be available to produce a blank form to fill in.)

\subsection{Descriptor for the ``horizon'' table}
A character descriptor is needed to specify which of three possible formats is
actually used:

{\bf MOUNTING}: possible values are
{\tt 'FORK'},
{\tt 'GERMAN'}, or
{\tt 'ALTAZ'}.
{\tt 'ALTAZ'} is self-explanatory; 
{\tt 'GERMAN'} applies to ``cross-axis'' and other
asymmetrical mountings that have different
constraints, depending on which side of the pier the telescope tube is on.
Everything else should be designated
{\tt 'FORK'}, whether it really is a fork or yoke mount, or any other
symmetrical form that is equatorially mounted and has no east-west
differences like the German form (so called because it was first designed by
Fraunhofer).

In the case of an alt-azimuth mounting that displays only equatorial
coordinates to the user, it would be more convenient to use the 
{\tt 'FORK'} form of table, despite the actual mounting.
(This may be the case for the NTT, for example.)
If only Right Ascension is provided and not hour angle,
the user will have to record the local sidereal time and compute the
hour angle.
Even so, this will be less work, and is less likely to introduce errors, 
than to convert between equatorial and horizon coordinates.

Three separate table formats correspond to each of these three descriptor
values.  The next three subsections describe these three forms.

\subsection{MOUNTING={\tt 'FORK'}}
\label{sect-fork}
The independent variable (i.e., the reference column of the table) is
labelled DEC, and contains the declination in degrees.
The table entries are the hour-angles of the
various limits, measured in decimal degrees.

Table~\ref{tbl:fork-ex} shows the layout for fork mounts.
Each column is described in detail below (cf. Table~\ref{tbl:fork-labels}).

\begin{table}[hbt]
\begin{center}
\begin{tabular}{|r|r|r|r|r|}           \hline
{\tt DEC} & {\tt OBSE} & {\tt MOONE} & {\tt OBSW} & {\tt MOONW} \\ \hline
+30.	    &  285.4   &  279.3		& 104.5	 & 109.1 \\ 
+20.	    &  283.6   &  276.5		& 94.7	& 104.3 \\ 
+10.	    &  280.3   &  272.7		& 91.1	&  99.5 \\ 
  0.	    &  275.4   &  269.3	 	& 84.5	&  89.2 \\ 
--10.	    &  270.1   &  262.4		& 80.2	&  84.6 \\ 
	\hline
\end{tabular}
\end{center}
\caption{Example of partial table contents for fork-type equatorial mountings}
\label{tbl:fork-ex}
\end{table}


\subsubsection{Column label: DEC}
The values in the reference column are declinations, in decimal degrees.
These are the fixed values set by the operator in compiling the
obstruction-limit data.
They should be accurate to about 0.1 degree of declination.

\subsubsection{Column label: OBSE}
The values in this column are the corresponding hour angles of the
eastern ``observation'' limits, in decimal degrees.
An accuracy of about 0.1 degree is adequate.
Most telescopes read out hours and minutes instead; these should be 
acceptable inputs to the table-making program, which should do the conversion.
If hours and minutes of time are read, try to read hour angles to the nearest
minute or better.

In some cases, hour angles east of the meridian are read as negative values; in
other cases, values will lie between $180^{\circ}$ and $360^{\circ}$
($12^{\rm h}$ and $24^{\rm h}$).
Both styles should be acceptable.
The minus sign may be omitted if the values are numerically smaller than
$180^{\circ}$ ($12^{\rm h}$).

\subsubsection{Column label: MOONE}
The values in this column are the corresponding hour angles of the
eastern ``moonlight'' limits, in decimal degrees.

\begin{table}[tbp]
\begin{center}
\begin{tabular}{|l|c|l|c|c|}           \hline
 Column Label & Contents & Units & Variable Type & Format \\ \hline
{\tt DEC}    &  declination   & degrees & R*4 real & F7.2 \\ 
{\tt OBSE}    &  eastern observation limit   & degrees & R*4 real & F7.2 \\ 
{\tt MOONE}    &  eastern moonlight limit   & degrees & R*4 real & F7.2 \\ 
{\tt OBSW}    &  western observation limit   & degrees & R*4 real & F7.2 \\ 
{\tt MOONW}    &  western moonlight limit   & degrees & R*4 real & F7.2 \\ 
	\hline
\end{tabular}
\end{center}
\caption{Column labels and contents in detail, for fork mountings}
\label{tbl:fork-labels}
\end{table}


\subsubsection{Column label: OBSW}
The values in this column are the corresponding hour angles of the
western ``moonlight'' limits, in decimal degrees.

\subsubsection{Column label: MOONW}
The values in this column are the corresponding hour angles of the
western ``moonlight'' limits, in decimal degrees.

A simple sanity check on the tabular data is that the ``moonlight''
limits should always be closer to the horizon
(i.e., farther from the meridian) than the ``observing''
limits, at every declination.
The difference is approximately
the angular size of the telescope entrance pupil, as
seen from the object that obscures the horizon.
If the obscuration is nearby, the difference may be many degrees; if distant,
it may be a fraction of a degree.


\subsection{MOUNTING={\tt 'GERMAN'}}
The independent variable (i.e., the reference column of the table) is
labelled DEC, and contains the declination in degrees.
The table entries are the hour-angles of the
various limits, measured in decimal degrees.
All angles should be accurate to about 0.1 degree.

These asymmetrical mountings suffer different obscurations and mechanical
limits when the telescope is east of the pier and west of the pier,
so it is necessary to have a double-sized table.
Each half of the table corresponds to the whole of a fork-mount table, but for
a particular side of the pier.
Therefore, you should read the detailed description in the previous section, for
MOUNTING={\tt 'FORK'}, before gathering the data for a German equatorial.
It will probably be most convenient to gather all the data for the ``telescope
east of pier'' position, and then all those for ``telescope west''.

The column labels are the same as for the fork mount, but prefixed by
{\tt TE}
for telescope east of the pier, and
{\tt TW}
for telescope west; see Tables~\ref{tbl:german-ex} and~\ref{tbl:german-label}.


\begin{table}[hbtp]
\begin{center}
% Here comes table column layout (NB: no numbers! rlc only!):
\begin{tabular}{|r|c|r|r|r|r|r|r|r|}           \hline
{\tt DEC} & {\tt TEOBSE} & {\tt TEMOONE} & {\tt TEOBSW} & {\tt TEMOONW}
	& {\tt TWOBSE} & {\tt TWMOONE} & {\tt TWOBSW} & {\tt TWMOONW}
		\\ \hline
+30.  & 5.6 & --84.5 & 109.3 & 119.1 & 285.4  & 283.5 & 6.3 & 99.1 \\ 
+20.  & 5.3 & --70.1 & 104.7 & 114.3 & 283.6  & 281.7 & 6.5 & 84.3 \\ 
+10.  & 5.4 & --76.8 & 104.7 & 106.1 & 280.3  & 279.1 & 6.7 & 79.5 \\ 
 0.   & 5.4 & --78.6 &  88.0 &  89.5 & 275.4  & 272.5 & 6.3 & 79.2 \\ 
--10. & 5.7 & --85.7 &  79.3 &  82.1 & 270.1  & 267.2 & 6.4 & 84.6 \\ 
	\hline
\end{tabular}
\end{center}
\caption{Example of partial table contents for German equatorial mountings}
\label{tbl:german-ex}
\end{table}


Table~\ref{tbl:german-ex} shows the table layout for German equatorials.
Each column is described in detail below; see Table~\ref{tbl:german-label}.
See section~\ref{sect-fork} on fork-mounts for more detailed discussions of the
quantities in the table, as the entries are basically the same for both types
of mounting.

\subsubsection{Column label: DEC}
Declination in decimal degrees.
An accuracy of 0.1 degree is appropriate.

\subsubsection{Column label: TEOBSE}
Eastern ``observing'' hour-angle limit (decimal degrees) for Telescope
East of the pier, at the given declination.
Eastern hour angles may be given as negative quantities, smaller in magnitude
than $180^{\circ}$.

\subsubsection{Column label: TEMOONE}
Eastern ``moonlight'' hour-angle limit (decimal degrees) for Telescope
East of the pier.

\subsubsection{Column label: TEOBSW}
Western ``observing'' hour-angle limit (decimal degrees) for Telescope
East of the pier.

\subsubsection{Column label: TEMOONW}
Western ``moonlight'' hour-angle limit (decimal degrees) for Telescope
East of the pier.

\begin{table}
\begin{center}
\begin{tabular}{|l|c|c|c|c|c|}           \hline
 Column Label & Tel. pos. & Contents & Units & Variable Type & Format \\ \hline
{\tt DEC}    & E of pier &  declination   & degrees & R*4 real & F7.2 \\ 
{\tt TEOBSE}    & E of pier &  ``Obs.'' limit E & degrees & R*4 real & F7.2 \\ 
{\tt TEMOONE}    & E of pier & ``Moon'' limit E & degrees & R*4 real & F7.2 \\ 
{\tt TEOBSW}    & E of pier &  ``Obs.'' limit W & degrees & R*4 real & F7.2 \\ 
{\tt TEMOONW}    & E of pier & ``Moon'' limit W & degrees & R*4 real & F7.2 \\ 
{\tt TWOBSE}    & W of pier &  ``Obs.'' limit E & degrees & R*4 real & F7.2 \\ 
{\tt TWMOONE}    & W of pier & ``Moon'' limit E & degrees & R*4 real & F7.2 \\ 
{\tt TWOBSW}    & W of pier &  ``Obs.'' limit W & degrees & R*4 real & F7.2 \\ 
{\tt TWMOONW}    & W of pier & ``Moon'' limit W & degrees & R*4 real & F7.2 \\ 
	\hline
\end{tabular}
\end{center}
\caption{Column labels and contents for German equatorials}
\label{tbl:german-label}
\end{table}

\subsubsection{Column label: TWOBSE}
Eastern ``observing'' hour-angle limit (decimal degrees) for Telescope
West of the pier.

\subsubsection{Column label: TWMOONE}
Eastern ``moonlight'' hour-angle limit (decimal degrees) for Telescope
West of the pier.

\subsubsection{Column label: TWOBSW}
Western ``observing'' hour-angle limit (decimal degrees) for Telescope
West of the pier.

\subsubsection{Column label: TWMOONW}
Western ``moonlight'' hour-angle limit (decimal degrees) for Telescope
West of the pier.

\subsubsection{Special remarks on German mountings}
One should expect some ``TEOBSE'' and ``TWOBSW'' hour angles to lie near the 
meridian, because the telescope tends to run into the pier at declinations
close to the latitude (i.e., near the zenith).
There is the possibility that some telescopes cannot quite reach the zenith
and may have small limits of either sign.
For this reason, the minus sign cannot be optional for hour angles east,
for German equatorials.

This mechanical limitation on setting the telescope may also affect
the ``moonlight'' limits.
Suppose the telescope is a reflector with an open tube, and can just reach the
meridian when it is near the zenith.
Then the Moon can only shine on the mirror (in this orientation) when it is
high enough to shine in over the edge of the dome.
As the lower edge of the dome is usually about the same height as the
intersection of the polar and declination axes, the telescope mirror is some
distance below the bottom of the dome shutter when the telescope points at the
zenith.
Then the Moon may have to be (say) $15^{\circ}$ high to illuminate the mirror,
with the telescope on this side of the pier.
Such considerations should be taken into account in compiling tables for German
equatorials.
(See Table~\ref{tbl:german-ex} for examples.)

In some cases (e.g., the ESO 1.5-meter), it is very inconvenient to move the
telescope from one side of the pier to the other during the night.
With some instruments, it may be necessary to change wiring harnesses in
reversing the telescope.
Because photometry requires efficient use of telescope time, these situations
make reversing the telescope impractical.
The best way to handle such cases is to designate the ``telescope East'' and
``telescope West'' conditions as separate foci in the observatory table file.
The obvious suffixes to use are E and W.
Then separate horizon-limit tables would be used for the two conditions.

\subsection{MOUNTING={\tt 'ALTAZ'}}
The independent variable (i.e., the reference column of the table) is
labelled AZI, and contains the azimuth in degrees.
Note that astronomical azimuth is normally measured positive
{\it eastward} from the north point on the horizon.
The table entries are the altitudes of the
two limits, measured in decimal degrees.

It should be obvious in this table that the ``moonlight'' limit is 
always less than the ``observing'' limit.
As azimuth runs from
$0^{\circ}$
to
$360^{\circ}$
completely around the horizon, there is no need to separate halves of the sky.

Table~\ref{tbl:altaz-ex} shows the layout for this form.
Each column is described in detail below (see Table~\ref{tbl:altaz-label}).

\begin{table}[hb]
\begin{center}
\begin{tabular}{|r|c|c|}           \hline
{\tt AZI} & {\tt OBSALT} & {\tt MOONALT} \\ \hline
  0.	    &    5.4   &    4.5		\\ 
+10.	    &    0.3   &    0.1		\\ 
+20.	    &    3.6   &   2.7		\\ 
+30.	    &    5.4   &  4.5		\\ 
	\hline
\end{tabular}
\end{center}
\caption{Example of table contents for alt-azimuth mountings}
\label{tbl:altaz-ex}
\end{table}

\subsubsection{Column label: AZI}
Azimuth, in decimal degrees, at which a limit is determined.
An accuracy of 0.1 degree is appropriate.

\subsubsection{Column label: OBSALT}
Limiting altitude for observations, in decimal degrees.
An accuracy of 0.1 degree is appropriate.

\subsubsection{Column label: MOONALT}
Limiting altitude for moonlight, in decimal degrees.
An accuracy of 0.1 degree is appropriate.


\begin{table}
\begin{center}
\begin{tabular}{|l|c|l|c|c|}           \hline
 Column Label & Contents & Units & Variable Type & Format \\ \hline
{\tt AZI}    &  azimuth & degrees & R*4 real & F7.2 \\ 
{\tt OBSALT} &  max. altitude for observations & degrees & R*4 real & F7.2 \\ 
{\tt MOONALT} & max. altitude for moonlight & degrees & R*4 real & F7.2 \\ 
	\hline
\end{tabular}
\end{center}
\caption{Column labels and contents for alt-azimuth mountings}
\label{tbl:altaz-label}
\end{table}


\section{Instrument configuration and run-specific information}
Information specific to a particular instrument is not so easy to
categorize.
There is some information connected with
individual passbands that can naturally be stored in tabular form: the
codes used for filters, and the names of the bands, for example.
But each particular type of detector has a different set of
characteristics, which in turn require different sets of supplementary
data.
Furthermore, there are distinct modes of operation peculiar to each type:
we need dead-time information about photomultipliers only when they are used as
pulse-generators, not in DC photometry or charge integration.


\subsection{Storage format}
This diversity of possibilities does not lend itself readily to MIDAS table
structures.
If, as is usual, only a single detector is used, it would be wasteful and
inconvenient to burden a table with several columns containing
identical detector data in every row.
Furthermore, information that should be the same for every filter,
such as detector information for a single-channel instrument, could become
inconsistent if presumably duplicate entries were stored in table format.
To include code to test for the consistency of such constant-valued columns
would impose overhead and maintenance problems for the programs that read the
table.

A possible solution would be to use a table file with one row per
filter, and to
store information that remains the same for {\it all} filters in descriptors.
This seems to be the policy that has been adopted for FITS tables.
Then
ordinary single-channel instruments could keep all the detector information in
descriptors.
But multi-channel instruments should store the detector information for each 
passband in the table itself, restoring the problem of duplicated data for
all the bands that use the same detector.

On the other hand, some kind of array structure is needed to hold the
information about detectors in multi-channel instruments.
But the channels do not necessarily correspond to passbands in a one-to-one
way; for example, an instrument might use a blue-sensitive photomultipler
tube to measure U, B, and V, and a ``red'' tube to measure R and I (see
the example in section~\ref{sect-2chan}).
We could store the
detector information as MIDAS ``descriptors''; then the problem is
that instruments with multiple detectors would require multi-element
descriptors, and a cross-reference table column to identify which detector goes
with which filter combination.

A practical if not very elegant solution is to store everything in one
{\it physical} table file, which contains two logical sub-tables --
one for passbands, and one for detectors.
Each sub-table contains an explicit index column, to allow explicit
cross-references, despite any rearrangement of the actual table rows.
This index column serves as the natural sequence number within each sub-table.
This reduces the number of files the user has to keep track of.
Invariant information for the whole instrument then goes in the table file's
descriptors.

Most of the information in this table is stored as strings,
rather than numerical values,
thus keeping the entries easy for humans to read.
Many of the items make sense (and will be looked for) only if others
have particular values; see Tables~\ref{tbl:passband-instr-cols},
\ref{tbl:instr-descriptors},
and \ref{tbl:detector-instr-cols}.


\subsection{General instrumental information}
The two principal classes of information needed about photometric
instruments concern filters and detectors.
We need two kinds of information for filters and detectors:
physical information about the instrument itself, and logical information
about the way it is represented in data files --
for example, the codes used to identify filter positions.

In addition, it is useful to know the condition of the
telescope optics: clean optics give not only better signal/noise ratio than
dirty ones, but also more stable zero-points from night to night.
Sometimes it is possible to have the optics cleaned before a critical observing
run; observers should consider this possibility.

Some, but by no means all, of the required information is available in the ESO
Archive -- mostly in the archive log files \cite{E92}.
This can be stripped out and used when it is available; when it is not, the
observer will have to supply the information.

In addition to information about the instrument itself, the reduction program
needs to know the structure of the data in their table file (see
section~\ref{sect-data}, ``Observational data'').
Thus, you must make sure that information such as the number of filter-code
columns and the filter codes that correspond to particular passbands, which is
in the instrument-description table, agrees with the actual data tables.
Usually, this is determined by the program that converts raw data files to
table format.


\subsection{Passbands}
\label{subsect-passbands}
To identify the passbands, we need a small sub-table to hold the relation
between codes recorded in the raw data and the standard passband names
(see Table~\ref{tbl:passband-instr-cols}), as well as other
information.
The number of passbands should always be the number of rows in the
table, so there is no need to save it explicitly.


\subsubsection{Columns BAND and NBAND}
The column named BAND gives the standard name of the band.
This column contains 8-byte character variables,
and is normally displayed with A8 format.

Standard values for the BAND column are:

{
\parindent=2pc

for the UBV(RI) system: {\tt 'U', 'B', 'V', 'R', 'I'}

for the 4-color system: {\tt 'u', 'v', 'b', 'y'}

for the H-beta system: {\tt 'betaW', 'betaN'} (for Wide and Narrow,
respectively)

for red-leak filters: the name of the main band followed by {\tt 'RL'};
e.g., {\tt 'URL', 'BRL'}, etc.

for ``neutral'' filter combinations: the name of the band, followed by
{\tt 'ND'} if only one value of 
\indent\indent attenuation is used, or by
{\tt 'ND1', 'ND2'}, etc., if more values are used

for any opaque position: {\tt 'DARK'} for a single detector;
or  {\tt 'DARK1'},  {\tt 'DARK2'}, etc. for multiple
\indent\indent detectors

\par
}

Notice that each distinct type of measurement counts as a separate band entry,
including measurements made with different neutral-density filters, red-leak,
and dark measurements.
For example, a one-channel
photometer with a filter wheel that measures U, B, V, and
the red leak in U, plus a slide containing open, opaque, and two
neutral-density filters would have [4 filters $\times$ (2 ND + 1 clear positions
= 3 different intensity measurements) ] = 12 different rows, plus a 13th row for
the dark measurement.
The combinations of red-leak filters that involve ND filters should be named
with the RL before the ND --- e.g., URLND1.
For more details, see the examples in subsection \ref{subsect-sample-inst},
``Sample instrument files''.

The column named NBAND contains an integer used for cross-referencing.
An I5 format is convenient.
Normally, this is the reference column for the whole table file.


\subsubsection{Column FILTCODE\_{\bf n}}
If {\bf NFILTCAR} (see section~\ref{sect-filt-desc}, ``Filter descriptors'')
contains 1, a column headed FILTCODE\_1 gives the code
in raw data files that represents each position of the filter carrier.
If multiple filter carriers are coded
separately, the column FILTCODE\_$n$ contains the coding for the $n$-th carrier.
On the other hand, it may be convenient to combine two or more filter
mechanisms into a single filter-code column in the instrument table.

The values used in the FILTCODE column(s) depend on the particular data-logging
system.  They can even be the standard names of the bands.
Thus, FILTCODE may just be a duplicate of the BAND column.
These columns are 8-byte character variables, and are normally displayed with A8
format.

Some multichannel instruments have separate filter mechanisms for each
detector.
For example, a two-channel instrument might use ``red'' and ``blue'' beams.
Then the filters used in the ``red'' beam would not affect measurements made in
the ``blue'' beam.
In this case, the word ``any'' can be inserted in the filter code for the beam
that is {\it not} used with a given output channel (see examples below).

For spectrometric multichannel instruments,
there may be no choice of filters for any channel: the data from different
channels are distinguished by position rather than by code in the raw data.
Then {\bf NFILTCAR} can be set to zero,
and the FILTCODE column can be omitted from the instrument description file.
In this case, the separate channels must still be identified on separate
rows in the final data table file (see
section~\ref{sect-data}, ``Observational data'')
by the standard names of the bands.

On the other hand, the Danish 6-channel spectrometer at La Silla has two
separate mechanisms for inserting neutral-density filters.
In this case, one must append an ND code to the passband name in the data file
(see section~\ref{sect-data}, ``Observational data''),
to indicate the combination of neutral filters in use.

Note that the OPTI-{\it n} keyword in the ESO Archive \cite{E92} includes
other optical elements than filters, and so is not uniquely related to the
numbering of filter wheels.


\subsubsection{Column NDVALUE}
If ``neutral'' filters are used, their quantitative effect should be stored in
a column named NDVALUE.
The real number stored here should normally be the factor by which the
intensity measured through the ND filter should be multiplied to be on the same
scale as data taken without the ND filter.
Therefore, the numbers are normally all bigger than unity, except for the
un-attenuated passbands, for which one normally puts unity in this column.
Because ``neutral'' filters are not really neutral, the value will differ
somewhat from one passband to the next.


\subsubsection{Column NDETUSED}
The column named NDETUSED gives the {\it number} of the detector used to
measure each band.
This number corresponds to the number stored in the NDET column of the detector
sub-table (see section~\ref{sect-det}).
It need not correspond to a data-logging code.


\subsubsection{Columns REDLEAK, RLTYPE, and MAKER}
Special problems arise with filters intended to measure red leaks in blue and
ultraviolet filters.
If the ``red-leak'' filter is simply an uncemented sandwich of the
short-wavelength filter and a sharp-cutoff
(long-pass) filter to block the main passband,
the leak will be measured about 8\% too low, because of Fresnel reflections 
at the two added air-glass surfaces.
An accurate red-leak measurement is possible only if the leak-measuring filter
is a cemented combination, {\it and} if the leak-isolating component does not
absorb (as Pyrex glasses do) at the wavelength of the leak.
These problems are most easily handled by including some additional columns in
the table (see table~\ref{tbl:passband-instr-cols}).

The column named REDLEAK contains an 8-character string that
specifies the treatment of red leaks in short-wavelength
filters.
Possible values are
{\tt 'MEASURED'}
if the red leak is measured by observations through a filter that isolates the
leak;
{\tt 'BLOCKED'}
if a copper-sulfate or other blocking filter is used; or
{\tt 'IGNORED'}
if the leak is neither measured nor blocked.
{\tt 'ABSENT'} can be used for long-pass filters, like the V of standard UBV.
It is the user's responsibility to determine that blocking is adequate,
particularly if interference filters and/or red-sensitive detectors are used.
An unblocked red leak can produce very large transformation errors.

If the leak is
{\tt 'MEASURED'}, additional information is required, because most
instruments do not provide a true measurement of the red leak.
The additional information is stored in character columns named
RLTYPE and MAKER.

Column RLTYPE may contain the values
{\tt 'CEMENTED'}
if the ultraviolet and long-pass components are cemented together;
{\tt 'LOOSE'}
if the two components are {\it not} optically contacted;
{\tt 'UNKNOWN'}
if information is not available.
If the filters are loose, the two extra air-glass reflections cause excess loss
that must be accounted for.

The column named MAKER may take the values
{\tt 'CORNING'}
if a Corning or Kopp (successor to Corning) glass is used for the
{\it long-pass component} of the red-leak filter;
{\tt 'SCHOTT'}
if a Schott glass (or other non-Pyrex base glass) is used; or
{\tt 'UNKNOWN'}
if information is not available.
This information is required because the Pyrex glass used as the base for
Corning filters absorbs appreciably at 
typical red-leak wavelengths; the measured
leak must therefore be increased to compensate for the absorption.

\begin{table}[htb]
\begin{center}
% Here comes table column layout (NB: no numbers! rlc only!):
\begin{tabular}{|l|l|c|c|c|}           \hline
  Column Label & Contents         & Variable Type & Format & When used \\ \hline
{\tt BAND}     &  band name                 & C*8 string & A8 & always \\
{\tt NBAND}    &  band number               & I  integer & I5 & always \\
{\tt FILTCODE\_1} &  filter code for 1st wheel & C*8 string & A8 & always \\
{\tt FILTCODE\_{\it n}} &  filter code for {\it n}th wheel & C*8 string & A8 & {\bf NFILTCAR} $>$ 1 \\
{\tt NDVALUE} &  attenuation factor        & R  real & F7.3 & ND filters used \\
{\tt NDETUSED} &  detector number           & I  integer & I8 & {\bf NDETS} $>$ 1 \\
{\tt REDLEAK}  &  red leak treatment        & C*8 string & A8 & always \\
{\tt RLTYPE}   &  RL filter construction    & C*8 string & A8 & REDLEAK={\tt MEASURED}\\
{\tt MAKER}    &  RL isolating glass maker  & C*8 string & A8 & REDLEAK={\tt MEASURED}\\
	\hline
\end{tabular}
\end{center}
\caption[]{Passband columns of the instrument table file}
\label{tbl:passband-instr-cols}
\end{table}

Sometimes only the shortest-wavelength band of a system has red-leak problems
(e.g., U of UBV, or u of uvby.)
However, if silicon detectors or red-sensitive photocathodes are used, blue and
even green (``visual'') bands may have red-leak problems, especially if heavily
reddened or late-type stars are observed.

Note that the importance of red leaks depends on the photometric system, the
filter set, the detector used, and the stars observed.
Failure to treat red leaks correctly will produce serious systematic errors,
which cannot be ``transformed away'' by any reduction program.
Worse yet, incorrect treatment of red leaks can propagate these errors
(through incorrect transformations) into
data for early-type stars that otherwise have negligible red-leak problems.
It is the user's responsibility to be aware of these problems.

For additional information on red leaks, see Shao and Young \cite{SY65},
besides
the very brief treatment on pp.\ 109 and 184 of Young \cite{Y74}.
Stetson \cite{S89} has illustrated how severe the problem can be when cool
objects (light bulbs!) are observed with CCDs.
Note his warning: ``Don't be satisfied with statements like
`The red leak is negligible'.''
Unfortunately, the important cautionary remarks of
A\v zusienis and Strai\v zys \cite{AS66}
regarding reddened stars are available only in Russian.
They show that the simple correction formula used by Shao and Young \cite{SY65}
is not correct for heavily reddened stars.

To sum up, one may say that red leaks should be measured whenever they
exceed the accuracy desired in the final results
-- which is more often than you
might think.

\subsection{Instrument descriptors}
Properties of the instrument that are associated with the instrument as a
whole, rather than with a particular filter or detector channel, belong in
descriptors in the instrument table file.
Most of these relate to the filter mechanisms.
In addition, it is convenient to have a character*72 descriptor
called {\bf INSTNAM} that gives
the name or designation of the particular instrument; and one to describe the
condition of the telescope optics, which will be treated at the end of this
section.
The descriptors are summarized in Table~\ref{tbl:instr-descriptors}.

\subsubsection{Filter descriptors}
\label{sect-filt-desc}
The two most critical types of physical information needed about the filters
themselves are
(1) what are their transmission curves? and (2) does the instrument either
regulate or measure their temperature?
Filter temperature is important, because filters are somewhat more
temperature-sensitive than detectors (see \cite{Y67}, and pp.\ 105-108
of \cite{Y74}).
In addition, we need to know how many different filter-code fields appear in
the data.
Bearing all this in mind, here are the descriptors for filters:

\subsubsection{Descriptor {\bf NFILTCAR}}
This integer descriptor tells the number of {\it filter-code fields} in the
data files, and hence the number of FILTCODE\_{\it n} columns in the
instrument table.
It is usually the same as the number of filter
carriers (usually wheels or slides).
NFILTCAR is the logical rather than the physical number of carriers; if
two or more filter wheels are encoded as a single character in the
data, there is effectively only one filter wheel, as far as data handling is
concerned.

If one filter mechanism carries chromatic filters and another carries
``neutral'' filters, the total number of bands
(i.e., rows) in the table should be the
product of the number of positions in the two carriers.
Thus, a 4-position main filter wheel and a 3-position attenuator in the same
measuring beam give 12 total passband combinations.
These may be described as a single logical filter mechanism if the positions of
the two wheels are indicated in adjacent data columns that can be combined into
a single code field.
They may equally well be treated as two logical filter carriers with separate
code columns.

It is also possible to have two filter wheels in series, arranged so
that one wheel carries chromatic filters for one photometric system, but
``neutral'' filters for another, whose chromatic filters are in the second
wheel.
Then only the combinations that make sense need be included in the instrument
table; those that would put two neutral filters in series, or two chromatic
filters of different systems, can be omitted.
(Note that there might be useful combinations of two chromatic filters: if one
wheel contains UBV filters and the other contains uvby filters, one might
combine a V filter with u to give a uRL combination.)


\subsubsection{Character descriptor FILTCAT}
If curves are available for the filters used, this holds the name of a MIDAS
catalog file that points to individual table files, which in turn hold the
transmission data.

The individual filter table files should give
transmittance (column name TRANS)
as a function of wavelength in nanometers (column name LAMBDA).
Each filter's
table file should contain a character descriptor named {\bf BAND}
that names the passband for which that filter is used.

If no filter curves are available, {\bf FILTCAT} should contain only spaces.

\subsubsection{Character descriptor FILTSTAT}
This descriptor specifies the state of filter temperature control.
It contains the value
{\tt 'REGULATED'}
if filter temperature is regulated;
{\tt 'MEASURED'}
if filter temperature is measured; and
{\tt 'DOME'}
if filters are unregulated, and approximately at dome temperature.

If {\bf FILTSTAT}= {\tt 'REGULATED'}, there may be a Real*4 descriptor
named
{\bf FILTTEMP}
in the instrumental ``.tbl'' file, giving the temperature of the set-point
in kelvins.
If {\bf FILTSTAT}= {\tt 'MEASURED'}, there should be a data column named
FILTTEMP in the {\it data} files (see next section)
that contains the measured filter temperature.


\begin{table}[hbt]
\begin{center}
\begin{tabular}{|l|l|l|c|}           \hline
 Name		 & Contents		  & Variable Type & When used \\ \hline
{\bf INSTNAM}    &  name of instrument   & C*72 string  & always \\ 
{\bf NFILTCAR}   &  no. of filter carriers & I integer  & always \\ 
{\bf FILTCAT}    &  filter catalog name   & C*80 string & always \\ 
{\bf FILTSTAT}   &  filter thermostating  & C*9 string & always \\ 
{\bf FILTTEMP}   &  filter temperature    & R*4 real   & {\bf FILTSTAT}={\tt REGULATED} \\ 
{\bf NDETS}      &  no. of detectors      & I integer  & always \\ 
{\bf CONDITION}  &  condition of optics    & C*7 string & always \\ 
	\hline
\end{tabular}
\end{center}
\caption[]{All possible Descriptors for the instrumental ``.tbl'' file}
\label{tbl:instr-descriptors}
\end{table}


\subsection{Detectors}
\label{sect-det}
The number of detectors is always kept in an integer descriptor, {\bf NDETS}.
This is ordinarily the same as the number of output data channels from the
instrument.

\subsubsection{Columns NDET and DETNAME}
The integer column named NDET contains the sequence number for the detector
sub-table.
Each detector channel has its own row in this sub-table.
For multichannel instruments that devote one detector to each passband,
these rows can be considered a natural continuation of the rows of the passband
sub-table.
In this case, the NBAND and NDET columns should have the same values within
each row.

The A*16 column named DETNAME is optional, and is provided only for the user's
convenience.
As its name indicates, it can hold a character string naming the detector.

\subsubsection{Column DETCODE}
If a multichannel instrument indicates which channel is being read out by a
code, it should be kept in a column named DETCODE.

\subsubsection{Column DET}
The detector type should be specified, so that programs using the data
can have approximate information about the spectral response and other
characteristics of the detector.
The primary indicator is a character column, DET,
which contains 
{\tt 'PMT'}
if the detector is a photomultiplier;
{\tt 'SILICON'}
for Si-CCDs and Si photodiodes; or 
{\tt 'OTHER'}
for any other type.
(As detector technology evolves, one would expect to extend
this list.)

\subsubsection{Photomultipliers: DET={\tt PMT}}
The spectral responsivity of a photomultiplier depends on the photocathode
composition, the window composition, and the mode of illumination (i.e., from
the vacuum side or the substrate side).
For many common situations, these factors have been combined into
standard spectral responses known as ``S-numbers''
(S-1, S-4, S-20, etc.)
that are used by most, but not all, manufacturers.
The spectral response should therefore be indicated by a character column
named
SNUMBER,
containing the S-number, if it is known (e.g., {\tt 'S-13'}).
Other valid string values are
{\tt 'BIALKALI'}
for ``bialkali'' photocathodes with glass windows;
{\tt 'QBIALKALI'}
for ``bialkali'' photocathodes with fused-quartz windows;
{\tt 'GAAS'}
for gallium arsenide ``negative-electron-affinity'' photocathodes
with glass windows;
and
{\tt 'QGAAS'}
for gallium arsenide ``NEA'' photocathodes with fused-quartz windows.
Any spectral response markedly different from these should be flagged as
SNUMBER={\tt 'OTHER'},
and the spectral response supplied in a separate table file, as described
under
DET={\tt 'OTHER'} (see section~\ref{spect-resp}).

Photomultipliers are used in different modes, which have different
properties.
This is specified by a character column
MODE,
whose values may be
{\tt 'PC'}
for pulse counting;
{\tt 'DC'}
for DC photometry; or
{\tt 'CI'}
for charge integration.

If 
MODE={\tt 'PC'},
additional information is needed to describe the pulse-overlap
(``dead-time'') correction.
This is given in another character column,
DEADTYPE,
which can have the values
{\tt 'EXTENDING'},
for a paralysable counter, or
{\tt 'NONEXTENDING'},
for a non-paralysable counter.
If the counter's behavior is unknown, and cannot be determined, set
DEADTYPE={\tt 'UNKNOWN'}.
The estimated value of the dead-time parameter itself, in seconds,
goes in a Real*4 column called
DEADTIME,
and the uncertainty of the dead-time parameter, again in seconds,
goes in a Real*4 column called
DEADTIMEERROR.

Users should be aware that, because pulse pile-up partly offsets
coincidence losses, the effective dead-time parameter depends on
a combination of the resolution of
the discriminator, the discriminator setting, and the characteristics
of the individual photomultiplier under actual conditions of use, such as
temperature and voltage, that affect the pulse shape and pulse-height 
distribution.
Therefore, it is essential to keep these parameters fixed during a run.
Also, the effective dead-time parameter should be determined from actual
photometric data gathered for the purpose of determining its value accurately;
nominal values of pulse-resolution times from manufacturers, or
pulse-resolution times determined with pulse generators, are {\it not}
suitable for correcting photometric measurements.

\subsubsection{Column COOLING}
As the stability of zero-points and transformation coefficients depends partly
on the detector temperature, information must be given on the detector cooling
arrangements.
This is stored in a character column called 
COOLING,
which may contain the strings
{\tt 'REGULATED'}
if an active closed-loop cooling system is used (either thermoelectric or
some other servo-controlled cooling);
{\tt 'UNREGULATED'}
if the tube is cooled in some way, but not regulated;
{\tt 'ICE'}
if ordinary (water) ice is used as coolant;
{\tt 'DRYICE'}
if dry ice (solid carbon dioxide) is used with{\it out} a heat-transfer fluid;
{\tt 'MEASURED'}
if the temperature is measured but not regulated;
or
{\tt 'NONE'}
if the PMT runs at ambient temperature.

One should be careful not to push temperature-regulated systems beyond their
capabilities.
A servo-controlled system that tries to cool all the time and never
oscillates about its set point is, in fact, unregulated rather than regulated.
As long as dark current is well below sky measurements, dark noise probably
adds little to the photon noise from the sky, and additional cooling is
unnecessary.
If the dark current is kept a little above the minimum possible value, so that
it remains in the strongly temperature-dependent regime, it serves as a useful
indicator of tube temperature and health.

If dry ice is used with a low-viscosity heat-transfer liquid such as
ethyl acetate or Freon-11,
COOLING
should be set to
{\tt 'REGULATED'};
but if dry ice is used with a viscous fluid such as alcohol,
{\tt 'DRYICE'}
should be used.
Note: Freon-11 is one of the CFCs most destructive to the ozone layer,
and should be avoided.

If
COOLING={\tt 'REGULATED'},
a Real*4 column named
DETTEMP
should contain the estimated detector temperature in kelvins.
With dry ice and ethyl acetate, the value in
DETTEMP
should be 195,
corresponding to $-78^{\circ}$C.

If
COOLING={\tt 'MEASURED'},
detector temperatures should be part of the regular data stream.
In this case, a Real*4 data column DETTEMP
should be in the data files, rather than in
the instrumental ``.tbl'' file.
(Cf.\ the similar usage of FILTTEMP, and further details in the next section.)

\begin{table}[hbt]
\begin{center}
\begin{tabular}{|l|c|c|c|c|}           \hline
 Column Label  & Contents      & Variable Type & Format & When used \\ \hline
{\tt DET}      &  detector type    & C*8 string & A8     & always \\ 
{\tt DETNAME}  &  detector name    & C*8 string & A8     & optional \\ 
{\tt NDET}     &  detector number  & I integer  & I5     & always \\ 
{\tt DETCODE}  &  detector code    & C*8 string & A8     & if dets. are coded \\
{\tt SNUMBER}  &  PMT S-number     & C*9 string & A9     & DET={\tt PMT} \\ 
{\tt MODE}     & PMT mode (PC/DC/CI)&C*2 string & A4     & DET={\tt PMT} \\ 
{\tt DEADTYPE} &  PMT deadtime type & C*12 string & A12  & DET={\tt PMT} \\ 
{\tt DEADTIME} &  PMT deadtime (sec) & R*4 real &  E8.3  & DET={\tt PMT} \\ 
{\tt DEADTIMEERROR}&PMT deadtime error&R*4 real &  E13.2  & DET={\tt PMT} \\ 
{\tt COOLING}   & detector cooling  & C*12 string & A12  & always \\ 
{\tt DETTEMP}   & detector temperature & R*4 real & F8.1 & COOLING={\tt REGULATED} \\ 
{\tt SPECTRESPTBL} & actual spectral response & C*(*) string &A& (see section~\ref{spect-resp}) \\
{\tt BLUERESP} & CCD blue response class & C*8 string &A8& DET={\tt SILICON} \\
	\hline
\end{tabular}
\end{center}
\caption[]{Detector columns of the instrument table file}
\label{tbl:detector-instr-cols}
\end{table}

\subsubsection{Silicon photodiodes and CCDs: DET={\tt SILICON}}
Unfortunately, the spectral responses of these devices are quite varied,
depending on details of manufacturing (e.g., polysilicon vs. aluminum 
electrodes; thinned vs. non-thinned),
preparation (use of blue-enhancing treatments such as
phosphors, UV-irradiation, and flashgates), and use (front-side vs. back-side
illumination).
The response also depends on temperature, as it does for all semiconducting
materials.

The preferred method of handling this problem is to use a table of (averaged)
spectral responsivity determined for the individual device under actual
conditions of use.
This means using the spectral-response table file described under
DET={\tt OTHER} (section~\ref{spect-resp}).
The name of the table file should be contained in a character column
named
SPECTRESPTBL, of adequate width to hold a file name (see
section~\ref{spect-resp} for a description of the file).
If no table is available, this column can be omitted.
If tables are available for only some detectors, the column should exist, and
contain blanks in the rows of detectors lacking detailed information.

Even if no detailed spectral response is available,
it is sometimes necessary to make a rough guess at the spectral
response, particularly for planning purposes.
Then, if
SPECTRESPTBL is missing,
there should be a character column named
BLUERESP that gives some indication of the expected blue response.
Valid string values are
{\tt 'FRONT'}
for front-side illumination of a normal CCD, with no phosphor coating;
{\tt 'BACK'}
for thinned, un-enhanced CCDs illuminated from the substrate side;
{\tt 'ENHANCED'}
for CCDs treated by UV irradiation, special gases, or flashgate; or
{\tt 'PHOSPHOR'}
for CCDs coated with a blue-sensitive phosphor.
These general categories provide some information on spectral response, but it
may easily be in error by a factor of 3 or more.

As for PMTs, the
COOLING
column is required.
Usually, CCDs are cooled with liquid nitrogen, but are actually kept
thermostatted by a servo system.
In this case,
COOLING={\tt 'REGULATED'}.
The same applies to chips cooled thermoelectrically, in most cases.
Occasionally one finds unregulated cooling; then
COOLING={\tt 'UNREGULATED'},
and the treatment is the same as for cooled but unregulated PMTs (see above).


\subsubsection{Other detectors: DET={\tt OTHER}}
Other detectors {\it require} a spectral-response table file, whose
name should be the contents of a character column named
SPECTRESPTBL in the detector sub-table of the instrumental ``.tbl'' file.

\label{spect-resp}
This spectral-response table file uses a column named 
{\tt 'LAMBDA'}
(containing wavelengths in nanometers) as the reference column.
Responsivities, in amperes per watt, go in a column named
{\tt 'RESP'}.
(Observers who have difficulty converting manufacturers' data from
microamperes per microwatt to amperes per watt should be encouraged to take up
a less demanding field than photometry.)
Alternatively, responsive quantum efficiencies can be put in a
column named
{\tt 'RQE'}; this quantity is dimensionless.
All these data are Real*4.
The table should contain one character descriptor, named
{\bf RESPTYPE},
whose value is either
{\tt 'RESP'} or
{\tt 'RQE'}, to indicate which type of data are tabulated.

The remarks made above about the
COOLING
column apply here also; see the discussions given in connection with PMTs
and CCDs.


\subsection{Telescope optics}
Finally, the condition of the telescope optics should be stored in a
character descriptor named
{\bf CONDITION}
in the instrumental ``.tbl'' file.
Possible values are
{\tt 'CLEAN'},
if the mirrors have been re-coated or cleaned
within two weeks of the observing run, and/or a flashlight beam is barely
visible on optical surfaces;
{\tt 'AVERAGE'},
if a flashlight beam is plainly visible on the optical surface, but the
dirt is not very bad; and
{\tt 'DIRTY'},
if shining a flashlight beam on the primary produces a sensation of
revulsion in a trained observer.
Obviously, some experience is required to judge these categories accurately.


\subsection{Sample instrument files}
\label{subsect-sample-inst}
Because the instrumental table file is rather complicated, and has a variable
structure that depends on the nature of the instrument, here are some
examples.

\subsubsection{A simple photometer}
First, consider a very simple 1-channel UBV photometer.
Let us assume a rather minimal instrument: no cooling or temperature
regulation, and simple DC photometry.
This resembles the instrument with which the UBV system was first set up.
Here is the table:


\begin{table}[ht]

{
\parindent=2pc
Descriptor values:
\vskip 4pt

{\bf NFILTCAR} = 1

{\bf NDETS} = 1

{\bf FILTSTAT} = {\tt DOME}

{\bf FILTCAT} = {\tt '\ '} (blank string)

{\bf CONDITION} = {\tt AVERAGE}

\par
}

\begin{center}
\vskip -8pt
Passband sub-table
\vskip 4pt
{\tt
\begin{tabular}{|c l c l l l|}           \hline
 NBAND & BAND & FILTCODE\_1 & REDLEAK  & RLTYPE & MAKER \\ 
 ----- & ---- & ----------  & -------- & ------ & ------- \\ 
   1   & U    &      3      & MEASURED & LOOSE  & CORNING \\ 
   2   & B    &      1      & IGNORED  &        &        \\ 
   3   & V    &      2      & ABSENT   &        &        \\ 
   4   & URL  &      4      & ABSENT   &        &        \\ 
	\hline
\end{tabular}
}

\vskip 10pt

Detector sub-table
\vskip 3pt
{\tt
\begin{tabular}{|c c c c c |}           \hline
 NDET & DET & SNUMBER & MODE & COOLING  \\ 
 ---- & --- & ------- & ---- & ------- \\ 
   1  & PMT &    S-4  &  DC  & NONE \\ 
	\hline
\end{tabular}
}
\end{center}
\caption[]{Instrument table file for a simple photometer}
\label{tbl:simple-example}
\end{table}

As there is only one detector, we need not include the NDETUSED column.

\begin{table}[htb]
{
\parindent=2pc
Descriptor values:
\vskip 4pt

{\bf NFILTCAR} = 2

{\bf NDETS} = 1

{\bf FILTSTAT} = {\tt DOME}

{\bf FILTCAT} = {\tt '\ '} (blank string)

{\bf CONDITION} = {\tt AVERAGE}
\par
}

\begin{center}

\vskip -8pt
Passband sub-table
\vskip 4pt
{\tt
\begin{tabular}{|c l c c r l l l|}           \hline
 NBAND & BAND & FILTCODE\_1 & FILTCODE\_2 & NDVALUE & REDLEAK  & RLTYPE   & MAKER \\ 
 ----- & ---- & ---------- & ----------   & ------- & -------- & -------- & ------ \\ 
   1   & u    &    10     &      0      & 1.000 & MEASURED & CEMENTED & SCHOTT \\ 
   2   & v    &    20     &      0      & 1.000 & BLOCKED  &          &        \\ 
   3   & b    &    30     &      0      & 1.000 & BLOCKED  &          &        \\ 
   4   & y    &    40     &      0      & 1.000 & BLOCKED  &          &        \\ 
   5   & uND  &    11     &      0      & 9.897 & MEASURED & CEMENTED & SCHOTT \\ 
   6   & vND  &    21     &      0      & 9.763 & BLOCKED  &          &        \\ 
   7   & bND  &    31     &      0      & 9.674 & BLOCKED  &          &        \\ 
   8   & yND  &    41     &      0      & 9.695 & BLOCKED  &          &        \\ 
   9   & DARK &   any     &      1      &       &          &          &        \\ 
	\hline
\end{tabular}
}

\vskip 10pt

Detector sub-table
\vskip 3pt
{\tt
\begin{tabular}{|c c c c c c c c c|}           \hline
 NDET & DET & SNUMBER & MODE & DEADTYPE & DEADTIME& DEADTIMEERROR& COOLING   & DETTEMP\\ 
 ---- & --- & ------- & ---- & --------- & --------& -------------& --------- & -------\\ 
   1  & PMT & QBIALKAI&  PC  & EXTENDING& 6.74E-8& 4.2E-9& REGULATED & 273. \\ 
	\hline
\end{tabular}
}
\end{center}
\caption[]{Instrument table file for a typical modern photometer}
\label{tbl:modern-example}
\end{table}

\subsubsection{A modern single-channel photometer}
Next, consider a more modern photometer that uses pulse-counting. 
It has a ``neutral'' filter in addition to standard uvby filters.
The ``neutral'' filter is in series with the passband filters, and is used
to determine the dead-time correction.
The positions of these two filter mechanisms are recorded as two adjacent
digits in the data, so we can treat them as a single filter code; the second
digit is 1 when the ``neutral'' filter is in the beam.

There is also a shutter whose position is encoded separately in the data
stream: 0 means open, 1 means shut.
This can be treated as a second logical filter mechanism.

The photomultiplier in this modern instrument is in a thermoelectrically cooled
chamber, regulated to run at $0^{\circ}$ C (273 K).
Table~\ref{tbl:modern-example} shows what we get.

Again, there is only one detector, so we need not include the NDETUSED column.


\begin{table}[tb]
{
\parindent=2pc
Descriptor values:
\vskip 4pt

{\bf NFILTCAR} = 2

{\bf NDETS} = 2

{\bf FILTSTAT} = {\tt MEASURED}

{\bf FILTCAT} = {\tt '\ '} (blank string)

{\bf CONDITION} = {\tt AVERAGE}
\par
}

\begin{center}

\vskip -8pt
Passband sub-table
\vskip 4pt
{\tt
\begin{tabular}{|c l l l l c |}           \hline
 NBAND & BAND & FILTCODE\_1 & FILTCODE\_2 & REDLEAK  & NDETUSED   \\ 
 ----- & ---- & ---------- & ----------   & -------  & -------- \\ 
   1   & U    &    1      &      any      & BLOCKED &    1     \\ 
   2   & B    &    2      &      any    & BLOCKED  &     1    \\ 
   3   & V    &    3      &      any    & ABSENT   &     1    \\ 
   4   & R    &    any    &      1      & BLOCKED  &     2    \\ 
   5   & I    &    any    &      2      & ABSENT   &     2    \\ 
   6   & DARK1 &   0      &      any    &          &     1    \\ 
   7   & DARK2 &  any     &      0      &          &     2    \\ 
	\hline
\end{tabular}
}

\vskip 10pt

Detector sub-table
\vskip 3pt
{\tt
\begin{tabular}{|c c c c l |}           \hline
 NDET & DET & SNUMBER & MODE & COOLING  \\ 
 ---- & --- & ------- & ---- & -------- \\ 
   1  & PMT & S-13    &  CI  & MEASURED \\ 
   2  & PMT & GAAS    &  CI  & DRYICE \\ 
	\hline
\end{tabular}
}
\end{center}
\caption[]{Instrument table file for a two-channel photometer}
\label{tbl:2-chan-example}
\end{table}

\subsubsection{A modern two-channel photometer}
\label{sect-2chan}
Next, consider a more elaborate UBVRI
photometer with two channels (a ``red'' and a
``blue'' tube).
We suppose it has separate filter wheels in the two beams; the first filter
wheel contains the UBV filters, and the second has the R and I filters.
Filter position 0 in each wheel is opaque; note that we need separate DARK
codes for the two channels.
Red leaks are blocked, and filter temperatures are measured.

If the filter wheels had been in series instead of
in separate beams, the unused wheel
would have to be set to a clear position, instead of the ``any'' entered in
the first five lines of
Table~\ref{tbl:2-chan-example}.

Because we have two detectors, the NDETUSED column is mandatory; see
Table~\ref{tbl:2-chan-example}.
In our example, the ``blue'' tube is uncooled, but its temperature is measured;
while the ``red'' tube is cooled with dry ice.
Both run in charge-integration mode.

\begin{table}[hbt]

{
\parindent=2pc
Descriptor values:
\vskip 4pt

{\bf NFILTCAR} = 1

{\bf NDETS} = 1

{\bf FILTSTAT} = {\tt DOME}

{\bf FILTCAT} = {\tt '\ '} (blank string)

{\bf CONDITION} = {\tt AVERAGE}

\par
}

\begin{center}
\vskip -8pt
Passband sub-table
\vskip 4pt
{\tt
\begin{tabular}{|c l c l |}           \hline
 NBAND & BAND & FILTCODE\_1 & REDLEAK  \\ 
 ----- & ---- & ----------  & ------- \\ 
   1   & B    &      B      & BLOCKED  \\ 
   2   & V    &      V      & BLOCKED  \\ 
	\hline
\end{tabular}
}

\vskip 10pt

Detector sub-table
\vskip 3pt
{\tt
\begin{tabular}{|c c c c c |}           \hline
 NDET & DET    & BLUERESP & COOLING & DETTEMP  \\ 
 ---- & ------- &-------- & --------- & -------\\ 
   1  & SILICON &  FRONT  & REGULATED & 180.\\ 
	\hline
\end{tabular}
}
\end{center}
\caption[]{Instrument table file for a simple CCD setup}
\label{tbl:ccd-example}
\end{table}

\subsubsection{CCD photometry}
Our final example is an instrument-description file used for
B and V magnitudes extracted from CCD frames.
The CCD is a front-illuminated chip, run at 180 K.
The filters are at ambient temperature, uncontrolled.
Bands are identified by name in the file of extracted values.

The instrumental description is in Table~\ref{tbl:ccd-example}.
Notice how this resembles the primitive UBV photometer in the first example.



\section{Observational data}
\label{sect-data}
Every instrument seems to produce its data in a different format.
However, it is relatively simple to re-format the data to a standard form;
MIDAS table files are the obvious standard form to use.
Usually the conversion is done in two steps: first reformat the existing
data as an ASCII file with all records in the same format,
and then convert this ASCII file to MIDAS table format.

The ASCII
re-formatting can be done by a user-written program, or by using UNIX tools
such as the stream editor ({\bf sed}) and the table-oriented programming
language {\bf awk}.
While the UNIX manual pages provide little useful information on these tools,
there are some excellent books available, such as \cite{SED}
and \cite{AWK}.

Often, much of the work has already been done.
If a program exists that reads the current instrumental data, it can readily be
modified to read the data and then reproduce them as an ASCII file, suitable for
conversion to MIDAS table format.
The data-reading part of the existing program is adaptable as the front end of
the reformatter.
To simplify the conversion, FORTRAN routines will be made available to
handle the back end.
Thus, very little work really has to be done.
In any case, the reformatting program only has to be written once for a given
instrument.

ESO telescopes provide relatively clean data files, but these files contain
more than one kind of record.
Thus, even these data files must be reformatted before they can be converted to
MIDAS tables by the CREATE/TABLE command.
Programs will be provided to convert data from ESO telescopes to the standard
table format.

\subsection{Required observational data}
A certain minimum set of data is required to make observations reducible.
These are the identity of the object measured; the identity of the bandpass in
which the measurement was made; the time of the observation; and, for
integration-type measurements, the duration of the integration.
Table~\ref{tbl:basic-obs-cols} describes the basic table-file columns in detail.

\subsubsection{What was the measurement?}
The measurements themselves should be stored in a column with the label
SIGNAL.
These are Real*4 data; the format specified in the table may depend on the
instrument.
Often the readings are recorded as integers; then assume the decimal point at
the end of the field.

Programs will expect that SIGNAL represents the integration of the
photon flux for the exposure time given in the EXPTIME column (see 
section~\ref{exptime}).
That is, it is the {\it ratio} of SIGNAL to EXPTIME that
represents an actual photon count
{\it rate}, or intensity, if the exposure times vary.

This assumes the data are in arbitrary intensity units (times time).
Sometimes one must deal with data in the form of magnitudes, as in
re-reducing old data, or data measured from strip-charts with a magnitude
ruler.
In that case, the column label should be RAWMAG;
see Table~\ref{tbl:other-obs-cols}.
Programs will expect RAWMAG to be the usual negative logarithms of
intensities; that is, RAWMAG values only use EXPTIME in determining weights.

Except for pulse counting with photomultipliers, where reasonably accurate
models exist for the nonlinearity, the SIGNAL values should have been corrected
for nonlinearity.
In any case, the EXPTIME values should have been corrected for
differences between nominal and actual exposure times.
Such corrections are especially important for CCD data, where they can vary
across the frame (see Stetson \cite{S89}).

\subsubsection{What was measured?}
An OBJECT column gives the name of the object observed (usually a star name).
Many instruments record only a code for the object, instead of a name.
These codes must be turned into standard names for the observational-data
tables.
Presumably the owners of such instruments already have software to do this
that can be cannibalized for the format conversion.

For measurements of dark current, the OBJECT column should contain the word
{\tt DARK}.
As dark measurements must be referred to the electrical zero of the system,
they are usually accompanied by such measurements.
The electrical-zero values should be identified as 
{\tt ZERO}
in the OBJECT column.
If no such data exist, they will be assumed numerically zero.

Naming the object
is simple when the measurement is just star + sky; one normally uses the
name of the star.
However, sky observations must be matched up with the proper stars.
This is not a trivial task, for multiple sky observations may be used for one
single star, and multiple star
observations may have to share a single sky measurement.

Thus, ``sky'' alone is not a sufficient identification; it must be something
like ``sky for such-and-such a star''.
A related problem is to know the coordinates where the sky is observed,
which are needed in modelling the sky brightness.
In
critical cases, it is common practice to measure sky on two or more positions
around a target object, and these positions must be identified.
Finally, we must be able to use sky-subtracted data, for which the sky
brightness may no longer be available (some CCD photometry falls in this
category).

A general treatment of this problem requires a column called OBJECT, bearing
the usual name of the object (as in the star tables); a column labelled
STARSKY, to distinguish between star+sky, star alone, or sky alone; and
additional columns to identify the sky position.

Valid strings for the STARSKY column are
{\tt STAR} for the sum (star + sky);
{\tt SKY} for sky alone; and
{\tt DIFF} for the difference.
The latter is often produced in CCD photometry.
Note that
{\tt SKY} data may still be useful in this case.

The position where sky was measured can be specified by its
offsets from the star in both coordinates.
Usually, these will be in two columns
named SKYOFFSETRA and SKYOFFSETDEC, to identify the sky position used.
These are convenient in most cases, as observers usually offset in just one
coordinate.
Often only one sky position is used, nearly always offset in the same direction.
For users of alt-azimuth mountings, these labels can be replaced by
SKYOFFSETALT and SKYOFFSETAZ;
see Table~\ref{tbl:other-obs-cols}.

It can be foreseen that lazy observers will fill up these columns with zeroes.
They should be warned that assuming the sky position to coincide with the star,
combined with measuring the sky always on the same side of a star,
can introduce systematic errors, because of the gradient of sky brightness with
zenith distance.
For faint stars this may not be negligible, particularly
if the offset is always in declination, which tends to correlate strongly with
zenith distance.

Some telescopes record the apparent position of each measurement.
In such cases, it will be more convenient to use columns named
SKYRA and SKYDEC instead of offsets
(see Table~\ref{tbl:other-obs-cols}).

In clusters and variable-star fields, the sky may be measured in a common
position for a group of stars.
In this case, the observations of a group are delimited by putting
{\tt BEGINGROUP}
in the OBJECT column at the start of the group, and
{\tt ENDGROUP}
at the end.
Then the sky position(s) should be given as absolute coordinates in
a star-catalog MIDAS table file, identified there as a string beginning with
the word {\tt SKY}.
The R.A.\ and Dec.\ for these sky positions can generally be determined
accurately enough by reference to some star on finding charts, or by
interpolation among the known positions of variable and comparison stars.
Normally, these reference sky positions will simply be included in the
program-star table files, with OBJECT names like
{\tt 'SKY for NGC 7789'}
or
{\tt 'SKY position 1 for RU Lupi'}.
This allows several distinct sky positions to be measured in the neighborhood
of such a group.

Because MIDAS tables may in principle be sorted on any column, and because
groups delimited by
{\tt BEGINGROUP}
and
{\tt ENDGROUP}
are inherently time-dependent, programs using such data must make sure the
data are sorted in time sequence.
This is not normally a problem, as time is the natural independent variable in
such a list of observations.
However, observers must be sure that the MJD\_OBS column is correct for the
{\tt BEGINGROUP}
and
{\tt ENDGROUP}
pseudo-objects.


\begin{table}
\begin{center}
\begin{tabular}{|l|c|c|l|l|}           \hline
 Column Label & Contents	& Units	& Variable Type & Format \\ \hline
{\tt SIGNAL}    & object measurement	       & exposure & R*4 real & Fw.d \\ 
{\tt OBJECT}    & object identification		&        & C*32 string & A32 \\ 
{\tt STARSKY}	& star/sky identification	&        & C*4 string  & A8 \\ 
{\tt SKYOFFSETRA} & sky measurement position	& arcsec & R*4 real   & F4.0 \\ 
{\tt SKYOFFSETDEC} & sky measurement position	& arcsec & R*4 real   & F4.0 \\ 
{\tt BAND}	& passband identification	&        & C*8 string & A8 \\ 
{\tt MJD\_OBS}	& start of integration		&  days  & R*8 real  & F12.5 \\ 
{\tt EXPTIME}	& duration of integration	& seconds & R*4 real  & F8.3 \\ 
{\tt COMMENT}    & comment field		&        & C*32 string & A32 \\ 
	\hline
\end{tabular}
\end{center}
\caption[]{Basic column specifications for observational-data tables}
\label{tbl:basic-obs-cols}
\end{table}


\subsubsection{Bandpass and detector identification}
The bandpass in which the measurement is made must be identified.
The bandpass name is recorded in a column labelled BAND.
(This name, combined with the information in the instrument file, is used to
identify the detector in multichannel instruments.)
Standard passband names should be used:
{\tt 'V', 'B', 'U', 'URL', 'R', 'I', 'u', 'v', 'b', 'y', 'betaW',} etc.
These should agree with the notation used for standard indices for the
standard stars (see section~\ref{sect-std-star}, above, which
describes standard-star table files).
Standard band names are also listed in subsection~\ref{subsect-passbands},
``Passbands''.

For {\tt DARK} measurements, a digit must be appended to indicate the
detector number, if more than one detector is used: {\tt DARK1, DARK2,} etc.
If red leaks are measured for two or more passbands, they must be plainly
marked; e.g.,
{\tt 'URL', 'BRL',} etc.
If ``neutral'' filters are used to measure nonlinearity, as is often done
with pulse-counting systems, the appropriate suffix
{\tt 'ND'} (for a single attenuator), or
{\tt 'ND1', 'ND2',} etc., should be appended to the BAND value.

Often a filter position is carried in the original data as a code.
Such information must be decoded to a standard band name
in the observation-table file.
The decoding information is normally found in the instrumental table file.

\subsubsection{Timing information}
It is not always easy to identify ``the'' time of an observation.
Some instruments record the time at which the observation began; some record
the end of the measurement, or even the time at which the readout was
recorded; very few record the middle of the exposure.
The ESO Archive records the starting time of the observation, recorded in a
FITS-header keyword named {\tt MJD-OBS}.
Because of problems in MIDAS with strings containing embedded minus signs, the
column label used here is MJD\_OBS.
This quantity is the geocentric Julian Date at the start of the integration,
minus 2400000.5 days.
To retain adequate precision (1 second is required), this {\it must}
be stored in double precision.

Note that this is geocentric, not heliocentric MJD.
It is not suitable for use in computing phases of eclipsing binaries and the
like without light-time corrections.

\label{exptime}
Having accepted a starting time as the basic timing datum, we must in every
case have an integration time, even for data (like DC photometry) where this is
not directly involved in calculating signal strength.
In any case we would need this information for weighting purposes.
Again the ESO Archive name is used as column label: EXPTIME.

\subsubsection{Comment field}
Comments are so common, and so useful, that a 32-byte COMMENT column
should be considered part of the basic data, even though it may be blank for
the majority of the data.
This field may be used to append  comments to a particular
observation, such as {\tt DOME IN THE WAY?},
{\tt MOON ON MIRROR},
or {\tt CONTRAIL}.

General comments, such as
{\tt Cirrus low in NW},
or {\tt LUNCH BREAK},
should be stored as data with the OBJECT field set to {\tt COMMENT}.
Comments longer than 32 characters can be split into 32-byte pieces with the
same time value.
The time field MJD\_OBS should always be filled in, but the rest can remain
undefined.

\subsection{Additional information}
Several other data are useful, or even essential.
Some of these, like temperature and humidity, are independent variables
that are likely to affect sensitivity and spectral response.
Atmospheric pressure, apart from very small effects, is directly
proportional to the Rayleigh optical depth of the Earth's atmosphere, which is
the most wavelength-dependent part of the extinction.
Additional instrumental parameters, like the size of the measuring aperture
or the high voltage used on a photomultiplier,
are essential and must be recorded for each observation if they vary.
Some systems have gain steps that must be recorded for every observation.
Quasi-neutral attenuators may be used to calibrate nonlinearity; such
information must be provided to the reduction program.
The Geneva quality-control parameters \cite{B84} may be available; again, they
should have separate columns in the table.
Measurements from a seeing monitor may also be available.

Table~\ref{tbl:other-obs-cols}
describes these additional columns in detail.

\subsubsection{Temperature and humidity data}
The most temperature-sensitive parts of most photometric instruments are the
filters, the detector, and the electronics.
The likely temperature coefficients are of similar orders of magnitude:
generally several tenths of a percent per degree.
As temperatures usually vary by several degrees during a run, temperature
effects are likely to exceed 0.01 magnitude.

Although the ESO Archive standard is to record temperatures in kelvins, this is
often inconvenient.
Temperature data may be recorded in Fahrenheit or Celsius, or in some scale
with perfectly arbitrary units, such as the output of some uncalibrated
thermistor sensor.
Although Celsius or Kelvin degrees are a useful basis for judging whether the
actual size of an apparent temperature coefficient is reasonable, the reduction
program simply needs an independent variable to work with.
Therefore, if the temperatures are not in kelvins, the appropriate units
should be provided in the table file (if temperatures are in a column), or as a
comment.

The temperatures of filters and detectors were discussed in previous sections
dealing with instrumental parameters.
If they are regulated, such data should be stored in
Real*4 descriptors in the instrumental ``.tbl'' files (see above).
If they are measured,
they should be in data columns with the labels FILTTEMP and/or DETTEMP.

If temperatures are measured only occasionally, and not with every
observation, the values should still be recorded in columns of the data table
file.
In this case, the temperature measurements are essentially asynchronous with
the photometric measurements; then the OBJECT column should contain the word
FILTTEMP or DETTEMP, as appropriate, and
the temperature columns will contain the ``undefined'' value for actual
observations.

For example, in the ESO Archive logfiles, {\tt DOME TEMP}
is recorded every 15 minutes.
This should be used for FILTTEMP if the filters are at ambient temperature,
and for DETTEMP for an uncooled detector.

If filter and detector temperatures are otherwise regulated or recorded, it may
still be useful to record DOMETEMP in the data file as a Real*4 column.
The times and temperatures can be stripped out of the logfiles and stored
in the observational-data files.

Relative humidity is treated exactly the same way.
The column label is RELHUM, and this should be put in the OBJECT column for
sporadic readings.

Note that the times must be
converted to Real*8 because of the MJD format required!
As data in the ESO Archive logfiles are stored in {\it hh:mm:ss} form, they
will have to be converted.

\subsubsection{Pressure}
Some observatories have accurate information available on atmospheric pressure.
If it is routinely available for every measurement, it should go in a column
labelled PRESSURE, with the SI unit kPa.
Note that pressures read from aneroid (dial-type) barometers
are not very accurate, and probably should not be used.
Only absolute pressures should be recorded, {\it not} values ``corrected to sea
level''.


\begin{table}
\begin{center}
\begin{tabular}{|l|c|c|l|l|}           \hline
 Column Label & Contents	& Units      & Variable Type & Format \\ \hline
{\tt RAWMAG}    & object measurement	      & magnitudes & R*4 real & Fw.d \\ 
{\tt SKYRA}     & sky measurement position	& degrees & R*4 real  & F4.1 \\ 
{\tt SKYDEC}    & sky measurement position	& degrees & R*4 real  & F4.1 \\ 
{\tt SKYOFFSETALT} & sky measurement position	& arcsec & R*4 real   & F4.0 \\ 
{\tt SKYOFFSETAZ} & sky measurement position	& arcsec & R*4 real   & F4.0 \\ 
{\tt FILTTEMP}    & filter temperature         & see text & R*4 real & F4.1 \\ 
{\tt DETTEMP}     & detector temperature       & see text & R*4 real & F4.1 \\ 
{\tt DOMETEMP}    & dome temperature           & see text & R*4 real & F4.1 \\ 
{\tt RELHUM}      & relative humidity          & per cent & R*4 real & F4.1 \\ 
{\tt PRESSURE}    & atmos.\ pressure           & kPa      & R*4 real & F4.1 \\ 
{\tt DIAPHRAGM}   & field stop code            &         & C*4 string & A4 \\ 
{\tt PMTVOLTS}    & PMT high voltage           &         & C*4 string & A4 \\ 
{\tt GENEVA\_Q}    & Geneva Q parameter         &         & R*4 real & E9.2 \\ 
{\tt GENEVA\_R}    & Geneva R parameter         &         & R*4 real & E9.2 \\ 
{\tt GENEVA\_G}    & Geneva G parameter         &         & R*4 real & E9.2 \\ 
{\tt SEEING}      & seeing value              & see text & C*4 string & A4 \\ 
{\tt ESTERR}      & estimated error           & see text & R*4 real & Fw.d \\ 
	\hline
\end{tabular}
\end{center}
\caption[]{Other column specifications for observational-data tables}
\label{tbl:other-obs-cols}
\end{table}


\subsubsection{Measuring aperture}
The wings of a telescopic image are due to surface scattering caused by
microroughness of polished optical surfaces, and to (usually) a much
smaller extent to scattering by dirt on the optics.
Contrary to popular mythology, atmospheric effects are quite negligible.
These wings contain some tens of per cent of the total starlight, for
typical surface quality.
If the measuring aperture varies, a varying amount of starlight will be
excluded.
Furthermore, the excluded fraction is wavelength-dependent; so the
transformation from instrumental to standard system changes.
Therefore,
the field stop, physical or synthesized, within which the measurements were
made, should always be constant.

Unfortunately, sometimes it is necessary to combine measurements made with
different field stops.
Observers should realize that this really means different instruments;
the differences are usually several per cent.
Calibration data should be taken (i.e., several stars of different colors
observed with all the apertures used) to determine the transformations between
them.

Usually, the actual aperture sizes are only approximately known.
In any case, the actual variation of the excluded energy fraction
with radius is not accurately predictable.
Therefore, it suffices to retain codes for apertures, rather than try to deal
with them quantitatively.
The code should be put in a column labelled DIAPHRAGM (the common term for the
field stop).

\subsubsection{PMT Voltage}
When photomultipliers are used, the spectral response depends in a complicated
way (involving several different phenomena) on the electrode potentials in the
first few stages.
If the high voltage is changed to vary the gain, as is sometimes done in DC or
CI work, the spectral response varies.
This must be treated exactly like a variable measuring aperture: only data
taken under constant conditions should be reduced together, but sometimes
this can be done if adequate calibration data have been measured.

The column label is PMTVOLTS.
Once again, because several complex effects are involved, the effects are not
predictable, so there is no point in trying to use quantitative values.
Besides, the voltage settings on many power supplies are not very accurate, nor
can one read an analog voltmeter precisely enough to obtain useful numbers.
The values in this column will be treated as strings rather than converted to
numbers.

\subsubsection{Gain steps}
Here we consider only purely electrical gain changes that are guaranteed to be
spectrally neutral.
Examples are voltage-divider steps used to vary the gains of amplifiers;
switch-selected capacitors used in charge-integration systems; and pre-scalers
sometimes used to extend the dynamic range of counting systems.

The problem is complicated because there can be more than one set of variable
gain steps (often both ``coarse'' and ``fine'' steps are provided), and because
the actual gain values may not be well known.
In the latter case, we would like to determine them, if adequate calibration
data are available.

This is handled by having up to three columns containing the gain
codes; these codes may actually be strings representing the approximate values
in magnitudes, or other convenient labels, such as switch positions recorded in
the raw data stream.
The columns are named GAIN1, GAIN2, and GAIN3.

A character descriptor,
{\bf GAINTBL},
in the observational-data table
gives the name of a MIDAS table file, whose
columns are again labelled GAIN1, GAIN2, and (if needed) GAIN3
(see Table~\ref{tbl:gain-table}).
The reference column of this table contains the gain codes, and is labelled
CODES.

Note that the gain values are multipliers or scale factors; they are {\it not}
expressed in magnitudes.
The true signal is the value in SIGNAL multiplied by the value(s) in the
GAINn column(s).
It is immaterial whether the largest or the smallest gain is assigned the value
unity; the scale is perfectly arbitrary.


\begin{table}[ht]
\begin{center}
\begin{tabular}{|l|c|l|l|l|}           \hline
 Column Label & Contents & Variable Type & Format \\ \hline
{\tt CODES}    &  gain codes   & C*4 string & A4 \\ 
{\tt GAIN1}    &  gain values for first gain adjustment   & R*4 real & E9.4 \\ 
{\tt GAIN2}    &  gain values for second gain adjustment   & R*4 real & E9.4 \\ 
{\tt GAIN3}    &  gain values for third gain adjustment   & R*4 real & E9.4 \\ 
{\tt GAINERROR1} & uncertainty of first gain adjustment   & R*4 real & E9.4 \\ 
{\tt GAINERROR2} & uncertainty of second gain adjustment  & R*4 real & E9.4 \\ 
{\tt GAINERROR3} & uncertainty of third gain adjustment   & R*4 real & E9.4 \\ 
	\hline
\end{tabular}
\end{center}
\caption[]{Columns of the gain-table file}
\label{tbl:gain-table}
\end{table}


All the gains are of course pure numbers, and so have no units.
It is the user's responsibility to make sure the gain columns in the gain-table
and the data-table files match up correctly.
To assist this matching process, {\it both} files may contain a character
descriptor named
{\bf GAINNAMES},
containing up to three words (separated by commas) that name the three
gain adjustments.

The gains should be determinable to extremely high accuracy by purely
electrical measurements.
In some cases, the measurements have not been done, and only nominal values are
available, perhaps based on resistor tolerances.
The uncertainties should be placed in the GAINERROR columns.

If the gain steps are unknown, the 
{\bf GAINTBL}
descriptor should contain one space.
If adequate calibration data are available, the reduction program will try to
construct a gain table, with the default name gain.tbl.

This table is a little peculiar, in that it is unlikely that the same names
will be used for the steps of the different adjustments.
For example, the high gain steps might be coded by letters, but the fine steps
by numbers.
In such cases, only one column in each row will have values defined.
This causes no problems, as only the combinations that have meaning should occur
in the data.

\subsubsection{Geneva parameters}
Some instruments produce the Geneva Observatory quality parameters Q, R, and G
\cite{B84}.
These should occupy separate columns in the data table, with labels
GENEVA\_Q, GENEVA\_R, and GENEVA\_G.

\subsubsection{Seeing}
Sometimes seeing estimates are available, either from the observer at the
eyepiece, or from a nearby seeing monitor.
It might also be estimated from the core widths of images on CCD frames.
Such values should go in a column headed SEEING.

While quantitative measures, such as FWHM in seconds of arc, are most useful,
it may still be possible to obtain usable information from seeing expressed on
some arbitrary scale.
One should be careful not to mix the two types, or to intermix seeing estimated
on different scales.

\subsubsection{Error estimates}
Data extracted from CCD frames may be accompanied by error estimates,
which can be used in determining weights in the general solution.
These should be in the same intensity units as the data in the SIGNAL column.
The same format should be used as for the SIGNAL.
The column label for estimated errors is ESTERR.

This column should not be used for ordinary photometric data (i.e., do not put
estimates of ``photon noise'' here).
It should only be used when an independent estimate of noise is available
{\it in addition to} the information in the other columns.

If the data were expressed as magnitudes (column RAWMAG), any error estimates
should also be in magnitudes.





 
\begin{thebibliography}{99} 
%\bibitem{KY89}  Kasten, F., Young, A.T. : 1989, {\it Appl. Opt.},
%		{\bf 28}, 4735.
\bibitem{AWK}	Aho, A.V., Kernighan, B.W., Weinberger, P.J. : 1988,
		{\it The AWK Programming Language,}
		Addison-Wesley, New York.
\bibitem{AS66}	A\v zusienis and Strai\v zys : 1966, Bull. Vilnius Astron. Obs.,
		No. 17, 3.
\bibitem{B84}	Bartholdi, P., Burnet, M., Rufener, F. : 1984, {\it A\&AP}
		{\bf 134}, 290.
\bibitem{SED}	Dougherty, D. : 1991, {\it sed \& awk,}
		O'Reilly \& Assoc., Sebastopol, CA.
\bibitem{E92}	{\it ESO Archive Data Interface Requirements}
		Rev. 1.3, March, 1992.
\bibitem{H91}	Heck, A. : 1991, {\it Astronomy, Space Sciences and
		Related Organizations of the World}
		(Publ. Spec. du C.D.S. no. 16)
		Observatoire Astronomique de Strasbourg, Strasbourg, France.
\bibitem{S89}	Stetson, P.B. : 1989, in {\it Highlights of Astronomy}
		{\bf 8}, 635.
\bibitem{SY65}	Shao, C.-Y., Young, A.T. : 1965, {\it AJ}
		{\bf 70}, 726.
\bibitem{Y67}	Young, A.T. : 1967, {\it MN}
		{\bf 135}, 175.
\bibitem{Y74}	Young, A.T. : 1974, in {\it Methods of Experimental Physics,}
		vol. {\bf 12}, Part A, {\it Astrophysics: Optical and
		Infrared,}
		ed. Carleton, N., Academic, New York.
\end{thebibliography}
%
\end{document}
