Subject: File-type extension code?

From: dwells at azalea.cx.nrao.edu (Don Wells)
Date: Fri, 26 Jun 1992 22:05:39 GMT

Should we agree on a recommended file type extension code for the
names of FITS files written on disks? 

If the answer is "yes", then I suggest that 'fit' would be a good
choice (i.e., the recommended practice would be that FITS files should
have names of the form *.fit).
--

Donald C. Wells             Associate Scientist        dwells at nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N

---

From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Date: Fri, 26 Jun 1992 22:29:00 GMT

In article <DWELLS.92Jun26170539 at azalea.cx.nrao.edu>, dwells at azalea.cx.nrao.edu (Don Wells) writes...
>have names of the form *.fit).

I personally use '.fits'.  Data I get from Big Bear Solar Observatory has the
extension '.fts'.  Data I get off of tape, I put whatever extension onto the
name I want.

I guess I don't feel too strongly about it.  The only place I can see it being
important is when data is ftp'd from some remote location (like my Big Bear
example above).  Although I haven't done it so far, I could pretty easily write
a reader that would try to open a file with the extensions '.fits', '.fit' and
'.fts' in turn, or to list all files with those three extensions.  Or, if I
wanted to, I could simply rename the file.

Bill Thompson

---

From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
Date: Sat, 27 Jun 1992 01:15:04 GMT

>have names of the form *.fit).

I strongly support ".fit" mainly because the CD-ROMs we have produced at the
Astronomical Data Center use this convention and we plan to continue with the
same practice.  Readers should remember that ISO 9660 Level 1 limits
filenames to MS-DOS-like 8.3, e.g. FILENAME.EXT as a maximum.  I have found
that in FTP downloads to MS-DOS machines, files with a ".fits" extension, the
local ftp program truncates the extension to ".fit".  Given the practice in 
standards of "sinking to the lowest common denominator", an extension of ".fit" 
is the most portable.

--
-- Lee E. Brotzman                    Internet:  leb at hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB at SCFMVS
-- NASA Goddard Space Flight Center

---

From: dbriggs at zia.aoc.nrao.edu (Daniel Briggs)
Date: 27 Jun 92 02:01:20 GMT

In article <DWELLS.92Jun26170539 at azalea.cx.nrao.edu>
>have names of the form *.fit).

It's probably a good idea, in the cases where the data format is made
explicit in an extension.  The local R&D imaging package, SDE, has been
using disk fits as the default data storage format for several years.
It knows to recognize *.FTS as a fits file and *.SDE as a machine dependent
memory image.  Neither of the above is the default format, which is again
FITS.  I suspect that I'm not alone in often encoding quite a lot of
information in the filename, like 3C84-X-BIG-CLN.XFR.20  An additional
recommended or manditory field on the end of every such name quickly
becomes a nuisance.  (Not that such things are easy to type in the first
place!)

However, in the case where a FITS file is stored as *.<FITS-identifier>, I
vote for the characters 'FTS'.  Try to say it, and you'll see that it is
really much more mnemonic than 'FIT'.  Sad to say, we should probably stick
to 3 character extensions, for the usual lowest common denominator reasons.
Would we be specifying a case for the characters?  If we have to pick one
or the other, 'FTS' is probably a better move than 'fts'.

-- 
| Daniel Briggs  (dbriggs at nrao.edu)                      |        USPA B-14993
| New Mexico Tech / National Radio Astronomy Observatory |            DoD #387
| P.O. Box O / Socorro, NM 87801   (505) 835-7391        |
Support the League for Programming Freedom  (info from league at prep.ai.mit.edu)

---

From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock)
Date: Sat, 27 Jun 1992 18:17:35 GMT

>names of FITS files written on disks? 

A resounding "yes".

>have names of the form *.fit).

Agreed - it's preferable to 'fts' for reasons of truncation, as Lee
points out.  Let's go for it...
--
----------------------------------------------------------------------------
-- Archie Warnock                   Internet:  warnock at hypatia.gsfc.nasa.gov
-- Hughes STX                       "Unix --- JCL For The 90s"
-- NASA/GSFC

