From fitsbits-request Tue May 4 17:28:19 1993 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 25 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1000" "" "4" "May" "93" "20:37:12" "GMT" "phjj at ruchem.ru.ac.za" "phjj at ruchem.ru.ac.za" nil "18" "fits viewer for solaris 2.1" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13677; Tue, 4 May 93 17:28:19 EDT Return-Path: Article-I.D.: hippo.1993May4.203446.284 Message-Id: <1993May4.203446.284 at hippo.ru.ac.za> Organization: Rhodes University, Grahamstown, SA Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!noc.near.net!das-news.harvard.edu!ogicse!psgrain!ee.und.ac.za!hippo!ruchem.ru.ac.za!PHJJ Reply-To: phjj at ruchem.ru.ac.za From: phjj at ruchem.ru.ac.za Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: fits viewer for solaris 2.1 Date: 4 May 93 20:37:12 GMT This must be a FAQ, but where can I get a simple, stand-alone (i.e. not needing iraf, aips, etc) viewer that will display fits files on my brand-new Classic running Solaris 2.1 (well, hopefully running 2.1 by tomorrow). Any comments on the impact of Solaris on astronomical software will also be welcome (i.e. was buying one of these new Suns a mistake or not). Thanks Justin ====================================================~~~~~*~~~~~~~~~~~*~~~~~~~~~ Justin Jonas Radio Astronomy Group, /V\ _____ __ __ Dept. Physics & Electronics, \ / \ / /____/ \ /_/| /_/| Rhodes University, \/ |v| \/ | __ \ /| | | | | | | Grahamstown 6140, South Africa \__|#|__/ 26m | |__) |/ | | | | | | Internet: phjj at ruchem.ru.ac.za HartRAO /X\ dish | ___ \ \ | \_\/ | | phjj at hippo.ru.ac.za /\/|\/\ |_|/ \__\/ \___/|_|/ Tel: +27(461)22023 ext 452 ____/\/__|__\/\____ From fitsbits-request Thu May 6 18:13:59 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18024; Thu, 6 May 93 18:13:59 EDT Return-Path: Message-Id: <1993May6.203624.1163 at hippo.ru.ac.za> Organization: Rhodes University, Grahamstown, SA Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!haven.umd.edu!uunet!psgrain!ee.und.ac.za!hippo!ruchem.ru.ac.za!PHJJ References: <1993May4.203446.284 at hippo.ru.ac.za> Reply-To: phjj at ruchem.ru.ac.za From: phjj at ruchem.ru.ac.za Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: fits viewer for solaris 2.1 Date: Thu, 6 May 1993 20:38:49 GMT In article <1993May4.203446.284 at hippo.ru.ac.za>, phjj at ruchem.ru.ac.za writes: >This must be a FAQ, but where can I get a simple, stand-alone (i.e. not >needing iraf, aips, etc) viewer that will display fits files on my >brand-new Classic running Solaris 2.1 (well, hopefully running 2.1 Well it looks like SAOimage is the thing, but has anyone managed to build it under Solaris 2.1 and Openwindows with gcc 2.3.3? Thanks Justin ====================================================~~~~~*~~~~~~~~~~~*~~~~~~~~~ Justin Jonas Radio Astronomy Group, /V\ _____ __ __ Dept. Physics & Electronics, \ / \ / /____/ \ /_/| /_/| Rhodes University, \/ |v| \/ | __ \ /| | | | | | | Grahamstown 6140, South Africa \__|#|__/ 26m | |__) |/ | | | | | | Internet: phjj at ruchem.ru.ac.za HartRAO /X\ dish | ___ \ \ | \_\/ | | phjj at hippo.ru.ac.za /\/|\/\ |_|/ \__\/ \___/|_|/ Tel: +27(461)22023 ext 452 ____/\/__|__\/\____ From fitsbits-request Thu May 13 15:42:12 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02081; Thu, 13 May 93 15:42:12 EDT Return-Path: Message-Id: <1993May13.183105.1245 at cs.uah.edu> Organization: Computer Science Dept. - Univ. of Alabama in Huntsville Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!malgudi.oar.net!news.cs.uah.edu!uahcs2.cs.uah.edu!vchagant Reply-To: vchagant at uahcs2.cs.uah.edu (Venkata Chaganti) From: vchagant at uahcs2.cs.uah.edu (Venkata Chaganti) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS/HDF Date: Thu, 13 May 93 18:31:05 GMT Hi FITS/HDF GURUS I would like to know wheter I can convert a FITS file created in VAX Environ ment to HDF file in UNIX environment. I did this binary FTP to UNIX and then try to use Reformat sw of NCSA But it gives error. If any one uses before I would like to contact them. Thanks. kris chaganti --------- vchagant at uahcs2.cs.uah.edu From fitsbits-request Fri May 14 14:21:40 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04970; Fri, 14 May 93 14:21:40 EDT Return-Path: Message-Id: <9305141821.AA06463 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Coordinate keywords for Vector Column Date: Fri, 14 May 93 14:21:33 EDT A Proposal for Coordinate Keywords Describing Vector Columns in Binary Tables Arnold Rots, William Pence, and Lorella Angelini NASA/GSFC 14 May 1993 The format of FITS binary table extensions allows columns of a table to consist of a vector of elements which may be grouped into a multidimensional array using the TDIMnnn keyword. By analogy with FITS images in a primary array or IMAGE extension, there is a need to be able to describe the world coordinate system of each axis of a multidimensional array. In the document "Representations of Celestial Coordinates in FITS" by Eric Greisen and Mark Calabretta, the following set of keywords have been defined to represent the coordinate information in a FITS image: CTYPEm CRVALm CRPIXm CDi_j For multidimensional arrays within binary tables, we propose the following set of analogous keywords: mCTYPnnn - (character string) name or label for the axis mCRVLnnn - (real) physical value of the reference pixel mCRPXnnn - (real) reference pixel for the axis. By definition, the first pixel on each axis is centered on 1.0 and ranges from 0.5 to 1.5. i_jCDnnn - (real) coordinate transformation matrix value In addition we propose the following new keyword: mCUNInnn - (character string) physical units of the axis The following conventions apply to this proposal: - 'nnn' is an integer column number identifying the column of the table to which the keyword applies. - 'm' is an integer in the range 1 - 9, inclusive, identifying the dimension of the multidimensional array to which the keyword applies. This convention only supports up to 9 dimensions, but this could be extended to 35 dimensions, if necessary, by allowing 'm' to be in the range 1 - 9, A - Z. - 'i' and 'j' are integers defining the matrix element within the 2-dimensional coordinate transformation matrix. Refer to the document "Representations of Celestial Coordinates in FITS" by Eric Greisen and Mark Calabretta for a complete description of this matrix. Example FITS binary table header using this convention: XTENSION= 'BINTABLE' / binary table extension BITPIX = 8 / 8-bit bytes NAXIS = 2 / 2-dimensional binary table NAXIS1 = 328 / width of table in bytes NAXIS2 = 8 / number of records PCOUNT = 0 / size of special data area GCOUNT = 1 / one data group (required keyword) TFIELDS = 2 / number of fields in each row TTYPE1 = 'OBJECT ' / Name of the observed object TFORM1 = '8A ' / data format of the field: ASCII Character TTYPE2 = 'RATE ' / Observe flux count rate TFORM2 = '80E ' / data format of the field: 4 byte real TUNIT2 = 'counts/s' / units of the RATE values EXTNAME = 'RATEFILE' / name of the extension TDIM2 = '(8,10) ' / vector is a 2-dimensional array 1CTYP2 = 'ENERGY ' / first axis is ENERGY 2CTYP2 = 'TIME ' / second axis is TIME 1CRVL2 = 2.5 / ref. value of 1st axis=2.5 2CRVL2 = 0.0 / ref. value of 2nd axis=0.0 1CRPX2 = 1.0 / ref. pixel of 1st axis=1.0 (center of 1st bin) 2CRPX2 = 1.0 / ref. pixel of 2nd axis=1.0 (center of 1st bin) 1_1CD2 = 0.1 / delta between pixels in 1st axis is 0.1 2_2CD2 = 4.0 / delta between pixels in 2nd axis is 4.0 1CUNI2 = 'keV ' / 1st axis has units of 1000 electron volts 2CUNI2 = 's ' / 2nd axis has units of seconds END In the above example, the second column of the table contains a 2-dimensional array containing the value of the observed count rate from the source in 8 different energy bins each measured at 10 different times. The lowest energy bin is centered on 2.5 keV, and there is a 0.1 keV energy difference between the bins. Each row of the array represents a different time, starting at relative time 0 with a 4 second time difference between rows. From fitsbits-request Fri May 14 17:14:36 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05120; Fri, 14 May 93 17:14:36 EDT Return-Path: Message-Id: <9305142114.AA06620 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Continuation Keywords Date: Fri, 14 May 93 17:14:59 EDT A Proposal for Continuation Keywords in FITS Headers William Pence and Arnold Rots NASA/GSFC 14 May 1993 The maximum allowed length of a single character string keyword value in a FITS header is 68 characters which is too short for some applications. In order to overcome this length restriction, we propose here several possible conventions for allowing a character string value to be specified over multiple keywords in the FITS header. We prefer the first option, but would welcome comments on any of these, or on any other possible option. Option 1. Blank Continuation Keyword Convention A continued string value is recognized by a backslash (\) as the last character in the first keyword string, followed by a keyword with a blank name followed by the continuation of the keyword value enclosed in quotes. Example: KEYNAME = 'This is a very long keyword string value which \' 'continues over several lines\' ' of the FITS header.' Option 2. 'CONTINUE' Keyword Convention A continued string value is recognized by a backslash (\) as the last character in the first keyword string, followed by a keyword with the name 'CONTINUE' containing the continuation of the keyword string value. Example: KEYNAME = 'This is a very long keyword string value which \' CONTINUE= 'continues over several lines\' CONTINUE= ' of the FITS header.' Option 3. A Completely General Continuation Keyword Convention A continued string value is recognized if the name of the continuation keyword is present at the end of the string enclosed in backslashes. Example: KEYNAMEA= 'This is a very long keyword string value which \KEYWORDB\' KEYWORDB= 'continues over several lines\KEYWORDC\' KEYWORDC= ' of the FITS header.' This will only be interpreted as a continuation if the referenced keyword exists and if the backslash is the last character of the string. Discussion: We prefer the first option because it should cause minimal confusion for basic FITS readers (they could simply treat the continuation lines as comments), and it is more compact and more efficient to parse than Option 3. Some FITS readers may complain or lose information with Option 2 if there are multiple CONTINUE keywords in a FITS header. The FITS standard does not prohibit having multiple keywords with the same name, but this is generally discouraged to avoid confusion. Option 3 is the most general, however, it is wasteful of header space (since it requires 10 characters for the continuation keyword name and backslashes) and it would be the least efficient to implement since there is no requirement that the continuation keywords are sequentially ordered in the FITS header. It should be pointed out that Option 3, although it might seem the most robust since it does not repeat keywords and is resistent to FITS readers/writers that throw away blank keyword lines, has the disadvantage that it allows recursion. As shown in the examples, this convention could be repeated on multiple lines to express arbitrarily long strings. It would probably be prudent, however, to place an upper limit on the total length of the concatenated string in order to simplify the task of parsing these strings, especially on systems with limited resources. We suggest that an upper limit somewhere in the range of 256 to 1024 characters would be appropriate. Since one should never skimp too much on these things, 1024 is probably the more prudent value. From fitsbits-request Fri May 14 19:05:54 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05515; Fri, 14 May 93 19:05:54 EDT Return-Path: Message-Id: <1t16e5INN12b at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!caen!nigel.msen.com!sdd.hp.com!decwrl!decwrl!hal.com!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> From: sla at umbra.UCSC.EDU (Steve Allen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 14 May 1993 22:28:21 GMT In article <9305142114.AA06620 at tetra.gsfc.nasa.gov> pence at tetra.gsfc.nasa.gov (William Pence) writes: > A Proposal for Continuation Keywords in FITS Headers > >Option 1. Blank Continuation Keyword Convention > >KEYNAME = 'This is a very long keyword string value which \' > 'continues over several lines\' > ' of the FITS header.' Is there any restriction that forces a FITS reader not to reorder the FITS cards? I believe I've met at least one data reduction package which did not guarantee that output sets of FITS cards would happen in the same sequence as input sets of FITS cards. Nonetheless, I prefer option 1 as a strategy for the future. _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me. From fitsbits-request Mon May 17 13:31:55 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10312; Mon, 17 May 93 13:31:55 EDT Return-Path: Message-Id: <17MAY199312425119 at stars.gsfc.nasa.gov> Organization: Hughes STX Corp./NASA Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!stars.gsfc.nasa.gov!bhill References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> From: bhill at stars.gsfc.nasa.gov (Robert S. Hill) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 17 May 1993 12:42 EST In article <9305142114.AA06620 at tetra.gsfc.nasa.gov>, pence at tetra.gsfc.nasa.gov (William Pence) writes... > A Proposal for Continuation Keywords in FITS Headers >The maximum allowed length of a single character string keyword value >in a FITS header is 68 characters which is too short for some >applications. In order to overcome this length restriction, we propose Could you give us an example of a real application? I, for one, am very leery of adding new syntax rules to FITS, particularly ones that depend on the ordering of header records, or which encourage (as opposed to merely tolerating) repetition of keywords. Robert S. Hill ---------------------------------------------------------------- bhill at stars.gsfc.nasa.gov Hughes STX Corp. Code 681, NASA Goddard Space Flight Center, Greenbelt, MD 20771 From fitsbits-request Mon May 17 14:03:00 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["9341" "" "17" "May" "1993" "13:02" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "178" "FITS basics and information (regular posting)" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10335; Mon, 17 May 93 14:03:00 EDT Return-Path: Message-Id: <17MAY199313025546 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger 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 (regular posting) Date: 17 May 1993 13:02 EDT This basic FITS information is posted and updated periodically for the benefit of new readers and the reference of old readers. 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 the instrument or the history of the data. The data follow, structured as the header specifies. The data section of the HDU may contain a digital image, but, except for the first, *it doesn't have to*. Other possible formats include tables and multidimensional matrices that are not images. The first HDU must contain a multidimensional matrix or no data at all; the data in subsequent HDUs, called extensions, may be of any type, consistent with certain rules. The "Image" in the name comes from the original use of the format to transport digital images, but it's not just for images any more. FITS is not principally a graphics format designed for the transfer of pictures; it does not incorporate "FITS viewers", packages for decoding the data into an image. Users must develop or obtain separate software to convert the data from the FITS file into a form that can be readily displayed. As has been discussed in this newsgroup, and in alt.sci.astro.fits before it, the Extended Portable Bitmap Toolkit (pbm+) can be used for converting many FITS files to such a format. However, support is not guaranteed for all FITS files where the data are in the form of an image. In particular, there may be problems when the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2). Archie Warnock and Ron Baalke have announced release of version 7.8 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov [128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp subdirectory. It is also available through Simtel-20 [192.88.110.20] at PD1:IMDISP78.ZIP. Additional discussion of FITS->image converters appears in this newsgroup from time to time. The fundamental references on FITS are the following four papers, often referred to collectively as the "Four FITS Papers". These papers are the formal standard for FITS, endorsed by the International Astronomical Union (IAU). Wells, D. C., Greisen, E. W., and Harten, R. H., "FITS: a flexible image transport system," Astronomy and Astrophysics Supplement Series, 44, 363-370, 1981. Greisen, E. W. and Harten, R. H., "An extension of FITS for small arrays of data," Astronomy and Astrophysics Supplement Series, 44, 371-374, 1981. (NOTE: The format described in this paper has been used almost exclusively to transport radio interferometry and is likely to be replaced by other formats in the future. Writing data other than radio interferometry data using this format is not recommended.) Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., "Generalized extensions and blocking factors for FITS," Astronomy and Astrophysics Supplement Series, 73, 359-364, 1988. Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., "The FITS tables extension, Astronomy and Astrophysics Supplement Series, 73, 365-372, 1988. A User's Guide for FITS, commissioned by NASA Headquarters, is maintained by the NASA/Science Office of Standards and Technology (NOST) FITS Support Office. This Guide is intended to be a tutorial for new FITS users. In addition to presenting the rules of FITS, it provides some of the history and reasoning behind the choice of the rules, adds recommendations on good practices, and discusses current developments in FITS. The current version, 3.0, was issued in January 1993. This document is at present available only in printed form, but steps are under way to generate a PostScript version that will work on many systems and a flat ASCII version. The NOST is sponsoring development of a formal standard for FITS. The goal is a document codifying FITS as endorsed by the IAU, eliminating some contradictions and ambiguities in the original FITS papers, that can be endorsed by the IAU FITS Working Group as the FITS standard. The document is being developed by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review by the astronomical community. Only minor revisions are expected to the draft currently available, version 0.3b, but the form of the standard is not final, and it does not supersede the four papers and Floating Point Agreement endorsed by the IAU as the official standard for FITS. The IAU has endorsed the Floating Point Agreement, which defines how floating point numbers are to be expressed in FITS. The basic agreement appears verbatim in the User's Guide, and the substance is incorporated in the Draft NOST FITS definition. The NOST maintains a file of FITS information available by anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in the directory FITS at this writing. A reorganization is planned that will move the FITS material to a FITS subdirectory under a STANDARDS directory. The FITS files include copies of the current NOST draft standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. Except that the ASCII form does not have an index, the copies in the three formats are identical; only one need be retrieved. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. A modified version of this posting also appears there. An AAREADME.DOC file describes the contents of the directory. A SOFTWARE subdirectory contains a program in C to read and list the headers of a FITS file and another file with information on publicly available FITS software packages. The ERRTEST subdirectory contains several versions of the same FITS file, a valid one and several with different kinds of header errors, for use in testing software to read FITS files. Be sure to use binary transfer for ftp access of FITS test files. Both the SOFTWARE and ERRTEST subdirectories include AAREADME.DOC files describing their content. A modified version of this posting is now in the main directory. Additional material can be obtained by anonymous ftp from the National Radio Astronomy Observatory, from fits.cv.nrao.edu, in the directory FITS. The Documents subdirectory (case is significant) contains copies of the BINTABLE Binary Tables extension proposal, which is now under consideration by the FITS committees, and a draft describing a proposed method for incorporating data compression under FITS. A number of additional documents are available in ASCII text form, including the proposal on physical blocking of FITS files on media other than tape, and material on FITS, its history, and the FITS community. Its FITS_wcs subdirectory contains material serving as the basis for continuing discussion of world coordinates issues, some of which appears on this newsgroup from time to time. One is a draft proposal for world coordinates conventions being developed by E. Greisen and M. Calabretta. Two AIPS memos describing projections from a sphere onto a plane are also included, in PostScript form. A copy of an earlier paper by D. Wells and R. Hanisch summarizing conclusions of a workshop on World Coordinates held in Charlottesville in 1988 remains in the Documents subdirectory. Unless otherwise noted, documents are available from NRAO in both LaTeX and PostScript forms. There is an AA.README file for the Documents subdirectory and a README file for its FITS_wcs subdirectory. Printed copies of many of the documents listed above can be obtained from the NOST Librarian. Printed copies of the User's Guide and either paper or electronic copies of the Draft NOST Standard, for those without ftp access, are available. Because of restrictions set by the copyright holder, NOST can send copies of the four FITS papers only to non-profit organizations. The NOST can be reached as follows: (Postal) NASA/Science Office of Standards and Technology Code 633.2 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Telephone: +1-301-286-3575 8 a. m. - 5 p. m., U. S. Eastern Time If the Librarian is unavailable, a phone mail system takes the call after four rings. Please mention this posting in your request. Use the FITS office electronic mail address below for replies or questions. It is monitored by other NOST staff members when I am away from the office and provides a greater certainty of rapid response. Barry M. Schlesinger Coordinator, NASA/NSSDC NOST FITS Support Office +1-301-513-1634 fits at nssdca.gsfc.nasa.gov NCF::FITS From fitsbits-request Mon May 17 14:50:25 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1101" "Mon" "17" "May" "93" "14:50:45" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "28" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10359; Mon, 17 May 93 14:50:25 EDT Return-Path: Message-Id: <9305171850.AA09504 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: Mon, 17 May 93 14:50:45 EDT Robert Hill wrote: >>The maximum allowed length of a single character string keyword value >>in a FITS header is 68 characters which is too short for some >>applications. In order to overcome this length restriction, we propose > >Could you give us an example of a real application? 68 characters is really quite a small limit, so there are many examples that could be cited. One example would be to specify the full path and filename for a calibration file. Our file names are about 30 characters long; after you add the full subdirectory path, it is not hard to exceed 68 characters. Another example is the column descriptor notation that we will probably be using for the XTE X-ray satelite data. The organization of this data is very complex, thus we need a rather complex string to describe the contents of each column of a binary table, which represents a multidimensional array of data. An example is: TDDES2 = 'E(X1L|X1R|X2L|X2R|X3L|X3R) & C("TDDMAC1(0:14)") & T([" at TIME",1024,0.00390625])' In principle this string could be hundreds of characters long. -Bill Pence From fitsbits-request Mon May 17 16:04:03 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["702" "Mon" "17" "May" "1993" "19:39:05" "GMT" "Doug Tody" "tody at noao.edu " nil "15" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10460; Mon, 17 May 93 16:04:03 EDT Return-Path: Message-Id: <1993May17.193905.11258 at noao.edu> Organization: National Optical Astronomy Observatories Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!gatech!ncar!noao!noao.edu!tody References: <9305171850.AA09504 at tetra.gsfc.nasa.gov> Reply-To: tody at noao.edu From: tody at noao.edu (Doug Tody) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: Mon, 17 May 1993 19:39:05 GMT There are many cases in IRAF image headers where a long string is stored in multiple FITS keywords. Here is an example: WAT2_001= 'wtype=multispec spec1 = "1 127 0 4953.94775390625 0.0714096948... WAT2_002= '9 256 0. 23.28 31.32" spec2 = "2 126 0 4998.365722656251 0.071... WAT2_003= '15742111 256 0. 46.07 58.42" spec3 = "3 125 0 5043.49462890624... Each card contains a 68 character string, and the software will simply concatenate these strings to generate the original long string. The advantage of this approach is that it uses only standard FITS, and does not assume that the cards occur in the header in any particular order. Any FITS reader can access the individual cards. - Doug From fitsbits-request Mon May 17 17:58:16 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1285" "" "17" "May" "93" "21:17:50" "GMT" "William Thompson" "thompson at serts.gsfc.nasa.gov " nil "38" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10505; Mon, 17 May 93 17:58:16 EDT Return-Path: Message-Id: Organization: NASA Goddard Space FLight Ceneter -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!usenet.ins.cwru.edu!agate!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> From: thompson at serts.gsfc.nasa.gov (William Thompson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 17 May 93 21:17:50 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: > A Proposal for Continuation Keywords in FITS Headers > William Pence and Arnold Rots > NASA/GSFC > 14 May 1993 (text deleted) Of three options shown, I also prefer the first. I don't see a whole lot of practical difference between Option 1, i.e. KEYNAME = 'This is a very long keyword string value which \' 'continues over several lines\' ' of the FITS header.' and Option 2, i.e. KEYNAME = 'This is a very long keyword string value which \' CONTINUE= 'continues over several lines\' CONTINUE= ' of the FITS header.' Option 3, i.e. KEYNAMEA= 'This is a very long keyword string value which \KEYWORDB\' KEYWORDB= 'continues over several lines\KEYWORDC\' KEYWORDC= ' of the FITS header.' just seems way too complex to me. Another real world application: for the SOHO project we'll be using a combination of FITS and CDF files, and will be converting some files back and forth between the two formats. The CDF files are much less restricted than FITS files in how long character strings can be (among other things). It would be nice to be able to convert to and from FITS without loss of information. Bill Thompson From fitsbits-request Mon May 17 18:26:36 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["633" "" "17" "May" "1993" "17:53" "EST" "Robert S. Hill" "bhill at stars.gsfc.nasa.gov " nil "18" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10529; Mon, 17 May 93 18:26:36 EDT Return-Path: Message-Id: <17MAY199317531948 at stars.gsfc.nasa.gov> Organization: Hughes STX Corp./NASA Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!sol.ctr.columbia.edu!emory!europa.eng.gtefsd.com!darwin.sura.net!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!stars.gsfc.nasa.gov!bhill References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> From: bhill at stars.gsfc.nasa.gov (Robert S. Hill) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 17 May 1993 17:53 EST In article , thompson at serts.gsfc.nasa.gov (William Thompson) writes... pence at tetra.gsfc.nasa.gov (William Pence) writes: Thanks to Pence and to Thompson for the application examples. Of the three alternatives proposed, I also prefer the first, simplest one. However, the FITS User's Guide should then warn against having FITS processors re-order records. I imagine that most don't, anyhow. Robert S. Hill ---------------------------------------------------------------- bhill at stars.gsfc.nasa.gov Hughes STX Corp. Code 681, NASA Goddard Space Flight Center, Greenbelt, MD 20771 From fitsbits-request Mon May 17 18:56:51 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6021" "" "17" "May" "93" "21:26:41" "GMT" "William Thompson" "thompson at serts.gsfc.nasa.gov " nil "131" "Re: Coordinate keywords for Vector Column" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10553; Mon, 17 May 93 18:56:51 EDT Return-Path: Message-Id: Organization: NASA Goddard Space FLight Ceneter -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!caen!sdd.hp.com!ux1.cso.uiuc.edu!howland.reston.ans.net!darwin.sura.net!ra!cs.umd.edu!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson References: <9305141821.AA06463 at tetra.gsfc.nasa.gov> From: thompson at serts.gsfc.nasa.gov (William Thompson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Coordinate keywords for Vector Column Date: 17 May 93 21:26:41 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: >A Proposal for Coordinate Keywords Describing Vector Columns in Binary Tables > Arnold Rots, William Pence, and Lorella Angelini > NASA/GSFC > 14 May 1993 >The format of FITS binary table extensions allows columns of a table to >consist of a vector of elements which may be grouped into a >multidimensional array using the TDIMnnn keyword. By analogy with FITS >images in a primary array or IMAGE extension, there is a need to be >able to describe the world coordinate system of each axis of a >multidimensional array. >In the document "Representations of Celestial Coordinates in FITS" by >Eric Greisen and Mark Calabretta, the following set of keywords have >been defined to represent the coordinate information in a FITS image: > CTYPEm > CRVALm > CRPIXm > CDi_j >For multidimensional arrays within binary tables, we propose the >following set of analogous keywords: > mCTYPnnn - (character string) name or label for the axis > mCRVLnnn - (real) physical value of the reference pixel > mCRPXnnn - (real) reference pixel for the axis. By definition, > the first pixel on each axis is centered on 1.0 > and ranges from 0.5 to 1.5. > i_jCDnnn - (real) coordinate transformation matrix value (rest deleted) Since you obviously intend to use the TDIM keyword, why don't you use the same structure for the other keywords. A long time ago I had proposed the following keywords to be used in conjuction with TDIM. New keyword Standard FITS equivalent TDESCnnn CTYPEmmm TROTAnnn CROTAmmm TRPIXnnn CRPIXmmm TRVALnnn CRVALmmm TDELTnnn CDELTmmm These keywords would have the same format as the TDIM keyword, since there is a one-to-one relationship between them. Thus your example under my system would look like XTENSION= 'BINTABLE' / binary table extension BITPIX = 8 / 8-bit bytes NAXIS = 2 / 2-dimensional binary table NAXIS1 = 328 / width of table in bytes NAXIS2 = 8 / number of records PCOUNT = 0 / size of special data area GCOUNT = 1 / one data group (required keyword) TFIELDS = 2 / number of fields in each row TTYPE1 = 'OBJECT ' / Name of the observed object TFORM1 = '8A ' / data format of the field: ASCII Character TTYPE2 = 'RATE ' / Observe flux count rate TFORM2 = '80E ' / data format of the field: 4 byte real TUNIT2 = 'counts/s' / units of the RATE values EXTNAME = 'RATEFILE' / name of the extension TDIM2 = '(8,10) ' / vector is a 2-dimensional array TDESC2 = '(ENERGY,TIME)' / Axes are energy versus time TRVAL2 = '(2.5,0.0)' / ref. value for each axis for reference pixel TRPIX2 = '(1.0,1.0)' / ref. pix. of each axis=1.0 (center of 1st bin) TDELT2 = '(0.1,4.0)' / delta between pixels along each axis. END (This does assume that the names of the dimensions don't themselves contain commas.) My FITS reading software (written in IDL) uses the same subroutine to parse these extra keywords as it uses for the TDIM keyword itself. One additional variation I allowed for was that a particular column might not have more than one dimension, in which case there would be no TDIM keyword for that column. In that case, I treat the '(' and ')' characters as optional, and the TDESC, etc. keywords would have a single value, although still of type string, e.g. TTYPE3 = 'VOLTAGE ' / voltages used for each energy TFORM3 = '8E ' / 8 voltage points corresponding to 8 energy pts TDESC3 = 'ENERGY ' / voltages are a function of energy TRVAL3 = '2.5 ' / energy starts at 2.5 keV TRPIX3 = '1.0 ' / ref. pixel is center of 1st bin TDELT3 = '0.1 ' / energy points are 0.1 keV apart William Pence goes on to write: >In addition we propose the following new keyword: > mCUNInnn - (character string) physical units of the axis Well, at the time I didn't propose any equivalent keyword, but I think that it's a good idea. I would propose the following TCUNI2 = '(keV,s) ' / axes have units of 1000 eV vs seconds TCUNI3 = 'keV ' / energy is in 1000 eV My proposal is similarly limited to about 7-9 axes, simply because of the limited length of the character string. If strings can be continued on the next line, as also recently proposed, then my scheme doesn't have any limits in terms of the number of dimensions that can be supported. One thing that my proposal doesn't address is incorporating the new CD matrix scheme into binary tables. This is simply because this didn't exist at the time I came up with this scheme, or else was being distributed through some mechanism I don't have access too. I would, however, propose the following: TiiiCnnn ='(CDiii001,CDiii002,...)' where iii represents the dimension representing a complete row in the transformation matrix. Thus, in the example shown above one could have T1C2 = '(0.1,0.0)' / First row in transformation matrix T2C2 = '(0.0,4.0)' / Second row in transformation matrix We have been baselining using TDESC, etc. for the data that will come down from the SOHO satellite (launch in 1995). Of course one always prefers ones own scheme, but we would like to maintain compatibility with the rest of the FITS community. My personal feeling is that if one is going to use a keyword like TDIM, then the keywords associated with it should be organized in the same way. I think this is less confusing to the user. Bill Thompson From fitsbits-request Mon May 17 20:26:35 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["269" "Mon" "17" "May" "1993" "23:45:32" "GMT" "Doug Tody" "tody at noao.edu " nil "6" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10852; Mon, 17 May 93 20:26:35 EDT Return-Path: Message-Id: <1993May17.234532.18859 at noao.edu> Organization: National Optical Astronomy Observatories Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!gatech!asuvax!ncar!noao!noao.edu!tody References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> Reply-To: tody at noao.edu From: tody at noao.edu (Doug Tody) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: Mon, 17 May 1993 23:45:32 GMT > Of three options shown, I also prefer the first. I don't see a whole lot of > practical difference between Option 1, i.e. > > KEYNAME = 'This is a very long keyword string value which \' > 'continues over several lines\' > ' of the FITS header.' >From an abstract point of view I agree with the rest of you - the nicest solution to this problem is to have something like backslash continuation to allow arbitrarily long header lines. However, I think this is a more serious change to FITS than has been admitted here. Whether you admit it or not, the above example is a single keyword=value statement which is spread over three lines of the header. In affect you are changing the lexical form of the header. For example, to delete this keyword, or copy it to another header, one would have to treat the three lines as a unit or the result would be a munged FITS header (compare this to KEYW_nnn, where the pattern KEYW_* input to a generic FITS program will automatically deal with the logical set of related keywords as a group). As has already been pointed out, there is no requirement that the ordering of FITS header lines be preserved. There are existing examples of FITS programs which change the order of header lines, e.g. to separate classes of keywords or resolve cases of redefined keywords. Hence, general FITS programs would have to recognize the proposed convention to be able to deal properly with headers containing this construct. Basic FITS is keyword=value in 80 chars. It is best to stick with something which is consistent with this, and perform logical grouping of related keywords at a higher level, outside of the basic header mechanism. The existing FITS header is pretty limited - someday it would be nice to have a comprehensive redesign which provides things such as longer keywords, variable length lines, backslash continuation, elimination of the inefficient blank fill, and hierarchical keywords (a way of structuring large headers into distinct name spaces). On the other hand we have a requirement to remain backwards compatible so that existing FITS archives can still be read. Maybe we will eventually find a way to add some of these desirable features while still remaining backwards compatible. Oh well. So long as what one does is compatible with the basic standard, one is free to solve problems such as this any way one wants. - Doug From fitsbits-request Mon May 17 21:21:12 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2039" "" "17" "May" "1993" "20:42" "EST" "Robert S. Hill" "bhill at stars.gsfc.nasa.gov " nil "44" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10899; Mon, 17 May 93 21:21:12 EDT Return-Path: Message-Id: <17MAY199320421274 at stars.gsfc.nasa.gov> Organization: Hughes STX Corp./NASA Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!stars.gsfc.nasa.gov!bhill References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> <1993May17.234532.18859 at noao.edu> From: bhill at stars.gsfc.nasa.gov (Robert S. Hill) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 17 May 1993 20:42 EST In article <1993May17.234532.18859 at noao.edu>, tody at noao.edu writes... >From an abstract point of view I agree with the rest of you - the nicest >solution to this problem is to have something like backslash continuation to >allow arbitrarily long header lines. However, I think this is a more >serious change to FITS than has been admitted here. Whether you admit it or >not, the above example is a single keyword=value statement which is spread >over three lines of the header. In affect you are changing the lexical form >of the header. For example, to delete this keyword, or copy it to another This is what bothered me as well, and is the reason I wanted to see examples. I think Doug has a real point here. Of course, any of the three proposals can be done, strictly speaking, without altering the standard; the problem is that none of them is very robust with respect to perfectly legal manipulations. Doug's practice of using numbered keywords is more robust and accords with existing FITS style. The disadvantage is that each instance requires special processing and a modest amount of additional documentation. >The existing FITS header is pretty limited - someday it would be nice to Yup. The usual device for overcoming the limitations of FITS is to invent a new extension. Maybe someone should propose an `extended-header extension': XTENSION= 'XTNDHEDR' BITPIX = 8 NAXIS = n END .... ASCII text in following form: ARBITRARILY-LONG-KEYWORD='ANYTHING AT ALL, DELIMITED BY BACKSLASH'\ANOTHER-ARBITRARILY-LONG-KEYWORD='MORE AND M ORE AND MORE AND MORE STUFF, EXCEEDING THE 68-CHARACTER LIMIT WITH GREAT GLEE AND GOOD FEELING'\ Actually, I'm kidding. But you could do it, right? Robert S. Hill ---------------------------------------------------------------- bhill at stars.gsfc.nasa.gov Hughes STX Corp. Code 681, NASA Goddard Space Flight Center, Greenbelt, MD 20771 From fitsbits-request Mon May 17 23:25:49 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["748" "Tue" "18" "May" "1993" "03:34:47" "GMT" "apryan at vax1.tcd.ie" "apryan at vax1.tcd.ie" nil "12" "GIF/TIF/etc dither/half-tone?" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10918; Mon, 17 May 93 23:25:49 EDT Return-Path: Message-Id: <1993May18.033447.1 at vax1.tcd.ie> Organization: Trinity College Dublin Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!utnut!torn!nott!bnrgate!bnr.co.uk!uknet!mcsun!ieunet!tcdcs!vax1.tcd.ie!apryan From: apryan at vax1.tcd.ie Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: GIF/TIF/etc dither/half-tone? Date: Tue, 18 May 1993 03:34:47 GMT Does anyone know anything about software and hardware to produce half tones (suitable for making plates for printing) from GIF/TIF/FITS/etc format files? Packages I have produce 'dithers' which I don't think are the same. -Tony Ryan, "Astronomy & Space", new International magazine, available from: Astronomy Ireland, P.O.Box 2888, Dublin 1, Ireland. 6 issues (one year sub.): UK 10.00 pounds, US$20 surface (add US$8 airmail). ACCESS/VISA/MASTERCARD accepted (give number, expiration date, name&address). Tel: 0891-88-1950 (UK/N.Ireland) 1550-111-442 (Eire). Cost up to 48p per min (WORLD'S LARGEST ASTRO. SOC. per capita - unless you know better? 0.035%) growing fast! up another notch by mid May 1993!-----^ From fitsbits-request Tue May 18 10:29:00 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["824" "Tue" "18" "May" "93" "14:37" "GMT" "\"Clive Page, Leicester University, UK\"" "CGP at STARLINK.LEICESTER.AC.UK" nil "16" "Re: Coordinate keywords for Vector Column" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12752; Tue, 18 May 93 10:29:00 EDT Return-Path: Message-Id: <9305181428.AA12746 at fits.cv.nrao.edu> Via: uk.ac.leicester.starlink; Tue, 18 May 1993 14:36:27 +0100 From: "Clive Page, Leicester University, UK" Sender: fitsbits-request at fits.CV.NRAO.EDU To: FITSBITS Subject: Re: Coordinate keywords for Vector Column Date: Tue, 18 May 93 14:37 GMT One disadvantage with the Rots/Pence/Angelini proposal that occurs to me is that it requires some FITS keywords to start with a digit. Although the FITS Standard does allow this (or indeed a keyword starting with a hyphen), it is not something that I have come across before. Indeed I had to look up the Standard to check that it really was permitted (see section 5.1.2.1). Problems are quite likely to arise with FITS readers that convert FITS files into other formats, these readers tend to convert FITS keywords into variable (or parameter) names, and names starting with a digit are not often permitted in these systems. It seems a pity to cause problems with existing software if it can be avoided. Bill Thompson's proposal doesn't have this problem, and to me it also seems a bit neater and simpler. Clive Page From fitsbits-request Tue May 18 17:25:49 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13144; Tue, 18 May 93 17:25:49 EDT Return-Path: Message-Id: <1993May18.142553.24015 at Princeton.EDU> Organization: Physics Department, Princeton University Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!bgsuvax!att!princeton!pupgg.princeton.edu!GROTH References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> ,<1993May17.234532.18859 at noao.edu> Reply-To: groth at pupgg.princeton.edu From: GROTH at pupgg.princeton.edu (Edward J. Groth 609-258-4361) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: Tue, 18 May 1993 14:25:53 GMT In article <1993May17.234532.18859 at noao.edu>, tody at noao.edu (Doug Tody) writes: >> Of three options shown, I also prefer the first. I don't see a whole lot of >> practical difference between Option 1, i.e. >> >> KEYNAME = 'This is a very long keyword string value which \' >> 'continues over several lines\' >> ' of the FITS header.' > >From an abstract point of view I agree with the rest of you - the nicest >solution to this problem is to have something like backslash continuation to >allow arbitrarily long header lines. However, I think this is a more >serious change to FITS than has been admitted here. Whether you admit it or >not, the above example is a single keyword=value statement which is spread >over three lines of the header. In affect you are changing the lexical form >of the header. For example, to delete this keyword, or copy it to another >header, one would have to treat the three lines as a unit or the result >would be a munged FITS header (compare this to KEYW_nnn, where the pattern >KEYW_* input to a generic FITS program will automatically deal with the >logical set of related keywords as a group). As has already been pointed >out, there is no requirement that the ordering of FITS header lines be >preserved. There are existing examples of FITS programs which change the >order of header lines, e.g. to separate classes of keywords or resolve cases >of redefined keywords. > >Hence, general FITS programs would have to recognize the proposed convention >to be able to deal properly with headers containing this construct. Basic >FITS is keyword=value in 80 chars. It is best to stick with something which >is consistent with this, and perform logical grouping of related keywords at >a higher level, outside of the basic header mechanism. > >The existing FITS header is pretty limited - someday it would be nice to >have a comprehensive redesign which provides things such as longer keywords, >variable length lines, backslash continuation, elimination of the >inefficient blank fill, and hierarchical keywords (a way of structuring >large headers into distinct name spaces). On the other hand we have a >requirement to remain backwards compatible so that existing FITS archives >can still be read. Maybe we will eventually find a way to add some of >these desirable features while still remaining backwards compatible. > >Oh well. So long as what one does is compatible with the basic standard, >one is free to solve problems such as this any way one wants. > > - Doug Well - here's my 2 cents: Don't mess with the basic keyword=value in 80 columns!!!!!!!!!!!!!!!!!!! Aside from the basic keywords there is no requirement on ordering - reordering to optimize particular applications is perfectly reasonable. What's wrong with KEY_1 = ' ' KEY_2 = ' ' .... KEY_N = ' ' ? The only problem I see with this is you don't necessarily know when the string ends, so precede the whole mess with KEY_0 = Integer giving length of string or number of KEY_n lines to follow. - Ed /----------------------------------------------------------------------\ | Edward J. Groth | Phone: 609-258-4361 | | Physics Dept., Jadwin Hall | Fax: 609-258-6853 <- Changed 1-Feb-93 | | Princeton University | SPAN/HEPNET: PUPGG::GROTH=44117::GROTH | | Princeton, NJ 08544 | Internet: groth at pupgg.princeton.edu | \----------------------------------------------------------------------/ From fitsbits-request Wed May 19 15:09:39 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1471" "" "19" "May" "93" "16:11:28" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "28" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16330; Wed, 19 May 93 15:09:39 EDT Return-Path: Message-Id: Organization: NASA Goddard Space FLight Ceneter -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!darwin.sura.net!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!Hypatia!leb References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> ,<1993May17.234532.18859 at noao.edu> <1993May18.142553.24015 at Princeton.EDU> From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 19 May 93 16:11:28 GMT I don't have much to say about the proposed methods for providing continued keyword values over multiple card images, except that I don't like it much. I prefer a method that has multiple ordered keywords (i.e. KEY1, KEY2, ... KEYn) as opposed to a new general rule for parsing *all* character-valued keywords. Why should I blow CPU cycles checking the last character of each and every string for a backslash on the off-chance one or two may be continued? With ordered keywords, I install a callback function for that specific keyword that knows how to deal with continuations (if any) and leave it at that -- or simply ignore the keyword, which I am free to do under the standard. If the keyword is (possibly) continued, I am not free to ignore it, but must parse forward in the input stream to skip over the continuations. I have to admit, though, that I do enjoy seeing people jump through hoops to try to get from FITS some of the descriptive power other disciplines have had for years. Rather than shoe-horning little conveniences into a wholly outdated exchange format, I'd much prefer to see a 'constitutional convention' called for a total redesign to make FITS actually fit in to modern networked data processing environments. But that's just me. -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS From fitsbits-request Wed May 19 15:18:40 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1759" "" "19" "May" "1993" "13:38" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "41" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16347; Wed, 19 May 93 15:18:40 EDT Return-Path: Message-Id: <19MAY199313384908 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!sdd.hp.com!nigel.msen.com!yale.edu!yale!gumby!wupost!darwin.sura.net!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> <1993May17.234532.18859 at noao.edu> <17MAY199320421274 at stars.gsfc.nasa.gov> 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: Continuation Keywords Date: 19 May 1993 13:38 EDT In article <17MAY199320421274 at stars.gsfc.nasa.gov>, bhill at stars.gsfc.nasa.gov (Robert S. Hill) writes... > ... The usual device for overcoming the limitations of FITS is to >invent a new extension. Maybe someone should propose an >`extended-header extension': > > XTENSION= 'XTNDHEDR' > BITPIX = 8 > NAXIS = n > END > .... ASCII text in following form: > > ARBITRARILY-LONG-KEYWORD='ANYTHING AT ALL, DELIMITED BY > BACKSLASH'\ANOTHER-ARBITRARILY-LONG-KEYWORD='MORE AND M > ORE AND MORE AND MORE STUFF, EXCEEDING THE 68-CHARACTER > LIMIT WITH GREAT GLEE AND GOOD FEELING'\ > >Actually, I'm kidding. But you could do it, right? No, because the rules for keywords apply to all keywords, even the user-supplied keywords, and even those in user-defined extensions. This rule is one of those that cannot be violated in user designs "The keyword is an 8-character ASCII string left justified in columns 1-8..." -- FITS Paper I 5.1.2.1 Keyword (bytes 1-8) "The keyword shall be a left justified, 8-character, blank filled ASCII string with no embedded blanks. All digits (hexadecimal 30 to 39,``0123456789'') and upper case alphabetic characters (hexadecimal 41 to 5A, ``ABCDEFG HIJKLMN OPQRST UVWXYZ'' are permitted; no lower case characters shall be used. The underscore (hexadecimal 5F, ``_'') and hyphen (hexadecimal 2D, ``-'' are also permitted. No other characters are permitted." Actually, for long strings of text, probably the way to go is with the commentary keywords: COMMENT, HISTORY, and keyword field blank. No special continuation is needed. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Wed May 19 19:27:07 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1273" "Wed" "19" "May" "1993" "21:19:52" "GMT" "Jeffrey W Percival" "jwp at sal.wisc.edu " nil "28" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16904; Wed, 19 May 93 19:27:07 EDT Return-Path: Message-Id: <1993May19.211952.470 at sal.wisc.edu> Organization: Space Astronomy Lab, Madison WI Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!sal.wisc.edu!jwp References: <1993May17.234532.18859 at noao.edu> <1993May18.142553.24015 at Princeton.EDU> From: jwp at sal.wisc.edu (Jeffrey W Percival) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: Wed, 19 May 1993 21:19:52 GMT In article leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) writes: >I have to admit, though, that I do enjoy seeing people jump through >hoops to try to get from FITS some of the descriptive power other >disciplines have had for years. Rather than shoe-horning little >conveniences into a wholly outdated exchange format, I'd much prefer to >see a 'constitutional convention' called for a total redesign to make >FITS actually fit in to modern networked data processing environments. >But that's just me. I was wondering when someone would say this. If we used a BNF-style specification for a header grammar, with a Lex-style tokenizer, all these issues of parsing and lookahead, not to mention the subtle "interpretation" conflicts that arise, would simply vanish. A lawyer-like combing of a possibly self-inconsistent plain-language specification, a-la the tax code, is hardly a substitute for a yes/no answer from a grammar-driven state machine! And if you change the grammar, you get your code remade for free. To paraphrase a saying around here (and not to derogate the seminal contibution of its creators), it would be nice to drag FITS kicking and screaming into the Eighties! -- Jeffrey W Percival (jwp at larry.sal.wisc.edu) (608)262-8686 From fitsbits-request Thu May 20 11:02:51 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3426" "" "19" "May" "1993" "15:39" "EST" "Robert S. Hill" "bhill at stars.gsfc.nasa.gov " nil "95" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18789; Thu, 20 May 93 11:02:51 EDT Return-Path: Message-Id: <19MAY199315394202 at stars.gsfc.nasa.gov> Organization: Hughes STX Corp./NASA Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!stars.gsfc.nasa.gov!bhill References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> <1993May17.234532.18859 at noao.edu> <19MAY199313384908 at nssdca.gsfc.nasa.gov> From: bhill at stars.gsfc.nasa.gov (Robert S. Hill) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 19 May 1993 15:39 EST In article <19MAY199313384908 at nssdca.gsfc.nasa.gov>, bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes... >In article <17MAY199320421274 at stars.gsfc.nasa.gov>, bhill at stars.gsfc.nasa.gov (Robert S. Hill) [that's me] writes... >> ... The usual device for overcoming the limitations of FITS is to >>invent a new extension. Maybe someone should propose an >>`extended-header extension': [... see below, maybe I wasn't very clear...] >>Actually, I'm kidding. But you could do it, right? > >No, because the rules for keywords apply to all keywords, even the >user-supplied keywords, and even those in user-defined extensions. >This rule is one of those that cannot be violated in user designs > >"The keyword is an 8-character ASCII string left justified in columns >1-8..." > -- FITS Paper I > >5.1.2.1 Keyword (bytes 1-8) >"The keyword shall be [...yada yada yada...] Barry, the idea of my thought experiment is that you can put any information you want into the *data* portion of an HDU. The point I was making is that the only way to get really broad new powers out of FITS is to find a way of encoding the desired information into an extension. But once you decide to do so, almost any result can be forced. I mean, the following is perfectly legal, as far as I can tell: Main header: SIMPLE = T BITPIX = 8 NAXIS = 0 EXTEND = T END Extension header: XTENSION= 'IMAGE ' BITPIX = 8 NAXIS = 1 NAXIS1 = 10000000 END Extension data: [...insert complete works of Shakespeare in TeX format here...] Okay, so why not the following? Main header: SIMPLE = T BITPIX = 8 NAXIS = 0 EXTEND = T END Header of first extension: XTENSION= 'XTNDHEDR' BITPIX = 8 NAXIS = 1 NAXIS1 = 15000 END Data of first extension: [...insert 15000 bytes of description, structured in some definite way, with *its own agreed syntax* distinct from FITS header syntax ...] Header of second extension: XTENSION= 'IMAGE ' BITPIX = -32 NAXIS = 3 NAXIS1 = 2048 NAXIS2 = 256 NAXIS3 = 32 END Data of second extension: [... the actual binary data ...] I hate to take so much space with this, but I was determined to make the faux pas of explaining my joke. Lee Brotzman's remark about a constitutional convention is well taken, because the extension mechanism is so clunky. (One would rather have had a richer format to start with.) But perhaps we are using extensions too conservatively. *Would* it in fact be possible to generate some sort of purely documentation-oriented extension that would meet Lee's criteria for modernity? Bob Hill ---------------------------------------------------------------- bhill at stars.gsfc.nasa.gov Hughes STX Corp. Code 681, NASA Goddard Space Flight Center, Greenbelt, MD 20771 From fitsbits-request Thu May 20 13:04:30 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["871" "" "20" "May" "93" "15:04:47" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "21" "Re: Continuation Keywords" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18881; Thu, 20 May 93 13:04:30 EDT Return-Path: Message-Id: Organization: NASA Goddard Space FLight Ceneter -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!newsserver.jvnc.net!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!Hypatia!warnock References: <9305142114.AA06620 at tetra.gsfc.nasa.gov> ,<1993May17.234532.18859 at noao.edu> <1993May18.142553.24015 at Princeton.EDU> From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Continuation Keywords Date: 20 May 93 15:04:47 GMT leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) writes: >for years. Rather than shoe-horning little conveniences into a wholly outdated >exchange format, I'd much prefer to see a 'constitutional convention' called for >a total redesign to make FITS actually fit in to modern networked data >processing environments. >But that's just me. No, it isn't just you. And it doesn't take much of a visionary to imagine "Grep-able FITS". WHAT? You want _DELIMITERS_??? In FITS??? But, in the meantime, we got what we got, and it works where it works (and I don't think Casey Stengel ever said that). -- _______________________________________________________________________ -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC Project STELAR: WAIS to do science From fitsbits-request Thu May 20 15:08:59 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["127" "Thu" "20" "May" "1993" "18:43:51" "GMT" "Greg Johnson" "k085722 at hobbes.kzoo.edu " nil "5" "Fits for Macs?" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18990; Thu, 20 May 93 15:08:59 EDT Return-Path: Message-Id: <1993May20.184351.22330 at hobbes.kzoo.edu> Organization: Kalamazoo College Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!bogus.sura.net!darwin.sura.net!howland.reston.ans.net!newsserver.jvnc.net!yale.edu!yale!gumby!kzoo!k085722 From: k085722 at hobbes.kzoo.edu (Greg Johnson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Fits for Macs? Date: Thu, 20 May 1993 18:43:51 GMT Are there any FITS converters/displayers available for the Macintosh? If so, from where? (anonymous ftp preferable). Thanks, From fitsbits-request Thu May 20 16:32:21 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1214" "Thu" "20" "May" "1993" "21:32:03" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "29" "Re: Fits for Macs?" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA19085; Thu, 20 May 93 16:32:21 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells References: <1993May20.184351.22330 at hobbes.kzoo.edu> From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Fits for Macs? Date: Thu, 20 May 1993 21:32:03 GMT In article <1993May20.184351.22330 at hobbes.kzoo.edu> k085722 at hobbes.kzoo.edu (Greg Johnson) writes: "Are there any FITS converters/displayers available for the Macintosh? If so, from where? (anonymous ftp preferable)." Do anonymous-FTP to fits.cv.nrao.edu [192.33.115.8], look in directory /FITS/OSsupport/MacOS, and read these 8 files: size date name ---- ------------ ------------ 430 Oct 28 1992 FITSIO.txt 2665 Oct 29 1992 FITSIO.v3p3 464 Oct 26 1992 Mac_Vista.txt 638 Oct 26 1992 NIH_Image.txt 865 Oct 28 1992 SpyGlass.txt 1020 Oct 28 1992 Various.txt 1267 Dec 2 11:56 ipsys.txt 685 Mar 5 11:40 maia.txt These small text files (private Email and newsgroup postings) describe various FITS packages available for MacOS. If you have any success send me an Email message that I can add to this directory to help the next person. -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Fri May 21 17:07:26 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4460" "Fri" "21" "May" "93" "17:07:46" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "86" "HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA22592; Fri, 21 May 93 17:07:26 EDT Return-Path: Message-Id: <9305212107.AA13862 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: HEASARC Continuation Keyword Convention Date: Fri, 21 May 93 17:07:46 EDT Thanks to everyone that commented on our proposals on 'Continuation Keywords' in FITS headers. Nearly everyone who expressed a preference for one of our 3 proposals preferred the first option, thus we intend to start using this, when necessary, in the FITS files produced by the HEASARC. Under this convention, a string keyword value may be continued over multiple keywords in a header by terminating the first line of the string with a backslash, and continuing it on the next keyword record which has a blank keyword name (the full definition of this convention and an example are given below). In reply to some other comments that were made: Some suggested that since FITS headers have such a rigid (and primative?) format, it would be better to completely redesign FITS rather than try to add patches to the existing system to support new features. This approach may have its merits, but in the meantime, we have to live with the current implementation of FITS and need to continue to find ways to adapt it to new situations. Doug Tody rightly pointed out that this proposal has significant implications when one needs to delete, copy, or otherwise manipulate string keywords. When performing such operations, one must treat the entire set of continuation keywords as a unit, otherwise the header may get messed up. This is very true, and I intend to modify the FITSIO software, in particular, to handle these situations transparently for the user. FITISO will then automatically write a string value over multiple keywords using this convention if it is more than 68 characters long. Similarly FITSIO will automatically concatenate the long string together when reading a FITS header. (There are also lower level FITSIO routines that may be used to read or write each individual header record, if desired). Contrary to Lee Brotzman's concern that this will eat up too many CPU cycle testing for continuation lines for every string keyword, I don't think this will really be very expensive. One has to parse the keyword record anyway to find the position of the closing single quote character marking the end of the string, so it is pretty trivial then to test the previous character to see if it is a backslash. Finally, several people expressed a preference for a scheme where continuation keywords are numbered as in KEY_1 = 'This is a long string tha\' KEY_2 = 't is continued on two lines of the header.' This is fine in simple cases, but in many of the cases where we envisage needing this facility, the keyword name already ends with a sequence number, (e.g.,signifying the binary table column to which it applies). It would be complicated to append a second continuation sequence number to these keywords. In addition, in many cases we are already hard pressed to encode all the desired information into an 8-character name, so we would not want to have to use some of these precious characters as a continuation sequence indicator. Also, it would be useful if the continuation convention was general enough such that it could also be applied to any previously defined FITS keywords such as 'TELESCOP', or 'OBSERVER' which could not be done if it was required to add a sequence number to the keyword name. The following is the precise definition of this continuation convention: The HEASARC Convention for the Continuation of FITS String Keyword Values William Pence and Arnold Rots NASA/GSFC 21 May 1993 This convention defines how to specify the value of a character string keyword which may be too long to fit within the 68-character limit of a single keyword value. This is done by inserting a backslash character immediately before the closing single quote character of the first keyword, and by then continuing the value string, again enclosed in single quote characters, on the next keyword in the header which must have a blank keyword name. The value string may be continued over multiple blank keywords as long as each previous string ends with a backslash character. Optionally, a comment string may follow the quoted value string on any or all of the continuation keywords. Example: OBSERVER= 'Sir Nathanual Hawthorn Jacobs \' / proposer's full name 'Mitchael Fitzpatrick David Millheart\' / this string starts in col. 9 ' Rosebud Washington, III' / proposer's name (cont.) END From fitsbits-request Sat May 22 14:31:23 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["344" "" "19" "May" "1993" "12:25:09" "-0700" "David Vezie" "dv at nntp.crl.com " nil "8" "FITSIO(c) & NAXISx comments" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00186; Sat, 22 May 93 14:31:23 EDT Return-Path: Message-Id: <1te1il$eee at crl.crl.com> Organization: CRL Internet Dialup Access 415-389-UNIX (guest) (tell 'em dv sent you) Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pacbell.com!pacbell!nntp.crl.com!not-for-mail From: dv at nntp.crl.com (David Vezie) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITSIO(c) & NAXISx comments Date: 19 May 1993 12:25:09 -0700 How do I, using FITSIO (actually, FITSIOC, the C wrapper for FITSIO) add comments to NAXIS1,2,..? Since FTPHDR gets all the axes itself, and constructs the header, there's no opportunity there to add comments to the axes. Should I add a second copy of NAXIS1,2,... to it, with comments in it? Or ??? David Vezie dv at xnet.ssl.berkeley.edu From fitsbits-request Mon May 24 08:19:27 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["687" "Mon" "24" "May" "1993" "08:18:39" "-0400" "Bruce O'Neel" "oneel at arupa.gsfc.nasa.gov " nil "22" "Re: FITSIO(c) & NAXISx comments" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05305; Mon, 24 May 93 08:19:27 EDT Return-Path: Message-Id: <9305241218.AA11043 at arupa.gsfc.nasa.gov> In-Reply-To: <1te1il$eee at crl.crl.com> from "David Vezie" at May 19, 93 12:25:09 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 687 From: oneel at arupa.gsfc.nasa.gov (Bruce O'Neel) Sender: fitsbits-request at fits.CV.NRAO.EDU To: dv at nntp.crl.com (David Vezie) Cc: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITSIO(c) & NAXISx comments Date: Mon, 24 May 1993 08:18:39 -0400 (EDT) > > How do I, using FITSIO (actually, FITSIOC, the C wrapper for FITSIO) > add comments to NAXIS1,2,..? Since FTPHDR gets all the axes itself, > and constructs the header, there's no opportunity there to add comments > to the axes. Should I add a second copy of NAXIS1,2,... to it, with > comments in it? Or ??? Try >>14 Modify (overwrite) the comment field of an existing keyword in the CHU - FTMCOM(unit,keyword,comment, > status) - in fortran as... call ftmcom(lun,'naxis1','This is the new comment',status) bruce -- USENET: Post to exotic, distant machines. Meet exciting, unusual people. And flame them. -- courtesy of Dan Sorenson, z1dan at exnet.iastate.edu From fitsbits-request Mon May 24 12:05:28 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2032" "" "24" "May" "93" "13:23:41" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "39" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06234; Mon, 24 May 93 12:05:28 EDT Return-Path: Message-Id: Organization: NASA Goddard Space FLight Ceneter -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!spool.mu.edu!uunet!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!Hypatia!leb References: <9305212107.AA13862 at tetra.gsfc.nasa.gov> From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: 24 May 93 13:23:41 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: >Contrary to Lee Brotzman's concern that this will eat up >too many CPU cycle testing for continuation lines for every string >keyword, I don't think this will really be very expensive. One has to >parse the keyword record anyway to find the position of the closing >single quote character marking the end of the string, so it is pretty >trivial then to test the previous character to see if it is a >backslash. I may not have worded my comment correctly, but really I was complaining about wasting *any* time checking *every* string for continuation. Not just too much, but any, including the time it will take to rewrite existing code. Your convention will dictate that *all* FITS readers must be rewritten in order to correctly interpret your headers. This is very costly, and I wish you would take a hard look at other, more FITS-like ways to solve your problem. Also, I was being flip about the "constitutional convention". FITS was designed in another era, and the fact that you feel you must use a convention that, although it doesn't break the letter of the standard, certainly breaks the "spirit" of the standard, provokes me to goad the powers-that-be that FITS isn't everything it is cracked up to be. We wouldn't want them to get too smug, now would we? :-) I know my opinion doesn't count for much against the FITS heavyweights, but please, take another look at what it is you are doing and look hard at what effect you will have on other software groups. Not everyone has a full-time staff of programmers to modify their code when you hit a syntactical stumbling block. -- -- Lee Brotzman P.S. *Now* I wish I was going to the Berkeley AAS meeting for WGAS. I'll wind up missing one just when it might get interesting. That figures. -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS From fitsbits-request Mon May 24 12:05:30 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1511" "" "24" "May" "93" "14:09:24" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "29" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06241; Mon, 24 May 93 12:05:30 EDT Return-Path: Message-Id: Organization: NASA Goddard Space FLight Ceneter -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!Hypatia!leb References: <9305212107.AA13862 at tetra.gsfc.nasa.gov> From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: 24 May 93 14:09:24 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: > The HEASARC Convention for the Continuation of FITS String Keyword Values > > William Pence and Arnold Rots > NASA/GSFC > 21 May 1993 > >This convention defines how to specify the value of a character string >keyword which may be too long to fit within the 68-character limit of a >single keyword value. This is done by inserting a backslash character >immediately before the closing single quote character of the first >keyword, and by then continuing the value string, again enclosed in >single quote characters, on the next keyword in the header which must >have a blank keyword name. The value string may be continued over >multiple blank keywords as long as each previous string ends with a >backslash character. Optionally, a comment string may follow the >quoted value string on any or all of the continuation keywords. If you are going to do this (and I still prefer you don't), you should establish an upper limit for the length of the string. Buffers need to be allocated to concatenate each piece of the string, and programmers will need guidance on what a safe limit is. My suggestion is 68. :-) No really, pick a reasonable limit like 500 or 1000 characters. -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS From fitsbits-request Mon May 24 16:32:46 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3595" "Mon" "24" "May" "93" "16:33:11" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "76" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06505; Mon, 24 May 93 16:32:46 EDT Return-Path: Message-Id: <9305242033.AA16610 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Mon, 24 May 93 16:33:11 EDT Lee Brotzman wrote (regarding our proposal for continuation keywords): > ... (stuff deleted) Your convention will dictate that *all* FITS >readers must be rewritten in order to correctly interpret your >headers. This is very costly, and I wish you would take a hard look at >other, more FITS-like ways to solve your problem. We decided to go with the current proposal because it seems like best alternative we could think of, and because no one else suggested a viable alternative. The only other suggestion we've seen is to use a numbered sequence of keywords (KEY1, KEY2, KEY3 ...) but this is unacceptable to us for several reasons: 1. This doesn't work if the keyword name already ends with a sequence number. In our applications we use FITS binary tables almost exclusively and many of our keywords are applicable to a specific column, so the keyword names end with the column sequence number (as in TDIMnnn). It is simply not practical to try to encode a continuation sequence number into these keyword names. There are only 5 characters left in the name to play with and we don't want to reserve 1 or 2 of them for a continuation character. 2. Using a numbered set of keyword names is a very application specific solution for individual cases, and is not a general solution to the continuation problem. Basically, you have to decide ahead of time whether a particular string keyword value is going to exceed 68 characters and if so, define a numbered naming sequence for it. Then all the software that reads this keyword has to know that it must read in an array of keywords to construct the whole string. But if you define a non-numbered keyword for an application, and then only later discover that the value will sometimes exceed 68 characters, then you are stuck. You would have to define a whole new set of numerical indexed keywords, and would have to change all your software to look for this new set of keywords. In the long run, I think our proposal will actually involve less change to existing software than the case-by-case numerically indexed keyword solution. To implement our general solution you just have to modify a single keyword parsing subroutine (as I will do in FITSIO) to handle the continuation convention. Then just relink your application software and that is about it. 3. While not essential, our proposal is retroactively applicable to any existing defined string keywords (e.g., TELESCOP). Otherwise one would have to define a new set of seqential keywords (TELEnnn) for this use, which would probably not be recognized by any existing FITS readers. Finally, we are certainly not requiring that all other groups immediately support this convention. Ideally, we would hope that this convention becomes endorsed by the wider FITS community. In the meantime, we have to implement some solution to this problem for immediate use within the HEASARC and this seems like the best alternative. On a slightly different issue Lee Brotzmann wrote: >If you are going to do this (and I still prefer you don't), you should >establish an upper limit for the length of the string. Buffers need to be >allocated to concatenate each piece of the string, and programmers will need >guidance on what a safe limit is. My suggestion is 68. :-) > >No really, pick a reasonable limit like 500 or 1000 characters. We didn't set a specific limit because it seemed like a completely arbitrary decision. Is there really a need for an upper limit? If so, is there a objective way of deciding what the limit should be? -Bill Pence HEASARC, NASA/GSFC From fitsbits-request Mon May 24 16:59:33 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["775" "Mon" "24" "May" "1993" "22:57:49" "+0200" "Thierry Forveille" "forveill at gag.observ-gr.fr " nil "16" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06532; Mon, 24 May 93 16:59:33 EDT Return-Path: Message-Id: <9305242059.AA06526 at fits.cv.nrao.edu> Posted-Date: Mon, 24 May 1993 22:57:49 +0200 In-Reply-To: <9305242033.AA16610 at tetra.gsfc.nasa.gov> References: <9305242033.AA16610 at tetra.gsfc.nasa.gov> From: forveill at gag.observ-gr.fr (Thierry Forveille) Sender: fitsbits-request at fits.CV.NRAO.EDU To: pence at tetra.gsfc.nasa.gov (William Pence) Cc: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Mon, 24 May 1993 22:57:49 +0200 I am jumping somewhat late into this continuation line discussion, so sorry if my point has already been addressed and I have missed that part of the discussion. I tend to agree that the continuation character is the least disturbing option to existing FITS readers (which tend to ignore blank keywords and will thus truncate the continued string) if continuation lines need to be implemented. I have however a slight impression that we are putting our cart before the horses since I haven't yet seen on the list a justification for this need. Most of the data I have actually came across only use a rather small fraction of the 68 allowed characters. Aren't we going to use header keywords when we should use something else? Thierry Forveille Observatoire de Grenoble From fitsbits-request Mon May 24 19:58:20 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2328" "" "24" "May" "93" "21:19:22" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "46" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07029; Mon, 24 May 93 19:58:20 EDT Return-Path: Message-Id: Organization: NASA Goddard Space FLight Ceneter -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!ra!cs.umd.edu!skates.gsfc.nasa.gov!Hypatia!leb References: <9305242033.AA16610 at tetra.gsfc.nasa.gov> From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: 24 May 93 21:19:22 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: >>No really, pick a reasonable limit like 500 or 1000 characters. > >We didn't set a specific limit because it seemed like a completely >arbitrary decision. Is there really a need for an upper limit? >If so, is there a objective way of deciding what the limit >should be? There's nothing wrong with being arbitrary. FITS is full of arbitrary. Pick a size that will be sufficient for all time, or at least for a few years. Something that I and other programmers can set and depend on (at least in a #define). I *could* set aside a 10,000 character temporary buffer to read in strings, but that's wasteful. Pick 500 or 1000 (I generally dislike using powers of two just for the sake of it, a philosophy that I picked up from being a fan of REXX). I'll quote a response I penned earlier today to Bruce O'Neel when he asked a similar question about using dynamically allocated arrays for these continued strings: "My original point, ... was that in order to dynamically allocate an array, I have to give [malloc] a size, and in order to determine the size I have to concatenate all the pieces, and in order to concatenate all the pieces I have to have an array large enough to hold them all, and in order to have one large enough I have to have an upper limit. The alternative would be to scan through all of the continued strings, counting lengths, then allocate the string I need and *rescan* the continued keyword. Yuch. Even worse than having continuations in the first place." Basically I have to hold onto the continued string somewhere before I can store it in the structure where it belongs, which will now have to be dynamically allocated in every case, since I can't predict the length of strings, which means more guard code against memory leaks, etc. etc. ad nauseum. 68 was such a nice, arbitrary limit. Sigh. Those were the days. If you have an alternative algorithm, please let's hear it. I could very well be missing something simple. Otherwise, just pick a number. I'll vote for 1000 (unless 68 is already taken :-). -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS From fitsbits-request Mon May 24 20:14:15 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2766" "Mon" "24" "May" "93" "17:12:57" "MST" "patron at noao.edu" "patron at noao.edu" nil "61" "Reading/writing FO" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07052; Mon, 24 May 93 20:14:15 EDT Return-Path: Message-Id: <930524171257.24e005cf at noao.edu> X-St-Vmsmail-To: ST%"fitsbits at fits.cv.nrao.edu" From: patron at noao.edu Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Reading/writing FO Date: Mon, 24 May 93 17:12:57 MST Hello. My name is Jesus Patron, and I am a graduate student of the University of La Laguna (Tenerife, Canary Island, SPAIN). I have being working in solar physics, in the field of heliosismology with Dr. Frank Hill at NSO (National Solar Observatory), Tucson,Az. since March 1991. I'm really interested in dealing with FITS format images, and I'm looking for help in how to read and write FITS images directly in FORTRAN language. I'm going to work with the 'INTEL' supercomputer of the Jet Propulsion Laboratory in Pasadena, Ca., and I wonder if there is any software built for reading and writing FITS images from/to FORTRAN programes. I will be very grateful to anyone that could help me in this. Thank you very much. My e-mail address is: "patron at noao.edu" Jesus From fitsbits-request Tue May 25 09:49:32 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA08996; Tue, 25 May 93 09:49:32 EDT Return-Path: Date: Tue, 25 May 93 09:48:34 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9305251348.AA17319 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU, patron at noao.edu Subject: Re: Reading/writing FO Sender: fitsbits-request at fits.CV.NRAO.EDU patron at noao.edu (Jesus Patron) wrote: > I'm really interested in dealing with FITS format images, and I'm >looking for help in how to read and write FITS images directly in FORTRAN >language. I'm going to work with the 'INTEL' supercomputer of the Jet >Propulsion Laboratory in Pasadena, Ca., and I wonder if there is any software >built for reading and writing FITS images from/to FORTRAN programes. The FITSIO package is available for reading or writing FITS files from Fortran or C programs. FITSIO has been ported to many different machines, but not specifically to an 'INTEL' supercomputer. More than likely, one of the existing FITSIO ports could be used as is, or with simple modifications, on the INTEL. The FITSIO code as well as documentation and example programs can be obtained via anonymous ftp from: tetra.gsfc.nasa.gov (128.183.8.77) Type the following commands from the ftp prompt to copy any desired files: ftp> user anonymous [or just type 'anonymous' if prompted for user] Password: [type your username as a password] ftp> cd pub/fitsio [to move to the fitsio subdirectory] ftp> ls [to see a list of the available files] ftp> get read.me [contains latest information about FITSIO] ftp> get fitsio.doc [complete user documentation] ftp> get fitsio.tex [Latex version of the documentation] ftp> get ... [get any additional desired files] ftp> quit -Bill Pence From fitsbits-request Tue May 25 10:33:15 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["870" "Tue" "25" "May" "1993" "10:32:28" "-0400" "Jeff Pedelty" "pedelty at jansky.gsfc.nasa.gov " nil "18" "FITSIO on Intel" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09049; Tue, 25 May 93 10:33:15 EDT Return-Path: Message-Id: <9305251432.AA05183 at jansky.gsfc.nasa.gov> Content-Type: text Content-Length: 870 From: pedelty at jansky.gsfc.nasa.gov (Jeff Pedelty) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITSIO on Intel Date: Tue, 25 May 1993 10:32:28 -0400 (EDT) patron at noao.edu (Jesus Patron) wrote: > I'm really interested in dealing with FITS format images, and I'm >looking for help in how to read and write FITS images directly in >FORTRAN language. I'm going to work with the 'INTEL' supercomputer of >the Jet Propulsion Laboratory in Pasadena, Ca., and I wonder if there >is any software built for reading and writing FITS images from/to >FORTRAN programes. My experience with the FORTRAN compiler on the Intel i860-based machine at JPL leads me to believe that porting FITSIO will be straightforward. The compiler was written by the Portland Group, and supports a large number of VAX extensions. Start with the DEC/Ultrix version, and I'm guessing that no modifications will be necessary. I'd be happy to take a look at any problems you encounter, as your finished product would be useful to me as well. Jeff Pedelty From fitsbits-request Tue May 25 16:37:55 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1699" "Tue" "25" "May" "93" "16:37:00" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "34" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09274; Tue, 25 May 93 16:37:55 EDT Return-Path: Message-Id: <9305252037.AA17717 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: forveill at gag.observ-gr.fr Cc: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Tue, 25 May 93 16:37:00 EDT Thierry Forveille wrote: >I have however a slight impression that we are putting our cart before the >horses since I haven't yet seen on the list a justification for this need. >Most of the data I have actually came across only use a rather small fraction >of the 68 allowed characters. Aren't we going to use header keywords when >we should use something else? This is not meant to be a flame, but I am rather surprised at how the question 'Why would you ever need more than 68 characters?' keeps getting raised. I would turn this around an ask 'How have FITS users been able to cope so long with this restriction?'. With just a little thought it is easy to come up with many examples of long strings that one might want to put into header keywords: - file names, including the full node:user:disk:direcory:subdirectory path - a bibibliographic reference, including the title of an article - postal address - a caption for a figure or plot - a long array of numbers (given as a quoted string) - Within the HEASARC we are running into a number of more specific cases with respect to fully describing the contents of various FITS binary tables which in general could require quite long strings. In the past it seems that FITS users have either just learned to live within this limit, or have developed rather adhoc solutions to cover a few specific cases where long strings could not be avoided. What we are proposing by this new 'continuation convention' is a general solution to this problem which will be applicable in all situations. This is in keeping with the philosophy that FITS must continue to evolve to meet the growing and changing needs of the users. -Bill Pence From fitsbits-request Tue May 25 17:22:30 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2421" "" "25" "May" "1993" "16:53" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "50" "New version of FITS Product Conformance Tester" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09302; Tue, 25 May 93 17:22:30 EDT Return-Path: Message-Id: <25MAY199316531810 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger 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: New version of FITS Product Conformance Tester Date: 25 May 1993 16:53 EDT A revised prototype of the developing NOST FITS Support Office software package to validate FITS files is now available for testing. It is written in ANSI C. As before, the FPCT checks for the presence of the required keywords in the primary header and whether or not they are in the proper order. It will find them if they are out of order but will issue warnings. Syntax is also checked. Also, if the user chooses, it creates a file of selected members of integer data arrays, as specified by the user, unless there are major header errors. This version cannot handle floating point. If there are minor header errors, it will attempt to derive information to obtain the data array but will warn the user that the data may not be extracted properly. The current version does not check extensions. A number of changes have been made since the previous version, among them the following: The software now checks whether named input files are successfully allocated, printing an error message and stopping execution when errors are detected. Special data types are defined for the data being read from the FITS file; a sequence of typedef statements can be revised by the user as appropriate to the hardware. The summary diagnostic has been split in two four separate messages: one for the header evaluation, one for the input file, one for allocation problems, and one for the data evaluation. The condition codes now make 0 a normal return, with progressively higher digits for each evaluation signifying progressively more serious problems. Comments, particularly on errors and portability problems, are solicited. We are concentrating at present on making the program itself function, and saving revisions of the interface, however awkward it may be at present, for later. The software has been developed on a VAX cluster. It can operate on machines that use twos complement integers with either most significant byte or least significant byte first, but not on ones complement hardware. ASCII-EBCDIC conversion also has not been implemented. Sun users should be warned that because the software is ANSI C, they will not be able to use SUN C1.0, the standard compiler for SPARCstations. To obtain a copy of the package and the instructions for use, send electronic mail to (Internet) fits at nssdca.gsfc.nasa.gov (NSI-DECnet) NCF::FITS Barry Schlesinger NOST FITS Support Office From fitsbits-request Tue May 25 19:07:43 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["997" "Tue" "25" "May" "1993" "21:19:15" "GMT" "Jeffrey W Percival" "jwp at sal.wisc.edu " nil "18" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09674; Tue, 25 May 93 19:07:43 EDT Return-Path: Message-Id: <1993May25.211915.29449 at sal.wisc.edu> Organization: Space Astronomy Lab, Madison WI Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!saimiri.primate.wisc.edu!sal.wisc.edu!jwp References: <9305242033.AA16610 at tetra.gsfc.nasa.gov> From: jwp at sal.wisc.edu (Jeffrey W Percival) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Tue, 25 May 1993 21:19:15 GMT In article leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) writes: :I'll quote a response I penned earlier today to Bruce O'Neel when he asked a :similar question about using dynamically allocated arrays for these continued :strings: : : "My original point, ... was that in order to dynamically allocate an : array, I have to give [malloc] a size, and in order to determine the : size I have to concatenate all the pieces, and in order to concatenate : all the pieces I have to have an array large enough to hold them all, : and in order to have one large enough I have to have an upper limit. : The alternative would be to scan through all of the continued strings, : counting lengths, then allocate the string I need and *rescan* the : continued keyword. Yuch. Even worse than having continuations in the : first place." Use realloc(3) as you find each continuation. No upper limits need be known. -- Jeffrey W Percival (jwp at larry.sal.wisc.edu) (608)262-8686 From fitsbits-request Tue May 25 19:07:28 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3111" "" "25" "May" "1993" "18:25" "EST" "Robert S. Hill" "bhill at stars.gsfc.nasa.gov " nil "69" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09665; Tue, 25 May 93 19:07:28 EDT Return-Path: Message-Id: <25MAY199318253505 at stars.gsfc.nasa.gov> Organization: Hughes STX Corp./NASA Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!nigel.msen.com!sdd.hp.com!ux1.cso.uiuc.edu!howland.reston.ans.net!darwin.sura.net!bogus.sura.net!ra!cs.umd.edu!skates.gsfc.nasa.gov!stars.gsfc.nasa.gov!bhill References: <9305252037.AA17717 at tetra.gsfc.nasa.gov> From: bhill at stars.gsfc.nasa.gov (Robert S. Hill) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: 25 May 1993 18:25 EST In article <9305252037.AA17717 at tetra.gsfc.nasa.gov>, pence at tetra.gsfc.nasa.gov (William Pence) writes... >This is not meant to be a flame, but I am rather surprised at how the >question 'Why would you ever need more than 68 characters?' keeps >getting raised. I would turn this around an ask 'How have FITS users >been able to cope so long with this restriction?'. With just a little This is also not meant to be a flame, but since you asked... > - file names, including the full node:user:disk:direcory:subdirectory path Gee, this bugs me, but I can't quite say exactly why. My own approach to this sort of thing is not to specify a filename, but to have a list of named resources that gets translated to filenames somewhere outside the FITS realm -- e.g., a bunch of flatfields for the different detectors and filters on our telescope. If I specify these things by actual filenames, the difficulty of porting the batch processing system across platforms is increased. I don't have a real strong objection to putting filenames in FITS headers, but I have always tried to avoid having a reason to do it. > - a bibliographic reference, including the title of an article > - postal address Why wouldn't these go into history cards? To me, keywords are like a parameter space describing your data, and stuff that is really just plain ol' text goes more naturally into history/comments. > - a caption for a figure or plot Seems a bit outside FITS's bailiwick to me. > - a long array of numbers (given as a quoted string) Better in this case to bite the bullet and make a keyword array with the XXXXX001, XXXXX002 method. People have invented huge arrays, e.g., HST Guide Star Selection Survey astrometry coefficients (not the CDm_n keywords, the other ones that go with GSSS images themselves; there must be a couple of dozen of them). > - Within the HEASARC we are running into a number of more specific cases >with respect to fully describing the contents of various FITS binary >tables which in general could require quite long strings. To me, this is your best case by far. IMHO, people's expectations are starting to stretch the boundaries of FITS a bit, even factoring in extensibility. It's fine to ask FITS to expand to fill the users' needs, but design aesthetics matter, too. In fact, they matter a lot. Following one's sense of what's clean and consistent with the past is just a way of looking into the crystal ball to anticipate and forestall future snarls. I hope you understand that we are not trying to keep you from doing what your project requires. It's just that the continuation proposal has obviously rung a mild, low-volume sort of ugly design alarm for some of us. (Not that FITS has never done that before :-) Like I said before, I don't really *hate* it to where I'd fight tooth and nail, and I say if you must do it, then do it, but it still makes me feel funny. Bob Hill ---------------------------------------------------------------- bhill at stars.gsfc.nasa.gov Hughes STX Corp. Code 681, NASA Goddard Space Flight Center, Greenbelt, MD 20771 From fitsbits-request Tue May 25 20:32:29 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1435" "Wed" "26" "May" "1993" "00:04:56" "GMT" "Doug Tody" "tody at noao.edu " nil "24" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09737; Tue, 25 May 93 20:32:29 EDT Return-Path: Message-Id: <1993May26.000456.270 at noao.edu> Organization: National Optical Astronomy Observatories Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!asuvax!ncar!noao!noao.edu!tody References: <9305252037.AA17717 at tetra.gsfc.nasa.gov> Reply-To: tody at noao.edu From: tody at noao.edu (Doug Tody) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Wed, 26 May 1993 00:04:56 GMT In article <9305252037.AA17717 at tetra.gsfc.nasa.gov>, pence at tetra.gsfc.nasa.gov (William Pence) writes: > been able to cope so long with this restriction?'. With just a little > thought it is easy to come up with many examples of long strings > that one might want to put into header keywords: > > - file names, including the full node:user:disk:direcory:subdirectory path > - a bibibliographic reference, including the title of an article > - postal address > - a caption for a figure or plot > - a long array of numbers (given as a quoted string) Gee Bill, maybe you ought to use an auxiliary table for such information? It is often simplest to put the occasional long string in a header using multiple keywords, but if you find yourself doing this often you may be using the wrong representation for your data. A table can easily accomodate large strings or other vector elements. A simple table with 3 or 4 columns (keyword name, value string, comment, and maybe a datatype code) would be logically equivalent to the FITS header, but would avoid most of the limitations, i.e., keyword names, value strings, and comments can be as long as you want. Sure it is a nusiance to have another table but it does avoid all these problems. If you find your data continually running into the limitations of the simple FITS header (such as you suggest) I think you ought to seriously consider this option. - Doug From fitsbits-request Tue May 25 20:58:24 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["388" "Tue" "25" "May" "1993" "23:42:03" "GMT" "Greg Hennessy" "gsh7w at fermi.clas.Virginia.EDU " nil "14" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09754; Tue, 25 May 93 20:58:24 EDT Return-Path: Message-Id: Organization: University of Virginia Path: cv3.cv.nrao.edu!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gsh7w References: <9305242033.AA16610 at tetra.gsfc.nasa.gov> <1993May25.211915.29449 at sal.wisc.edu> From: gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Tue, 25 May 1993 23:42:03 GMT Jeffrey W Percival writes: #Use realloc(3) as you find each continuation. No upper limits need be known. And what about those who use computers that don't have realloc? Not very flexible it seems. -- -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w at virginia.edu UUCP: ...!uunet!virginia!gsh7w From fitsbits-request Wed May 26 10:27:44 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["10338" "Wed" "26" "May" "1993" "15:42:58" "+0200" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "221" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10979; Wed, 26 May 93 10:27:44 EDT Resent-Message-Id: <9305261427.AA10979 at fits.cv.nrao.edu> Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Reply-To: Lucio Chiappetti In-Reply-To: <9305212107.AA13862 at tetra.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Resent-Sender: Lucio Chiappetti From: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU Resent-From: fitsbits-request To: William Pence Cc: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Wed, 26 May 1993 15:42:58 +0200 (MET DST) Resent-Date: Wed, 26 May 1993 15:42:58 +0200 (MET DST) I apologize for coming late into this discussion, but I was away for most of the last two weeks. I picked up the various messages last Friday as "travel reading material", and I am now reading the forthcoming discussion. Most of my comments have already been raised, I reiterate them here mainly to give further support. 1) REAL need for string > 68 characters 1.1) is it REALLY necessary ? This has been questioned, and I would say that I agree with most of the questions raised (i.e. I generally do not see a need for this, beside some special cases). In fact I have been recently defining a data format for our internal use (this format is not FITS, but was designed to be 1-to-1 mappable to FITS for transport). In this format I store keywords in a header (more properly a trailer, to allow extendability) in binary format, essentially as : 1 byte : code indicating the data type (CHAR, I*4, R*4, R*8) * 1 byte : length of the data field in bytes (n) 8 char : NAME of the kewyord (8 char for FITS compatibility) n char : value(s) of the keyword (if the keyword is CHAR this is a string of length n, if the keyword is numeric, it is an array of n/4 I*4 or R*4 or n/8 R*8 ... in general the array is actually a single scalar) From the fact that I use one byte for the length (field marked as *) a nominal limit of 255 characters can be derived for string keywords. I originally wanted to limit this to 246 (so that 1+1+8+n = 256), but I soon decided to impose a further limit, and use 68 JUST IN ORDER TO BE COMPATIBLE WITH FITS. This is somewhat the opposite approach to HEASARC. I started with a non-FITS format for storage, and accepted to put limitations in it in order to be compatible with FITS for transport. HEASARC started with the choice to use FITS also for storage, and is now finding some intrinsic limitations in it ... 1.2) in which cases it might be necessary ? Some persons asked for examples. Most of the examples provided are of "documentary" nature. I would in general agree with the comments supplied by Robert Hill. Namely : - filenames including a full path : ARE THESE OF ANY RELEVANCE OUTSIDE THE SITE where the files were produced ? My personal approach is to store in the header only the name part (e.g. in the case of a file names /xas/calib/xmm/epic/pinco.matrix, I would store in the header only "pinco" ; the extension ".matrix" should be implicit in the file format, and the path should be site dependent (e.g. set according to environment variables) - information like bibliography, addresses, captions look to me to be there FOR DOCUMENTATION ONLY, therefore they belong to the class of "comments". See point 4 below. - an example of a complex string descriptor for XTE was made. This appeared to me really awkward !! Is not really possible to arrange things to be simpler ? - finally, the case was made of a keyword describing an array of numbers. This is something I find sometimes useful. For instance if an instrument has seven PMTs, it might be useful to record their HV setting as an "array kewyord" PMTHVS of 7 numbers. This is possible in the scheme I described above (but I use binary representation), but is quite FITS-unlike ... or un-FITS-like ?). I had the problem of writing this into FITS for export and PROVISIONALLY used an arrangement as follows : in the FITS file I put a character string PMTHVS which says 'this kewyord is an array from PMTHV1 to PMTHV7' and I follow with seven numbered keywords I am not completely happy with this arrangement, and so far it is not reversible (I mean I can write my file into FITS for documentary purpose, but cannot read such "array kewyords" back yet), and, what matters more, is NOT INTEROPERABLE. That is none of the readers I use follows that particular convention. I know by looking at MIDAS-produced FITS files that MIDAS writes array descriptors (how keywords are named in MIDAS) as strings, e.g. PMTHVS = '105 104 106 107 93 100 102', and this convention is reversible within MIDAS, but I am not aware of any related documen- tation. I am also not aware if IRAF has any similar facility. Maybe fitsbits subscribers directly involved in MIDAS and IRAF might comment on that. ***** I presume that HERE there is a VALID case for defining an INTEROPERABILITY standard. But this should be called "a standard for array of numbers in FITS kewyords" and not a "standard for long character strings" ***** 2) Compatibility with the past I regard the issue of compatibility with the past (and present) of paramount importance (the so-called "once FITS forever FITS" principle), and I agree with the comments by Lee Brotzman on this. Defining a standard which no other reader can use defies interoperability (which is the modern way to interpret the "T for Transport" in FITS. ^ Of course it may be legitimate instead to use a local convention which is useful at one site, or within one package, but this convention shall apply only in such a way not to hinder anybody else to use the data with other packages. In the present case this means that the convention for continuation keywords should allow readers to skip them, and that their interpretation is not essential for the analysis. 3) Maximum length I feel that a maximum length should be defined, if reconstructing the entire value is necessary for the analysis (if is is just of "documetnary" nature, it might be truncated in a harmless way). This is said from the point of view of the Fortran programmer. My *personal* preference is for this length to be no more than 255 character, for the very simple reason that my own software may be already compatible with it, in the case I'd decide to support the new convention. (but this is obviously not a strong reason). 4) Suggestions and conclusions My strong preference is NOT to define any new standard which forces ALL FITS readers and dependent software (i.e. analysis packages) to be rewritten in order to allow use of keyword values longer than 68. This also implies that the information written in such keywords is NOT to be used outside the site where the files are produced or with other packages than those used there. I.e. that all other software can SKIP such information (treat it as comments) in a harmless way. In this sense it is ACCEPTABLE to follow a convention in which one has 1234567890 KEYWORDX='value blah blah \' ' continues \' ' etc. etc. up to the end' provided "columns 1 to 8 are left blank" in order to comply with the standard about comments (NOST 100.03b pag. 19) IF however the information to be written in strings longer than 68 is essentially of "documentary nature", that is is there just to remind an human of how the file was produced, it might be treated as a COMMENT or HISTORY and split on several lines without any mandatory indication of continuation. I am personally using the following convention in my files. I do not allow a given named keyword to appear more than once in an header, but for HISTORY, COMMENT and PARENTS (this is a local usage to keep trace of the ancestor files to a given file). In general a file header looks like : some keywords freely interspersed with COMMENT keywords one or more HISTORY keywords ------------------------------------- some more keywords one or more HISTORY keyowrds ------------------------------------- etc. Each set of HISTORY keyowrds records the run string of the command which generated or modified the file. In general a command may also modify a file in place, altering some keywords, and adding some new ones, but will add a new history section. The HISTORY case is the only case in which I ever had to write things longer than 68 characters (command run strings), and I was happy to do this splitting them in more lines, with continuation lines starting with a plus sign. As an example (this is taken from an header lister output, so it is not in FITS, but it should be obvious how it could look in FITS): (J) BITPIX = 8 (J) NAXIS1 = 16 (J) NAXIS2 = 12232 (J) TFIELDS = 6 ...... (C) HISTORY = oapxas targetcrab 900.0 target_crablike (C) COMMENT = Converted to focal plane units (C) COMMENT = Original file modified in place (C) COMMENT = THETA PHI converted into X Y ...... (C) HISTORY = focalplane targetcrab 7500.0 (C) COMMENT = X Y shifted by DELTAX DELTAY (J) DELTAX = -5000 (J) DELTAY = 5000 (C) HISTORY = relocate targetcrab -5000 5000 (C) COMMENT = Converted to single chip pixels (C) COMMENT = X,Y converted to X,YPOSITN ...... (C) HISTORY = chipsize targetcrab targetcrab_eev1_c 27. 768 1024 0. (C) HISTORY = + MOS_EEV_framestore_top_chip 0.100 The last HISTORY kewyord is continued on two lines. This is used for visual inspection only, and the fact that, being FITS-like, it fits (sic!) into 80 characters allows easy display on any terminal. I am NOT advocating this latter (the "plus" convention) as a proposed solution, it is just an example to indicate that, IF "long" keyowrds are needed ONLY for documentation they CAN be handled as "comments" ----------------------------------------------------------------------------- A member of G.ASS : Group for Astronomical Software Support ----------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR Milano | U N I C U I Q U E via Bassini 15 - I-20133 Milano - Italy | System Manager Internet: LUCIO at IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: | ----------------------------------------------------------------------------- From fitsbits-request Wed May 26 14:35:43 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["986" "Wed" "26" "May" "1993" "19:33:41" "GMT" "Pat Murphy" "pmurphy at cv3.CV.NRAO.EDU " nil "22" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11236; Wed, 26 May 93 14:35:43 EDT Return-Path: Message-Id: Organization: National Radio Astronomy Observatory Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!pmurphy References: <9305242033.AA16610 at tetra.gsfc.nasa.gov> <1993May25.211915.29449 at sal.wisc.edu> From: pmurphy at cv3.CV.NRAO.EDU (Pat Murphy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Wed, 26 May 1993 19:33:41 GMT "GH" == Greg Hennessy writes: GH> Jeffrey W Percival writes: JP> Use realloc(3) as you find each continuation. No upper limits need JP> be known. GH> And what about those who use computers that don't have realloc? Not GH> very flexible it seems. realloc is part of posix.1 so it's available on at least a fairly reasonable subset of systems. At least unix systems... and no, this doesn't answer the question. - Pat -- ========================================================================== | Patrick P. Murphy, Ph.D. Scientific Programming Analyst | | National Radio Astronomy Observatory Net: pmurphy at nrao.edu | | 520 Edgemont Road Phone: (804) 296-0372 | | Charlottesville, VA 22903-2475 VoiceMail: (804) 980-5889 | | "I don't believe in the no-win scenario" --- James T. Kirk | ========================================================================== From fitsbits-request Wed May 26 15:09:09 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["755" "Wed" "26" "May" "1993" "16:20:55" "GMT" "Jeffrey W Percival" "jwp at sal.wisc.edu " nil "17" "Re: HEASARC Continuation Keyword Convention" "^From:" nil nil "5"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11249; Wed, 26 May 93 15:09:09 EDT Return-Path: Message-Id: <1993May26.162055.17810 at sal.wisc.edu> Organization: Space Astronomy Lab, Madison WI Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!sal.wisc.edu!jwp References: <1993May25.211915.29449 at sal.wisc.edu> From: jwp at sal.wisc.edu (Jeffrey W Percival) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HEASARC Continuation Keyword Convention Date: Wed, 26 May 1993 16:20:55 GMT In article gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) writes: >Jeffrey W Percival writes: >#Use realloc(3) as you find each continuation. No upper limits need be known. > >And what about those who use computers that don't have realloc? The original comment referred to a call to malloc(), hence my refere