From fitsbits-request Thu Dec 17 09:23:08 1992 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 8 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4893" "Thu" "17" "December" "1992" "13:54:50" "GMT" "Don Jennings" "jennings at antwrp.antwrp.gsfc.nasa.gov " nil "95" "VAX R*8 to FITS/IEEE R*8 conversion problem" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01263; Thu, 17 Dec 92 09:23:08 EST Return-Path: Message-Id: Organization: Compton Gamma Ray Observatory Science Support Center Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!nsisrv!news2.gsfc.nasa.gov!jennings From: jennings at antwrp.antwrp.gsfc.nasa.gov (Don Jennings) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: VAX R*8 to FITS/IEEE R*8 conversion problem Date: Thu, 17 Dec 1992 13:54:50 GMT My organization often needs to convert data that is native to the VAX architecture into a FITS format. Since the VAX real*8 bit pattern is different >from the FITS/IEEE real*8 bit pattern, it is not possible to completely encapsulate a VAX real*8 in a IEEE real*8; specificly, a loss of precision occurs when transforming a VAX real*8 into an IEEE real*8. One solution we have devised is to save the 7th byte of VAX real*8 values, where the loss of precision occurs, and add them to a column of the binary table where the real*8 values are being stored. The following is a suggested list of rules for the extra column: It would always be the last column of the table. Each column entry would contain the 7th byte of all real*8 values occurring in a given row. Thus, if a table row contained 5 real*8 values, then the extra column's TFORM code would be 8B, if the row contained any real*8 variable length array entries then the extra column's TFORM code would be PB(XXXX). FITS readers residing on non-VAX architectures would be able to ignore the extra column, while VAX FITS readers could completely reconstruct the original real*8 value by reading the extra column's values. Has anyone out there had this problem? Does anyone out there have a different solution? If so, then I would like to hear from you. Please send/post any general comments on the above scheme you might have as well. Don Jennings, COSSC/GSFC From fitsbits-request Thu Dec 17 11:30:32 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2987" "Thu" "17" "December" "92" "11:30:58" "EST" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "56" "Re: VAX R*8 to FITS/IEEE R*8 conversion problem" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01393; Thu, 17 Dec 92 11:30:32 EST Return-Path: Message-Id: <9212171630.AA05949 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: VAX R*8 to FITS/IEEE R*8 conversion problem Date: Thu, 17 Dec 92 11:30:58 EST Don Jennings wrote: > My organization often needs to convert data that is native to the VAX > architecture into a FITS format. Since the VAX real*8 bit pattern is different > from the FITS/IEEE real*8 bit pattern, it is not possible to completely > encapsulate a VAX real*8 in a IEEE real*8; specificly, a loss of precision > occurs when transforming a VAX real*8 into an IEEE real*8. > > One solution we have devised is to save the 7th byte of VAX real*8 values, > where the loss of precision occurs, and add them to a column of the binary > table where the real*8 values are being stored. The following is a suggested > list of rules for the extra column: > > It would always be the last column of the table. > > Each column entry would contain the 7th byte of all real*8 values > occurring in a given row. Thus, if a table row contained 5 real*8 > values, then the extra column's TFORM code would be 8B, if the I think you mean 5B, not 8B (?) > row contained any real*8 variable length array entries then the > extra column's TFORM code would be PB(XXXX). > > FITS readers residing on non-VAX architectures would be able to ignore the > extra column, while VAX FITS readers could completely reconstruct the original > real*8 value by reading the extra column's values. My reaction to this is that it is not very useful to put information in a FITS file that only a particular machine will be able to interpret. One of the main purposes of FITS is to make the information in the file portable to any machine. So I think you have 2 choices. 1. If this added precision in the VAX value is really significant, then you need to find a portable way of including it in the FITS file. One way might be to express the double precision value as 2 columns: one containing the integer part, and the other containing the fractional part of the value. 2. If the added precision in the VAX value is not really significant (the VAX G_floating datatype has effectively 4 more bits of precision than an IEEE R*8 value) then one should not worry about it, and one should accept the fact that the FITS file cannot preserve every last bit of information on every type of machine. As an aside, I'm sure you are aware that the VAX has 2 different R*8 data representations. The default D_floating representation which you are probably using reserves 8 bits for the exponent and 55 bits for the mantissa. The G_floating representation on the otherhand is similar to the IEEE R*8 representation: both have 11 bits for the exponent and 52 bits for the mantissa. The G_floating and IEEE values are still not identical though because the VAX interprets the exponent and mantissa numbers as normalized, ("hidden bit normalization") which effectively gives you another bit of precision compared to the IEEE value. If you were to use G_floating on the VAX, you probably would not notice the loss of precision in converting the data back and forth from FITS. -Bill Pence From fitsbits-request Thu Dec 17 12:24:41 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["11157" "Thu" "17" "December" "92" "17:58:58" "ITA" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "222" "Re: VAX R*8 to FITS/IEEE R*8 conversion problem" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01442; Thu, 17 Dec 92 12:24:41 EST Resent-Message-Id: <9212171724.AA01442 at fits.cv.nrao.edu> Return-Path: < at vm.cnuce.cnr.it:EXOSAT at IMISIAM.BITNET> Message-Id: <9212171724.AA01436 at fits.cv.nrao.edu> Organization: Istituto di Fisica Cosmica e Tecnologie Relative In-Reply-To: Message of Thu, 17 Dec 92 11:30:58 EST from X-Acknowledge-To: Resent-Sender: Lucio Chiappetti From: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU Resent-From: fitsbits-request To: fitsbits at fits.CV.NRAO.EDU Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion problem Date: Thu, 17 Dec 92 17:58:58 ITA Resent-Date: Thu, 17 Dec 92 17:58:58 ITA On Thu, 17 Dec 92 11:30:58 EST William Pence said: >Don Jennings wrote: > >> My organization often needs to convert data that is native to the VAX >> architecture into a FITS format. Since the VAX real*8 bit pattern is >different >> from the FITS/IEEE real*8 bit pattern, it is not possible to completely >> encapsulate a VAX real*8 in a IEEE real*8; specificly, a loss of precision >> occurs when transforming a VAX real*8 into an IEEE real*8. > >My reaction to this is that it is not very useful to put information in a FITS > file >that only a particular machine will be able to interpret. One of the main > purposes of >FITS is to make the information in the file portable to any machine. I would tend to agree with Bill on this. > >1. If this added precision in the VAX value is really significant, .... >2. If the added precision in the VAX value is not really significant ... > I had recently the converse concern of this, that is not about the added precision in the Vax representation, but the fact that the IEEE representation for REAL*8 allows a wider range of exponents, larger than the 1.E-38 to 1.E38 allowed by usual (D_FLOAT) on Vax (as clearly stated by Bill here below) >As an aside, I'm sure you are aware that the VAX has 2 different R*8 data >representations. The default D_floating representation which you are probably > using >reserves 8 bits for the exponent and 55 bits for the mantissa. The G_floating >representation on the otherhand is similar to the IEEE R*8 representation: >both >have 11 bits for the exponent and 52 bits for the mantissa. The G_floating >and IEEE values are still not identical though because the VAX interprets the >exponent and mantissa numbers as normalized, ("hidden bit normalization") which >effectively gives you another bit of precision compared to the IEEE value. >If you were to use G_floating on the VAX, you probably would not notice the >loss of precision in converting the data back and forth from FITS. > I recently was engaged in setting up something able to exchange files between Vaxes (2-complement byteswapped integers, Vax format REAL*4 and REAL*8 D_FLOATs), Suns (2-complement integers, IEEE REAL*4 and REAL*8) and DECstations (2-complement byteswapped integers, byteswapped IEEE REAL*4 and *8). The idea was to copy the files and convert them in place without passing through an intermediate FITS file. The idea is to use some simple routines, and to change the file in place on the destination machine (therefore only a conversion foreign-->local is needed on each operating system) The byteswap can be easily handled in Fortran in a portable way. For the conversion from IEEE to Vax format on VMSI use some assembler routines kindly provided by Bill in his FITSIO packages (on copyright from the IRAF team). The R*4 Vax to IEEE can be easily handled in Fortran on Unix, due to the fact that all what is needed is to shuffle bytes and adjust the exponent bias. I have for the moment suspended work on the R*8 Vax to IEEE conversion because I need to clear my mind. The conversion from G_FLOAT would be analogous to the R*4 one, but the one for D_FLOAT (the reverse of the ieeed routine in the IRAF VMS assembler routine) is not obviously done in Fortran. What I am uncertain of, is whether I should continue using D_FLOAT on Vax or move to G_FLOAT. I actually use quite a limited amount of REAL*8 values, and I was always happy with applying some scale factors when exceeding the exponent range (1.OE38 for both R*4 and D_FLOAT R*8). From the quoted assembler routine I derive that IRAF does the same. I would appreciate to know other people's opinion on the matter whether G_FLOAT should be recommended on VMS for IEEE compatibility, or not. ----------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR Milano | U N I C U I Q U E via Bassini 15 - I-20133 Milano - Italy | System Manager Internet: LUCIO at IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: EXOSAT at IMISIAM | ----------------------------------------------------------------------------- From fitsbits-request Thu Dec 17 13:09:26 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1411" "Thu" "17" "December" "1992" "18:09:12" "GMT" "Chris Flatters" "cflatter at cv3.CV.NRAO.EDU " nil "24" "Re: VAX R*8 to FITS/IEEE R*8 conversion prob" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01462; Thu, 17 Dec 92 13:09:26 EST Return-Path: Message-Id: <1992Dec17.180912.16963 at nrao.edu> Organization: NRAO Path: cv3.cv.nrao.edu!laphroaig!cflatter References: <9212171630.AA05949 at tetra.gsfc.nasa.gov> Reply-To: cflatter at cv3.CV.NRAO.EDU From: cflatter at cv3.CV.NRAO.EDU (Chris Flatters) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion prob Date: Thu, 17 Dec 1992 18:09:12 GMT In article AA05949 at tetra.gsfc.nasa.gov, pence at tetra.gsfc.nasa.gov (William Pence) writes: >As an aside, I'm sure you are aware that the VAX has 2 different R*8 data >representations. The default D_floating representation which you are probably using >reserves 8 bits for the exponent and 55 bits for the mantissa. The G_floating >representation on the otherhand is similar to the IEEE R*8 representation: both >have 11 bits for the exponent and 52 bits for the mantissa. The G_floating >and IEEE values are still not identical though because the VAX interprets the >exponent and mantissa numbers as normalized, ("hidden bit normalization") which >effectively gives you another bit of precision compared to the IEEE value. >If you were to use G_floating on the VAX, you probably would not notice the >loss of precision in converting the data back and forth from FITS. IEEE values are also normalized as long as they are greater than or equal to 2 ** E_min, where E_min is the minimum exponent. An IEEE-754 double has a precision of 53 base-2 digits (identical to VAX G-floating) as long as E >= E_min (E_min = -1022). VAX G-floating and IEEE-754 doubles probably differ in the bias of the exponent (this is the difference between normalized IEEE singles and VAX F-floats). Incidentally, if you think about it you will realize that the exponent can not be normalized. Chris Flatters cflatter at nrao.edu From fitsbits-request Thu Dec 17 16:25:18 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1259" "Thu" "17" "December" "1992" "19:53:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "28" "Re: Re: VAX R*8 to FITS/IEEE R*8 conversion problem" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01571; Thu, 17 Dec 92 16:25:18 EST Return-Path: Message-Id: <17DEC199215532833 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!caen!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!nsisrv!stars.gsfc.nasa.gov!thompson References: <9212171724.AA01436 at fits.cv.nrao.edu> From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Re: VAX R*8 to FITS/IEEE R*8 conversion problem Date: Thu, 17 Dec 1992 19:53:00 GMT In article <9212171724.AA01436 at fits.cv.nrao.edu>, Lucio Chiappetti writes... (stuff deleted) > The conversion from G_FLOAT would be analogous to the R*4 one, but the > one for D_FLOAT (the reverse of the ieeed routine in the IRAF VMS assembler > routine) is not obviously done in Fortran. > What I am uncertain of, is whether I should continue using D_FLOAT on Vax > or move to G_FLOAT. > > I actually use quite a limited amount of REAL*8 values, and I was always > happy with applying some scale factors when exceeding the exponent range > (1.OE38 for both R*4 and D_FLOAT R*8). From the quoted assembler routine > I derive that IRAF does the same. > > I would appreciate to know other people's opinion on the matter > whether G_FLOAT should be recommended on VMS for IEEE compatibility, > or not. I believe that G_FLOAT and H_FLOAT (REAL*16) are not supported on the new Alpha machines. We use IDL, which doesn't give the user the option of selecting D_FLOAT or G_FLOAT (and doesn't support quadruple-precision). On the VAX, it uses D_FLOAT numbers for double precision. (As an aside, IDL does provide built-in support for converting between IEEE and host formats, for all datatypes it supports.) Bill Thompson From fitsbits-request Thu Dec 17 16:25:21 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2235" "Thu" "17" "December" "1992" "20:04:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "42" "Re: VAX R*8 to FITS/IEEE R*8 conversion problem" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01580; Thu, 17 Dec 92 16:25:21 EST Return-Path: Message-Id: <17DEC199216040789 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!nsisrv!stars.gsfc.nasa.gov!thompson References: From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion problem Date: Thu, 17 Dec 1992 20:04:00 GMT In article , jennings at antwrp.antwrp.gsfc.nasa.gov (Don Jennings) writes... >My organization often needs to convert data that is native to the VAX >architecture into a FITS format. Since the VAX real*8 bit pattern is different >from the FITS/IEEE real*8 bit pattern, it is not possible to completely >encapsulate a VAX real*8 in a IEEE real*8; specificly, a loss of precision >occurs when transforming a VAX real*8 into an IEEE real*8. > >One solution we have devised is to save the 7th byte of VAX real*8 values, >where the loss of precision occurs, and add them to a column of the binary >table where the real*8 values are being stored. The following is a suggested >list of rules for the extra column: > > It would always be the last column of the table. This statement alone raises warning flags in my mind. I'm firmly of the opinion that the structure of binary tables should not in any way depend on the order in which the columns appear. If you're going to do something like this, you should indicate the column with an appropriate label (TTYPE). > > Each column entry would contain the 7th byte of all real*8 values > occurring in a given row. Thus, if a table row contained 5 real*8 > values, then the extra column's TFORM code would be 8B, if the > row contained any real*8 variable length array entries then the > extra column's TFORM code would be PB(XXXX). > >FITS readers residing on non-VAX architectures would be able to ignore the >extra column, while VAX FITS readers could completely reconstruct the original >real*8 value by reading the extra column's values. > >Has anyone out there had this problem? Does anyone out there have a >different solution? If so, then I would like to hear from you. Please >send/post any general comments on the above scheme you might have as well. > > Don Jennings, COSSC/GSFC If that last byte is important, than it will be important regardless of what computer you're analyzing the data on. If so, then a better, more machine-independent way of transferring the full significance of the data has to be devised. If it isn't important, then one shouldn't worry about it. Bill Thompson From fitsbits-request Fri Dec 18 12:14:04 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1322" "Fri" "18" "December" "92" "09:16:13" "+0100" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "24" "Re: VAX R*8 to FITS/IEEE R*8 conversion problem" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03134; Fri, 18 Dec 92 12:14:04 EST Resent-Message-Id: <9212181714.AA03134 at fits.cv.nrao.edu> Return-Path: < at vm.cnuce.cnr.it:EXOSAT at IMISIAM.BITNET> Resent-Organization: Istituto di Fisica Cosmica e Tecnologie Relative Resent-To: fitsbits at fits.CV.NRAO.EDU Message-Id: <199212180817.AA03568 at chenas.inria.fr> Posted-Date: Fri, 18 Dec 92 09:16:13 +0100 X-Acknowledge-To: From: Lucio Chiappetti From: forveill at gag.observ-gr.fr (Thierry Forveille) Sender: fitsbits-request at fits.CV.NRAO.EDU Resent-From: at vm.cnuce.cnr.it:EXOSAT at IMISIAM.BITNET To: lucio at ifctr.mi.cnr.it Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion problem Date: Fri, 18 Dec 92 09:16:13 +0100 Resent-Date: Fri, 18 Dec 92 18:09:09 ITA I received the mail below from Thierry Forveille privately, but then we both considered it could be of interest to the list, so I am forwarding it below. Lucio Chiappetti ----------------------------Original message---------------------------- We actually have available some fortran code that performs the transformations you need and which I can send you if you like. It was developped for exactly the kind of application you contemplate, transparent access to data files accross an heterogeneous network. In addition to what you request, we also support conversion to non-native formats since we also want to modify files on other machines, not only read them. The code is written in fortran (I agree the R*8 conversion is non trivial!) and performs all possible conversions between Vax and both flavours of IEEE (little and big endians), and has versions for all three types of hardware (for efficiency, it uses integer multiplications instead of bit shifts where it can). All IEEE special values are handled (infinities, NaNs...) are handled, and converted to a user specified blanking value. These routines have been extensively used for about two years, and work without user complaints... Thierry Forveille Observatoire de Grenoble forveill at gag.observ-gr.fr From fitsbits-request Fri Dec 18 16:47:07 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["8015" "Fri" "18" "December" "1992" "21:01:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "158" "FITS basics and information (periodic posting)" "^From:" nil nil "12"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03321; Fri, 18 Dec 92 16:47:07 EST Return-Path: Message-Id: <18DEC199216012686 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!nsisrv!nssdca.gsfc.nasa.gov!bschlesinger From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS basics and information (periodic posting) Date: Fri, 18 Dec 1992 21:01:00 GMT 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/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 expressed in FITS. 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 NASA draft 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. 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 suggested method for data compression under FITS. It also contains text of a paper summarizing conclusions of a workshop on World Coordinates held in Charlottesville in 1988, which is serving as the basis for continuing discussion of world coordinates issues, some of which appears on this newsgroup from time to time. These documents are available in both LaTeX and PostScript forms. 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. 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/OSSA 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: (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. Barry M. Schlesinger Coordinator, NASA/NSSDC NOST FITS Support Office (301) 513-1634 fits at nssdca.gsfc.nasa.gov NCF::FITS