From fitsbits-request Mon Jan 2 13:03:08 1995 X-VM-Message-Order: (2 1 3 5 7 8 9 4 10 11 13 15 14 16 12 17 18 19 20 21 22 25 6 26 23 24) X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" X-VM-Labels: nil X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil X-VM-Bookmark: 26 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["739" "" " 2" "January" "1995" "18:02:56" "GMT" "Don Wells" "dwells at nrao.edu" "" "15" "Re: What is sci.astro.fits?" "^From:" nil nil "1" "1995010218:02:56" "What is sci.astro.fits?" (number " " mark " Don Wells Jan 2 15/739 " thread-indent "\"Re: What is sci.astro.fits?\"\n") "<789001006snz at alpiar.demon.co.uk>"] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02805; Mon, 2 Jan 95 13:03:08 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells References: <788623606snz at kwest.demon.co.uk> <789001006snz at alpiar.demon.co.uk> Newsgroups: sci.astro.fits From: dwells at nrao.edu (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: What is sci.astro.fits? Date: 02 Jan 1995 18:02:56 GMT FITS [Flexible Image Transport System] is the standard data interchange and archival format of the worldwide astronomy community. The Feb-1992 Call-For-Votes to create USENET newsgroup sci.astro.fits stated that it will be unmoderated, and that it ".. will provide a forum for the discussion of all topics concerning the FITS [Flexible Image Transport System] data format..". For further information about FITS, see http://fits.cv.nrao.edu/ (or ftp://fits.cv.nrao.edu/). -- Donald C. Wells Associate Scientist dwells at nrao.edu http://fits.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From fitsbits-request Tue Jan 3 09:30:51 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1089" "" " 3" "January" "1995" "08:56" "EDT" "Barry M. Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov" "<3JAN199508562575 at nssdca.gsfc.nasa.gov>" "33" "Re: What is sci.astro.fits?" "^From:" nil nil "1" "1995010312:56:00" "What is sci.astro.fits?" (number " " mark " Barry M. Schlesin Jan 3 33/1089 " thread-indent "\"Re: What is sci.astro.fits?\"\n") "<789001006snz at alpiar.demon.co.uk>"] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04783; Tue, 3 Jan 95 09:30:51 EST Return-Path: Message-Id: <3JAN199508562575 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!uwm.edu!lll-winken.llnl.gov!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <788623606snz at kwest.demon.co.uk> <789001006snz at alpiar.demon.co.uk> Newsgroups: sci.astro.fits 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: What is sci.astro.fits? Date: 3 Jan 1995 08:56 EDT In article <789001006snz at alpiar.demon.co.uk>, Ronald at alpiar.demon.co.uk writes... >In article > steckner at hookup.net "Thomas Steckner" writes: > >> >Sorry to be thick but I came across this group in my listing >> >and I can't work out what it is from the few postings? >> >-- >> >Kevin William West >> >Resident Caulkhead >> >Isle of Wight >> > >> I agree >> Me too! > >-- >Ronald Alpiar The full two-part FITS basics and information posting should have appeared at your sites shortly after December 28. It was posted with a one-month expiration. If it is gone from your site, it can be found via ftp://nssdca.gsfc.nasa.gov/fits (VAX) - prime site ftp://nssdc.gsfc.nasa.gov/pub/fits (accessible via Mosaic) a copy, not a mirror at all times, in the file basics_info.txt. And if it is already gone from your site, you might want to consult with your sysadmin about the expiration times for FAQs and other periodic informational postings. If it never appeared, let me know. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Wed Jan 4 14:06:12 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6599" "Wed" " 4" "January" "1995" "14:06:05" "-0500" "William Pence" "pence at tetra.gsfc.nasa.gov" "<199501041906.OAA02759 at tetra.gsfc.nasa.gov>" "132" "draft column naming convention" "^From:" nil nil "1" "1995010419:06:05" "draft column naming convention" (number " " mark " William Pence Jan 4 132/6599 " thread-indent "\"draft column naming convention\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA08209; Wed, 4 Jan 95 14:06:12 EST Return-Path: Message-Id: <199501041906.OAA02759 at tetra.gsfc.nasa.gov> From: 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: draft column naming convention Date: Wed, 4 Jan 1995 14:06:05 -0500 During the discussion here last month about the TSORTKEY convention for specifying how a FITS table has been sorted, another related issue was raised, having to do with naming conventions for column names in a table. In response to this, our OGIP FITS Working Group has drafted the following proposed recommendation on column names. We would welcome any comments or discussion about this. -Bill Pence, for the OFWG ---------------------------------------------------------------------------- FITS Table Column Naming Conventions DRAFT: 16 Dec 1994 It is often logical or convenient to refer to a column in a FITS table by its name as given by the TTYPEn keyword. The FITS Standard, however, does not require the TTYPEn keyword, nor does it provide unambiguous guidelines for the value of the TTYPEn keyword when it is present. In order to enforce some homogeneity within FITS tables and to provide guidelines for software that must read them, the following conventions are recommended (and required for all FITS tables produced by the HEASARC/OGIP): 1. Every column of a FITS table (either ASCII 'TABLE' or binary 'BINTABLE') must be given a unique name using the TTYPEn keyword. 2. Only upper or lower case letters, the digits from 0 to 9, and the underscore character may be used in the column name. This is similar to the restriction placed on FITS keyword names (with the exception of not allowing the hyphen character), which makes it possible to replace a column in a table with a keyword with the same name if the column values are identical in every row (the so-called 'Greenbank Convention'). Note that this specifically excludes ASCII blank characters within the name, except that non-significant trailing blanks are allowed (e.g., TTYPE1 = 'X '). In cases where the column name consists of several 'words', the words should be concatenated together or connected with the underscore character (e.g., 'Bright_Stars'). 3. While both upper and lower case may be used within a column name, the case is not significant when comparing names (e.g., 'COL_NAME', 'Col_Name', and 'col_name' are all considered the same name and are not unique). Software should be case insensitive when searching for a given column name. 4. Column names must begin with a letter, and not a digit or the underscore character. This allows the column name to be used as a variable name within processing software since many software languages do not allow a variable name to begin with a digit. This restriction also enables users or software to unambiguously refer to a column by its positional number instead of its name. The only allowed exception to this rule is in the case of standard FITS keywords whose name begins with a digit (there are none known at present), in which case these same names may be used as column names. 5. It is strongly recommended that the column names within a given table be unique within the first 8 characters. This allows the first 8 characters to be used as a unique keyword name (e.g., under the 'Greenbank Convention'), and it minimizes the overhead on software when searching a list of column names for a matching string. It is recognized, however, that this 8 character restriction can be impractical in cases where the table contains many columns or where the preferred names for the columns are dictated by some external source (e.g., in a project database that defines longer names). In these cases, column names that are only unique within up to 16 characters are allowed. 6. The column names may be up to 68 characters in length (the maximum length of a FITS string-valued keyword) as long as the first 8 (or 16) characters are unique. In general, software should always use and preserve at least the first 16 characters of the column names when processing a FITS table. Conversely, writers of FITS tables should not assume that more than the first 16 characters of the column name will be recognized or preserved by processing software. ----------------------------------------------------------------------------- (The following appendices are not part of the proposed convention, but are included here for convenience). Appendix A. For reference, the sections of the NOST Standard "Definition of FITS" that (may) pertain to the TTYPEn keyword are listed below. Section 5.3.2.1 (Fixed Format Character String Keyword Requirements): If the value is a character string, column 11 shall contain a single quote (hexadecimal code 27); the string shall follow, starting in column 12, followed by a closing single quote that should not occur before column 20 and must occur in or before column 80. 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. The character string shall be composed only of ASCII text. [ASCII text is defined to be ASCII characters hexadecimal 20-7E]. Section 8.1.2 (Reserved Keywords in ASCII Table Extensions): TTYPEn Keywords: The value field for this indexed keyword shall contain a character string, giving the name of field n. It is recommended that only letters, digits, and the underscore (hexadecimal code 5F) be used in the name. However, string comparisons with the values of TTYPEn keywords should not be case sensitive. The use of identical names for different fields should be avoided. Section A.4 (Binary Table Header): TTYPEnnn (character) gives the label for field nnn. Appendix B: For reference, the sections of the NOST "User's Guide for FITS" that (may) pertain to the TTYPEn keyword are listed below. 3.1.1 (FITS Fundamentals, the Primary HDU) The format of a fixed format value field depends upon its type: [a character string has] a beginning "'" in column 11 and an ending "'" in or after column 20 but no later than column 80, with the string in between. [...] If the reading program requires the value of the keyword to interpret the data properly, the information should be in the first eight characters. Users should name their strings accordingly. For purely descriptive material, it is not so critical to have the meaning be clear from the first eight characters, but it is still a good idea. 3.4.2. (Reserved Keywords for ASCII Tables Extension): TTYPEn (character) is the heading for field n. The recommended characters are letters digits, and underscore. Lowercase letters may be used. The hyphen is *not* recommended. While more than one field may have the same heading (value of TTYPEn), the practice is not recommended. From fitsbits-request Wed Jan 4 18:02:55 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2167" "Wed" " 4" "January" "1995" "18:02:49" "-0500" "William Pence" "pence at tetra.gsfc.nasa.gov" "<199501042302.SAA08132 at tetra.gsfc.nasa.gov>" "44" "Re: FITS checksum proposal" "^From:" nil nil "1" "1995010423:02:49" "FITS checksum proposal" (number " " mark " William Pence Jan 4 44/2167 " thread-indent "\"Re: FITS checksum proposal\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA08514; Wed, 4 Jan 95 18:02:55 EST Return-Path: Message-Id: <199501042302.SAA08132 at tetra.gsfc.nasa.gov> From: 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 checksum proposal Date: Wed, 4 Jan 1995 18:02:49 -0500 There have been no comments on the FITS CHECKSUM proposal posted here on 20 December by Rob Seaman, so before it fades away, it may be worth posting a reminder about this proposal to groups that maintain archives of FITS data, or that distribute FITS files to users, and urge them to consider adding the CHECKSUM and DATASUM keywords to their FITS files. These 2 keywords allow the recipient of the FITS file to verify the integrity of the file and ensure (within some reasonable probability) that the copied file is identical to the original. It would be easy to modify existing FITS reading programs to check for these keywords and verify the checksum values. If the computed checksums are not consistent with the keyword values then the user should be warned that the file has either been modified since the checksums were inserted, or that the file is corrupted in some way. It is not difficult to calculate the checksum from first principles, but for added convenience, the latest version of the FITSIO subroutine package (V3.7) contains 2 new subroutines for (a) computing and inserting the CHECKSUM and DATASUM keywords into any FITS HDU, and (b) verifying that the computed checksum in a FITS HDU is consistent with the checksum keywords, if they exist. The 2 new subroutines are: call ftpcks( unit, status) (Put ChecKSum) which computes and writes the 2 keywords into the opened FITS file, and call ftvcks( unit, dataok, hduok, status) (Verify ChecKSum) which looks for the 2 keywords in the opened FITS file, and if they exist, verifies the checksum value. The dataok and hduok output parameters indicate whether the checksum for the data unit alone, and the entire HDU, respectively, are correct or not. Finally, the latest version of the VERIFITS program that checks any FITS file for conformance with the FITS Standard will also verify the checksum if these keywords exist. The new versions of FITSIO and VERIFITS that support the checksum keywords will be made available via anonymous ftp on legacy.gsfc.nasa.gov in the /software/fitsio and /software/fitsio/verifits directories by the end of this week. -Bill Pence From fitsbits-request Thu Jan 5 18:54:38 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4758" "" " 5" "January" "1995" "23:54:15" "GMT" "Don Wells" "dwells at nrao.edu" "" "80" "Moved & Seconded (was Re: FITS checksum proposal)" "^From:" nil nil "1" "1995010523:54:15" "Moved & Seconded (was Re: FITS checksum proposal)" (number " " mark " Don Wells Jan 5 80/4758 " thread-indent "\"Moved & Seconded (was Re: FITS checksum proposal)\"\n") "<199501042302.SAA08132 at tetra.gsfc.nasa.gov>"] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12690; Thu, 5 Jan 95 18:54:38 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells References: <199501042302.SAA08132 at tetra.gsfc.nasa.gov> Newsgroups: sci.astro.fits From: dwells at nrao.edu (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Moved & Seconded (was Re: FITS checksum proposal) Date: 05 Jan 1995 23:54:15 GMT It appears to me that Rob Seaman's checksum idea has been independently implemented by both him and Bill Pence, and that Pence has joined Seaman in advocating this idea for general adoption by the FITS community. I therefore conclude that, in the spirit of Robert's Rules of Order, this is a motion which has been moved and seconded, and is now ready for discussion. I have placed copies of the postings by Seaman and Pence into the FITS archive as the two files ftp://fits.cv.nrao.edu/fits/documents/proposals/checksum{1,2}.news I recommend that chairpersons and members of the various regional FITS committees consider this proposal for possible adoption as a standard and/or recommended practice in the FITS community. In particular, the WGAS FITS Committee should consider the checksum proposal, because it was developed within the WGAS (North American) region. -*- Newcomers to the FITS world should know that the procedure for creating FITS standards has been deliberately designed to be slow and tedious, with multiple stages of review and multiple formal votes. We require multiple implementations with demonstrations of interoperability _before_ the formal votes. Our cumbersome protocols are necessary because we expect FITS standards to survive for _decades_. Suppose that one or more members of the WGAS FITS Committee (see ftp://fits.cv.nrao.edu/fits/documents/committees/aas_wgas_fits_committee.txt and ftp://fits.cv.nrao.edu/fits/traffic/wfc/wfc.dis) request that the Committee consider this checksum proposal. This could lead to much discussion (there is a special Email exploder for WFC deliberations), the members could produce one or more additional implementations, various refinements to the text or technical details of the proposal could be suggested and implemented, etc. Eventually the Chair of WFC will ask the Committee members to communicate by private Email if any of them object to the proposal or if for some reason they will not be ready/able to vote on the proposal during a certain specified period (usually one week). A major reason for asking this question is that the Chair wants to find out whether anyone might want to vote NO. Of course, a committee member who has objections should have voiced those objections during the discussions, and those objections should have been dealt with by the Chair and the authors of the proposal. An important goal of the FITS community is that all votes in all FITS committees should be unanimous if at all possible (so far, there has never been a NO vote in any of the FITS committees). Finally, when the WFC Chair judges that the members are all ready, the Chair calls for the vote by Email, with a deadline. If the WFC approves the proposal, the proposal will be forwarded to the IAU FITS Working Group (the control authority for the FITS standards). The IAU FWG will not consider the proposal until the other regional committees (Japanese, European) have also approved it by formal votes (in the case of the BINTABLE/Blocking/IMAGE proposals, this stage of the process took more than a year). The IAU FWG will review the proposal yet again, may make additional modifications (the regional groups may have approved slightly different proposals), may require yet more interoperability testing, etc. The successive revisions to the proposal will be placed in anonymous-FTP archives and the whole FITS community will be asked to review them and comment. Eventually, when the IAU-FWG Chair judges that consensus has been achieved, the FWG will conduct its own formal vote on the final proposal. The IAU-FWG requires YES-votes from 3/4 of the voting membership and no NO-votes for approval on first try, and a six month delay and a second 3/4 YES if any NO votes were cast (the intent is to discourage NO votes and to encourage compromise to achieve total consensus). For the BINTABLE standard, this whole process, from initial concept through prototype implementations to final standard, took about seven years. BINTABLE was an exceptional case -- proposals as simple as the checksum idea should take no more than four years. Of course, by the time the IAU-FWG completed the process for BINTABLE, some institutions had more than five years of production experience with the format, several spacecraft projects and ground-based telescopes had committed to use it for their data products, and everyone was firmly convinced that it was a good idea. Don Wells Chair, IAU FITS Working Group -- Donald C. Wells Associate Scientist dwells at nrao.edu http://fits.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From fitsbits-request Fri Jan 6 10:12:43 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2385" "" " 6" "January" "1995" "15:01:04" "GMT" "Bob Hanisch" "hanisch at stsci.edu" "<3ejlvg$4ks at marvel.stsci.edu>" "69" "WGAS meetings at Tucson AAS" "^From:" nil nil "1" "1995010615:01:04" "WGAS meetings at Tucson AAS" (number " " mark " Bob Hanisch Jan 6 69/2385 " thread-indent "\"WGAS meetings at Tucson AAS\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14633; Fri, 6 Jan 95 10:12:43 EST Return-Path: Message-Id: <3ejlvg$4ks at marvel.stsci.edu> Organization: Space Telescope Science Institute, Baltimore, MD 21218 Path: solitaire.cv.nrao.edu!iraf!stsci!hanisch Newsgroups: sci.astro.fits,alt.sci.astro.aips,adass.general From: hanisch at stsci.edu (Bob Hanisch) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: WGAS meetings at Tucson AAS Date: 6 Jan 1995 15:01:04 GMT WGAS Meetings at the January 1995 AAS Meeting Session 69: Remote Observing Tuesday 10 January 1995, 2:00 -- 3:30 pm Maricopa (Tucson Convention Center) Sponsored by the Working Group on Astronomical Software 69.01 Low Bandwidth Techniques for Remote Observing Jeff Percival (Space Astronomy Laboratory, U. Wis.) 115.04 Compression and Progressive Transmission of Astronomical Images Rick White (STScI) 69.02 Remote Observing for the Small Observatory Arne Henden (USNO-Flagstaff) 69.03 Remote Observing with Robotic Telescopes on Mt. Hopkins Greg Henry (Tennessee State University) 69.04 The MicroObservatory Net Ken Brecher (Boston U.) and P. Sadler (CfA) 69.05 Successful Operation of Remote Telescopes for Education and Research Carl Pennypacker, S. Deustua, S. Perlmutter, G. Goldhaber, and E. Arsem (Lawrence Berkeley Lab) 69.06 IUE Remote Observing System Andy Michalitsianos (NASA-GSFC LASP), R. E. Pitts, A. Groebner, and R. Arquilla (CSC - IUE Observatory) Session 115: Working Group on Astronomical Software Thursday 12 January 1995, 10:00 -- 11:30 am Maricopa (Tucson Convention Center) 115.01 Lessons Learned from Providing Internet Support for the Shoemaker-Levy 9 Observing Campaign Ann Raugh (U. Maryland) 115.02 On-Line Resources from the FITS Support Office (poster) Barry Schlesinger (Hughes STX) and D. M. Sawyer (NASA-GSFC) 115.03 The FITS Table Database for XTE Arnold Rots (USRA -- NASA-GSFC) Business Meeting o Electronic Publishing o APLett on-line demo o On-Line Preprint Services (ADASS, APS workshops) o ADASS V - Tucson, AZ, 22-25 October 1995; contact J. Barnes (NOAO), softconf at noao.edu o FITS o new chair of WGAS FITS committee o NOST committee activities o checksum proposal o hierarchical grouping convention proposal o world coordinates proposal o Other Issues -- _______________________________________________________________________________ Robert J. Hanisch Space Telescope Science Institute, hanisch at stsci.edu 3700 San Martin Drive, Baltimore, MD 21218 USA Tel. (410)338-4910 Fax. (410)338-5090 From fitsbits-request Fri Jan 6 12:02:06 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["22846" "" " 6" "January" "1995" "16:19:05" "GMT" "Don Jennings" "jennings at tcumsh.gsfc.nasa.gov" "" "433" "Reposting of Hierarchical Grouping Proposal" "^From:" nil nil "1" "1995010616:19:05" "Reposting of Hierarchical Grouping Proposal" (number " " mark " Don Jennings Jan 6 433/22846 " thread-indent "\"Reposting of Hierarchical Grouping Proposal\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14854; Fri, 6 Jan 95 12:02:06 EST Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!newsxfer.itd.umich.edu!gatech!swrinde!ihnp4.ucsd.edu!ames!newsfeed.gsfc.nasa.gov!news.gsfc.nasa.gov!jennings Newsgroups: sci.astro.fits From: jennings at tcumsh.gsfc.nasa.gov (Don Jennings) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Reposting of Hierarchical Grouping Proposal Date: 06 Jan 1995 16:19:05 GMT This is a reposting of the FITS hierarchical grouping proposal. We have had several good comments/suggestions sent to us by email that I will summarize and post at a later time (once I get permission from the authors). This proposal is also on the agenda for the up comming WGAS forum at the AAS meeting in Tucson. Latex and postscript versions of this proposal are available via anonymous ftp at ssvs.gsfc.nasa.gov in the /pub/convert directory. It is also online at http://acadia.gsfc.nasa.gov/convert/group.html Don Jennings, jennings at tcumsh.gsfc.nasa.gov ------------------------------------------------------------------------------ A Hierarchical Grouping Convention for FITS Donald G. Jennings, GSFC/HSTX William D. Pence, GSFC Michael Folk, NCSA Barry M. Schlesinger, GSFC/HSTX Proposal Draft, Revision 4 December 16, 1994 Abstract This paper describes a grouping convention for FITS that facilitates the construction of hierarchical associations of Header Data Units (HDUs). The grouping convention uses FITS table structures (ASCII or binary) to encapsulate pertinent information about the HDUs belonging to a group. Group members may reside in a single FITS file or be distributed in many FITS files; the FITS files themselves may reside on different computer systems. 1. Introduction The rules for generalized extensions in FITS (Grosbol et. al., 1988) provide for FITS formatted files containing more than one header data unit. By using combinations of ASCII tables (Harten et. al., 1988), binary tables (Cotton et. al., 1994) and image extensions (Ponz et. al., 1994) related data sets requiring different data structures may be stored in the same FITS file, each within its own HDU. Unfortunately, once the related data sets are segregated into separate HDUs the relationship between them is often lost. The FITS standard currently allows for simple hierarchical associations of HDUs within a single FITS file through use of the EXTLEVEL keyword. However, this mechanism has several major limitations. First, its use is not well defined. Different organizations may use EXTLEVEL for widely varying purposes and still not violate the FITS standard. Secondly, it does not specify a mechanism for defining distinct multiple groups of HDUs within a FITS file. Lastly, it cannot be used to associate HDUs residing in different FITS files. Except for very simple cases, FITS contains no mechanism for creating or preserving associations between HDUs or groups of HDUs. As the volume and complexity of FITS formatted data grows, the need for a recognized and versatile HDU grouping mechanism increases. Individuals can be overwhelmed trying to manage and analyze large data sets unless those sets are logically organized. Software tools also require data organization in order to access all necessary components of an observation, simulation or experimental data set. As an example of where grouping capabilities within FITS would be useful, consider the following. It is desirable to combine a set of observations from a given time period into a single FITS file for transport and archival purposes. For each observation there is an observation log, an event list, a derived image and a set of instrument calibration data; furthermore, several observations share a common set of calibration data. By using a grouping mechanism each [log, event list, image, calibration] set could be logically tagged as an associated observation group and the calibration data could be made a part of many different observation groups, thus eliminating the need to store it more than once. Software could retrieve all the information about a given observation simply by extracting those HDUs defined in the table that identifies members of the group. Also, observations of the same object from different observational periods could be combined into a group and accessed as a unit, even though the HDU sets comprising the different observations reside in separate FITS files. The following sections describe a scheme for implementing a hierarchical grouping of header data units within single and multiple FITS files. Section 2 discusses the content of table extensions used to define HDU groupings. Section 3 lists those keywords recommended for headers of group member extensions. Finally, Section 4 provides sample headers from FITS table extensions containing grouping structures. 2. Group Tables A group table, as defined in this convention, is a FITS table extension that contains a list of all the associated member HDUs in the group. Group tables may be represented by either FITS ASCII tables XTENSION= 'TABLE ' or binary tables XTENSION= 'BINTABLE', and are uniquely distinguished from other types of FITS tables by having the EXTNAME = 'GROUPING' keyword and value in the header. The other required or recommended keywords and columns in a group table are described in the following sections. There may be zero, one, or more group tables within a given FITS file. Each group table may reference any number of HDUs. The entire set of HDUs referenced in a group table, along with the group table itself, form a group . Individual HDUs referenced in a group table are said to be members of the group or group members. Groups can contain any type and mix of HDU. This includes all of the IAU-endorsed extensions as well as other extensions that conform to the requirements for generalized FITS extensions. Note that a group may also contain other groups as members, since a group table is itself a FITS extension. This feature allows for the construction of hierarchical structures of HDUs within a single FITS file or across many FITS files. 2.1 Group Member Identification Methods Group tables specify the names and locations of FITS files containing member HDUs as well as identifying members within their FITS files. The name and location of each FITS file is specified by using the World-Wide Web (Berners-Lee, 1994) Uniform Resource Identifiers, or URIs. All current and future forms of URIs, such as Uniform Resource Locators (URL) and the proposed Uniform Resource Names (URN), shall constitute valid names, although the group table must specify the type of URI being used. If the group member resides in a different FITS file but on the same computer system then partial URIs (specifically partial URLs) may be used instead of absolute URIs to specify the member's file location. If the group member resides in the same FITS file as the group table itself, then the URI field may be left blank. The location of member HDUs within FITS files may be specified in two different ways, either by reference or by absolute position. The reference identification method uses the values of the XTENSION, EXTNAME and EXTVER keywords to uniquely identify the member HDU within the FITS file. The position method uses the HDU order number to identify members, with the primary array having order value 0, the first extension order value 1, and so on. Users may choose either or both identification methods when constructing a group table. While the reference method is not invalidated by a reordering of HDU positions within FITS files, it does require that each member HDU have a unique set of (non-FITS-required) keyword values, Thus, this method may present problems for FITS files whose headers cannot be easily modified, such as FITS files on read-only media. The position identification method provides for quick ``random'' access to the member HDUs, since software does not have to sort though each extension looking for the correct set of keyword values, but will be affected if the order of member HDUs within their FITS files is changed (please note: there is nothing within the current FITS standard governing how or when HDUs may be reordered within their files). 2.2 Group Table Keywords In addition to the standard required FITS table extension keywords, the following keywords are required in the header of a group table: EXTNAME (character): This value of the FITS reserved keyword uniquely identifies that this FITS extension contains a group table. For group tables EXTNAME must have the value `GROUPING'. EXTVER (positive integer): The value of this FITS reserved keyword serves as a group ID number that uniquely distinguishes this group from any other groups that may be defined in the same FITS file. This group number may also be used in the header of each group member to identify the group(s) to which the member belongs (see section 3, GRPIDn keyword). The following keyword is strongly recommended for inclusion in the header of each group table: GRPNAME (character): This keyword contains the name associated with the group table. GRPNAME values are case-insensitive and should only contain letters, digits, and the underscore character (and not contain any embedded blank (ASCII 32) characters). 2.3 Group Table Columns The number of columns required in a group table depends on which method is used to identify the members (and recall that both methods may be used within the same group). If the members are identified by reference then the following columns are required: TTYPEn = 'MEMBER_XTENSION' -- character field: Contains the value of the XTENSION keyword from the group member's header. In the case of primary HDUs where there is no required XTENSION keyword, the value of `PRIMARY' will be used instead. Therefore, the current valid entries for this column are 'PRIMARY ', 'TABLE '+, 'BINTABLE', 'IMAGE ' or any other IAU FITS Working Group registered XTENSION value. This field may contain the FITS null value appropriate for this column type if the value is unknown (e.g., if the position identification method described below is used to identify the member location). TTYPEn = 'MEMBER_NAME' -- character field: Contains the value of the EXTNAME keyword from the group member's header. In the case of primary HDUs where the EXTNAME keyword is not defined or when the member extension has no EXTNAME keyword present, this field may contain the FITS null value appropriate for the column type. TTYPEn = 'MEMBER_VERSION' -- integer field: Contains the value of the EXTVER keyword from the group member's header. In the case of primary HDUs, or if the EXTVER keyword is not present in the member header then a value of 1 should be assumed. If members are identified by file position then the following column is required: TTYPEn = 'MEMBER_POSITION' -- integer field: Contains a group member's position within its FITS file. The file's primary header is given a position value of 0, the first extension is given a position value of 1, and so on. If for some reason a group member's `MEMBER_POSITION' value becomes invalid or undefined, then this column field should be filled with the FITS null value appropriate for the column format. If some or all of the group members reside in FITS files separate from the group table itself then the following two columns are also required: TTYPEn = 'MEMBER_LOCATION' -- character field: Contains the location of the group member's FITS file using Uniform Resource Identifiers. If the FITS file resides on the same computer system as the group table, then partial URIs may be used instead of absolute URIs, and if the group member resides in the same FITS file as the group table then the field may be filled with blanks. If the MEMBER_LOCATION value becomes unknown or invalid then this field may be filled with the FITS null value appropriate for the column type. TTYPEn = 'MEMBER_URI_TYPE' -- character field: Contains the mne-monic for the Uniform Resource Identifier type used in the corresponding MEMBER_LOCATION field. Recommended values for this column field are `URL' for the Uniform Resource Locator and `URN' for the Uniform Resource Name. As other URI types are defined their mnemonics will also become acceptable values for this field. In cases where the MEMBER_URI_TYPE is undefined (such as a null or blank MEMBER_LOCATION field value) this field may contain the FITS null value appropriate for the column type. Besides the table columns defined above, a group table may contain any number of user defined columns. Group table columns may appear in any order within the table and their TTYPEn values are not to be considered case-sensitive. 3. Keywords for Group Member Extensions No additional keywords are required for HDUs that are members of a group. This rule is to ensure that all currently existing FITS files and their constituent HDUs may all be part of this convention. There are, however, several grouping related keywords whose presence is strongly recommended in newly created headers. The description of these keywords follow. EXTNAME (character): This keyword is the FITS reserved keyword EXTNAME. Extensions that are part of groups should use this keyword to allow member identification by reference. EXTVER (integer): This keyword is the FITS reserved keyword EXTVER. Extensions that are part of groups should use this keyword in their headers to allow member identification by reference. GRPIDn (integer): A series of indexed keywords that denote the group(s) to which an HDU belongs. The value of GRPIDn is the EXTVER value of the nth group table that the HDU is a member of. In this sense, the EXTVER value of a group table defines a unique ID for the group within a FITS file. If the value of GRPIDn is negative, then the HDU is a member of a group defined in another file. In this case the absolute value of GRPIDn is the EXTVER value of the external group table, and the corresponding GRPLCn keyword holds the URI of the FITS file containing the group's table. The GRPIDn keywords (and their associated GRPLCn keywords) not only identify HDUs as members of groups, but also allow group members to ``point'' back to their group tables. Any software that might change the position or nature of the HDU would know that it was a member of a group and that the group table would require updating. GRPLCn (character): A series of indexed keywords that contain the Uniform Resource Identifiers corresponding to the GRPIDn keyword. The GRPLCn values follow the same syntax rules as those specified for the group table's MEMBER_LOCATION column (see section 2). It is unnecessary to have a GRPLCn keyword accompany a GRPIDn keyword when the value of the GRPIDn keyword is positive. 4. Example Group Table Headers The following are examples of valid group table headers that use different combinations of identification methods. Example 1: A group containing five members all of which reside in the same file as the group table. This group is itself a member of two other groups and both of those groups' tables reside in the same file as this extension. The member position identification method is used to locate member HDUs. XTENSION= 'BINTABLE' / This is a binary table BITPIX = 8 / Table contains 8-bit bytes NAXIS = 2 / Number of axis NAXIS1 = 4 / Width of table in bytes NAXIS2 = 5 / Number of member entries GCOUNT = 1 / Mandatory FITS keyword PCOUNT = 0 / Number of bytes in HEAP area TFIELDS = 1 / Number of columns in table EXTNAME = 'GROUPING' / This BINTABLE contains a group EXTVER = 3 / The ID number of this group GRPID1 = 1 / Part of group 1 GRPID2 = 2 / Part of group 2 TTYPE1 = 'MEMBER_POSITION' / Position of member within file TFORM1 = '1J' / Datatype descriptor END Example 2: A group containing 150 members, some of which reside in FITS files different from that of the group table. This group is not a member of any other group, although it is the seventh group table defined in the FITS file. All member identification methods are used. XTENSION= 'BINTABLE' / This is a binary table BITPIX = 8 / Table contains 8-bit bytes NAXIS = 2 / Number of axis NAXIS1 = 76 / Width of table in bytes NAXIS2 = 150 / Number of member entries GCOUNT = 1 / Mandatory FITS keyword PCOUNT = 0 / Number of bytes in HEAP area TFIELDS = 6 / Number of columns in table EXTNAME = 'GROUPING' / This BINTABLE contains a group EXTVER = 7 / The ID number of this group TTYPE1 = 'MEMBER_LOCATION' / URI of file containing member HDU TFORM1 = '30A ' / Datatype descriptor TTYPE2 = 'MEMBER_URI_TYPE' / URI type of MEMBER_LOCATION field TFORM2 = '3A ' / Datatype descriptor TTYPE3 = 'MEMBER_POSITION' / Position of member within file TFORM3 = '1J ' / Datatype descriptor TTYPE4 = 'MEMBER_XTENSION' / XTENSION keyword value of member TFORM4 = '8A ' / Datatype descriptor TTYPE5 = 'MEMBER_NAME' / EXTNAME keyword value of member TFORM5 = '30A ' / Datatype descriptor TTYPE6 = 'MEMBER_VERSION' / EXTVER keyword value of member TFORM6 = '1J ' / Datatype descriptor END Example 3: A group containing 17 members, some of which reside in FITS files different from that of the group table. This group is a member of six other groups, two of which are defined in FITS files on other computer systems and one that is defined in a FITS file on the same computer system. The member reference identification and member file location methods are used. Two user defined columns are also present. XTENSION= 'BINTABLE' / This is a binary table BITPIX = 8 / Table contains 8-bit bytes NAXIS = 2 / Number of axis NAXIS1 = 180 / Width of table in bytes NAXIS2 = 17 / Number of member entries GCOUNT = 1 / Mandatory FITS keyword PCOUNT = 0 / Number of bytes in HEAP area TFIELDS = 7 / Number of columns in table EXTNAME = 'GROUPING' / This BINTABLE contains a group EXTVER = 7 / The ID number of this group GRPID1 = 3 / Member of group 3 GRPID2 = 6 / Member of group 6 GRPID3 = 18 / Member of group 18 GRPID4 = -1 / Member of external group 1 GRPLC4 = 'http://fits.gsfc.nasa.gov/FITS/file1.fits' / location of COMMENT FITS file containing group GRPID5 = -5 / Member of external group 5 GRPLC5 = '/FITS/file5.fits' / Location of file containing group GRPID6 = -2 / Member of external group 2 GRPLC6 = 'http://www.noao.edu/irafdir/file2.fits' / location of COMMENT FITS file containing group TTYPE1 = 'USER_INFO_1' / A user supplied column TFORM1 = '25J ' / Datatype descriptor TTYPE2 = 'MEMBER_LOCATION' / URI of file containing member HDU TFORM2 = '30A ' / Datatype descriptor TTYPE3 = 'MEMBER_XTENSION' / XTENSION keyword value of member TFORM3 = '8A ' / Datatype descriptor TTYPE4 = 'MEMBER_NAME' / EXTNAME keyword value of member TFORM4 = '30A ' / Datatype descriptor TTYPE5 = 'USER_INFO_2' / A user supplied column TFORM5 = '5A ' / Datatype descriptor TTYPE6 = 'MEMBER_VERSION' / EXTVER keyword value of member TFORM6 = '1J ' / Datatype descriptor TTYPE7 = 'MEMBER_URI_TYPE' / URI type of MEMBER_LOCATION field TFORM7 = '3A ' / Datatype descriptor END Example 4: A group containing 82 members, some of which reside in FITS files different from that of the group table. This group is a member of three other groups, and makes use of the member position and member file location methods. One user defined column is present. Note that in this example an ASCII table (as opposed to a binary table) is used to define the group. XTENSION= 'TABLE ' / This is an ASCII table BITPIX = 8 / Table contains 8-bit ASCII characters NAXIS = 2 / Number of axis NAXIS1 = 46 / Width of table in bytes NAXIS2 = 82 / Number of member entries GCOUNT = 1 / Mandatory FITS keyword PCOUNT = 0 / Mandatory FITS keyword TFIELDS = 4 / Number of columns in table EXTNAME = 'GROUPING' / This TABLE contains a group EXTVER = 31 / The ID number of this group GRPID1 = 3 / Member of group 3 GRPID2 = 9 / Member of group 9 GRPID3 = 27 / Member of group 27 TTYPE1 = 'USER_INFO_1' / A user supplied column TFORM1 = 'E10.3 ' / Datatype descriptor TBCOL1 = 1 / Starting table column for field TTYPE2 = 'MEMBER_LOCATION' / URI of file containing member HDU TFORM2 = 'A30 ' / Datatype descriptor TBCOL2 = 11 / Starting table column for field TTYPE3 = 'MEMBER_URI_TYPE' / URI type of MEMBER_LOCATION field TFORM3 = 'A3 ' / Datatype descriptor TBCOL3 = 41 / Starting table column for field TTYPE4 = 'MEMBER_POSITION' / XTENSION keyword value of member TFORM4 = 'I3 ' / Datatype descriptor TBCOL4 = 44 / Starting table column for field END 5. Acknowledgments We gratefully acknowledge the support of the NASA Applied Information Systems Research Program, underwhich this effort is funded. 6. References Berners-Lee, Tim, 1994. ``World Wide Web Initiative'', CERN - European Particle Physics Lab. http://info.cern.ch/hypertext/WWW /TheProject.html . Cotton, W. D., Tody, D. and Pence W., 1994. ``Binary Table Extension to FITS: A Proposal'', version dated June 13, 1994, final form. NRAO FITS Archives. http://fits.cv.nrao.edu/fits/documents/standards/bintable3.ps . Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., 1988. ``Generalized extensions and blocking factors for FITS,'' Astronomy and Astrophysics Suppl., 73, 359-364. Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., 1988. ``The FITS tables extension'', Astronomy and Astrophysics Suppl., 73, 365-372. Ponz, J. D., Thompson, R. W., and Munoz, J. R., 1994. ``FITS Image Extension'' , Astronomy and Astrophysics Suppl., vol 105, pp 53-55. From fitsbits-request Fri Jan 6 17:16:03 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1772" "" " 6" "January" "1995" "16:37" "EDT" "Barry M. Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov" "<6JAN199516370470 at nssdca.gsfc.nasa.gov>" "39" "Re: draft column naming convention" "^From:" nil nil "1" "1995010620:37:00" "draft column naming convention" (number " " mark " Barry M. Schlesin Jan 6 39/1772 " thread-indent "\"Re: draft column naming convention\"\n") "<199501041906.OAA02759 at tetra.gsfc.nasa.gov>"] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA15690; Fri, 6 Jan 95 17:16:03 EST Return-Path: Message-Id: <6JAN199516370470 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!swrinde!ihnp4.ucsd.edu!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <199501041906.OAA02759 at tetra.gsfc.nasa.gov> Newsgroups: sci.astro.fits 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: draft column naming convention Date: 6 Jan 1995 16:37 EDT In article <199501041906.OAA02759 at tetra.gsfc.nasa.gov>, William Pence writes... >---------------------------------------------------------------------------- > > FITS Table Column Naming Conventions > DRAFT: 16 Dec 1994 > > ... > >5. It is strongly recommended that the column names within a given >table be unique within the first 8 characters. This allows the first 8 >characters to be used as a unique keyword name (e.g., under the >'Greenbank Convention'), and it minimizes the overhead on software when >searching a list of column names for a matching string. It is >recognized, however, that this 8 character restriction can be >impractical in cases where the table contains many columns or where the >preferred names for the columns are dictated by some external source >(e.g., in a project database that defines longer names). In these >cases, column names that are only unique within up to 16 characters are >allowed. An additional reason for keeping the first 8 characters unique lies in some history that not all readers here may be aware of. In the first FITS paper (page 366, paragraph 2) there is the statement, "... recipients of FITS tapes should be prepared to interpret the first eight characters of a string (appearing between single quotes). Originators of FITS tapes may generate longer strings, but should no (sic) expect recipients to decode more than the first eight characters...." While this statement was geared to the state of the art at the time (early 1980s), my understanding is that some data systems may require unique values for the first eight characters of the values of the TTYPEn. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Fri Jan 6 17:34:03 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1546" "Fri" " 6" "January" "1995" "17:33:57" "-0500" "William Pence" "pence at tetra.gsfc.nasa.gov" "<199501062233.RAA25134 at tetra.gsfc.nasa.gov>" "39" "FITSIO, version 3.7" "^From:" nil nil "1" "1995010622:33:57" "FITSIO, version 3.7" (number " " mark " William Pence Jan 6 39/1546 " thread-indent "\"FITSIO, version 3.7\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA15737; Fri, 6 Jan 95 17:34:03 EST Return-Path: Message-Id: <199501062233.RAA25134 at tetra.gsfc.nasa.gov> From: William Pence Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Cc: pence at tetra.gsfc.nasa.gov, ftoolsdis at ascasrv.gsfc.nasa.gov Subject: FITSIO, version 3.7 Date: Fri, 6 Jan 1995 17:33:57 -0500 New Versions of FITSIO and VERIFITS The new V3.70 release of the FITSIO and VERIFITS software is now available via anonymous ftp from legacy.gsfc.nasa.gov in the /software/fitsio and /software/fitsio/verifits directories. (It may be a couple hours before our automatic mirroring software copies the new files to these directories). New features in this release of FITSIO include: - new subroutines that compute or verify the checksum keywords, following the proposal that was posted here last month by Rob Seaman. - a completely new C interface to FITSIO written by Jim Ingham at the HEASARC. This consists of a set of C macro definitions, one for each FITSIO subroutine which replace the set of C wrapper routines in the previous release and which provide a more nature interface for C programmers. - new subroutines to compute the WCS transformation between pixel location in an image and celestial coordinates. These routines use a Fortran transcription (provided by Kent Blackburn) of the C WCS routines from Classic AIPS that Don Wells announced here last October. - Wild cards ('*' and '?') may be used when specifying a column name The new VERIFITS release contains 2 new features: - it verifies the checksum values if the CHECKSUM and DATASUM keywords are present. - it issues a warning if the table column names do not follow the NOST recommendations (e.g., unique names (within 8-characters) consisting only of letters, digits, and the underscore character). From fitsbits-request Sun Jan 15 20:16:18 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["638" "Sun" "15" "January" "1995" "17:44:21" "-0700" "Jeff Bloch" "jbloch at sstcx1.lanl.gov" "" "15" "BUNIT names for dimensionless numbers?" "^From:" nil nil "1" "1995011600:44:21" "BUNIT names for dimensionless numbers?" (number " " mark " Jeff Bloch Jan 15 15/638 " thread-indent "\"BUNIT names for dimensionless numbers?\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09247; Sun, 15 Jan 95 20:16:18 EST Return-Path: Message-Id: Organization: Los Alamos National Laboratory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!newsxfer.itd.umich.edu!gatech!ncar!newshost.lanl.gov!usenet Newsgroups: sci.astro.fits From: Jeff Bloch Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: BUNIT names for dimensionless numbers? Date: Sun, 15 Jan 1995 17:44:21 -0700 (MST) I have read over the OGIP Memo on physical unit names for the BUNIT keyword. My question is what is the preferred way unitless numbers like standard deviations, or dimensionless ratios should be labeled in the BUNIT parameter? -------------------------------------------------------------------------- Jeffrey Bloch Office: (505) 665-2568 Astrophysics and Radiation Measurements Group ALEXIS Soc: (505) 665-5975 Los Alamos National Laboratory FAX: (505) 665-4414 Group NIS-2, Mail Stop D436 e-mail: jbloch at lanl.gov Los Alamos, NM 87545 -------------------------------------------------------------------------- From fitsbits-request Mon Jan 16 20:16:59 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["616" "Tue" "17" "January" "1995" "00:48:00" "GMT" "Amy B. Sprenkle" "abs9d at galen.med.virginia.edu" "" "16" "Need a sample BITPIX=32,-32,-64 File" "^From:" nil nil "1" "1995011700:48:00" "Need a sample BITPIX=32,-32,-64 File" (number " " mark " Amy B. Sprenkle Jan 17 16/616 " thread-indent "\"Need a sample BITPIX=32,-32,-64 File\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA17642; Mon, 16 Jan 95 20:16:59 EST Return-Path: Message-Id: Organization: uva Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!murdoch!galen.med.Virginia.EDU!abs9d Newsgroups: sci.astro.fits From: abs9d at galen.med.Virginia.EDU (Amy B. Sprenkle) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Need a sample BITPIX=32,-32,-64 File Date: Tue, 17 Jan 1995 00:48:00 GMT Hi, I am an amateur astronomer who has written a FITS image viewer for windows3.1. So far, everything is works great for BITPIX = 8 or 16, but I am having a hard time finding some sample images that are in 32 bit integer, 32 bit float or 64 bit float to test my viewer. If anyone has some sample files available by ftp, please let me know. I have downloaded a few samples from the HST archive, but they are all BITPIX = 16 and you cant find search the archive for a particular format. If you know a particular image at the archive site (i.e.Dataset = W0cd0101t), this would be helpful as well. Thanks, Amy From fitsbits-request Tue Jan 17 00:28:16 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["804" "" "17" "January" "1995" "05:28:09" "GMT" "Don Wells" "dwells at nrao.edu" "" "19" "Re: Need a sample BITPIX=32,-32,-64 File" "^From:" nil nil "1" "1995011705:28:09" "Need a sample BITPIX=32,-32,-64 File" (number " " mark " Don Wells Jan 17 19/804 " thread-indent "\"Re: Need a sample BITPIX=32,-32,-64 File\"\n") ""] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA17961; Tue, 17 Jan 95 00:28:16 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells References: Newsgroups: sci.astro.fits From: dwells at nrao.edu (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Need a sample BITPIX=32,-32,-64 File Date: 17 Jan 1995 05:28:09 GMT In article abs9d at galen.med.Virginia.EDU (Amy B. Sprenkle) writes: ".. [want] sample images.. 32 bit integer, 32 bit float.. 64 bit float.." Try these test files: ftp://fits.cv.nrao.edu/fits/data/tests/pg93/tst000[3-8].fits These are ramps and waves in the three data types which you want to test. In addition, file 13 is 32-bit FP. I suggest that you also try your code on the oldest (09/13/79) 32-bit integer FITS file: ftp://fits.cv.nrao.edu/fits/data/tests/incunabula/m87-32.fits -- Donald C. Wells Associate Scientist dwells at nrao.edu http://fits.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From fitsbits-request Tue Jan 17 17:06:34 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1699" "" "17" "January" "1995" "05:47:05" "GMT" "Adam Bernstein" "adam at csi.jpl.nasa.gov" "<3fflkp$kh0 at grover.jpl.nasa.gov>" "39" "Re: Need a sample BITPIX=32,-32,-64 File" "^From:" nil nil "1" "1995011705:47:05" "Need a sample BITPIX=32,-32,-64 File" (number " " mark " Adam Bernstein Jan 17 39/1699 " thread-indent "\"Re: Need a sample BITPIX=32,-32,-64 File\"\n") ""] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA20976; Tue, 17 Jan 95 17:06:34 EST Return-Path: Message-Id: <3fflkp$kh0 at grover.jpl.nasa.gov> Organization: Jet Propulsion Laboratory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!swrinde!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!grover.jpl.nasa.gov!grover.jpl.nasa.gov!adam References: Newsgroups: sci.astro.fits From: adam at csi.jpl.nasa.gov (Adam Bernstein) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Need a sample BITPIX=32,-32,-64 File Date: 17 Jan 1995 05:47:05 GMT In article , abs9d at galen.med.Virginia.EDU (Amy B. Sprenkle) writes: |> Hi, |> |> I am an amateur astronomer who has written a FITS image |> viewer for windows3.1. So far, everything is works great for |> BITPIX = 8 or 16, but |> I am having a hard time finding some sample images that are in |> 32 bit integer, 32 bit float or 64 bit float to test my |> viewer. If anyone has some sample files available by ftp, Why not make your own? Write a little program to read in one of the images you do have in its native format, copy the data array to another array of type long int, float, or double, and write the image data back out from the new array. You'll have to change the relevant values in the header, but other than that, it seems straightforward. |> please let me know. I have downloaded a few samples from the |> HST archive, but they are all BITPIX = 16 and you cant find |> search the archive for a particular format. If you know a |> particular image at the archive site (i.e.Dataset = W0cd0101t), |> this would be helpful as well. Don't know about that -- I doubt you're going to find images stored in long formats when the CCD that's generating them is limited to a 16 bit range. |> |> Thanks, Amy Adam -- ------------------------------------------------------------------------ Adam Bernstein Phone: 818 354-9784 Jet Propulsion Lab Guidance & Control / FAX: 818 393-6105 MS 198-235 Optical Tracking Group 4800 Oak Grove Dr. adam at dragon.jpl.nasa.gov Pasadena, CA 91109 ------------------------------------------------------------------------ From fitsbits-request Wed Jan 18 14:04:53 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["931" "" "18" "January" "1995" "16:45:16" "GMT" "Bob Hanisch" "hanisch at stsci.edu" "<3fjgis$8sf at marvel.stsci.edu>" "20" "new chair of WGAS FITS Committee" "^From:" nil nil "1" "1995011816:45:16" "new chair of WGAS FITS Committee" (number " " mark " Bob Hanisch Jan 18 20/931 " thread-indent "\"new chair of WGAS FITS Committee\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24197; Wed, 18 Jan 95 14:04:53 EST Return-Path: Message-Id: <3fjgis$8sf at marvel.stsci.edu> Organization: Space Telescope Science Institute, Baltimore MD Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!math.ohio-state.edu!howland.reston.ans.net!agate!news.ucdavis.edu!csus.edu!nic-nac.CSU.net!news.Cerritos.edu!news.Arizona.EDU!CS.Arizona.EDU!noao!stsci!iris.stsci.edu!hanisch Reply-To: hanisch at stsci.edu Newsgroups: sci.astro.fits From: hanisch at stsci.edu (Bob Hanisch, ST ScI) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: new chair of WGAS FITS Committee Date: 18 Jan 1995 16:45:16 GMT I am pleased to announce that the FITS Committee of the AAS Working Group on Astronomical Software will now be chaired by Dr. Peter Teuben of the University of Maryland. Peter replaces Don Wells of NRAO, who has served ably in this role for the last 7 years (or more!). Don has recently assumed the chairmanship of the IAU FITS Committee, and asked to step down from the WGAS FITS Committee chairmanship. Peter Teuben has been active in FITS issues for many years, most recently as a member of the NASA FITS Technical Panel. Peter may be reached at teuben at astro.umd.edu. Bob Hanisch Chair, AAS Working Group on Astronomical Software (WGAS) _______________________________________________________________________________ Robert J. Hanisch Space Telescope Science Institute, hanisch at stsci.edu 3700 San Martin Drive, Baltimore, MD 21218 USA Tel. (410)338-4910 Fax. (410)338-5090 From fitsbits-request Thu Jan 19 19:14:03 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2141" "Thu" "19" "January" "1995" "19:12:10" "-0500" "Ian M. George" "GEORGE at lheavx.gsfc.nasa.gov" "<950119191210.20400265 at lheavx.gsfc.nasa.gov>" "40" "RE: BUNIT names for dimensionless numbers?" "^From:" nil nil "1" "1995012000:12:10" "BUNIT names for dimensionless numbers?" (number " " mark " Ian M. George Jan 19 40/2141 " thread-indent "\"RE: BUNIT names for dimensionless numbers?\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA28750; Thu, 19 Jan 95 19:14:03 EST Return-Path: Message-Id: <950119191210.20400265 at lheavx.gsfc.nasa.gov> From: "Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)" Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Cc: GEORGE at lheavx.gsfc.nasa.gov Subject: RE: BUNIT names for dimensionless numbers? Date: Thu, 19 Jan 1995 19:12:10 -0500 (EST) On 1995 Jan 15, Jeff Bloch writes: > I have read over the OGIP Memo on physical unit names for the BUNIT > keyword. My question is what is the preferred way unitless > numbers like standard deviations, or dimensionless ratios should be > labeled in the BUNIT parameter? ... As Jeff correctly points out, the memo (OGIP/93-001) concerning the OGIP-approved character strings used to specify physical units (currently) does not mention what to do in cases where the physical quantities are dimensionless. ... In such cases, I believe most OGIP-produced files are currently using a "blank" character string (ie padded with spaces) as the keyword value. However, I admit that this may not be the best choice since it is ambiguous as to whether the associated physical values really are dimensionless, or whether the creator (human or s/w) simply forgot to construct & fill in the appropriate string. ... To this end, I would be interested in getting feedback on the following proposed addendum to the current memo: | | | a) - If the physical quantity is dimensionless, | | then the string 'unitless' be used | | b) - If the units of the physical quantity are unknown, | | then the string 'unknown' be used | | | | In both cases, the strings should be considered case-sensitive | | | | A "unit-string" consisting entirely of spaces should also be | | considered to imply that the associated physical quality is | | dimensionless. | | | ... Please post any comments to this newsgroup asap. Finally I'd like to emphasise that this is personal response to the question, and has not yet been discussed by the OGIP FITS Working Group. Regards Ian M George HEASARC From fitsbits-request Fri Jan 20 10:55:41 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1806" "" "20" "January" "1995" "15:55:33" "GMT" "Bill Cotton" "bcotton at nrao.edu" "" "42" "FITSview (0.4.0) for MS Windows Available" "^From:" nil nil "1" "1995012015:55:33" "FITSview (0.4.0) for MS Windows Available" (number " " mark " Bill Cotton Jan 20 42/1806 " thread-indent "\"FITSview (0.4.0) for MS Windows Available\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01271; Fri, 20 Jan 95 10:55:41 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells Newsgroups: sci.astro.fits,sci.astro.amateur,sci.astro,alt.sci.astro.aips From: bcotton at nrao.edu (Bill Cotton) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITSview (0.4.0) for MS Windows Available Date: 20 Jan 1995 15:55:33 GMT FITSview (0.4.0) for MS Windows 20 January 1995 This is to announce the availability of an updated version of the beta release of FITSview for MS Windows. This release includes the new features of optionally loading an image upside down and logging selected or fitted pixel positions in a text file. Many small bugs were fixed and the program was translated from c++ to c to improve its reliability. This is a FITS image viewer for Windows which features manipulation of the display (brightness, contrast, pseudo color), zoom and scroll, blinking images for comparison, displaying 3-D images as a "movie", and determining the celestial position and brightness of features in the image. Celestial positions are determined using world coordinate projections (WCS). All defined FITS data types are supported (8, 16, 32 bit integers and 32 and 64 bit IEEE), as are blanked pixels. Two and three dimensional simple FITS images are supported. FITSview runs on Windows 3.1 or later and uses any multicolor (or multiple gray level) display although 256 color displays give the best results. Extensive online documentation is included. FITSview for Windows is available at no cost via anonymous ftp as the two files: ftp://fits.cv.nrao.edu/fits/os-support/ms-windows/fitsview/fitsv040.txt ftp://fits.cv.nrao.edu/fits/os-support/ms-windows/fitsview/fitsv040.zip Installation is described in file fitsv040.txt. Implementations under X-windows and MacIntosh are under consideration. bcotton at nrao.edu -- Donald C. Wells Associate Scientist dwells at nrao.edu http://fits.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From fitsbits-request Fri Jan 20 23:20:04 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["365" "" "21" "January" "1995" "04:03:02" "GMT" "Astronomy Ireland" "ai at iol.ie" "<3fq11m$mrc at barnacle.iol.ie>" "9" "FAQ location?" "^From:" nil nil "1" "1995012104:03:02" "FAQ location?" (number " " mark " Astronomy Ireland Jan 21 9/365 " thread-indent "\"FAQ location?\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA04163; Fri, 20 Jan 95 23:20:04 EST Return-Path: Message-Id: <3fq11m$mrc at barnacle.iol.ie> Organization: Ireland On-Line Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!swrinde!pipex!iol!ai Newsgroups: sci.astro.fits From: ai at iol.ie (Astronomy Ireland) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: FAQ location? Date: 21 Jan 1995 04:03:02 GMT Is the FITS FAQ available somewhere by ftp etc.? -- David Moore BSc FRAS, Editor of "Astronomy & Space" magazine. (ai at iol.ie) Chairman, Astronomy Ireland, P.O.Box 2888, Dublin 1. Tel: +353-1-459 8883. Fax: +353-1-459 9933. ________Irish News: 1550-111-442 (calls cost upto 58p/minute)________ _____U.K.: 0891-88-1950 (39p/min cheap, 49p/min all other times)_____ From fitsbits-request Wed Jan 25 10:01:27 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["547" "" "25" "January" "1995" "09:29" "EDT" "Barry M. Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov" "<25JAN199509292299 at nssdca.gsfc.nasa.gov>" "19" "Re: FAQ location?" "^From:" nil nil "1" "1995012513:29:00" "FAQ location?" (number " " mark " Barry M. Schlesin Jan 25 19/547 " thread-indent "\"Re: FAQ location?\"\n") "<3fq11m$mrc at barnacle.iol.ie>"] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA21559; Wed, 25 Jan 95 10:01:27 EST Return-Path: Message-Id: <25JAN199509292299 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!math.ohio-state.edu!howland.reston.ans.net!news.sprintlink.net!hookup!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <3fq11m$mrc at barnacle.iol.ie> Newsgroups: sci.astro.fits 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: FAQ location? Date: 25 Jan 1995 09:29 EDT In article <3fq11m$mrc at barnacle.iol.ie>, ai at iol.ie (Astronomy Ireland) writes... >Is the FITS FAQ available somewhere by ftp etc.? > >-- >David Moore BSc FRAS, Editor of "Astronomy & Space" magazine. >(ai at iol.ie) Chairman, Astronomy Ireland, P.O.Box 2888, Dublin 1. It is available from ftp://nssdca.gsfc.nasa.gov/fits/basics_info.txt Since NSSDCA is a VAX, Mosaic users should use ftp://nssdc.gsfc.nasa.gov/pub/fits/basics_info.txt A new version should be posted later this week. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Fri Jan 27 12:19:09 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["12554" "" "27" "January" "1995" "11:19" "EDT" "Barry M. Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov" "<27JAN199511191422 at nssdca.gsfc.nasa.gov>" "272" "FITS basics and information (periodic posting) - 1/2" "^From:" nil nil "1" "1995012715:19:00" "FITS basics and information (periodic posting) - 1/2" (number " " mark " Barry M. Schlesin Jan 27 272/12554 " thread-indent "\"FITS basics and information (periodic posting) - 1/2\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA01536; Fri, 27 Jan 95 12:19:09 EST Return-Path: Message-Id: <27JAN199511191422 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!portal.gmu.edu!europa.eng.gtefsd.com!gatech!howland.reston.ans.net!agate!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Newsgroups: sci.astro.fits,sci.data.formats 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: FITS basics and information (periodic posting) - 1/2 Date: 27 Jan 1995 11:19 EDT FITS basics and information, Part 1 Preface 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, under the overall supervision of Donald M. Sawyer (GSFC/NSSDC). It provides a brief description of FITS and information on software and documentation, discusses some topics that have appeared on sci.astro.fits, and answers some questions on FITS frequently received by the FITS Support Office. Changes from Previous Month o Imminence of action on units revision to NOST Definition o New draft of BINTABLE; where to find it o New section on proposed conventions o Discussion of grouping proposal o Discussion of checksum proposal o New version of FITSIO discussed o Updated FITSview information o Relocation of material from hypatia.gsfc.nasa.gov to nssdc.gsfc.nasa.gov Table of Contents Part 1 Preface Changes from Previous Month Table of Contents 1 Introduction 1.1 What FITS Is 1.2 How FITS Evolves 1.3 What FITS Is Not 2 FITS Documents 2.1 The FITS Papers 2.2 Binary Tables 2.3 User's Guide 2.4 NOST Definition of FITS 2.4.1 Version 1.0 2.4.2 Proposed Revision on Units Specification 2.5 Floating Point Agreement 2.6 World Coordinates 2.7 Proposed Conventions Part 2 3 Software and Sample Data 3.1 NOST 3.1.1 FITS Product Conformance Tester with Instructions 3.1.2 Header Lister 3.1.3 Error Test Files 3.2 HEASARC 3.2.1 FITSIO 3.2.2 FTOOLS 3.2.3 VERIFITS 3.3 ADC FITS Tables Browser 3.4 Converting FITS Files to Image Format 3.4.1 Major Astronomical Imaging Packages 3.4.2 pbm+ 3.4.3 IMDISP (IBM/PC) 3.4.4 Applications with xv 3.0 3.4.5 ViewFITS (OS/2) 3.4.6 FITS and the Macintosh 3.4.7 FITSview (Windows) 3.5 World Coordinates 4 On-line Information Sources 4.1 NOST 4.2 HEASARC 4.3 NRAO 4.4 HEAFITS exploder 5. Contributors (non-exhaustive list) 6. NOST services 1 Introduction 1.1 What FITS Is 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 supports 5 data types in primary or IMAGE data arrays: 8-bit unsigned binary integers, 16-bit twos-complement signed binary integers, 32-bit twos-complement signed binary integers, 32-bit IEEE-754 standard floating point numbers, and 64-bit IEEE-754 floating point numbers. For signed integers, the byte that includes the sign bit is first and the byte that has the 1-bit as its least significant bit is last. FITS does not support the 16-bit unsigned integer data type generated by many analog/digital converters. Conforming FITS files can be produced from such data by subtracting 32768_decimal from the converter output before writing to the file, while setting the BZERO keyword in the FITS header equal to 32768 and the BSCALE keyword equal to 1. A FITS reader will then add 32768 to the value in the file, restoring the original value, before interpreting it. Whether a 16-bit unsigned data type should be added, and if so, how, is controversial and under discussion, especially in sci.astro.fits. 1.2 How FITS Evolves The international authority for FITS is the International Astronomical Union (IAU) FITS Working Group (IAUFWG), which was given authority over FITS matters by the 1988 IAU General Assembly. This Group is associated with the Working Group on Astronomical Data. The current chair is D. Wells (NRAO) and the vice-chair is E. Raimond (NFRA). When the developer of a data structure finds that it does not fit well into an existing standard FITS format, a new design may be developed. No change can be made that would cause existing FITS files to be out of conformance -- the "once FITS, always FITS" rule. A unique name for any new extension type must be registered with the IAU FITS Working Group, optionally through the NOST FITS Support Office. After community discussion, most of which will be electronic, a formal proposal is distributed. This proposal is discussed by the community and may be further modified. Tests are run using the new format to confirm that it can be practically used for data transport. If the astronomical community reaches a consensus that the proposal should be adopted as standard FITS, and if successful data transfer using the proposed extension can be demonstrated, it is submitted for ratification to the regional committees--the European FITS Committee, the Japanese FITS Committee, and the American Astronomical Society Working Group on Astronomical Software (WGAS) FITS Committee. Following approval by the regional committees, it is submitted to the IAU FITS Working Group. Approval by the Working Group establishes it as a standard extension. 1.3 What FITS Is Not 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. There is no standard package for all applications; section 3.4 discusses some possibilities. 2 FITS Documents 2.1 Published Papers The fundamental references on FITS are the following five papers. The first four have often been referred to collectively as the "Four FITS Papers". These papers, along with the Floating Point Agreement (section 2.5) and the binary tables definition (section 2.2), are the formal standard for FITS, endorsed by the 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. Ponz, J. D., Thompson, R. W., and Munoz, J. R., "The FITS Image Extension," Astronomy and Astrophysics Supplement Series, 105, 53-55, 1994. 2.2 Binary Tables On June 15, 1994, the IAU FITS Working Group announced the acceptance of BINTABLE, the binary table extension, as a standard extension. A draft of the description of the extension, to be submitted for publication to Astronomy and Astrophysics, is available at the NRAO site (see section 4.3, in part 2). 2.3 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.1, was issued in May 1994. 2.4 NOST Definition of FITS 2.4.1 Version 1.0 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, version 1.0, 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 IAUFWG for endorsement as the international FITS standard, to replace the endorsed standard -- originally the four FITS papers, to which the Floating Point Agreement (section 2.4), and now the IMAGE and binary table extensions and the physical blocking conventions have been added. 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.2 Proposed Revision on Units Specification A new Technical Panel has been formed, primarily to draft a revised NOST definition of FITS incorporating IMAGE, BINTABLE, and the blocking agreement, but also to rectify any oversights or omissions that may be brought to its attention by the community. Dr. Hanisch, the chair of the panel that developed version 1.0 of the Definition of FITS, is chairing this new panel. In response to community comments on the version 1.0 treatment, the panel developed and released text covering requirements and recommendations on units to be used in FITS files. The Technical Panel is now reviewing community comments received over a one-month review period. The draft text is available from the NOST FTP site (section 4.1) in the file units_revision.txt, in flat ASCII text form, with an approximate length of two printed pages. The NOST Librarian can also provide printed copies and electronic copies for those without ftp access. When the community review process is complete, the text finally adopted by the Technical Panel will be incorporated in the NOST Definition of FITS, producing version 1.1. Action is expected shortly. 2.5 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.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 site (4.3). 2.7 Proposed Conventions Rob Seamon and Bill Pence have proposed a scheme for embedding a checksum within a FITS header. This checksum could be used to verify that the data in a file were transported without errors. A copy is available by anonymous ftp from iraf.noao.edu, in the /misc/checksum directory. IAU FITS Working Group Chair D. Wells has recommended that this proposal be considered by the regional FITS committees. D. Jennings, W. Pence, M. Folk, and B. Schlesinger have proposed a convention for logically grouping together FITS HDUs that are physically separated in a given file or are located in different files. One of the features of this proposal is that it will facilitate HDU-FITS conversion. Versions in TeX/PostScript are available by anonymous ftp at ssvs.gsfc.nasa.gov in the pub/convert directory; an html version may be viewed at http://acadia.gsfc.nasa.gov/convert/group.html . From fitsbits-request Fri Jan 27 12:20:16 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["18160" "" "27" "January" "1995" "11:22" "EDT" "Barry M. Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov" "<27JAN199511222988 at nssdca.gsfc.nasa.gov>" "359" "FITS basics and information (periodic posting) - 2/2" "^From:" nil nil "1" "1995012715:22:00" "FITS basics and information (periodic posting) - 2/2" (number " " mark " Barry M. Schlesin Jan 27 359/18160 " thread-indent "\"FITS basics and information (periodic posting) - 2/2\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA01545; Fri, 27 Jan 95 12:20:16 EST Return-Path: Message-Id: <27JAN199511222988 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!portal.gmu.edu!europa.eng.gtefsd.com!news.umbc.edu!haven.umd.edu!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Newsgroups: sci.astro.fits,sci.data.formats 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: FITS basics and information (periodic posting) - 2/2 Date: 27 Jan 1995 11:22 EDT FITS basics and information, Part 2 3 Software and Sample Data 3.1 NOST All NOST software is available from the NOST ftp site (4.1). 3.1.1 FITS Product Conformance Tester with Instructions 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. Even after finding an error in a required keyword, it will continue evaluating the file, looking for errors in required keywords. If the syntax errors do not keep the software from making a reasonable guess as to the values of all the required keywords, and the resultant values are valid, it will try to read the primary data array if the user has so specified. 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. The file includes only a primary header and data array. Be sure to use binary transfer for ftp access of FITS test files. 3.2 HEASARC The NASA/Goddard High Energy Astrophysics Science Archive Research Center (HEASARC) has developed and maintains FITS software and utilities, including the FITSIO package and FTOOLS utilities. See 4.2 for information on electronic access to FITSIO and supporting documentation. 3.2.1 FITSIO The FITSIO package, maintained by Bill Pence, provides FORTRAN software for easily reading and writing FITS format files. The current version is 3.7. There is a C interface, consisting of a set of C macro definitions, one for each FITSIO subroutine, replacing the C wrapper routines of previous versions. FITSIO runs on most types of machines. It supports all the currently defined standard FITS extensions including IMAGE and BINTABLE and contains world coordinates subroutines for conversion between pixel and celestial coordinates. There is also software support for the checksum proposal discussed in section 2.7. 3.2.2 FTOOLS James Kent Blackburn and Bill Pence document the FTOOLS collection of over 100 utility programs to create, examine, or modify FITS data files. These programs are useful for examining the contents of FITS files and modifying them for input to more involved analysis tasks; they cannot generally be used for detailed data analysis or model fitting. The current version 3.2 was released in November 1994; new versions are released about every 3 months. Users have the option of installing the entire FTOOLS package, which includes many routines specific to high energy astrophysics, or a core set that contains only the routines that perform general operations on FITS files. FTOOLS can be built as a package within IRAF or as a set of stand alone executable tasks. FTOOLS is supported on the following platforms: Unix: ALPHA/OSF, DEC/ULTRIX, SUN/SunOS, SUN/Solaris, MODCOMP/REALIX VMS: ALPHA/VMS, VAX/VMS. Questions or comments should be sent to ftoolshelp at athena.gsfc.nasa.gov 3.2.3 VERIFITS W. Pence (GSFC/HEASARC) has announced the VERIFITS program to verify the conformance of any FITS format data file on magnetic disk to the standard, checking keywords and data. At user option it will list the total number of pixels, number of null pixels and maximum and minimum data values. If it finds an error while evaluating the header, it normally ceases validation and reports the error. The VERIFITS program is a stand alone version of the fverify task that is included in the IRAF or Host FTOOLS package. Both VERIFITS and fverify perform the same verification checks, but fverify has a nicer user interface, as provided by the IRAF or Host environments. Several different binary executable versions of VERIFITS are available, for running on SUN workstations, DECstations, DEC Alphas running OSF/1 or VAX/VMS machines.The VERIFITS source code is also provided and may be easily linked with the FITSIO library to run on the other types of machine on which FITSIO is supported. While VERIFITS has been extensively tested, under some unusual circumstances not covered by the tests it may still fail to detect a FITS format error or may issue an error message that does not accurately describe the problem. 3.3 ADC FITS Tables Browser The Astrophysics Data Center has released the ADC FITS Table Browser, which has been tailored specifically for use with the ADC CD-ROMs but may be used with other FITS ASCII Tables. It reads standard FITS ASCII tables and allows the user to interactively browse through them and selectively display any field or record in a table. File extraction facilities allow the writing of all or part of the input table to disk in FITS or text file format. Copies of the program for MS-DOS and Unix are available by anonymous FTP on nssdc.gsfc.nasa.gov in the directory /pub/ADC/software/ftb. See the file README.FTB for instructions on downloading, installation, and use. 3.4 Converting FITS Files to Image Format Disclaimer: The mention of particular software packages is not necessarily intended as an endorsement of those packages to the exclusion of others. Users should obtain proper licensing for any proprietary package or format mentioned. Information about publicly available nonproprietary packages is welcome, and, if the package appears relevant and useful, will be added to this posting. Information about such packages should include how they can be obtained and whom to contact with questions. It should also describe any limits on the FITS files that the package can handle (e. g., NAXIS must be 2; data array members must be integers). 3.4.1 Major Astronomical Imaging Packages The three major astronomical imaging packages -- the Astronomical Image Processing System (AIPS), the European Southern Observatory Munich Image and Data Analysis System (ESO-MIDAS), and the Image Reduction and Analysis Facility (IRAF) -- provide facilities for displaying images stored in FITS files. These packages are large and probably best installed on major systems. AIPS was developed by the National Radio Astronomy Observatory (NRAO), and IRAF by the National Optical Astronomy Observatories; the origins provide an indication of the best applications. Europeans might find ESO-MIDAS more convenient. 3.4.2 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 array members are in IEEE floating point format (BITPIX<0) or the array has more than two dimensions (NAXIS>2). 3.4.3 IMDISP (IBM/PC) Archie Warnock and Ron Baalke have announced release of version 7.9 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.9 is available via anonymous ftp at explorer.arc.nasa.gov [128.102.32.10] in a file called imdisp79.zip in the pub/SPACE/SOFTWARE subdirectory. and at nssdc.gsfc.nasa.gov in the pub/ADC/software/imdisp subdirectory. It may also be available (at least for the time being) through Simtel-20 [192.88.110.20] 3.4.4 Applications with xv 3.0 For a system that has xv 3.0, some unsupported modifications to apply it to FITS files exist. Adam Bernstein (adam at dragon.jpl.nasa.gov) has made some additional modifications to the original set, to overcome some implementation problems. They are available by ftp to csi.jpl.nasa.gov in the /pub/users/adam directory. They can handle files with any of the valid FITS values of BITPIX, and can handle NAXIS>2 provided NAXISn=1 for n>2 (a convention often used in radio astronomy). The file "convert.tar.Z" contains these changes, as well as a new program called "FITS2GIF" created to allow non-interactive conversion of a large number of FITS files to GIF format. Use of xv 3.0 at a site must be licensed. 3.4.5 ViewFITS (OS/2) Dominique Beauchamp, Universite Laval, Quebec City, has released version 0.4, rel. 1 of ViewFITS, a FITS reader for OS/2 2.1 presentation manager. It is on ftp.cdrom.com in /pub/os2/incoming, file name vf04r1.zip, although it will probably be moved to /pub/os2/2_1/graphics/vf04r1.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. 3.4.6 FITS and the Macintosh Thorsten Lemke, at Brunswick in Germany has added FITS support to GraphicConverter for the Macintosh and provided the following information. GraphicConverter 1.7.7 or later can import FITS array files with all five permitted data types (8, 16, 32 bit integer and 32, 64 bit real). Every FITS file will be converted to 8 bit gray scale on opening because this is the maximum number of grays on a Macintosh. GraphicConverter can convert FITS and other files to a lot of different graphic file formats i.e. PICT, TIFF, GIF, PCX, IFF, PPM... GraphicConverter is available via ftp info-mac archives. A mirror site is amug.org 165.247.10.2 pub/ftp1/info-mac 1/1 ALL ftp email Arizona Macintosh Users Group, Phoenix, Arizona, USA GraphicConverter is in the folder grf/util/graphicconverter* The site at NRAO, described in 4.3,contains a collection of Usenet postings and electronic mail messages about the use of FITS on Macintosh hardware, in fits/os-support/mac-os/. 3.4.7 FITSview (Windows) Bill Cotton at NRAO has announced an updated beta release, version 0.4.0, of FITSview, a FITS image viewer for Windows. Celestial positions are determined using world coordinate projections. All defined FITS data types are supported, as are blanked pixels. Two and three dimensional simple FITS images are supported. FITSview runs on Windows 3.1 or later and uses any multicolor (or multiple gray level) display. Extensive on-line documentation is included. It is available by ftp from the NRAO site: ftp://fits.cv.nrao.edu/fits/os-support/ms-windows/fitsview/fitsv040.txt ftp://fits.cv.nrao.edu/fits/os-support/ms-windows/fitsview/fitsview040.zip Installation is described in fitsv040.txt. 3.5 World Coordinates Two ANSI C functions, worldpos() and xypix(), convert (RA, dec) <--> pixel location for 8 common types of projective geometries where "(RA,Dec)" are more generically (long,lat). These functions are based on the World Coordinates implementation of Classic AIPS. The software is in src/wcs/worldpos.tar.gz at the NRAO site (section 4.3) and supporting documentation can be found in documents/wcs/. 4 On-line Information Sources 4.1 NOST The NOST maintains a file of FITS information available by anonymous ftp from nssdca.gsfc.nasa.gov/fits or by DECnet copy from NSSDCA, in the directory FITS. A proposed reorganization could move the FITS material to a FITS subdirectory under a STANDARDS directory. NSSDCA is a VAX, and the files there cannot be accessed using Mosaic. Lynx will work with URL ftp://nssdca.gsfc.nasa.gov/fits. A copy of the NOST files can be reached using Mosaic from ftp://nssdc.gsfc.nasa.gov/pub/fits. Because this site is not a mirror and must be manually revised, updates may lag those at NSSDCA. 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; therefore, only one need be retrieved. The draft revisions to the standard covering the specification of units are provided as a text file. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is a copy of the proposal for the IMAGE extension, an earlier version of the paper cited in 2.1. The current version of the User's Guide is available in LaTeX, Unix(.Z)-compressed PostScript and uncompressed PostScript, along with a style file for the LaTeX version. A copy of the conventions for physical blocking on various media, as adopted by the IAU FITS Working Group, is available in flat ASCII text form. 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 HEASARC FITS software, utilities, and accompanying documentation are available as follows: ftp://legacy.gsfc.nasa.gov/software/fitsio contains the FITSIO package, and supporting documentation. ftp://legacy.gsfc.nasa.gov/software/fitsio/verifits contains the VERIFITS validator and supporting documentation. ftp://legacy.gsfc.nasa.gov/software/ftools/release contains the FTOOLS collection, and supporting documentation. The FTOOLS software is being distributed as compressed tar files. All three directories contain informational README files. 4.3 NRAO A library of FITS material can be found at ftp://fits.cv.nrao.edu/fits, located at NRAO. 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 have descriptive README files; in addition, the 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 the FITS Archive as well, at the URL http://fits.cv.nrao.edu. The documents subdirectory of the fits directory contains a number of subdirectories. The BINTABLE draft for Astronomy and Astrophysics is, in various formats, in files bintable_aa.*. A proposals subdirectory is reserved for detailed proposals currently being considered by the FITS committees. It contains the two announcements of the checksum proposal, and a checksum subdirectory contains the proposal itself and some supporting material. 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 and earlier documents and presentations on world coordinates. 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, pointers to other code, and an archive of Usenet postings related to FITS. 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. Some contributors (non-exhaustive list) A. Bernstein (JPL) D. Beauchamp (U. Laval) W. Cotton (NRAO) T. Lemke (U. of Brunswick) W. Pence (GSFC/HEASARC) D. Wells (NRAO) and the participants in sci.astro.fits and the fitsbits mailing list 6. NOST Services The NOST library 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 cannot provide copies of the IEEE floating point standard, which is copyright to IEEE. 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 9:00 a. m. - 6:00 p. m., U. S. Eastern Time (-0500 from the last Sunday in October through the first Saturday in April; -0400 the remainder of the year) 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. When communicating with the NOST library or FITS Support Office, please provide your name, affiliation, and location. 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 Tue Jan 31 00:16:44 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["209" "Tue" "31" "January" "1995" "04:19:40" "GMT" "Amy B. Sprenkle" "abs9d at galen.med.virginia.edu" "" "11" "ARN provision SIMPLE = T ?" "^From:" nil nil "1" "1995013104:19:40" "ARN provision SIMPLE = T ?" (number " " mark " Amy B. Sprenkle Jan 31 11/209 " thread-indent "\"ARN provision SIMPLE = T ?\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA16855; Tue, 31 Jan 95 00:16:44 EST Return-Path: Message-Id: Organization: uva Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!murdoch!galen.med.Virginia.EDU!abs9d Newsgroups: sci.astro.fits From: abs9d at galen.med.Virginia.EDU (Amy B. Sprenkle) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: ARN provision SIMPLE = T ? Date: Tue, 31 Jan 1995 04:19:40 GMT Hi, I ran across some "FITS" files whose header started SIMPLE = T /ARN provision yet the file does not appear to follow much if any of the standard fits format. What is the story here? Thanks Amy From fitsbits-request Tue Jan 31 00:16:55 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["599" "Tue" "31" "January" "1995" "04:27:44" "GMT" "Amy B. Sprenkle" "abs9d at galen.med.virginia.edu" "" "23" "Some questions on WFPC2 fits data..." "^From:" nil nil "1" "1995013104:27:44" "Some questions on WFPC2 fits data..." (number " " mark " Amy B. Sprenkle Jan 31 23/599 " thread-indent "\"Some questions on WFPC2 fits data...\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA16864; Tue, 31 Jan 95 00:16:55 EST Return-Path: Message-Id: Organization: uva Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!murdoch!galen.med.Virginia.EDU!abs9d Newsgroups: sci.astro.fits From: abs9d at galen.med.Virginia.EDU (Amy B. Sprenkle) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Some questions on WFPC2 fits data... Date: Tue, 31 Jan 1995 04:27:44 GMT Hi, I have been working with some WFPC2 images (amateur astronomer) and I noticed the DATAMAX and DATAMIN fields apply to the first image only. Is this the standard convention, and if so, does the Min/Max data for the rest of the chips show up in the header? Also, what is the convention as far as the order of images? Is it as shown below with the third image being the Planetary camera? 11 113 2244 2244 Lastly, when trying to determine pixel RA/DEC coordinates and the image is MIRROR=T, do you have to flip the image (left-Right?) so that the coordinates match up? Thanks Amy:) From fitsbits-request Tue Jan 31 11:52:55 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2872" "Tue" "31" "January" "1995" "11:52:46" "-0500" "Arnold Rots" "arots at xebec.gsfc.nasa.gov" "<199501311652.LAA13015 at xebec.gsfc.nasa.gov>" "59" "Re: FITS checksum proposal" "^From:" nil nil "1" "1995013116:52:46" "FITS checksum proposal" (number " " mark " Arnold Rots Jan 31 59/2872 " thread-indent "\"Re: FITS checksum proposal\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA18962; Tue, 31 Jan 95 11:52:55 EST Return-Path: Message-Id: <199501311652.LAA13015 at xebec.gsfc.nasa.gov> X-Mailer: ELM [version 2.4 PL24beta] Content-Type: text Content-Length: 2871 From: Arnold Rots Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Cc: arots at xebec.gsfc.nasa.gov (Arnold Rots) Subject: Re: FITS checksum proposal Date: Tue, 31 Jan 1995 11:52:46 -0500 (EST) There is one issue that I would like to raise about the checksum proposal by Seaman and Pence; I do not necessarily disagree with the proposal as it is, but I believe that the following ought to be considered. The question is whether the checksum operations should be done at the HDU level or at the file level. In the former case (as proposed) one would put the checksum keywords in all headers; in the latter only in the primary header. I believe that, from the viewpoint of practical use of the checksum, it does not matter which approach is chosen. To me, the important thing is that the checksum over the entire FITS file is supposed to be zero, in both cases. That means that one can use any checksum checking tool that one happens to have lying around and that such a tool does not need to know anything about FITS files. Some have made the argument that the current proposal allows one to find out in which extension the checksum does not check. I would consider the value of such information rather minimal: if the checksum of a FITS file is not zero, I would consider the entire file suspect and would want a new copy, regardless of where the checksum error occurred. So, if it doesn't matter a great deal from the standpoint of functionality, are there any arguments for or against either approach on the basis of implementation or operation? There are some, but I would consider them fairly marginal: -In the current proposal, when one extension is modified, one does not have to calculate the checksum over the entire file; the strength of this argument depends on the frequency of such operations and the size of the files. -If there is one checksum per file, one has to go all the way back to the primary header to update the checksum keyword; in either case one has to give up the notion of FITS files as sequential files - whether one then goes back to the last extension header or to the primary header makes no difference anymore. -With a single checksum per file, the checksum calculation and update can be hidden rather elegantly in the file closing utility of any FITS package; one can do a similar thing with checksums for each HDU. -With a single checksum per file it is easier to retrofit a checksum into existing FITS files since one does not have to look into each individual HDU; though sort of marginal, this is the strongest argument that I am aware of. This leads me to the reason why I brought this issue up. Given the fact (at least in my mind) that there is no good functional reason to prefer one approach over the other, is anybody aware of any other, strong arguments in favor or against either choice? If not, then I don't care particularly which way the decision goes, but it would be a pity if we adopted one and discovered a year from now that the other would have saved us considerable headaches. - Arnold Rots From fitsbits-request Tue Jan 31 12:20:13 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["338" "Tue" "31" "January" "1995" "12:20:03" "EST" "Jonathan McDowell" "jcm at urania.harvard.edu" "<9501311720.AA26144 at urania.harvard.edu>" "10" "Re: FITS checksum proposal " "^From:" nil nil "1" "1995013117:20:03" "FITS checksum proposal" (number " " mark " Jonathan McDowell Jan 31 10/338 " thread-indent "\"Re: FITS checksum proposal \"\n") ""] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA19015; Tue, 31 Jan 95 12:20:13 EST Return-Path: Message-Id: <9501311720.AA26144 at urania.harvard.edu> In-Reply-To: Message from Arnold Rots of "Tue, 31 Jan 95 11:52:46 -0500." <199501311652.LAA13015 at xebec.gsfc.nasa.gov> From: "Jonathan McDowell" Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: FITS checksum proposal Date: Tue, 31 Jan 95 12:20:03 EST Arnold Rots argues for one checksum per file, not one per HDU. However, The advantage of having one checksum per HDU is that an individual HDU can be moved from one file to another without modification. (Sometimes one considers the FITS file as an extra directory level in which the HDUs play the role of files). - Jonathan McDowell From fitsbits-request Tue Jan 31 16:33:19 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["876" "" "31" "January" "1995" "13:43" "EDT" "Barry M. Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov" "<31JAN199513432658 at nssdca.gsfc.nasa.gov>" "27" "Re: ARN provision SIMPLE = T ?" "^From:" nil nil "1" "1995013117:43:00" "ARN provision SIMPLE = T ?" (number " " mark " Barry M. Schlesin Jan 31 27/876 " thread-indent "\"Re: ARN provision SIMPLE = T ?\"\n") ""] nil) Received: by fits.cv.nrao.edu (4.1/DDN-CV/1.8) id AA19710; Tue, 31 Jan 95 16:33:19 EST Return-Path: Message-Id: <31JAN199513432658 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!hookup!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: Newsgroups: sci.astro.fits 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: ARN provision SIMPLE = T ? Date: 31 Jan 1995 13:43 EDT In article , abs9d at galen.med.Virginia.EDU (Amy B. Sprenkle) writes... >Hi, > > I ran across some "FITS" files whose header started > > SIMPLE = T /ARN provision > > yet the file does not appear to follow much if any of >the standard fits format. What is the story here? > Without knowing more about the files, only general comments are possible. The signature of FITS is SIMPLE = T at the start of the file, with the = in column 9 and T in column 30. To be a legitimate FITS file, the material following that first line must follow the FITS rules, and the FITS signature should not be used if the rest of the files does not do so. If the line is exactly as above, it does not follow the FITS syntax, but it still should not be called FITS. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Wed Feb 1 11:16:49 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["628" "Wed" "1" "February" "1995" "15:24:50" "GMT" "Amy B. Sprenkle" "abs9d at galen.med.virginia.edu" "" "18" "Re: ARN provision SIMPLE = T ?" "^From:" nil nil "2" "1995020115:24:50" "ARN provision SIMPLE = T ?" (number " " mark " Amy B. Sprenkle Feb 1 18/628 " thread-indent "\"Re: ARN provision SIMPLE = T ?\"\n") "<31JAN199513432658 at nssdca.gsfc.nasa.gov>"] nil) Received: by fits.cv.nrao.edu (4.1/DDN-CV/1.8) id AA22448; Wed, 1 Feb 95 11:16:49 EST Return-Path: Message-Id: Organization: uva Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!murdoch!galen.med.Virginia.EDU!abs9d References: <31JAN199513432658 at nssdca.gsfc.nasa.gov> Newsgroups: sci.astro.fits From: abs9d at galen.med.Virginia.EDU (Amy B. Sprenkle) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: ARN provision SIMPLE = T ? Date: Wed, 1 Feb 1995 15:24:50 GMT Thanks Barry, I have looked at these files in detail, and they are very similar to standard FITS (80 byte records followed by data) except they allow record block size modification in the header and do not use any of the required keywords. This is unfortunate because there appears to be little memory savings from their modification, and no enhancements. They should have just left them in fits format. Apparently IMDISP reads these files OK..? Do you know the author of IMDISP? Oh,.. almost forgot, these files have SIMPLE and T in the correct place, but the equals sign is in 28, not 9 byte location. Thanks Amy