---

From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Date: Sat, 27 Jun 1992 23:56:00 GMT

In article <1992Jun27.020120.670 at zia.aoc.nrao.edu>, dbriggs at zia.aoc.nrao.edu (Daniel Briggs) writes...
>or the other, 'FTS' is probably a better move than 'fts'.

When I ftp a file from a VAX machine (which is case insensitive) to a UNIX
machine, the filename always comes over as lowercase.  For that reason '.fts'
is much better than '.FTS'.

Bill Thompson

---

From: Lucio Chiappetti - IFCTR Milano<lucio at ifctr.mi.cnr.it>
Date: Mon, 29 Jun 1992 15:47:02 GMT

>Donald C. Wells Associate Scientist dwells at nrao.edu writes :

>Should we agree on a recommended file type extension code for the
                      -----------
>choice (i.e., the recommended practice would be that FITS files should
                   -----------
>have names of the form *.fit).

  My *personal* inclination would favour '.fits' more than '.fit' (in some
  context one might think this is reserved or used by some fitting programs),
  however I appreciate the issue of "minimum compatibility" which may indi-
  cate usage of 3-char extensions (BUT do we really think realistic to use
  FITS files on PCs ? Are there any other systems nowadays requiring this
  limitation ?). In general I like "verbose" filetypes ('image' and not 'img',
  'spectrum' and not 'spx', 'rate' and not 'rat' etc.)

  However I believe there is one more important issue, which makes me
  underline the word "recommended" above.
  That is, will the major packages (IRAF, MIDAS, IDL ... should add AIPS,
  but we do not use it at this site, sorry Don) comply with the recom-
  mendation ?

  One of the major uses of keeping FITS data on disk should be to store
  them in a machine and package independent format (suppose you want to
  interchange data between IRAF and MIDAS, or between a Sun and a DECstation
  sharing NFS disks).

  Of course another one could be to retrieve stuff from ftp archives, in
  which case a self-documenting extension certainly helps.

  Coming back to the major package issue, at the moment they are still
  excessively linked to the mag tape model (this does NOT imply that I
  favour using FITS other than a 'T'ransport format,I am just talking of
  the names) :

  e.g. IRAF (unless one does it file by file) saves FITS files on disk
       as xxxx001 xxxx002 xxxx003 (with a 3-figure ordinal and NO extension)
       MIDAS instead uses xxxx0001.mt xxxx0002.mt etc. (with a 4-figure
       ordinal and .mt extension)

  IF they would save their files with the same name they have in the native
  format (e.g. pinco.imh pinco.pix pinco.bdf etc.) and a standard FITS
  filetype (pinco.fits or pinco.fit or pinco.fts) that would save the user
  to do the renaming all the times (or similar workarounds)

  I believe that, until the major packages will support the recommendation,
  it will remain just that. In this respect I have no strong preference for
  any of the proposed names.

-----------------------------------------------------------------------------
       A member of  G.ASS : Group for Astronomical Software Support
-----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR Milano        |         U N I C U I Q U E
via Bassini 15 - I-20133 Milano - Italy    |          System  Manager
Internet: LUCIO at IFCTR.MI.CNR.IT            |           FORTUNAE SUAE
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |
Bitnet:   EXOSAT at IMISIAM                   |
-----------------------------------------------------------------------------
Acknowledge-To: <EXOSAT at IMISIAM>

---

From: dwells at azalea.cx.nrao.edu (Don Wells)
Date: Mon, 29 Jun 1992 13:39:07 GMT

In article <9206290904.AA06192 at fits> Lucio Chiappetti - IFCTR
Milano<lucio at ifctr.mi.cnr.it> writes:

 LC> "... My *personal* inclination would favour '.fits' more than
 LC> '.fit' (in some context one might think this is reserved or used
 LC> by some fitting programs), however I appreciate the issue of
 LC> "minimum compatibility" which may indi- cate usage of 3-char
 LC> extensions (BUT do we really think realistic to use FITS files on
 LC> PCs ? Are there any other systems nowadays requiring this
 LC> limitation ?).  

