From fitsbits-request Wed Dec 1 17:47:56 1993 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 7 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05609; Wed, 1 Dec 93 17:47:56 EST Return-Path: Message-Id: <1DEC199317193783 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <2d751a$l2u at gap.cco.caltech.edu> From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS table version numbers. Date: 1 Dec 1993 17:19 EDT In article <2d751a$l2u at gap.cco.caltech.edu>, mcs at goblin.caltech.edu (Martin Shepherd) writes... > >... one has a FITS file containing a >number of table extensions which all have the same EXTNAME name, but >some are represented as ASCII tables and others as binary tables. > >... should the EXTVER numbers be distinct regardless of the >representation of the table, or should the ASCII table versions follow >a different sequence of EXTVER numbers than the binary table versions? > >Until today my assumption had been that ASCII and binary table >extensions were effectively just specific implementations of a generic >(non-instantiable) table extension, and that regardless of the >representation, the EXTVER numbers would be distinct if the tables had >the same EXTNAME and EXTLEV values. ASCII Tables ('TABLE ') and binary tables ('BINTABLE') are separate extensions, as separate from each other as from 'IMAGE '. So an ASCII table and a binary table with the same value of EXTNAME, EXTVER, and EXTLEV are distinct extensions. That said, however, I don't think it's a good idea to have two extensions in a file with the same values of EXTNAME. It can be confusing. It's like having two different tables in a paper with the same caption. Barry Schlesinger NOST FITS Support Office From fitsbits-request Thu Dec 2 00:18:14 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["7085" "" "2" "December" "1993" "05:02:37" "GMT" "Martin Shepherd" "mcs at goblin.caltech.edu " nil "145" "Re: FITS table version numbers." "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05717; Thu, 2 Dec 93 00:18:14 EST Return-Path: Message-Id: <2djste$i8e at gap.cco.caltech.edu> Organization: California Institute of Technology, Pasadena Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!goblin!mcs References: <2d751a$l2u at gap.cco.caltech.edu> <1DEC199317193783 at nssdca.gsfc.nasa.gov> From: mcs at goblin.caltech.edu (Martin Shepherd) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS table version numbers. Date: 2 Dec 1993 05:02:37 GMT In article <1DEC199317193783 at nssdca.gsfc.nasa.gov> bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes: >In article <2d751a$l2u at gap.cco.caltech.edu>, mcs at goblin.caltech.edu (Martin Shepherd) writes... >>[Original question and most of answer omitted] > >That said, however, I don't think it's a good idea to have two >extensions in a file with the same values of EXTNAME. It can be >confusing. It's like having two different tables in a paper with the >same caption. With this in mind, would it be wise to consider extending the NOST standard to say that the values of EXTNAME, EXTVER and EXTLEV are sufficient to distinguish one extension from another, and that all extensions must be distinct to this extent? I personally feel that the particular internal representation of an extension is irrelevant for identification purposes. Is it too late to suggest changes to the standard? > Barry Schlesinger > NOST FITS Support Office Martin Shepherd (mcs at phobos.caltech.edu) From fitsbits-request Thu Dec 2 15:01:24 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07658; Thu, 2 Dec 93 15:01:24 EST Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson References: <2d751a$l2u at gap.cco.caltech.edu> <1DEC199317193783 at nssdca.gsfc.nasa.gov> From: thompson at serts.gsfc.nasa.gov (William Thompson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS table version numbers. Date: 2 Dec 93 19:26:56 GMT bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes: (stuff deleted) >That said, however, I don't think it's a good idea to have two >extensions in a file with the same values of EXTNAME. It can be >confusing. It's like having two different tables in a paper with the >same caption. I agree. Our IDL software is able to select extensions by either EXTNAME, or by it's position in the file (i.e. the first extension, second, etc.), which is crude. If one had two extensions in the file with the same EXTNAME, then there would be no way to specify which one without resorting to the brute-force method of using it's position. Bill Thompson From fitsbits-request Thu Dec 2 16:21:05 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1190" "Thu" "2" "December" "93" "16:20:45" "EST" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "24" "Re: FITS table version numbers." "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07755; Thu, 2 Dec 93 16:21:05 EST Return-Path: Message-Id: <9312022120.AA01922 at tetra.Gsfc.NASA.Gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Cc: pence at tetra.gsfc.nasa.gov Subject: Re: FITS table version numbers. Date: Thu, 2 Dec 93 16:20:45 EST > That said, however, I don't think it's a good idea to have two > extensions in a file with the same values of EXTNAME. It can be > confusing. It's like having two different tables in a paper with the > same caption. > > Barry Schlesinger > NOST FITS Support Office Related to this EXTNAME discussion, it is perhaps worth recalling that the OGIP made a proposal here recently of using a hierarchy of HDUCLASn keywords, in addition to the standard EXTNAME keyword, to provide a more flexible and detailed way of describing the contents of a particular extension or the primary array. We think the HDUCLASn keywords provide a better way for software to locate a particular extension it is looking for instead of trying to use the ill-defined EXTVER or EXTLEVEL keywords to distinquish between different extensions with identical values for the EXTNAME keyword. We have only just begun to use these HDUCLASn keywords, but we think they offer significant advantages in terms of clearly documenting what is in the extension and in distinquishing each extension from all the other extensions in the file in a way that both humans and software can easily understand. -Bill Pence From fitsbits-request Fri Dec 3 12:19:13 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2301" "" "3" "December" "1993" "11:50" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "44" "Re: FITS table version numbers." "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10227; Fri, 3 Dec 93 12:19:13 EST Return-Path: Message-Id: <3DEC199311502291 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!europa.eng.gtefsd.com!uunet!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <2d751a$l2u at gap.cco.caltech.edu> <1DEC199317193783 at nssdca.gsfc.nasa.gov> <2djste$i8e at gap.cco.caltech.edu> From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS table version numbers. Date: 3 Dec 1993 11:50 EDT In article <2djste$i8e at gap.cco.caltech.edu>, mcs at goblin.caltech.edu (Martin Shepherd) writes... >In article <1DEC199317193783 at nssdca.gsfc.nasa.gov> bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes: >> >>... I don't think it's a good idea to have two >>extensions in a file with the same values of EXTNAME. It can be >>confusing. > >With this in mind, would it be wise to consider extending the NOST >standard to say that the values of EXTNAME, EXTVER and EXTLEV are >sufficient to distinguish one extension from another, and that all >extensions must be distinct to this extent? I personally feel that the >particular internal representation of an extension is irrelevant for >identification purposes. > >Is it too late to suggest changes to the standard? > The formal answer is to say that substantive changes in the NOST Standard would have to be considered by a NOST Technical Panels. However, it should be emphasized that the NOST role in this process has been to codify the FITS standard as given in the FITS papers and other documents endorsed by the IAU, not to make the rules. The question here is the interpretation of the language in the Generalized Extensions paper, (Grosb\o l, et. al. 1988, A&A Suppl., 73, 359), "...to give unique names and version numbers to individual extensions..." The supporting discussion discusses distinguishing among different extensions of type 'TABLE ' and goes on to motivate the need for EXTVER by noting that "more than one extension of the same type and name might occur". This language suggests that extensions of different type (TABLE vs BINTABLE) but the same name would not be regarded as identical. While I cannot say conclusively what a Technical Panel would do in this case, I would note that the Panel that drafted version 1 approached similar issues by taking the position that they should be discussed in the User's Guide. Particularly in light of the note by Bill Thompson that use of identical values of EXTNAME for two extensions of different files, even of the same type, can cause problems for existing software, I would expect to recommend against such practices in the next comprehensive revision (version 4) of the User's Guide. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Mon Dec 6 11:41:54 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1553" "Mon" "06" "December" "93" "10:29:06" "UCR" "\"Marcelo Magallon Gh.\"" "MMAGALLO%UCRVM2.BITNET at uga.cc.uga.edu" nil "42" "BZERO/BSCALE question" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14842; Mon, 6 Dec 93 11:41:54 EST Return-Path: < at uga.cc.uga.edu:MMAGALLO at UCRVM2.BITNET> Message-Id: <9312061641.AA08715 at cv3.cv.nrao.edu> From: "Marcelo Magallon Gh." Sender: fitsbits-request at fits.CV.NRAO.EDU To: FITSBITS at NRAO.EDU Subject: BZERO/BSCALE question Date: Mon, 06 Dec 93 10:29:06 UCR I'm working with some FITS that are pretty funny. Firts of all, they have one extension, but no EXTEND keyword. The extension name is IMAGE-IUE They are have NAXIS=1. The BITPIX keyword is 16 for both PDA and the extension, and they use BZERO and BSCALE in order to output IEEE values. They use CDELTn and CRVALn, too. My problem is that BZERO and BSCALE keywords are present in the primary header, but not in the extension. Do I have to assume that they are the same for the extension? Marcelo Magallon Gh. Have a nice day! Astrophysics Group, University of Costa Rica. MMAGALLO at UCRVM2.UCR.AC.CR Research is what you're doing when MMAGALLO at HUETAR.CI.UCR.AC.CR you don't know what you are doing. MMAGALLO at UCRVM2.bitnet From fitsbits-request Tue Dec 7 17:02:16 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["101" "" "7" "December" "93" "21:19:29" "GMT" "William Thompson" "thompson at serts.gsfc.nasa.gov " nil "5" "Is this group archived?" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18351; Tue, 7 Dec 93 17:02:16 EST Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson From: thompson at serts.gsfc.nasa.gov (William Thompson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Is this group archived? Date: 7 Dec 93 21:19:29 GMT I'm sure this has been asked before, but is this group archived somewhere? Thank you, Bill Thompson From fitsbits-request Tue Dec 7 18:08:27 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18431; Tue, 7 Dec 93 18:08:27 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 7 Dec 1993 23:08:10 GMT From: dwells at fits.CV.NRAO.EDU (Don Wells) Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells References: Subject: Re: Is this group archived? Sender: fitsbits-request at fits.CV.NRAO.EDU In article thompson at serts.gsfc.nasa.gov (William Thompson) writes: WT> I'm sure this has been asked before, but is this group archived WT> somewhere? Yes, in directory ftp://fits.cv.nrao.edu/fits/traffic/sciastrofits/ The current contents of the directory are: -r--r--r-- 1 dwells 2234 May 31 1993 charter_sci_astro_fits.news -r--r--r-- 1 dwells 1005 May 5 1992 control.9205 -r--r--r-- 1 dwells 2035 Jul 5 17:15 readership-saf.news -r--r--r-- 1 dwells 21220 May 31 1993 result_sci_astro_fits.news lrwxrwxrwx 1 dwells 8 Dec 1 00:01 saf -> saf.9312 dr-xr-xr-x 2 dwells 512 Aug 19 09:59 saf.91 dr-xr-xr-x 2 dwells 512 May 29 1993 saf.92 -r--r--r-- 1 dwells 17377 Feb 2 1993 saf.9301 -r--r--r-- 1 dwells 67298 Apr 12 1993 saf.9302 -r--r--r-- 1 dwells 61163 Apr 12 1993 saf.9303 -r--r--r-- 1 dwells 22052 May 4 1993 saf.9304 -r--r--r-- 1 dwells 163961 May 29 1993 saf.9305 -r--r--r-- 1 dwells 143916 Jul 2 09:25 saf.9306 -r--r--r-- 1 dwells 48993 Aug 9 17:45 saf.9307 -r--r--r-- 1 dwells 139206 Sep 6 10:34 saf.9308 -r--r--r-- 1 dwells 68471 Sep 30 09:37 saf.9309 -r--r--r-- 1 dwells 82011 Nov 1 08:30 saf.9310 -r--r--r-- 1 dwells 108788 Nov 30 15:00 saf.9311 -rw-rw-rw- 1 dwells 13346 Dec 7 18:00 saf.9312 Your posting asking this question is the last message in file "saf", which is aliased to file "saf.9312". Messages for 1991 and 1992 are stored in subdirectories. The whole mass of text has been indexed, and can be searched using WAIS at the URL wais://fits.cv.nrao.edu/nrao-fits -- 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 fitsbits-request Wed Dec 8 10:01:27 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA19745; Wed, 8 Dec 93 10:01:27 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 8 Dec 1993 09:33 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <8DEC199309334071 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!malgudi.oar.net!news.ans.net!europa.eng.gtefsd.com!library.ucla.edu!agate!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <9312061641.AA08715 at cv3.cv.nrao.edu> Subject: Re: BZERO/BSCALE question Sender: fitsbits-request at fits.CV.NRAO.EDU In article <9312061641.AA08715 at cv3.cv.nrao.edu>, "Marcelo Magallon Gh." writes... >I'm working with some FITS that are pretty funny. > >Firts of all, they have one extension, but no EXTEND keyword. The extension >name is IMAGE-IUE > If the FITS files has extensions, it must have EXTEND = T in the primary header. If it does not, it is out of conformance. Remember, however, that EXTEND = T in the primary header does not require that extensions be present. The name 'IMAGE-IUE' is not registered with the IAU FITS Working Group. There is an extension 'IUEIMAGE'. There is also a question as to whether names of more than 8 characters are permissible for an extension. The NOST Definition codifies the rule as "Reading the data values in a FITS file should not require decoding any more than the first eight characters of a character string value of a keyword." This language would appear to imply that, since the type of an extension must be identified before the data can be read, than that name would have to be unique in the first 8 characters. >They are have NAXIS=1. > Conformant. The array is one dimensional. >The BITPIX keyword is 16 for both PDA and the extension, and they use >BZERO and BSCALE in order to output IEEE values. > Before the adoption of IEEE floating point, this kind of scaling was the only way to us FITS to transfer floating point physical values. >They use CDELTn and CRVALn, too. > >My problem is that BZERO and BSCALE keywords are present in the primary >header, but not in the extension. Do I have to assume that they are >the same for the extension? > No. The BZERO and BSCALE keywords apply only to the data immediately following the header, in the same HDU. BZERO and BSCALE must be defined independently for the primary data array and each extension. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Thu Dec 16 18:19:35 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09268; Thu, 16 Dec 93 18:19:35 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 16 Dec 1993 16:33 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <16DEC199316330354 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!europa.eng.gtefsd.com!paladin.american.edu!afterlife!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Subject: FITS basics and information (periodic posting) - 2/2 Sender: fitsbits-request at fits.CV.NRAO.EDU FITS basics and information, Part 2 3 Software and Sample Data 3.1 NOST All NOST software is available from the NOST ftp site. 3.1.1 FITS Product Conformance Tester The FITS Product Conformance Tester is a software package in C being developed by the NOST for validating FITS files. The available prototype validates required keywords in the primary header and, at the user's option, prints selected values from the primary data array. Because this software is still under development, it should not be run before reading the separate instructions file. 3.1.2 Header lister This program prints out all the headers in a FITS file, including the primary header and all extension headers. It does not evaluate them for errors. It is a useful tool for obtaining a quick summary of the contents of a FITS file. 3.1.3 Error Test files These files consist of several versions of the same FITS file, a valid one and several with different kinds of header errors. They are useful for testing the ability of software designed to read FITS files to cope with files that are not standard FITS or with errors in the file. Be sure to use binary transfer for ftp access of FITS test files. 3.2 FITSIO The HEASARC at Goddard Space Flight Center has developed a package of Fortran subroutines, called FITSIO. This package provides software for easily reading and writing FITS format files. FITSIO runs on most types of machines. It supports all the currently defined standard FITS extensions; it also supports the proposed IMAGE and BINTABLE extension types, as well as the conventions proposed in the BINTABLE documents. See 4.2 for information on electronic access to FITSIO and supporting documentation. 3.3 Converting FITS files to image format 3.3.1 pbm+ The Extended Portable Bitmap Toolkit (pbm+) can be used for converting many FITS files to image format. However, support is not guaranteed for all FITS files where the data are in the form of an image. In particular, there may be problems when the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2). 3.3.2 IMDISP (IBM/PC) Archie Warnock and Ron Baalke have announced release of version 7.8 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov [128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp subdirectory. It is also available (at least for the time being) through Simtel-20 [192.88.110.20] 3.3.3 ViewFITS (OS/2) Dominique Beauchamp, Universite Laval, Quebec City, has released version 0.3, rel. 2 of ViewFITS, a FITS reader for OS/2 2.1 presentation manager. It is on ftp.cdrom.com in /pub/os2/incoming, file name vf03r2.zip. This program gives the user the opportunity to display FITS images (8,16 or 32 bits, integer or float), modifying the gray shade palette, doing negation and zooming out. The program now uses bitmap instead of direct drawing to the screen, with 100x faster execution time. It is still a beta version. If you try it, report the results to beaucham at phy.ulaval.ca. 4 Summary of on-line sources 4.1 NOST The NOST maintains a file of FITS information available by anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in the directory FITS. A proposed reorganization could move the FITS material to a FITS subdirectory under a STANDARDS directory. The FITS files include copies of the current NOST standard, the Definition of FITS, in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. The only difference among the three formats is that the ASCII form lacks typeface formatting; only one need be retrieved. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. There is a PostScript copy of the current version of the User's Guide, generated by capturing the Macintosh MS Word original in PostScript format. Nearly 200 copies have been retrieved, with only one printing problem and one preview problem reported; however, because of the well-known problems in converting Macintosh Word to PostScript, universal portability cannot be guaranteed. Please notify the FITS Support Office by electronic mail of any problems. The directory also contains a modified version of this posting. An AAREADME.DOC file describes the contents of the directory. A SOFTWARE subdirectory contains the FITS Product Conformance Tester prototype, along with instructions. The instructions should be retrieved along with the software. The C software to read and list the headers of a FITS file is also in this subdirectory. Another file provides information on publicly available FITS software packages. The ERRTEST subdirectory contains the error test files described in section 3.1.1. Remember that binary transfer should always be used for FITS files. Both the SOFTWARE and ERRTEST subdirectories include AAAREADME.DOC files describing their content. 4.2 HEASARC The FITSIO package, supporting documentation, and some other software resources are available via anonymous ftp from legacy.gsfc.nasa.gov in the /software/fitsio/ directory. 4.3 NRAO The machine fits.cv.nrao.edu at the National Radio Astronomy Observatory (NRAO) contains a library of FITS-related material in the directory fits. The documents subdirectory contains a number of subdirectories. A proposals subdirectory contain proposals such as the BINTABLE Binary Tables extension proposal. A drafts subdirectory contains drafts of designs not yet submitted, for example, a proposed method for incorporating data compression under FITS. The wcs subdirectory contains a draft of the current proposal for world coordinate system conventions now under community review. Other subdirectories of the fits directory include sample fits files -- both actual data files and files specially constructed to test the ability of software to read all kinds of fits structures, some code for particular environments and pointers to other code, and an archive of Usenet postings related to FITS. This machine supports a WAIS server named nrao-fits which has an index of all of the FITS-related text files in the archive; the file nrao-fits.src is available at think.com and at ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src. There is a World Wide Web server for this FITS archive, at the URL http://fits.cv.nrao.edu, as well. (Thanks to Don Wells for this information) 4.4 HEAFITS exploder An electronic mail listserver called HEAFITS has been set up as a specialized group for discussion of High Energy Astrophysics- specific FITS issues that would not necessarily be of interest to the majority of subscribers to the existing sci.astro.fits newsgroup and fitsbits mailing list. To *subscribe* to the HEAFITS group, send the following one-line e-mail message to listserv at legacy.gsfc.nasa.gov: subscribe heafits Your Name where 'Your Name' is your actual First and Last names. Messages to the actual mailing list are sent to heafits at legacy.gsfc.nasa.gov. 5. NOST services The NOST Librarian can provide printed copies of many of the documents listed above. Printed or electronic copies of the User's Guide and the NOST Standard, for those without ftp access, are available. Because of restrictions set by the copyright holder, NOST can send copies of the four FITS papers only to non-profit organizations. The NOST can be reached as follows: (Postal) NASA/Science Office of Standards and Technology Code 633.2 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Telephone: +1-301-286-3575 7:30 a. m. - 4:30 p. m., U. S. Eastern Time If the Librarian is unavailable, a phone mail system takes the call after four rings. Please mention this posting in your request. Use the FITS office electronic mail address below for replies or questions. It is monitored by other NOST staff members when I am away from the office and provides a greater certainty of rapid response. Barry M. Schlesinger Coordinator, NASA/NSSDC NOST FITS Support Office +1-301-441-4205 fits at nssdca.gsfc.nasa.gov NCF::FITS From fitsbits-request Thu Dec 16 18:19:33 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09261; Thu, 16 Dec 93 18:19:33 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 16 Dec 1993 16:15 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <16DEC199316152704 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!usenet.ins.cwru.edu!eff!news.umbc.edu!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Subject: FITS basics and information (periodic posting) - 1/2 Sender: fitsbits-request at fits.CV.NRAO.EDU FITS basics and information, Part 1 This basic Flexible Image Transport System (FITS) information is posted and updated periodically by the NASA/Science Office of Standards and Technology (NOST) FITS Support Office to provide a brief description of FITS and information on software and documentation for the benefit of new readers and the reference of old readers. Table of Contents Part 1 1 What FITS Is and Isn't 2 FITS Documents 2.1 The FITS Papers 2.2 User's Guide 2.3 NOST Definition of FITS 2.4 Floating Point Agreement 2.5 Proposed Extensions 2.6 World Coordinates Part 2 3 Software and Sample Data 3.1 NOST 3.1.1 FITS Product Conformance Tester 3.1.2 Header lister 3.1.3 Error Test files 3.2 FITSIO 3.3 Converting FITS files to image format 3.3.1 pbm+ 3.3.2 IMDISP (IBM/PC) 3.3.3 ViewFITS (OS/2) 4 Summary of on-line sources 4.1 NOST 4.2 HEASARC 4.3 NRAO 4.4 HEAFITS exploder 5. NOST services 1 What FITS Is and Isn't FITS (Flexible Image Transport System) is a data format designed to provide a means for convenient exchange of astronomical data between installations whose standard internal formats and hardware differ. A FITS file is composed of a sequence of Header Data Units (HDUs). The header consists of keyword=value statements, which describe the format and organization of the data in the HDU and may also provide additional information, for example, about instrument status or the history of the data. The data follow, structured as the header specifies. The data section of the HDU may contain a digital image, but, except for the first, *it doesn't have to*. Other possible formats include tables and multidimensional matrices that are not images. The first HDU must contain a multidimensional matrix or no data at all; the data in subsequent HDUs, called extensions, may be of any type, consistent with certain rules. The "Image" in the name comes from the original use of the format to transport digital images, but it's not just for images any more. FITS is not principally a graphics format designed for the transfer of pictures; it does not incorporate "FITS viewers", packages for decoding the data into an image. Users must develop or obtain separate software to convert the data from the FITS file into a form that can be readily displayed. 2 FITS Documents 2.1 The FITS Papers The fundamental references on FITS are the following four papers, often referred to collectively as the "Four FITS Papers". These papers are the formal standard for FITS, endorsed by the International Astronomical Union (IAU). Wells, D. C., Greisen, E. W., and Harten, R. H., "FITS: a flexible image transport system," Astronomy and Astrophysics Supplement Series, 44, 363-370, 1981. Greisen, E. W. and Harten, R. H., "An extension of FITS for small arrays of data," Astronomy and Astrophysics Supplement Series, 44, 371-374, 1981. (NOTE: The format described in this paper has been used almost exclusively to transport radio interferometry and is likely to be replaced by other formats in the future. Writing data other than radio interferometry data using this format is not recommended.) Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., "Generalized extensions and blocking factors for FITS," Astronomy and Astrophysics Supplement Series, 73, 359-364, 1988. Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., "The FITS tables extension, Astronomy and Astrophysics Supplement Series, 73, 365-372, 1988. 2.2 User's Guide A User's Guide for FITS, commissioned by NASA Headquarters, is maintained by the NOST FITS Support Office. This Guide is intended to be a tutorial for new FITS users. In addition to presenting the rules of FITS, it provides some of the history and reasoning behind the choice of the rules, adds recommendations on good practices, and discusses current developments in FITS. The current version, 3.0, was issued in January 1993. 2.3 NOST Definition of FITS The NOST has codified FITS as endorsed by the IAU into a formal standard, eliminating some contradictions and ambiguities in the original FITS papers. This Definition of FITS was developed by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review by the astronomical community. On June 18, 1993, it was approved as a NOST Standard by an Accreditation Panel consisting of the NOST Executive Board and an astronomical community representative; this review was to confirm that the community had been given a satisfactory opportunity to review the standard and that the Technical Panel had properly considered and responded to all comments. The NOST standard has been submitted to the IAU FITS Working Group (IAUFWG) for endorsement as the international FITS standard, to replace the four FITS papers and the Floating Point Agreement (section 2.4), which are the current endorsed standard. While oversights in non-controversial areas may be rectified as a result of the review by the IAUFWG, significant changes are unlikely, because members of this committee were active in the process of reviewing the standard and their comments were given significant weight in the deliberations of the Technical Panel. 2.4 Floating Point Agreement Originally, FITS permitted only integers in the data array following the first, or primary header. The IAU has since endorsed the Floating Point Agreement, which specifies the use of IEEE-754 floating point and describes its use in FITS. The basic agreement appears verbatim in the User's Guide, and the substance is incorporated in the NOST standard. 2.5 Proposed Extensions Two new extension types, binary tables (type name BINTABLE) and images, like the data in the primary HDU but in an extension (type name IMAGE), are currently under consideration for endorsement by the IAU FITS Working Group. Printed copies of the proposals for both are available from the NOST; the description of IMAGE is available electronically from the NOST by anonymous ftp and that of BINTABLE from the National Radio Astronomy Observatory (NRAO). See section 5 for details of ftp resources. 2.6 World Coordinates A draft text of conventions for World Coordinates is currently under community review. It proposes rules for relating a FITS data array to the physical quantities the numbers represent, with detailed discussion of projections from the celestial sphere to the array plane. It is available electronically from the NRAO ftp site.