Re: [TASS] Martin's variable, FITS keywords, FAQ, etc.

[Herbert R Johnson <hjohnson@PLUTO.NJCC.COM>]

Arne's comments on this are well-taken.

On         Tue, 30 Nov 1999 15:21:49 -0800, Chris Albertson <calbertson@LOGICON.COM> wrote:
*>Arne A. Henden wrote:
*>>
*>> I recommend you use start-of-exposure as the time
*>> written into the fits header.
*>
*>Why start-of-exposure? I would think mid exposure better
*>reflects when the oberservation was made.  Knowing the
*>exposure time you can always compute one from the other
*>so does it really matter?

I agree that it does not matter, as long as you have a reliable time tick
at SOME point during image acquisition, and know the lenght of exposure
and other time constants. For myself, the key word in that sentence is
"reliable". This is why I've been persistant in determine the exact
time tick for the Mark III images. If the FITS header is explict about
its time reference - a remark record may be necessary - when it occurs
is at best a standards issue and at worst a software problem. Given
that we are interpreting image data automatically, we DO need to be
consistent in whatever we define or so explict that a program can determine
it.

Chris, what is the time tick referenced to in your Mark III Linux driver?
Start of exposure, start of A/D conversion, and of what scan line?

*>>   I prefer Chris' idea of including engineering
*>> data as part of the fits header ...
*>
*>>   On my own reductions, I keep pertinent exposure information
*>> (field name, exposure time, time/date, filter, etc.) in
*>> the header of all starlists, but do not keep engineering
*>> data.  You rarely look at that except when looking at the
*>> original images.
*>
*>I was thinking that as we intend to likely throw away the
*>image files we would want to carry the engineering data forward
*>in the derived files and database.

For instance, Chris wrote a utility to time-stamp each scan row in the
Mark III, because of some drift of the scan clock. While that data need
not be included in the reduced star lists - how could it? - what may
be useful would be to include in the FITS header the variation in
scan rate, say an average with standard deviation. This and other methods
may be a way to "include" engineering data in our processed partial results:
some kind of reduction that is relevant and specific to the data.

The only other engineering data that would fit this scheme would be
the dark covered pixels: again an average and a st. dev., maybe some
comparision to average background too (dark plus sky background
according to some standard). Work on the current run of Mark IV images
would contribute to defining these items and their reduction. It will
probably take a round or two of image production to resolve this.

Herb JOhnson

Herbert R. Johnson              http://pluto.njcc.com/~hjohnson
hjohnson@pluto.njcc.com         voice 609-771-1503, New Jersey USA
             amateur astronomer and astro-tour guide
     S-100 computer restoration, parts, manuals as "Dr. S-100"
   rebuilder/reseller of compact Macs for your computing pleasure