FITS files are used on PCs by many people. Also, CD-ROMs also use the
DOS caseless 8+3 naming convention.

 LC> "... will the major packages (IRAF, MIDAS, IDL ... AIPS.. comply
 LC> with the recom- mendation ?"..
 LC> IF they would save their files with the same name they have in
 LC> the native format (e.g. pinco.imh pinco.pix pinco.bdf etc.) and a
 LC> standard FITS filetype (pinco.fits or pinco.fit or pinco.fts)
 LC> that would save the user to do the renaming all the times (or
 LC> similar workarounds)  

This is exactly my motivation for asking the question. I noticed in a
recent newsletter that the ST-SDAS team have added support for FITS as
an *internal* (in addition to interchange) disk format, with names
*.fit.  I expect that this will start a trend. It would be convenient
if the various packages could share an internal file format as well as
an interchange format; a naming convention would facilitate this.
--

---

From: ahenden at magnus.acs.ohio-state.edu (Arne A Henden)
Date: Mon, 29 Jun 1992 13:34:41 GMT

> warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) writes:
  For those cases where the file type must be specified, I'd prefer
.fits for those systems that can handle it and .fit for the lowest
common denominator (and lower case for Bill's reason).  The 8x3 format
of PCs and ISO9660 is really limiting in this day and age, and quite
often my files end up looking like 891206.005 for raw data, but stored
in fits format.  Therefore, I'd stess that the .fit/.fits extension
is a *recommended* extension only and not a required one.  You can
always build a reader that has a set of default file extensions in
use by your organization.

---

From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Date: Mon, 29 Jun 1992 14:38:00 GMT

In article <9206290904.AA06192 at fits>, lucio at ifctr.mi.cnr.it (Lucio Chiappetti -
IFCTR Milano) writes...

>  to do the renaming all the times (or similar workarounds)

I would like to point out that IDL does do exactly this.  The FITS tape reader
we have will allow the user to specify a keyword which contains the filename.
Then, for each file it reads, it will check the header for this keyword.

It used to be that the IDL FITS tape reader that we had converted the file to
SDAS format when it wrote it to disk.  However, we now have a reader which
leaves it a FITS file--and it automatically puts on the extension '.fits'.

Bill Thompson

---

From: zarate at scivax.stsci.edu
Date: Mon, 29 Jun 1992 16:33:57 GMT

In article <DWELLS.92Jun26170539 at azalea.cx.nrao.edu>, dwells at azalea.cx.nrao.edu
(Don Wells) writes...

> have names of the form *.fit).

I have developed a library under IRAF to access FITS files by any
IRAF tasks and so far the default file type extension is ".fit". So 
I cannot agree more with this recommended practice for FITS on disk.

But I must say that having one extension is somewhat restrictive and
sometimes impossible to applied. For example here at the Institute we
generate data sets with filenames that differ only on the extension
(3 characters); for example "z0ad010ar.c3h". One alternative in replacing
"c3h" for "fit" is to apppend it to the original name, like
"z0ad010ar.c3h.fit".

To avoid the previous unwanted filename; a more general FITS file type 
extension is to have "??f" were "?" is any character.

I would like to agree on a minimum number of possible FITS extension
that any FITS reader can handle as defaults.

Nelson Zarate   (zarate at stsci.edu)
Space Telescope Science Institute
Baltimore, Maryland 21218
(410) 516-8697

---

From: pence at heawk1.gsfc.nasa.gov ( William Pence)
Date: Mon, 29 Jun 1992 15:47:19 GMT

Having read the various reponses to the suggested file type extension code,
I would vote for using .fits, (truncated to .fit on machines that only
support 3 letter extensions).  I fully agree with one of the posters that this should
only be a recommendation, and not a requirement.  We have recently issued
many fits files on CDROM with the 8.3 file name restriction, where we
had to use the extension characters to uniquely identify the file;
it was too wasteful of filename space to name all the files .fit.

-Bill Pence

---

