From dlc at convex.com Thu Aug 20 18:51:16 1992 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 9 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["660" "Mon" "10" "August" "1992" "12:53:14" "GMT" "Dominique Le Corre" "dlc at convex.com " nil "18" "AVS module to read FITS files." "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Nntp-Posting-Host: convex1.convex.com Organization: CONVEX Computer Corporation, Richardson, Tx., USA Distribution: sci.astro.fits alt.sci.astro.fits comp.graphics.avs X-Disclaimer: This message was written by a user at CONVEX Computer Corp. The opinions expressed are those of the user and not necessarily those of CONVEX. From: dlc at convex.com (Dominique Le Corre) Subject: AVS module to read FITS files. Date: Mon, 10 Aug 1992 12:53:14 GMT A new AVS module is available for astronomers at IAC (avs.ncsc.org). This module, called read_fits, reads into an AVS field primary data, image extensions, Ascii tables, fixed and variable length binary tables >from any HDU of a FITS formatted file. It can also display keywords and table components in a text window. It handles byte, 16-bit integer, 32-bit integer, 32-bit real and 64-bit real data. It also supports complex and double complex data for tables only in the text window. It is based on the FITSIO package from W.D. Pence. Enjoy it. D. LE CORRE CONVEX S.A 9,Ave Ampere 78180 Montigny-le-Bx France E-mail : dlc at cvxfr.fr.convex.com (short term) From sped at galileo.ifa.hawaii.edu Mon Aug 24 21:12:38 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["376" "" "24" "August" "92" "22:20:13" "GMT" "Byron Han" "sped at galileo.ifa.hawaii.edu " nil "9" "FITS IO in C?" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Organization: Institute for Astronomy, Hawaii Nntp-Posting-Host: galileo.ifa.hawaii.edu From: sped at galileo.ifa.hawaii.edu (Byron Han) Subject: FITS IO in C? Date: 24 Aug 92 22:20:13 GMT Does anyone have a fits IO package written in C (equivalent to, say, the FISIO package in Fortran by Pence at NASA/GSFC)? Or better yet, does anyone have any image processing software that runs on a Macintosh that can import/export FITS images? (I am aware of Image from NIH but am looking for something with a better focus on astronomical applications) Thanks in advance. From dwells at fits.cv.nrao.edu Wed Aug 26 17:53:13 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6986" "Wed" "26" "August" "1992" "22:52:29" "GMT" "Don Wells" "dwells at fits.cv.nrao.edu " nil "142" "FITS Basics (Monthly Posting)" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Organization: nrao Distribution: sci From: dwells at fits.cv.nrao.edu (Don Wells) Subject: FITS Basics (Monthly Posting) Date: Wed, 26 Aug 1992 22:52:29 GMT I am posting the following text for Barry Schlesinger, whose news posting facility is temporarily broken. -Don ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 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 or data set. 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 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). 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/OSSA 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. This document is available only in hard copy form. NASA is sponsoring development of a formal standard for FITS. The goal of this process is a document consistent with 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 current draft, 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 stored in the data matrix defined in the first of the four papers. The basic agreement appears verbatim in the User's Guide, and the substance is incorporated in the Draft NASA Standard. 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. It includes copies of the current draft NASA Standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. 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 README. file describes the contents of the directory. A SOFTWARE subdirectory, described by an included README.FIRST file, 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. An included README.FIRST file contains details. Paper copies of many of the documents listed above can be obtained from the NOST Librarian. Paper 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/OSSA Office of Standards and Technology Code 633 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Telephone: (301)286-3575 8 a. m. - 5 p. m., U. S. Eastern Time Please mention this posting in your request. Barry M. Schlesinger Coordinator, NASA/NSSDC NOST FITS Support Office (301) 513-1634 fits at nssdca.gsfc.nasa.gov NCF::FITS -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From cflatter at nrao.edu Wed Aug 26 21:22:13 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["140" "Wed" "26" "August" "1992" "23:15:36" "GMT" "Chris Flatters" "cflatter at nrao.edu " nil "5" "Year 2000" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Reply-To: cflatter at nrao.edu Organization: NRAO From: cflatter at nrao.edu (Chris Flatters) Subject: Year 2000 Date: Wed, 26 Aug 1992 23:15:36 GMT Dates in FITS are stored using two digits for the year. Has anyone thought about what happens in 2000? Chris Flatters cflatter at nrao.edu From eychaner at suncub.bbso.caltech.edu Thu Aug 27 20:53:09 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["947" "" "27" "August" "92" "01:21:24" "GMT" "Another casualty of applied metaphysics" "eychaner at suncub.bbso.caltech.edu " nil "17" "Re: Year 2000" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Reply-To: eychaner at suncub.bbso.caltech.edu Organization: Big Bear Solar Observatory, Caltech Nntp-Posting-Host: suncub.bbso.caltech.edu From: eychaner at suncub.bbso.caltech.edu (Another casualty of applied metaphysics) Subject: Re: Year 2000 Date: 27 Aug 92 01:21:24 GMT cflatter at nrao.edu (Chris Flatters) writes: >Dates in FITS are stored using two digits for the year. Has anyone thought >about what happens in 2000? Sure; dates show up as 01/01/00, for example. Personally, my software is designed to interpret a two-digit date between 1970 and 2069; considering this site was built in 1969, it seemed a reasonable choice. You could, of course, choose a different start date. Eventually, it will break, but I suspect it will be obsolete before then. -G. ****************************************************************************** Glenn Eychaner, Big Bear Solar Observatory, California Institute of Technology NSI/DECnet: SUNCUB::EYCHANER Internet: eychaner at suncub.bbso.caltech.edu USmail: 40386 North Shore Lane eychaner_g at caltech.edu Big Bear City, CA 92314 Phone: (714) 866-5791 or (818) 356-4014 (909) after November 14, 1992 From thompson at stars.gsfc.nasa.gov Thu Aug 27 20:54:07 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["977" "Thu" "27" "August" "1992" "14:07:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "24" "Re: Year 2000" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Subject: Re: Year 2000 Date: Thu, 27 Aug 1992 14:07:00 GMT In article <1992Aug26.231536.5504 at nrao.edu>, cflatter at nrao.edu writes... >Dates in FITS are stored using two digits for the year. Has anyone thought >about what happens in 2000? > > Chris Flatters > cflatter at nrao.edu I've been looking into this for the SOHO program. Currently, I've been looking into a CCSDS standard "Time Code Formats" CCSDS 301.0-B-2. I believe this is also an ISO standard, but the number eludes me right now. Basically, the standard allows you to enter dates in the form, e.g. 1992-08-27T10:03:38.123 There's also an alternate form that allows you to use day-of-year rather than month and day. Either the date or time part can be left out, in which case the "T" separater is omitted. The fractional seconds is optional, and can be to any precision desired. Although I like FITS, and plan to use it, I find the eight character limit very constraining. As one person I work with said, "It's like programming in FORTRAN 2". Bill Thompson From warnock at Hypatia.gsfc.nasa.gov Thu Aug 27 20:54:25 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["716" "" "27" "August" "92" "14:11:52" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "15" "Re: Year 2000" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Reply-To: warnock at hypatia.gsfc.nasa.gov Organization: Hughes STX at Goddard Space Flight Center Nntp-Posting-Host: hypatia.gsfc.nasa.gov From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Subject: Re: Year 2000 Date: 27 Aug 92 14:11:52 GMT In article <27AUG199210071784 at stars.gsfc.nasa.gov>, thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes: |> Although I like FITS, and plan to use it, I find the eight character limit very |> constraining. As one person I work with said, "It's like programming in |> FORTRAN 2". And we're all the way up to FORTRAN 77, with 90 due out RSN . Seriously, though, it's supposed to be that way - maximum portability and all that... -- ---------------------------------------------------------------------------- -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC From cflatter at nrao.edu Thu Aug 27 20:54:42 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["630" "Thu" "27" "August" "1992" "16:07:06" "GMT" "Chris Flatters" "cflatter at nrao.edu " nil "14" "Re: Year 2000" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Reply-To: cflatter at nrao.edu Organization: NRAO From: cflatter at nrao.edu (Chris Flatters) Subject: Re: Year 2000 Date: Thu, 27 Aug 1992 16:07:06 GMT In article 27AUG199210071784 at stars.gsfc.nasa.gov, thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes: >In article <1992Aug26.231536.5504 at nrao.edu>, cflatter at nrao.edu writes... >>Dates in FITS are stored using two digits for the year. Has anyone thought >>about what happens in 2000? >> >> Chris Flatters >> cflatter at nrao.edu > >I've been looking into this for the SOHO program. Currently, I've been looking >into a CCSDS standard "Time Code Formats" CCSDS 301.0-B-2. I believe this is >also an ISO standard, but the number eludes me right now. A usually reliable source tells me that it is ISO 8601 From thompson at stars.gsfc.nasa.gov Thu Aug 27 20:55:50 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6236" "" "27" "August" "92" "16:11:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "156" "Re: Year 2000" "^From:" nil nil "8"]) Newsgroups: sci.astro.fits Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Subject: Re: Year 2000 Date: 27 Aug 92 16:11:00 GMT In article <27AUG199210071784 at stars.gsfc.nasa.gov>, I wrote ... >In article <1992Aug26.231536.5504 at nrao.edu>, cflatter at nrao.edu writes... >>Dates in FITS are stored using two digits for the year. Has anyone thought >>about what happens in 2000? >> >> Chris Flatters >> cflatter at nrao.edu > >I've been looking into this for the SOHO program. Currently, I've been >looking into a CCSDS standard "Time Code Formats" CCSDS 301.0-B-2. I believe >this is also an ISO standard, but the number eludes me right now. ... I found my reference. I believe that the CCSDS standard mentioned above also corresponds to ISO 8601, although I can't get a copy of that document. I do include below the relevant passage from CCSDS 301.0-B-2. Bill Thompson ------------------------------------------------------------------------------- CCSDS RECOMMENDATION FOR TIME CODE FORMATS 2.5 CCSDS ASCII CALENDAR SEGMENTED TIME CODE (ASCII) 2.5.1 T-FIELD The CCSDS ASCII segmented time code is composed of a variable number of ASCII characters forming the T-field. Both ASCII time code variations are UTC-based and leap second corrections must be made. The time represented is intended to match civil time usage. Therefore, the epoch is taken to be the usual Gregorian calendar epoch of 1 AD, and the time is that of the prime meridian. The ASCII time code Recommendations are Level 1 time code formats. 2.5.1.1 ASCII TIME CODE A, Month/Day of Month Calendar Variation: The format for ASCII Time Code A is as follows: YYYY-MM-DDThh:mm:ss.d->dZ where each character is an ASCII character using one octet with the following meanings: YYYY = Year in four-character subfield with values 0001-9999 MM = Month in two-character subfield with values 01-12 DD = Day of month in two-character subfield with values 01-28, -29, -30, or -31 "T" = Calendar-Time separator hh = Hour in two-character subfield with values 00-23 mm = Minute in two-character subfield with values 00-59 ss = Second in two-character subfield with values 00-59 (-58 or -60 during leap seconds) d->d = Decimal fraction of second in one- to n-character subfield where each d has values 0-9 "Z" = time code terminator (optional) Note that the hyphen (-), colon (:), letter "T" and period (.) are used as specific subfield separators, and that all subfields must include leading zeros. As many "d" characters to the right of the period as required may be used to obtain the required precision. An optional terminator consisting of the ASCII character "Z" may be placed at the end of the time code. EXAMPLE: 1988-01-18T17:20:43.123456Z 2.5.1.2 ASCII TIME CODE B, Year/Day of Year Calendar Variation: The format for ASCII Time Code B is as follows: YYYY-DDDThh:mm:ss.d->dZ where each character is an ASCII character using one octet with the following meanings: YYYY = Year in four-character subfield with values 0001-9999 DDD = Day of year in three-character subfield with values 001-365 or -366 "T" = Calendar-Time separator HH = Hour in two-character subfield with values 00-23 MM = Minute in two-character subfield with values 00-59 SS = Second in two-character subfield with values 00-59 (-58 or -60 during leap seconds) d->d = Decimal fraction of second in one- to n-character subfield where each d has values 0-9 "Z" = time code terminator (optional) Note that the hyphen (-), colon (:), letter "T" and period (.) are used as specific subfield separators, and that all subfields must include leading zeros. As many "d" characters to the right of the period as required may be used to obtain the required precision. An optional terminator consisting of the ASCII character "Z" may be placed at the end of the time code. EXAMPLE: 1988-018T17:20:43.123456Z 2.5.1.3 SUBSETS OF THE COMPLETE TIME CODES: When it is desired to use SUBSETS of each of the TWO ASCII time code format variations described above, the following rules must be observed: a. The "calendar" subset (all subfields to the left of the "T") and the "time" subset (all subfields to the right of the "T") may be used independently as separate "calendar" or "time" formats, provided the context in which each subset is used makes its interpretation unambiguous. b. When calendar or time subsets are used alone, the "T" separator is omitted. c. Calendar or time subsets may contain all the defined subfields, or may be abbreviated to the span of interest by deleting the unneeded subfields, either on the left or on the right. However, when subfields are deleted on the LEFT, all separators that had delimited the deleted subfields must be retained (except for the "T" which, by rule b, is dropped if the subset is used alone.) When subfields are deleted on the RIGHT, the separators that had delimited the deleted subfields are dropped. d. Subsets may NOT consist of partial subfields (e.g., must use "ss", not "s"). In particular, consistent use of the complete four-character YYYY subfield is required (e.g., "1989" instead of "89") because of the need to accommodate the upcoming century rollover in only 1 1 years. Note, however, that each fractional second ("d" character) is considered to be a complete subfield, and so any number of fractional seconds may be used. e. If calendar and time SUBSETS are then brought together to form a single time code format (joined with the "T" separator) the CALENDAR subset may NOT have been truncated from the RIGHT,.and the TIME subset may NOT have been truncated from the LEFT. That is, the format must be integral around the "T". f. Standardization on the use of these time code formats for purposes OTHER than identifying an instant of calendar or time in UTC (e.g., unconventional use as a counter or tool for measuring arbitrary intervals) is not recommended. It is felt such a specialized application can best be viewed not as a time code format but rather as an engineering measurement format. Any such application of these time code formats is considered beyond the scope of this recommendation. 2.5.2 P-FIELD: There is no P-field identifying the ASCII Time Code Formats. The P-field information is implicit in the parsing of the ASCII time code.