From fitsbits-request Wed Sep 1 18:10:41 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3508" "Wed" "1" "September" "93" "18:09:37" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "72" "HDUCLASn keywords" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01238; Wed, 1 Sep 93 18:10:41 EDT Return-Path: Message-Id: <9309012209.AA21329 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Cc: pence at tetra.gsfc.nasa.gov Subject: HDUCLASn keywords Date: Wed, 1 Sep 93 18:09:37 EDT As was posted here previously, the HEASARC plans to use a hierarchy of HDUCLAS1, HDUCLAS2, ... FITS keywords to classify each type of FITS extension (Header and Data Unit) that it creates. An example of this would be HDUCLAS1 = 'GTI' (For Good Time Intervals extension) and HDUCLAS2 = 'STANDARD' or HDUCLAS2 = 'ALL' depending on whether it contains all the good time intervals, or only the standard set of intervals. Before implementing this scheme, however, a debate arose here about whether it would be useful to reserve the top level 'HDUCLAS1' keyword as an identifier for different diciplines, or oranizations that had defined the lower level hierarchy of HDUCLASn keywords. For example, we could have: HDUCLAS1 = 'OGIP' or 'XRAY' HDUCLAS2 = 'GTI' HDUCLAS3 = 'STANDARD' This would immediately tell software and users that this file follows some standard defined by the OGIP (or is an XRAY type file), as opposed to some FITS file which may have been defined by NRAO for instance for radio data. This could be useful if different groups choose the same class name, such as 'SPECTRUM' for files which have entirely different format and keywords (an radio FITS spectral file will probably look very different from an Xray FITS spectral file). It was argued that without this extra hierarchical layer, others in the community would be reluctant to use the HDUCLASn keywords and if they did, the lack of standardization on permitted HDUCLAS1 keyword values would cause confusion. There were a number of objections to this suggestion, however: - This use of the HDUCLAS1 keyword as a 'family' label is rather different from the intended use of providing a hierarchical classification of the scientific content of file. Thus, it may be better to use a separate distinct keyword to define this if it is really necessary. - In practice, there are many other keywords or combinations of keywords in the header (TELESCOP, INSTRUME, AUTHOR), which at least implicitly identify the source or origin of the file. - in most cases the software will simply have to skip over the HDUCLAS1 keyword before looking at the HDUCLAS2 and higher keywords to determine which type of FITS extension it is. This wastes header space and CPU cycles. - this may lead to geo-political copyright disputes over which group first defines certain new classes of extensions. For instance, SAO and the HEASARC may well define similar formats to store xray data. Does one institution then get all the credit in the header, by having HDUCLAS1 = 'SAO' in all those types of FITS files. Or if the HDUCLAS1 keyword has a broad definition e.g., 'XRAY' then it may seem presumptuous for one group to define a new class and expect that all other XRAY groups should recognize and adopt it. - just because the OGIP decides not to use the HDUCLAS1 keyword in this way does not prevent other groups from doing so. For instance NRAO could uniquely identify all it's FITS files with HDUCLAS1= 'NRAO' if it wanted to. Given that we must make some decisions on the usage of HDUCLASn keywords in the next few days, we would like some input from other groups. Without strong opinions to the contrary, we will most likely not use HDUCLAS1 in the way described here. Do any other groups see a practical need for the HDUCLASn keywords, and do they think they might use them in their FITS files? If so do you have an opinion on whether or not the HDUCLAS1 keyword should be reserved as a generic family/institution identifier? -Bill Pence From fitsbits-request Thu Sep 2 04:33:35 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5220" "Thu" "2" "September" "1993" "10:01:00" "+0200" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "124" "Re: FITS Coordinate Keywords" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01704; Thu, 2 Sep 93 04:33:35 EDT Resent-Message-Id: <9309020833.AA01704 at fits.cv.nrao.edu> Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Reply-To: Lucio Chiappetti In-Reply-To: <9308312154.AA20977 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: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS Coordinate Keywords Date: Thu, 2 Sep 1993 10:01:00 +0200 (MET DST) Resent-Date: Thu, 2 Sep 1993 10:01:00 +0200 (MET DST) On Tue, 31 Aug 1993, William Pence wrote: > This note describes the 3 different sets of coordinate system keywords > that the HEASARC proposes to use within it's FITS files. One of these [...] > primary array). Any comments, criticisms, or suggestions about these > proposed sets of keywords are welcome. > Here are my 0.02 {currency_units} > --------------------------------------------------------------------------- > A. Possible FITS Image Representations > Are you concerned here only with "true" images (counts vs detector x,y and/or counts vs ra,dec), OR ALSO with any z=f(x,y) representation (e.g. z=response matrix, x=input energy y=output channel ; z=chisquare, x=log NH y=spectral index ; etc. etc.) ? I will be concerned also of the second case > > 1. Primary Array Coordinate Keywords > > All the keywords listed here, except for the last CUNIT keyword, > have been widely used in the FITS world and form the basis for > the 2 other sets of derived keywords. The CUNIT keyword has been > added for generality in cases where the axis units are not already > implied by the CTYPE value. This is the WCS convention set, isn't it ? This convention is essentially geared to celestial images and uses CTYPEm in a very specific way. However, it looks to be backward compatible with the basic FITS standard, in which CTYPEm can be anything (e.g. "Log NH" and "Spectral_Index") and one can use CRPIX,CRVAL,CDELT to manage a linear transformation. [an extension to WCS to handle LOGARITHMIC transformation would be useful] I would not forget BUNIT in the keyword list (that is, the units on the z axis) By the way ... in X-rays one usually has : * detector x,y "raw" coordinates * detector x,y "corrected" coordinates ( = raw if no distortions) arbitrary x,y rebinned pixels * celestial coordinates using WCS I generally assume that one may be interested only in the asterisked quantities (usually detector coords). DOES EVERYBODY AGREE ON THIS ? E.g. for an 8192x8192 detector, with a 273x273 images, anchored at pixel 2731,2731 and zoomed by a factor 10 one will have, conforming with the conventions : (J) NAXIS1 = 273 (J) NAXIS2 = 273 (C) BUNIT = PHOTONS (C) CTYPE1 = XPIX or name tbd (C) CTYPE2 = YPIX or name tbd (R) CRPIX1 = 1.00000 (R) CRPIX2 = 1.00000 (R) CRVAL1 = 2731.00 (R) CRVAL2 = 2731.00 (R) CDELT1 = 10.0000 (R) CDELT2 = 10.0000 > > 2. BINTABLE Array Coordinate Keywords > > In this case the image is represent by a vector column in a Binary Table. If I understand correctly the case mentioned here is the one in which each element of the table is a 10x20 image. I fail to understand why one may want to do this, and I'll certainly not use nor encourage use of columns with TDIMensionality greater than 1. Therefore I have no comments on the proposed convention since I will never make use of such complex format. The cases I'm considering are : table elements are scalar (e.g. one column contains energy, and the other contains counts/s) in this case the TUNITn are sufficient table elements are 1-d vectors (e.g. one column contains scalar time, and the other contains an entire spectrum, or the counts in several bands) In this case at the moment the description of what is on the single "depth" axis is undefined. Can your convention cope with it ? Is a different convention better ? Or does one instead need an ad-hoc convention case-by-case ? > 3. Table List Coordinate Keywords. > > In this case the image is not represented as an array, but instead each > pixel (or perhaps only each non-zero pixel) is listed separately on > multiple rows of a FITS table. Each row has a column for the X It looks like that what you have in mind here is a photon list where the coordinates are not detector x,y as usual, but directly RA and DEC. (Your convention is required, beyond usual TUNiTn, ONLY in such case, did I get it right ?) Does the transformation (projection) used to display a pre-accumulated image (which a photon list is not) really matter ? Can't you (if you really want to store RA and DEC) convert detector x,y to RA,DEC using the satellite attitude (better if stored in the file header, EVEN if one is keeping the file as detector x,y ... but you already have a separate convention for that) and leave any projection to the image accumulation/display software ? ----------------------------------------------------------------------------- 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 Thu Sep 2 04:44:13 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4706" "Thu" "2" "September" "1993" "10:16:42" "+0200" "Lucio Chiappetti" "lucio at IFCTR.MI.CNR.IT" nil "100" "Re: HDUCLASn keywords" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01713; Thu, 2 Sep 93 04:44:13 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative In-Reply-To: <9309012209.AA21329 at tetra.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HDUCLASn keywords Date: Thu, 2 Sep 1993 10:16:42 +0200 (MET DST) On Wed, 1 Sep 1993, William Pence wrote: > As was posted here previously, the HEASARC plans to use a hierarchy of > HDUCLAS1, HDUCLAS2, ... FITS keywords to classify each type of [...] > > Before implementing this scheme, however, a debate arose here about > whether it would be useful to reserve the top level 'HDUCLAS1' keyword > as an identifier for different diciplines, or oranizations that > had defined the lower level hierarchy of HDUCLASn keywords. [...] > It was argued that without this extra hierarchical layer, others in the > community would be reluctant to use the HDUCLASn keywords and if they did, > the lack of standardization on permitted HDUCLAS1 keyword values would > cause confusion. Yes Or at least I think it is wise to have a "signature" in the file which tells what convention is used (this could be also useful for other "quick classification" of the files, sort of (although not completely) the discussion going over on sci.data.formats ... I'm thinking here of some sort of "magic number" to be used by the "file" command. One already has SIMPLE=T for FITS, could have XTENSION=something for extensions, e.g. to tell a bintable, just one more keyword can identify the convention used and then convention dependent keywords, so one could tell a file is a i ii iii iv ... FITS BINTABLE OGIP SPECTRUM ... or a FITS BINTABLE MIDAS Photonlist or a XAS TABLE SPECTRUM (non FITS file) or a FITS BINTABLE XAS SPECTRUM (same stored in FITS) etc. > There were a number of objections to this suggestion, however: > > - This use of the HDUCLAS1 keyword as a 'family' label is rather > different from the intended use of providing a hierarchical > classification of the scientific content of file. Thus, it may be > better to use a separate distinct keyword to define this if it is > really necessary. > > - In practice, there are many other keywords or combinations of > keywords in the header (TELESCOP, INSTRUME, AUTHOR), which at least > implicitly identify the source or origin of the file. > I would not rely too much on "implicit" things, better have some explicit thing. It is true that this could use some existing keyword one possibility is EXTNAME (the dread EXTNAME ?) another one is ORIGIN if this is used not to identify the organization or observatory, but the software package who wrote it, e.g. ORIGIN = 'ESO-MIDAS' / Written by MIDAS or a combination ORIGIN = 'XAS ' / EXTNAME = 'TIME PROFILE' / name of this binary table extension However currently I have the problem that, if I import a file, and then copy/manipulate it I tend to preserve the ... original ORIGIN keyword > - in most cases the software will simply have to skip over the HDUCLAS1 > keyword before looking at the HDUCLAS2 and higher keywords to determine > which type of FITS extension it is. This wastes header space and CPU > cycles. > 80 bytes and how many nanoseconds ? > - this may lead to geo-political copyright disputes over which group > first defines certain new classes of extensions. For instance, SAO and That's why I suggested an identifier of the software package ... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IN CONCLUSION I do not care whether this keyword is called HDUCLAS1, ORIGIN, EXTNAME or whatever, but I'd strongly like to be able to identify clearly what a file is. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ For instance I have a "fromfits" program which converts from FITS to internal format. Can easily tell an IMAGE from a BINTABLE, but if EXTNAME is not one of the recognized ones, it cannot classify the bintable and flags it as "generic table". I also have a separate prototype "fromogip" program to handle EXTNAME.EQ.'SPECRESP MATRIX', EXTNAME.EQ.'MATRIX' and EXTNAME.EQ.'SPECTRUM'. I have "manually" to know which program to use, while having a definite convention, I could merge the two programs, or have one call the other. ----------------------------------------------------------------------------- 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 Thu Sep 2 09:46:44 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2100" "" "2" "September" "1993" "09:21" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "54" "Re: FITS Coordinate Keywords" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02751; Thu, 2 Sep 93 09:46:44 EDT Return-Path: Message-Id: <2SEP199309213480 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 References: From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS Coordinate Keywords Date: 2 Sep 1993 09:21 EDT In article , Lucio Chiappetti writes... >On Tue, 31 Aug 1993, William Pence wrote: > >> 1. Primary Array Coordinate Keywords >> > ... > By the way ... > in X-rays one usually has : > > * detector x,y "raw" coordinates > * detector x,y "corrected" coordinates ( = raw if no distortions) > arbitrary x,y rebinned pixels > * celestial coordinates using WCS > > I generally assume that one may be interested only in the asterisked > quantities (usually detector coords). DOES EVERYBODY AGREE ON THIS ? > E.g. for an 8192x8192 detector, with a 273x273 images, > anchored at pixel 2731,2731 and zoomed by a factor 10 one will have, > conforming with the conventions : > > (J) NAXIS1 = 273 > (J) NAXIS2 = 273 > (C) BUNIT = PHOTONS > (C) CTYPE1 = XPIX or name tbd > (C) CTYPE2 = YPIX or name tbd > (R) CRPIX1 = 1.00000 > (R) CRPIX2 = 1.00000 > (R) CRVAL1 = 2731.00 > (R) CRVAL2 = 2731.00 > (R) CDELT1 = 10.0000 > (R) CDELT2 = 10.0000 > > ... I'm not sure what is intended in the verbal description -- that is, what the raw pixel values in the FITS files are supposed to be, and what the physical interpretation is supposed to be. However, the set of keywords would be interpreted as follows: The FITS file constains a 273 x 273 array (values of NAXISn). The axes represent pixel numbers. FITS array member (1,1), from the value of CRPIXn, corresponds to physical pixel unit (CRVALn) values (2731,2731). ("The value field [of the CRVALn keyword] shall contain a floating point number, giving the value of the CTYPEn keyword at the reference point CRPIXn." __NOST _Definition of FITS_). The increment per index number in the FITS file is 10; thus, FITS array member (2,2) would be coordinate (2741,2741). (By the way, the quotes around the character string keywords were left out in the example.) Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Thu Sep 2 11:17:16 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2013" "Thu" "2" "September" "1993" "17:13:10" "+0200" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "45" "Re: FITS Coordinate Keywords" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04368; Thu, 2 Sep 93 11:17:16 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative In-Reply-To: <2SEP199309213480 at nssdca.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS Coordinate Keywords Date: Thu, 2 Sep 1993 17:13:10 +0200 (MET DST) On 2 Sep 1993, BARRY M. SCHLESINGER wrote: > In article , Lucio Chiappetti writes... > > E.g. for an 8192x8192 detector, with a 273x273 images, > > anchored at pixel 2731,2731 and zoomed by a factor 10 one will have, > > conforming with the conventions : > > > > (J) NAXIS1 = 273 > > (J) NAXIS2 = 273 > > (C) BUNIT = PHOTONS etc. etc. > I'm not sure what is intended in the verbal description -- that is, > what the raw pixel values in the FITS files are supposed to be, and > what the physical interpretation is supposed to be. However, the set > of keywords would be interpreted as follows: > > The FITS file constains a 273 x 273 array (values of NAXISn). The > axes represent pixel numbers. FITS array member (1,1), from the value > of CRPIXn, corresponds to physical pixel unit (CRVALn) values > (2731,2731). > The increment > per index number in the FITS file is 10; thus, FITS array member (2,2) > would be coordinate (2741,2741). > Yes, this a 273x273 "image pixel" image rebinned with zoom factor 10 from a portion of the full FOV of an 8192x8192 "detector image" (actually a spare ROSAT PSPC in focus of SAX FM mirrors at Panter Long Beam facility), with the lower corner at (2731,2731). This way one can always refer to (meaningful) detector coords and not to (meaningless) "image pixels" > (By the way, the quotes around the character string keywords were > left out in the example.) > Yes, this the output of an header lister (and actually the original file is not even FITS), but the meaning was clear anyhow 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) | From fitsbits-request Thu Sep 2 11:33:22 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2403" "" "2" "September" "93" "14:08:41" "GMT" "William Thompson" "thompson at serts.gsfc.nasa.gov " nil "58" "Re: FITS Coordinate Keywords" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04854; Thu, 2 Sep 93 11:33:22 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!swrinde!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson References: From: thompson at serts.gsfc.nasa.gov (William Thompson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS Coordinate Keywords Date: 2 Sep 93 14:08:41 GMT Lucio Chiappetti writes: >On Tue, 31 Aug 1993, William Pence wrote: (stuff deleted) >> >> 2. BINTABLE Array Coordinate Keywords >> >> In this case the image is represent by a vector column in a Binary Table. > If I understand correctly the case mentioned here is the one in which > each element of the table is a 10x20 image. > I fail to understand why one may want to do this, and I'll certainly > not use nor encourage use of columns with TDIMensionality greater than 1. Well, from my point of view, multiply dimensioned columns in FITS binary tables are a must. Without it, binary tables just aren't much use to us, and without binary tables, FITS files just aren't much use except for fairly simple data sets. (Of course there is the IMAGE extension, but the thought of having files with 30-50 seperate image extensions all related to each other makes me shiver.) > > Therefore I have no comments on the proposed convention since I will > never make use of such complex format. > The cases I'm considering are : > table elements are scalar > (e.g. one column contains energy, and the other contains counts/s) > in this case the TUNITn are sufficient > table elements are 1-d vectors > (e.g. one column contains scalar time, and the other contains an > entire spectrum, or the counts in several bands) > In this case at the moment the description of what is on the > single "depth" axis is undefined. > Can your convention cope with it ? Is a different convention better ? > Or does one instead need an ad-hoc convention case-by-case ? The case I'm considering has the following properties: * Multiple simultaneous measurements in up to 32 wavelength regions. * Each data array can have up to four dimensions (2 spatial, spectral, temporal) depending on the configuration of the instrument. * The data set will also include associated information about the observation--e.g. mechanism positions, pointing, exact times. These data may also be multidimensional. For example, in a pinhole raster scan, each X, Y point will have a separate time. The best way that I can see to put this data into a FITS file is to use binary tables with the TDIM convention for the multidimensional aspect. I have also considered the Green Bank convention and the new IMAGE extension. Bill Thompson From fitsbits-request Fri Sep 3 12:00:23 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["278" "Fri" "3" "September" "93" "11:59:19" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "6" "tape interface software" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09146; Fri, 3 Sep 93 12:00:23 EDT Return-Path: Message-Id: <9309031559.AA08889 at tetra.gsfc.nasa.gov> From: pence at tetra.gsfc.nasa.gov (William Pence) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Cc: pence at tetra.gsfc.nasa.gov Subject: tape interface software Date: Fri, 3 Sep 93 11:59:19 EDT We need a tape device interface subroutine library in order to copy FITS files from tape to disk. Is there a good public domain, machine independent, tape I/O library (for C or Fortran) available that supports all the common tape drives, including DAT end Exabyte. -Bill Pence From fitsbits-request Sat Sep 4 05:46:39 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["943" "Sat" "04" "September" "93" "11:49:13" "+0200" "francois at SIMBAD.u-strasbg.fr" "francois at SIMBAD.u-strasbg.fr" nil "21" "FITS units (OGIP Memo)" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11100; Sat, 4 Sep 93 05:46:39 EDT Return-Path: Message-Id: <9309040949.AA12901 at SIMBAD.u-strasbg.fr> X-Mts: smtp From: francois at SIMBAD.u-strasbg.fr Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS units (OGIP Memo) Date: Sat, 04 Sep 93 11:49:13 +0200 -------------------------------------------------- I tried for more than 2 weeks to send comments about the "Specification of Physical Units within OGIP FITS files" (OGIP Memo OGIP/93-001) to their authors Ian M. George & Lorella Angelini at their SPAN address LHEAVX::GEORGE or LHEAVX::ANGELINI specified in their document, but apparently their vax is always down... Can one of the authors specify a more reliable e-mail address -- or maybe should this discussion more widely open ? Francois Ochsenbein ===================================================================== Internet: francois at simbad.u-strasbg.fr SPAN: SIMBAD::FRANCOIS Phone: +33 88 35 84 11 Fax: +33 88 25 01 60 Post: Dr Francois Ochsenbein, Centre Donnees astronomiques (CDS) Observatoire Astronomique 11, rue de l'Universite 67000 STRASBOURG, France ===================================================================== From fitsbits-request Sat Sep 4 09:51:57 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["653" "" "4" "September" "1993" "09:23:48" "-0400" "Davin C. Flateau" "davin at telerama.pgh.pa.us " nil "12" "imq standard" "^From:" nil nil "9"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12474; Sat, 4 Sep 93 09:51:57 EDT Return-Path: Message-Id: <26a4t4$28h at telerama.pgh.pa.us> Organization: Telerama Public Access Internet, Pittsburgh, PA Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!agate!library.ucla.edu!news.mic.ucla.edu!magnesium.club.cc.cmu.edu!telerama.pgh.pa.us!telerama.pgh.pa.us!not-for-mail From: davin at telerama.pgh.pa.us (Davin C. Flateau) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: imq standard Date: 4 Sep 1993 09:23:48 -0400 I am trying to find an existing Macintosh application that will uncompress the "imq" standard that NASA uses on their image CD-ROMs. The CD-ROMs include the source code for doing the decompression, but I don't want to build an application if one already exists. Any help on the imq standard would be appreciated. Thanx! Davin -- _____________________________________________________________________________ Davin C. Flateau | PLANETARIA (r) | Interactive ~ *| Internet: davin at telerama.pgh.pa.us | Post Office Box 25 | Galactic * | "I saw Halley's Smudge!" | Pittsburgh, PA 15145 | Education ~ * | From fitsbits-request Wed Sep 8 10:16:43 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA23578; Wed, 8 Sep 93 10:16:43 EDT Return-Path: Message-Id: <9309081416.AA23572 at fits.cv.nrao.edu> Date: Wed, 8 Sep 1993 15:11:45 +0100 From: pma at rlsvs2.bnsc.rl.ac.uk (Peter M Allan) To: fitsbits at fits.CV.NRAO.EDU Subject: Re: tape interface software X-Vms-To: SMTP%"fitsbits at fits.cv.nrao.edu" X-Vms-Cc: PMA Sender: fitsbits-request at fits.CV.NRAO.EDU The STARLINK Project has a magnetic tape handling package. It is written in FORTRAN and runs on VAX/VMS, SunOS, Solaris, Ultrix and DEC OSF/1. The low level routines on Unix are written in C. For further information, contact the STARLINK software librarian, Martin Bly, ussc at star.rl.ac.uk Peter Allan STARLINK Project Rutherford Appleton Laboratory From fitsbits-request Thu Sep 9 03:32:16 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA26162; Thu, 9 Sep 93 03:32:16 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 8 Sep 1993 21:08:57 GMT From: dougg at carson.u.washington.edu (Douglas Gottshall) Message-Id: <26lhl9$8c8 at news.u.washington.edu> Organization: University of Washington, Seattle Path: cv3.cv.nrao.edu!uvaarpa!ruacad!vtserf.cc.vt.edu!uunet!spool.mu.edu!news.clark.edu!netnews.nwnet.net!news.u.washington.edu!carson.u.washington.edu!dougg Subject: Telescope For Sale Sender: fitsbits-request at fits.CV.NRAO.EDU COULTER_ODYSSEY_1_TELESCOPE_FOR_SALE 13.1" REFLECTOR WITH SIMPLE MOUNT. IMMACULATE CONDITION, RARELY USED. APPROXIMATELY 1 YEAR WAITING PERIOD TO ORDER ONE NOW FROM COULTER. NEW PRICE 1988 - $500.00 PLUS $100.00 SHIPPING. WILL SELL NOW FOR $500.00 OR BEST REASONABLE OFFER. THIS IS A GOOD QUALITY LARGE REFLECTOR TELESCOPE AT A VERY LOW PRICE BECAUSE OF THE SIMPLE DESIGN AND INEXPENSIVE MATERIALS USED. TO PURCHASE A COMPARABLE SCOPE USING MORE COMMON MATERIALS AND AN EQUATORIAL MOUNT WOULD COST OVER $2000.00. CALL DOUG AT (206) 543-7575 EXT. 322 (WORK) (206) 365-3824 (HOME) LEAVE MESSAGE E-MAIL dougg at u.washington.edu From fitsbits-request Fri Sep 10 18:12:07 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04153; Fri, 10 Sep 93 18:12:07 EDT Return-Path: Date: Fri, 10 Sep 93 18:11:07 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9309102211.AA16141 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS Coordinate Keywords Cc: pence at tetra.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU [This note from Bob Payne may be of general interest, so I'm reposting it and my reply to the whole group]. ----- Begin Included Message ----- From rpayne at sadira.gb.nrao.edu Fri Sep 10 16:30:05 1993 To: pence at tetra.gsfc.nasa.gov Subject: FITS Coordinate Keywords Your note on the FITS Coordinate Keywords has been very useful to me in thinking about GBT data sets. Your example on the BINTABLE Array Coordinate Keywords gave fixed values for all of the rows in the table. If one or more axes varied from row to row would you allow TTYPEn = 'mCTYPnnn' so that the coordinates could vary from row to row? Do you plan on making use of the above convention ? Thanks, ----- End Included Message ----- Bob, This is a very good point that Don Wells also mentioned to me in a phone call a couple days ago. What you are describing here is part of the 'Greenbank convention' which you are obviously already aware of. If a column in a FITS table has a constant value for all rows in the table, then it will save space to remove the column from the table and instead specify the value as a keyword in the header. The convention is that the keyword name should be the same as the name of the (previous) column. In the example of a multidimentional binary table column that I had given in my previous post, I had assumed that the coordinate information would be identical for all the rows of the table, and hence, the reference pixel (for example) for ALL rows in the table was given by the mCRPXnnn keyword (where m is the axis number in the multidimentional array, and nnn is the number of the column containing the multidimensional array). But as you and Don rightly pointed out, in general the value of the reference pixel (or the reference value, or the pixel increment, etc) will be different for each row of the binary table. So in the general case, these values should not be given as a keyword, but instead as another column in the table where the column name (given by the TTYPEnnn keyword) will be identical to the keyword name that I had used in my example. Don Wells also had another suggestion: If one were to place a restriction on the binary table usage so that no more than one multidimensional vector array column is allowed per table, then the keyword or column name syntax for the coordinate information becomes much simpler. Instead of having to have keywords like '2CRPX7' which is interpreted as 'the reference pixel value for the 2nd axis in the multidimentional array in column 7' one could simply use the same keyword names as are used in the primary array, i.e. 'CRPIX2'. This is because it is no longer necessary to represent the column number (7 in this case) in the keyword or column name because there is only a single array in the table. So the 'CRPIX2' keyword or column would apply to the vector column in the table regardless of which column it was in. This is an interesting idea that deserves more consideration, but my main concern with this is that if one has a whole set of related multidimensional arrays (as we do for some of our instruments), it would complicated the bookkeeping and file management tasks if each different type of array had to be placed in a separate FITS file (or a separate extension in a FITS file, which logically amounts to about the same thing). One would then need the ability to 'join' the different FITS tables based upon some common column (e.g., TIME). In our case, it seems much more managable (at least at first glance) to put all these related arrays into separate columns in a single binary table. When the next set of arrays comes along from the instrument, these are then stored in the next row of that same table. This keeps all the data in one simple, tidy file. So in summary, we will use the 'Greenbank convention' to replace a keyword with a column in the table if it varies from row to row. This in effect blurs the distinction between a FITS keyword and a table column; they are basically interchangeable and the choice of which one to use just depends on whether or not the value you wish to store varies with different rows in the table. But I don't think we would be happy with restricting ourselves to a single multidimentional column per binary table, thus we will have to use the more complicated keyword/column names for the coordinate information. -Bill Pence From fitsbits-request Mon Sep 13 14:16:15 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10162; Mon, 13 Sep 93 14:16:15 EDT Return-Path: Date: Mon, 13 Sep 93 14:15:11 EDT From: arots at xebec.gsfc.nasa.gov (Arnold Rots) Message-Id: <9309131815.AA14728 at xebec.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS Coordinate Keywords Cc: pence at tetra.gsfc.nasa.gov, rpayne at nrao.edu Sender: fitsbits-request at fits.CV.NRAO.EDU Bob Payne suggested to allow columns in binary tables to indicate that they contain coordinate information for other columns, through a mechanism like: TTYPEn = 'mCTYPnnn' If I understand this correctly, he probably means: TTYPEnnn = 'mCTYPkkk' column n contains the coordinate type for the m-th coordinate in column k. I am not quite sure this is a common occurrence, but there are similar situations that would be quite common: if a column contained time series vectors, there would most likely be another column containing a time stamp for each row, which would serve as the reference pixel value. So: TTYPEn = 'mCRPXk' I think, though, that this convention runs the wrong way around. It should be: TTYPEn = 'TIME' mCRPXk = 'TIME' This tags column n as containing a value for "TIME" and says that the reference pixel value for coordinate m in column k can be found in a column labeled "TIME". It is bad practice to put the referencing information with the data values; one usually references at the insertion point. A very simple reason for this is that it allows one value to be referenced more than once. It seems likely, that such a table will contain several columns of time series arrays, all having the same time stamp as their starting time. The definition that Bob gave would require (identical) time columns for each of those time series. I would propose a single column labeled "TIME" that could be referenced as often as one wants. The referencing would take place through the TTYPEn keyword (let's say, converted to upper case, with blanks stripped out). Actually, I would like to add a little to this syntax, to make it fit in naturally with a more generalized referencing scheme (I am sure we will need/want one in the future, so one might as well plan for it). Following is an exerpt from a draft propsal that Bill Pence and I put together several months ago: ---------------- We propose that references to other entities be enclosed in double quotes ("); that names of keywords be preceded by an exclamation mark(!); names of columns by the at-symbol ( at ); and names of tables by the pound sign (#). Names of keywords are just that. Names of columns consist of the contents of the appropriate TTYPEnnn keywords. And names of table consist of the name of the FITS file, followed by the extension number enclosed in square brackets. Examples: String substitution KEYWORD = 'This is a data descriptor for "!KEYWORD2" histograms' KEYWORD2= 'Channels 1:3,4:8,9:24,25:31' would be expanded/equivalent to: KEYWORD = 'This is a data descriptor for Channels 1:3,4:8,9:24,\' '25:31 histograms' Column reference TTYPE1 = 'Time' TTYPE2 = 'Time Series' TDIM2 = '(1024)' 1CTYP2 = 'Time' 1CRPX2 = 1 1CRVL2 = '" at Time" + 0.0' 1_1CD2 = 0.001 " at Time" refers to the value (in the same row) in the column with TTYPE='Time'. Table/column reference Suppose one has a binned spectrum in each cell of a particular column of TABLE1; the upper and lower bounds of the histogram bins are contained in the columns with TTYPE='UBOUNDS' and TTYPE='LBOUNDS' of TABLE2 which happens to be extension 13 in FITS file 'abcxyz.123'. These arrays of boundaries would be indicated as: "#abcxyz.123[13] at UBOUNDS" and "#abcxyz.123[13] at LBOUNDS", respectively. Table references This scheme can also be used to build databases out of FITS tables by building tables which cells contain strings that consist of table references of the form "#abcxyz.123[13]". This may sound familiar to those who are acquainted with the tables in AIPS++. -------------- - Arnold Rots From fitsbits-request Mon Sep 13 23:28:26 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11019; Mon, 13 Sep 93 23:28:26 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 13 Sep 93 23:18:53 GMT From: thompson at serts.gsfc.nasa.gov (William Thompson) Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson Subject: Converting TAI to/from UTC Sender: fitsbits-request at fits.CV.NRAO.EDU Please forgive me if this is somewhat off the normal subjects for the newsgroups that I am posting this to, but these are the closest matches that I could find. I just wrote some IDL software for converting between TAI and UTC time formats, taking into account the "leap second" differences between them. I thought that it would be a good idea to check my results against those produced by other, similar software. If anyone does have such software, I would be grateful if the following example (picked at random) could be confirmed/disproved. UTC: 1984-05-13 12:34:56 TAI: 831,990,918 seconds since 1958-01-01 00:00:00 Thank you for your trouble, Bill Thompson From fitsbits-request Tue Sep 14 08:45:33 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12342; Tue, 14 Sep 93 08:45:33 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 14 Sep 1993 05:15:42 GMT From: awoolley at franklin.cc.utas.edu.au (yellooW ynohtnA) Message-Id: <273k1u$hnq at diemen.utas.edu.au> Organization: University of Tasmania, Australia. Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!europa.eng.gtefsd.com!uunet!munnari.oz.au!newsroom.utas.edu.au!franklin.cc.utas.edu.au!awoolley Subject: FAQ? One available? Sender: fitsbits-request at fits.CV.NRAO.EDU Hi there! Before I ask any questions that may an FAQ, could someone please email the FAQ (if there is one) for this group or email me the address to an FTP site that may/will have it. Thanks in advance. Anthony Woolley... -- | Anthony Woolley | "Use the fork Luke, don't give in to the | | awoolley at postoffice.utas.edu.au | temptation of the dark finger-bowl" | | "Welcome back to reality" | | From fitsbits-request Wed Sep 15 10:40:02 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14631; Wed, 15 Sep 93 10:40:02 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 15 Sep 1993 09:07 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <15SEP199309072252 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!europa.eng.gtefsd.com!library.ucla.edu!agate!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <9309131815.AA14728 at xebec.gsfc.nasa.gov> Subject: Re: FITS Coordinate Keywords Sender: fitsbits-request at fits.CV.NRAO.EDU > >We propose that references to other entities be enclosed in double >quotes ("); that names of keywords be preceded by an exclamation >mark(!); names of columns by the at-symbol ( at ); and names of tables >by the pound sign (#). >Names of keywords are just that. Names of columns consist of the >contents of the appropriate TTYPEnnn keywords. And names of table >consist of the name of the FITS file, followed by the extension >number enclosed in square brackets. > >Examples: > >String substitution > >KEYWORD = 'This is a data descriptor for "!KEYWORD2" histograms' >KEYWORD2= 'Channels 1:3,4:8,9:24,25:31' > >would be expanded/equivalent to: >KEYWORD = 'This is a data descriptor for Channels 1:3,4:8,9:24,\' > '25:31 histograms' > > >Column reference > >TTYPE1 = 'Time' >TTYPE2 = 'Time Series' >TDIM2 = '(1024)' >1CTYP2 = 'Time' >1CRPX2 = 1 >1CRVL2 = '" at Time" + 0.0' >1_1CD2 = 0.001 > >" at Time" refers to the value (in the same row) in the column with >TTYPE='Time'. > > >Table/column reference > >Suppose one has a binned spectrum in each cell of a particular >column of TABLE1; the upper and lower bounds of the histogram >bins are contained in the columns with TTYPE='UBOUNDS' and >TTYPE='LBOUNDS' of TABLE2 which happens to be extension 13 in >FITS file 'abcxyz.123'. These arrays of boundaries would be >indicated as: > >"#abcxyz.123[13] at UBOUNDS" and "#abcxyz.123[13] at LBOUNDS", respectively. > > >Table references > >This scheme can also be used to build databases out of FITS tables >by building tables which cells contain strings that consist of table >references of the form "#abcxyz.123[13]". >This may sound familiar to those who are acquainted with the tables >in AIPS++. > Caution should be exercised in the use of at (hexadecimal 40) because the ASCII standard (ANSI X3.4-1977 = ISO 646) designates this character as one for which national standardization is permitted, one which should not be used in international interchange without prior agreement between sender and recipient. Similarly, hexadecimal 23 (# or *number* sign in the ASCII standard) may in some countries be the poound sterling symbol. Barry Schlesinger FITS Support Office From fitsbits-request Wed Sep 15 19:05:59 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA15285; Wed, 15 Sep 93 19:05:59 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Wed, 15 Sep 1993 17:50:09 GMT From: alberto at cfa0 (Alberto Accomazzi) Message-Id: Organization: Smithsonian Astrophysical Observatory, Cambridge, MA, USA Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!noc.near.net!das-news.harvard.edu!husc-news.harvard.edu!hsdndev!cfanews!cfa0!alberto Subject: FITS bintable for LUTs Sender: fitsbits-request at fits.CV.NRAO.EDU I am rewriting some software that converts X-window dumps into FITS format and decided to make it adhere more strictly to the FITS standard. I would like to be able to store the color lookup tables (or, to use the X jargon, the installed colormap) at the end of the FITS data as a binary extension table. The main data in the FITS file is the image pixmap from the window dump. The colormap would consist of 3 (RGB) byte arrays containing 256 elements each. This is how I thought the extension header would look like: XTENSION= 'BINTABLE' BITPIX = 8 NAXIS = 2 NAXIS1 = 256 NAXIS2 = 3 PCOUNT = 0 GCOUNT = 1 TFIELDS = 1 TFORM1 = '256B ' TDISP1 = 'B4.1 ' EXTNAME = 'LUTS ' / Color lookup tables END Does anybody have comments/suggestions about this? In particular, I'm trying to decide what the best EXTNAME for this kind of data should be. I'd like to incorporate a check for extension tables containing these LUTS in some of my utility programs (such as pnmtofits and fitstopnm), and it would be nice if we could agree on some EXTNAME keyword value that should be looked for by display/conversion programs. I looked at the NOST 100-1.0 document but could not find anything about EXTNAME values. - Alberto -- ========== Alberto Accomazzi Harvard-Smithsonian Center for Astrophysics alberto at cfa.harvard.edu 60 Garden Street, MS 39 (617) 495-7076 Cambridge, MA 02138 USA From fitsbits-request Thu Sep 16 12:19:04 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA17006; Thu, 16 Sep 93 12:19:04 EDT Return-Path: Date: Thu, 16 Sep 93 12:17:57 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9309161617.AA23327 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS bintable for LUTs Cc: pence at tetra.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU Alberto Accomazzi (Sept 15) wrote: >I would like to be able to store the color lookup tables >(or, to use the X jargon, the installed colormap) at the >end of the FITS data as a binary extension table. >The main data in the FITS file is the image pixmap from the >window dump. >The colormap would consist of 3 (RGB) byte arrays containing >256 elements each. This is how I thought the extension header >would look like: >XTENSION= 'BINTABLE' >BITPIX = 8 >NAXIS = 2 >NAXIS1 = 256 >NAXIS2 = 3 >PCOUNT = 0 >GCOUNT = 1 >TFIELDS = 1 >TFORM1 = '256B ' >TDISP1 = 'B4.1 ' >EXTNAME = 'LUTS ' / Color lookup tables >END What about the TTYPE1 keyword? It is good practice to always provide a name for each column (e.g. TTYPE1 = 'LUT ') and then have the software locate the desired column by it name, rather than assuming a particular location for the column. This decouples the software somewhat from the internal structure of the table. If this is to be a general format for storing LUTS, you might also consider putting each LUT color into a separate column; with your proposed scheme it is not clear which color is in which row of the table. Also, putting the colors into separate columns makes it easy to store multiple LUTS in different rows of the table. In this case it would also be useful to provide a 'NAME' column to identify which LUT is which. So the table would end up with 4 columns something like this: XTENSION= 'BINTABLE' BITPIX = 8 NAXIS = 2 NAXIS1 = 784 NAXIS2 = 1 PCOUNT = 0 GCOUNT = 4 TFIELDS = 1 TTYPE1 = 'LUT_NAME' TFORM1 = '16A ' TTYPE2 = 'R_LUT ' TFORM2 = '256B ' TDISP2 = 'B4.1 ' TTYPE3 = 'G_LUT ' TFORM3 = '256B ' TDISP3 = 'B4.1 ' TTYPE4 = 'B_LUT ' TFORM4 = '256B ' TDISP4 = 'B4.1 ' EXTNAME = 'LUTS ' / Color map lookup tables END The order of the columns should not be considered significant and could vary from table to table. Using EXTNAME = 'LUTS ' seems like the obvious choice. For the FITS files we produce here at the HEASARC, we are in addition providing a HDUCLASn keyword to provide a more detailed hierarchical description of the content of the FITS extension or primary array. This is probably not really needed here, but in principle this could be used to further describe the type of LUT it is: HDUCLAS1= 'LUT ' / This is a color map look-up-table HDUCLAS2= 'GREYSCALE' / this is a grey-scale LUT (as opposed to pseudo color) HDUCLAS3= 'LINEAR ' / this is a linear ramp LUT I'm not really suggesting you use the HDUCLAS2 and higher keywords, but this illustrates the concept. -Bill Pence pence at tetra.gsfc.nasa.gov From fitsbits-request Wed Sep 22 15:35:35 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02974; Wed, 22 Sep 93 15:35:35 EDT Return-Path: Date: Wed, 22 Sep 93 15:34:17 EDT From: arots at xebec.gsfc.nasa.gov (Arnold Rots) Message-Id: <9309221934.AA19284 at xebec.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: AUTHOR Keyword Sender: fitsbits-request at fits.CV.NRAO.EDU The use of this keyword seems to have diverged (or may be just evolved), so I would like to solicit some opinions (consensus would be nice, but that is undoubtedly too much to hope for) on what to do with it. I had a vague recollection that AUTHOR was intended to refer to human authors, but there seems to be an increasing tendency use it for storing the names of the software SCRIBES that generate the files. I thought I'd try to get my definitive guidance from the NOST document, but, unfortunately, that does not seem capable of making up its mind, either. The March 8, 1993, version says on p. 18: >Bibliographic Keywords >AUTHOR Keyword The value field shall contain a character string identifying >who compiled the information in the data associated with the header. This >keyword is appropriate when the data originate in a published paper or are >compiled from many sources. Purely for bibliographic purposes, thus, and referring to true (human) authors. However, on p. 43 it says: >AUTHOR gives the name of the author or creator of the table. A software scribe (i.e., a computer program) could fit the bill. My question is: is the definition on p.18 outdated and should AUTHOR be used to identify the scribe that created the file/table? Or should we preserve AUTHOR's originally intended use and invent another keyword (I would suggest CREATOR) to identify which version of which program created the file/table? - Arnold Rots From fitsbits-request Fri Sep 24 18:19:33 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09968; Fri, 24 Sep 93 18:19:33 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 24 Sep 1993 09:28 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <24SEP199309284602 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Subject: FITS basics and information (periodic posting) Sender: fitsbits-request at fits.CV.NRAO.EDU 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 (at least for the time being) through Simtel-20 [192.88.110.20] Dominique Beauchamp, Universite Laval, Quebec City, has released version 0.3, rel. 2 of ViewFITS, a FITS reader for OS/2 2.1 presentation manager. It is on ftp.cdrom.com in /pub/os2/incoming, file name vf03r2.zip. This program gives the user the opportunity to display FITS images (8,16 or 32 bits, integer or float), modifying the gray shade palette, doing negation and zooming out. The program now uses bitmap instead of direct drawing to the screen, with 100x faster execution time. It is still a beta version. If you try it, report the results to beaucham at phy.ulaval.ca. 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. The NOST has codified FITS as endorsed by the IAU into a formal standard, eliminating some contradictions and ambiguities in the original FITS papers. This Definition of FITS was developed by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review by the astronomical community. On June 18, 1993, it was approved as a NOST Standard by an Accreditation Panel consisting of the NOST Executive Board and an astronomical community representative; this review was to confirm that the community had been given a satisfactory opportunity to review the standard and that the Technical Panel had properly considered and responded to all comments. The NOST standard has been submitted to the IAU FITS Working Group (IAUFWG) for endorsement as the international FITS standard, to replace the four FITS papers and the Floating Point Agreement, which are the current endorsed standard. While oversights in non-controversial areas may be rectified as a result of the review by the IAUFWG, significant changes are unlikely, because members of this committee were active in the process of reviewing the standard and their comments were given significant weight in the deliberations of the Technical Panel. 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 NOST 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. A proposed reorganization could move the FITS material to a FITS subdirectory under a STANDARDS directory. The FITS files include copies of the current NOST draft standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. The only difference among the three formats is that the ASCII form lacks typeface formatting; only one need be retrieved. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. There is a PostScript copy of the current version of the User's Guide, generated by capturing the Macintosh MS Word original in PostScript format. Nearly 100 copies have been retrieved, with only one printing problem and one preview problem reported; however, because of the well-known problems in converting Macintosh Word to PostScript, universal portability cannot be guaranteed. Please notify the FITS Support Office by electronic mail of any problems. The directory also contains a modified version of this posting. An AAREADME.DOC file describes the contents of the directory. A SOFTWARE subdirectory contains a prototype for software in C that will eventually validate FITS files, along with instructions. Because this software is still under development, it should not be run before reading the separate instructions file. The current version investigates required keywords for primary headers and prints sample data for integer data arrays. There is also C software to read and list the headers of a FITS file. Another file provides 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 (case is significant). The documents subdirectory contains a number of subdirectories. A proposals subdirectory contain proposals, such as the BINTABLE Binary Tables extension proposal, which is now under consideration by the IAU FITS Working Group. A drafts subdirectory contains drafts of designs not yet submitted, for example, a proposed method for incorporating data compression under FITS. The wcs subdirectory contains material serving as the basis for continuing discussion of world coordinates issues, some of which appears on this newsgroup from time to time. Printed copies of many of the documents listed above can be obtained from the NOST Librarian. Printed or electronic copies of the User's Guide and the NOST Standard, for those without ftp access, are available. Because of restrictions set by the copyright holder, NOST can send copies of the four FITS papers only to non-profit organizations. The NOST can be reached as follows: (Postal) NASA/Science Office of Standards and Technology Code 633.2 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Telephone: +1-301-286-3575 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 Tue Sep 28 12:44:34 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA20844; Tue, 28 Sep 93 12:44:34 EDT Return-Path: Date: Tue, 28 Sep 93 12:44:24 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9309281644.AA02485 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: HEAFITS discussion group Cc: pence at tetra.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU This is a periodic posting to remind readers of this news group that an electronic mail listserver called HEAFITS has been set up for the purpose of discussing issues related to FITS format files in High Energy Astrophysics (HEA). This is intended to be a more specialized group for discussion of HEA-specific FITS issues that would not necessarily be of interest to the majority of subscribers to the existing FITSBITS and WGAS mail groups. To SUBSCRIBE to the HEAFITS group, send an e-mail message to the following address: listserv at legacy.gsfc.nasa.gov in which the body of the mail message contains one line of text: subscribe heafits Your Name where 'Your Name' is your actual First and Last names. To POST a message to this group after you have subscribed, simply send the message to heafits at legacy.gsfc.nasa.gov (Note the distinction that you subscribe by sending a message to listserv at legacy.gsfc.nasa.gov, but that messages to the HEAFITS group must be sent to heafits at legacy.gsfc.nasa.gov). There is no strict charter for what topics can be discussed within the HEAFITS group, but in general, the purpose of this mail distribution group is to promote the development of standards for FITS files containing data related to high energy astrophysics. This includes, but is not limited to, proposals for standard keyword names, or standard binary table layouts and column names to be used for different classes of HEA data. From fitsbits-request Wed Sep 29 17:33:40 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03438; Wed, 29 Sep 93 17:33:40 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 29 Sep 1993 14:22 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <29SEP199314224806 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!ra!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <1993Sep29.155652.14869 at ennews.eas.asu.edu> Subject: Re: FITS keywords definitions - FAQ? Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1993Sep29.155652.14869 at ennews.eas.asu.edu>, scowen at wfpc3.la.asu.edu (Paul A. Scowen) writes... >Is there a document somewhere that can be downloaded (Postscript or TeX) that >defines the current set of FITS keywords, TABLES included, with their >definitions (mathematical as well where appropriate) and unit conventions? >... For those who missed the FITS basics and information posting, the contents are available by anonymous ftp from nssdca.gsfc.nasa.gov, directory FITS, file BASICS_INFO.TXT. This file discusses the basic FITS documentation, including the NOST Definition of FITS and the NOST User's Guide to FITS, both of which are available in electronic form from the same directory. >I ask because there's a lot of old "FITS compliant" software running around >out there that isn't. Thanks. > I would like to hear about any such software and what the problems are. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Thu Sep 30 09:29:19 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05436; Thu, 30 Sep 93 09:29:19 EDT Return-Path: X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed; Thu, 30 Sep 1993 14:27:55 +0100 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Thu, 30 Sep 1993 14:28:22 +0100 Date: Thu, 30 Sep 1993 14:28:22 +0100 X400-Originator: Gunnar.Nilssen at avh.unit.no X400-Recipients: fitsbits at nrao.edu X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930930142822] X400-Content-Type: P2-1984 (2) Content-Identifier: 162 Conversion: Prohibited From: Gunnar Nilssen Message-Id: <"162*/G=Gunnar/S=Nilssen/OU=avh/O=unit/PRMD=uninett/ADMD= /C=no/" at MHS> To: fitsbits at NRAO.EDU Sender: fitsbits-request at fits.CV.NRAO.EDU subscribe