From: Lucio Chiappetti - IFCTR Milano<lucio at ifctr.mi.cnr.it>
Date: Mon, 29 Jun 1992 23:48:25 GMT

>Nelson Zarate   (zarate at stsci.edu) writes
>

 Names containing more than one dot in the full filename should be avoided.
 Any non-Unix operating system will complain.
 One possibility (ussed quite frequently by various pieces of s/w) is to
 replace the dots with underscores (but the last, new one), e.g.
 z0ad010ar_c3h.fit

---

From: tody at noao.edu (Doug Tody NOAO/IRAF)
Date: Mon, 29 Jun 1992 18:26:42 GMT

As Nelson, Don and others have mentioned we are adding a FITS image kernel
to IRAF - this will allow FITS files on disk or CD-ROM to be directly
accessed with IRAF image tasks.  One of the motivations for this image
kernel will be to make it easier to share images between different analysis
systems (IRAF and AIPS, IDL, MIDAS etc.).  It will also be nice to be able
to directly browse FITS archives such as CD-ROMs, without having to convert
the image to a different format.

I agree that, particularly for data sharing, it would be nice to be able
to agree upon a standard file extension.  Reviewing the situation with IRAF
I find that we have been using ".fits".  Files with the extension ".fits"
can be included in IRAF directory trees and will be treated as exportable,
machine independent files by IRAF programs like rmbin, wtar, "mkpkg <arch>"
and so on.

The current IRAF image kernel interface (IKI) supports file extensions of
only three characters or less, which is probably why Nelson used ".fit" in
his development version of the FITS image kernel.  This three character
limit can easily be changed however, it is internal to the interface and the
limit exists only because of the set of supported disk image formats in
existence at the time IKI was initially developed.  We can change this when
the FITS image kernel is integrated into IRAF.

As Bill Pence mentions CD-ROMs have been written which contain FITS files
with no file extension, due to limitations on file names imposed by the ISO
9660 standard, which is DOS oriented (recently I heard of something called
the Rock Ridge extensions which addresses this problem, but I think it may
only be for CD-ROMS meant to be read on UNIX or other non-DOS systems).  If
a file extension were used on such a CD-ROM it would have to be limited to
three characters.  It appears that we cannot count on the file extension to
specify the file type if we are trying to read data written externally.

Given our interest in archival data and CD-ROMS I think there is some
justification for the ".fit" extension, however I suspect that the DOS and
CD-ROM problem is going to cause problems no matter what we do.  For data
sharing using FITS-on-disk the most natural file extension is probably
".fits", and this is what IRAF currently supports.  I could live with either
choice.  I don't like ".fts" (sounds like fourier transform spectrometer
data to me) and I don't like "??f" ("??h" as for SOGS data was bad enough).

Doug Tody
-- 
Doug Tody, National Optical Astronomy Observatories, Tucson AZ, 602-325-9217
UUCP: {arizona,decvax,ncar}!noao!tody  or  uunet!noao.edu!tody 
Internet: tody at noao.edu             SPAN/HEPNET: NOAO::TODY (NOAO=5355)

---

From: sla at fast.ucsc.edu (Steve Allen)
Date: 29 Jun 92 18:50:20 GMT

In article <pence.709832839 at heawk1> pence at heawk1.gsfc.nasa.gov ( William Pence) writes:
>only be a recommendation, and not a requirement.

I concur with the suggestion that ".fits" should be the *recommended* default.
However, given the differences between various filesystems and the severe
constraints imposed by some, this will have to stand as a recommendation.
I do not see this as issue as being something to get dogmatic about, and
if given the chance to vote, I would vote against the adoption of any
particular type/extension as a requirement.
_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla at helios.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me.

---

From: cflatter at nrao.edu (Chris Flatters)
Date: Mon, 29 Jun 1992 20:21:36 GMT

Since it is possible to determine whether a file its a FITS file or not by
checking for the magic string "SIMPLE =             T" at the beginning of
a file, I don't see any necessity to mandate or to recommend the use of any
particular extension for FITS files on disk.  Why not leave the choice of
file name up to the user?

	Chris Flatters
	cflatter at nrao.edu