Subject: Re: ORIGIN and CREATOR keywords

From: forveill at gag.observ-gr.fr (Thierry Forveille)
Date: Thu, 4 Nov 1993 12:30:49 +0100

BARRY M. SCHLESINGER writes:
 > In article <9310271725.AA04437 at fits.cv.nrao.edu>, forveill at gag.observ-gr.fr (Thierry Forveille) writes...
 > >My impression is that the definition of ORIGIN as the organisation writing
 > >the file dates back to days when there was to a large extent a one-to-one 
 > >mapping between institutions/telescopes and data reduction programs. With
 > >fewer packages spreading to more places, the meaning probably shifted to
 > >follow the usefull information. 
 > 
 > FITS Paper I defines ORIGIN to be "Tape writing institution."  That 
 > meaning is the one that has been intended all along. 
 > 
 > >I cannot come up with an example where
 > >the place a file was written at is relevant, rather than the program (with
 > >its control parameters if any). 
 > 
 > One usage, touched on by Lucio Chiappetti, is that when particular
 > institutions or groups have defined keywords to have particular
 > meanings, and the same keyword may be used in different ways by
 > different organizations, the ORIGIN keyword identifies whose
 > conventions are being used. 
 > 
I certainly agree that different organization may use the same keywords
with different meanings, and actually surprised this doesn't create trouble
more frequently. My point is that the tape writing institution (i.e. 
the institution owning the computer running the program, or the tape drive, 
or the disk) is irrelevant. AIPS running at STScI will produce AIPS looking
FITS with AIPS keywords, not IRAF (or STSDAS) looking FITS. Keywords are
pretty much hard-coded into writing programs in practice.

With the advent of wide area networks, the writing institution also becomes 
a rather fuzzy concept: I sometimes run on my institution's computer a 
program stored on the disk of another institution (nfs mounted on mine) and 
write the output on the disk of a third institution. Which of these should be 
considered as the "tape writing institution"?

 > >I would thus we keep ORIGIN to mean the writing program/package (and 
 > >accordingly adjust the standard) unless somebody uses it with its initial
 > >definition.
 > > 
 > 
 > We would then have a keyword with an ambiguous definition.  And we
 > can't *change* the meaning because doing so would cause existing FITS
 > files to be out of conformance.  Any existing usage of ORIGIN with a
 > meaning other than that defined in the first FITS paper is simply not
 > in conformance with standard FITS.  If we are going to have a keyword 
 > to identify the software that produced a file, it should be a new 
 > keyword; we should not redefine an existing one.
 > 
My feeling is that we already have a keyword with an ambiguous definition
anyway. One definition is printed in paper I, and a second incompatible
definition is set by the zillions of existing FITS files which use it with
the meaning of the proposed CREATOR keyword (I have yet to encounter a real
FITS file using it with the original meaning). We thus have to decide
which of these should be kept. If, as you suggest, the main objective is that 
existing FITS files should remain valid, we should change the standard 
to put it in line with common practice, unless of course somebody comes up 
with thousands of files really using the original definition.

 > >It is on the other hand unfortunately not true that the writing program is
 > >irrelevant when decoding a FITS file. FITS is mostly a grammar, and only
 > >to a very limited extent a vocabulary. It is still quite common to see
 > >images with no axis description (thus implicitely CRVALi=0,CDELTi=1,CRPIXi=0)
 > >storing the RA and Dec of the central pixel as something like RA-POINT
 > >(or RA_PNTG, RA-OBS, RA_TELES....), plus the focal scale and orientation
 > >of the pixel array. They are perfectly valid FITS files and the axis 
 > >information is there, though arguably not in a very convenient shape.
 > 
 > I would discourage the practice of using keywords other than the
 > standard keywords to express concepts for which a standard keyword
 > exists.  In the NOST User's Guide, we say, "Different keywords should
 > not be used in the place of reserved keywords to express the same
 > concepts."  FITS Paper I describes the purpose of reserving keywords
 > in FITS as "to facilitate and encourage the specification of detailed
 > intensity, coordinate, and documentary information with each image."
 > Expression of concepts in ways other than that defined in the standard
 > complicates the task of the reader, defeating the purpose of
 > standardization.  As Wells, Greisen and Harten noted in the first FITS
 > paper, "... we will all have to be careful to avoid compromising this
 > tool by basic departures from the basic FITS standard. 
 > 
I certainly agree with this statement and hate patching a FITS reader to decode
lousy coordinate information, but we sometimes have to live with existing 
files. Once major packages like IHAP did produce truck loads of 9 track 
tapes with this type of coordinate information, and may still be in use at some
places.
The main point however is that different programs use different keywords
for the same information (which of course is  bad style if a reserved keyword
would fit), and that knowing the program sometimes help.

 > > 
 > >The 8 character limit as worded in the Standard does mean that a FITS reader
 > >is at present only requested to read the first 8 characters. I have fortunately
 > >never encountered any program that enforces this limitation, but I do
 > >agree that it should be suppressed as soon as feasible.
 > > 
 > 
 > The 8 character limit on values of a character keyword applies only 
 > when the information from that keyword is needed by the software to 
 > actually read the data from the file.  It does not apply to 
 > information required only for scientific interpretation of the header 
 > and data.  
 > 
As pointed out in the original mail on the 8 character limit (I cannot remember
who the author was), enforcement of the limit would wreck decoding of a 
1024x1024 (actually even 128x128) matrix in a binary table. It would have
TDIMi = '(1024,1024)' and would need at least an 11 character string
to correctly read the data. Unless of course you consider the difference 
between a 1024x1024 2D array and a 1048576 1D vector to be part of the
scientific interpretation... Given the negligible cost of a 68 byte buffer
on today's computer, I can see no reason for keeping this limitation.

	Thierry Forveille