From fitsbits-request Sun Aug 1 22:20:18 1993 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 43 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA25357; Sun, 1 Aug 93 22:20:18 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: the "archival" issue Date: Mon, 2 Aug 1993 03:20:02 GMT The appended posting by Archie Warnock appeared in newsgroup sci.data.formats two days ago. I am reposting it to sci.astro.fits because I suspect that many s.a.f. subscribers do not read s.d.f. and because I agree with what Archie says here about design considerations for archival-quality data formats. Glossary: HDF = Hierarchical Data Format (developed by NCSA at UIUC), API = Application Programming Interface, CDF = Common Data Format (developed at NASA-GSFC), EOS = Earth Observation Systems (the "Mission to Planet Earth" project at GSFC, which has chosen HDF as its archival format). -Don -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Newsgroups: sci.data.formats Subject: Re: HDF as an archive format Date: 30 Jul 93 14:30:30 GMT Organization: NASA Goddard Space Flight Center -- InterNetNews site mike at jpl-devvax.jpl.nasa.gov (Mike Tankenson) writes: >1) Is there something inherent about HDF that would prevent its use as an >archive format? Depends on how serious you are about archiving. The fundamental question to ask is how will a user, some 20 or 30 years in the future, upon finding a file in HDF format, access the data. In my opinion, formats which are defined _solely_ by software toolboxes and APIs are extremely dangerous for archival storage. We have no way of assuring future generations of users that the software will be usable. The questions to ask about archival storage are: 1. Where is the byte-by-byte description of the format given? In an internationally recognized standards document? In the refereed literature? In a private publication by some individual institution? In source code? Which is most likely to be accessible 50 years from now? 2. Is the format self-documenting? Is the metadata in (at least) ASCII? Can the user determine anything about the contents of the data from a simple dump? 3. Is the format well-defined? Can a user assume that versions are backward compatible? There are (at least) three different applications for data formats - interchange, access and archival storage. It is not at all obvious that any single format can meet the needs of all 3 simultaneously, even less obvious that any single format currently _does_ meet the needs of all 3. In general, working formats need to emphasize access (read/write) efficiency. Interchange formats need storage efficiency and standardized numeric representations. Archival formats need to be self-documenting, externally documented and simple. Things like HDF, netCDF and CDF are good working formats but are risky as archival formats (at least, I've never seen references to format descriptions in the refereed literature - I hope I'm wrong, cause otherwise EOSDIS is gonna be in a lot of trouble years from now). FITS and PDS are pretty good interchange and archival formats, but weak working formats. It's an important area for discussion... -- _______________________________________________________________________ -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC Project STELAR: WAIS to do science -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Mon Aug 2 07:36:27 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["984" "Mon" "2" "August" "1993" "12:31:42" "+0100" "Clive Page, Leicester University, UK" "cgp%ltvad.dnet at star-gw.rl.ac.uk " nil "18" "Underscores vs hyphens in FITS column names" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA26455; Mon, 2 Aug 93 07:36:27 EDT Return-Path: Message-Id: <9308021131.AA02875 at star-gw.rl.ac.uk> From: cgp%ltvad.dnet at star-gw.rl.ac.uk (Clive Page, Leicester University, UK) Sender: fitsbits-request at fits.CV.NRAO.EDU To: "fitsbits at fits.cv.nrao.edu"%RLSGW.dnet at star-gw.rl.ac.uk Subject: Underscores vs hyphens in FITS column names Date: Mon, 2 Aug 1993 12:31:42 +0100 I'd like to support the recent posting by Bill Pence recommending that underscores be used in place of hyphens in FITS keyword names where possible. Apart from the reasons cited, the problems of parsing an expression involving FITS keyword names should be considered; one might want to do this when using utilities such as FTOOLS to compute a new column or select a given set of rows. In such cases the selection expression might include FITS keyword names as "variable names". If some of these names contain hyphens (which are just like minus signs) parsing the expression is much harder, which means the syntax rules forced on the user are bound to be more complex. We are, of course, stuck with some names like DATE-OBS for historical reasons, but in my view it would be better to avoid creating new names like this in future. I also support the other recent postings concerning min and max table column keywords, and standard keywords for RA, DEC, and reference frames. From fitsbits-request Mon Aug 2 10:00:47 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["215" "" "2" "August" "1993" "13:43:47" "GMT" "Edward J.M. Colbert" "colbert at astro.umd.edu " nil "8" "Making a FITS file" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27278; Mon, 2 Aug 93 10:00:47 EDT Return-Path: Message-Id: <23j5mj$4p0 at umd5.umd.edu> Organization: University of Maryland, Astronomy Department Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!news-feed-2.peachnet.edu!umn.edu!spool.mu.edu!wupost!uunet!haven.umd.edu!umd5.umd.edu!colbert From: colbert at astro.umd.edu (Edward J.M. Colbert) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Making a FITS file Date: 2 Aug 1993 13:43:47 GMT Hi: I would like to take a 3-dimensional float array (x,y,z)_i and make a FITS image out of it with x and y on the pixel axes. There must be a routine already written to do this. Where can I get it? Thanks, Ed From fitsbits-request Mon Aug 2 10:52:36 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2699" "Mon" "2" "August" "93" "10:51:43" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "79" "Re: Making a FITS file" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27300; Mon, 2 Aug 93 10:52:36 EDT Return-Path: Message-Id: <9308021451.AA13415 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: Re: Making a FITS file Date: Mon, 2 Aug 93 10:51:43 EDT Ed colbert wrote: >I would like to take a 3-dimensional float array (x,y,z)_i and make >a FITS image out of it with x and y on the pixel axes. There must >be a routine already written to do this. Where can I get it? I'm not sure what you mean by "with x and y on the pixel axes", but the following sample subroutine will take a 3-d array and write it out as a 3-D FITS image (data cube) if that is what you wanted to do. First, build a copy of the FITSIO subroutine library, available from the /pub/fitsio/ directory in the anonymous ftp account on tetra.gsfc.nasa.gov then link it will the following Fortran subroutine as a template for creating a FITS file. You will probably need to make some minor modifications to this subroutine to meet your exact requirements.: C------------------------------------------------------------------------------- subroutine make3d(array,nx,ny,nz) C Write the array of data out to a FITS file. C array = input floating point 3D array C nx = input size of the first axis of array C ny = input size of the second axis of array C nz = input size of the third axis of array integer nx,ny,nz real array(nx,ny,nz) integer status,blocksize,iunit,bitpix,naxis,naxes(3) integer pcount,gcount,group,fpixel,nelem logical simple,extend C initialize status, FITS blocksize, and the fortran unit number to use status=0 blocksize=1 iunit=21 C Create the new FITS file called file3d.fits call ftinit(iunit, 'file3d.fits', blocksize, status) C Define datatype of FITS array as single precision floating point. bitpix=-32 C Initialize values for required keywords simple=.true. naxis=3 naxes(1)=nx naxes(2)=ny naxes(3)=nz pcount=0 gcount=1 extend=.true. C Write the required primary array keywords call ftphpr(iunit,simple,bitpix,naxis,naxes,pcount,gcount, & extend,status) C Define the primary array structure (sets up internal FITSIO parameters) call ftpdef(iunit,bitpix,naxis,naxes,pcount,gcount,status) C Write the primary array of data (real*4 data array) group=1 fpixel=1 nelem=nx*ny*nz call ftppre(iunit,group,fpixel,nelem,array,status) C Close the FITS file call ftclos(iunit,status) end C------------------------------------------------------------------------- It would be useful to add more error checking to the above program such as checking that the returned status values are = 0. Also, one would probably want to add some additional optional header keywords to the FITS file. This can be easily be done with other FITSIO subroutine calls. -Bill Pence From fitsbits-request Tue Aug 3 14:08:12 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["870" "" "3" "August" "93" "16:40:57" "GMT" "William Thompson" "thompson at serts.gsfc.nasa.gov " nil "19" "Re: min and max table column keywords" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00481; Tue, 3 Aug 93 14:08:12 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson References: <9307301816.AA21391 at tetra.gsfc.nasa.gov> From: thompson at serts.gsfc.nasa.gov (William Thompson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: min and max table column keywords Date: 3 Aug 93 16:40:57 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: >Here within the OGIP/HEASARC we have a need to define a pair of standard >FITS header keywords to give the minimum and maximum values contained >within a column in a FITS table. These keywords would be analogous to >the DATAMIN and DATAMAX keywords which are defined for use with >FITS images. An obvious choice of names for these new keywords would >be: >TDMINnnn = 0.0 / the actual minimum value contained in column nnn of the table >TDMAXnnn = 1000. / the actual maximum value contained in column nnn of the table >Does anyone have any comment on these keyword names? Or has an alternative >keyword already been proposed and/or used for this purpose? I had proposed these same keywords earlier, and have been planning to use them for the SOHO project. It is the most obvious choice. William Thompson From fitsbits-request Wed Aug 4 20:45:42 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["453" "Wed" "4" "August" "1993" "20:55:10" "GMT" "Dominique Beauchamp" "beaucham at phy.ulaval.ca " nil "13" "A FITS viewer for OS/2 PM ViewFITS" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04486; Wed, 4 Aug 93 20:45:42 EDT Return-Path: Message-Id: Organization: CRAPUL Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!darwin.sura.net!math.ohio-state.edu!sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!mcrcim.mcgill.edu!sifon!athena.ulaval.ca!leo!beaucham Reply-To: beaucham at phy.ulaval.ca From: beaucham at phy.ulaval.ca (Dominique Beauchamp) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: A FITS viewer for OS/2 PM ViewFITS Date: Wed, 4 Aug 1993 20:55:10 GMT Hi! I released yesterday the most recent version (0.3 rel. 2) of ViewFITS, a FITS viewer for OS/2 2.1, presentation manager. If you want to get it, it is on ftp.cdrom.com in /pub/os2/incoming, its name is vf03r2.zip. The package comes with 3 images. It is still a beta version but has interesting features. If you try it, let me know! Dominique Beauchamp InterNet: beaucham at phy.ulaval.ca FidoNet (NET MAIL or Astronomy Echo): DOMINIQUE BEAUCHAMP From fitsbits-request Thu Aug 5 18:33:48 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3300" "" "5" "August" "1993" "19:38:15" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "61" "Re: HDF as an archive format" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07223; Thu, 5 Aug 93 18:33:48 EDT Return-Path: Message-Id: <23rnj7INNo7d at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: <5AUG199310442680 at nssdca.gsfc.nasa.gov> From: sla at umbra.UCSC.EDU (Steve Allen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: HDF as an archive format Date: 5 Aug 1993 19:38:15 GMT In article <5AUG199310442680 at nssdca.gsfc.nasa.gov> bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes: >First of all, a general comment. All FITS formats endorsed by the IAU >have been published in the refereed literature... Which is a good thing. Anything that goes in to a FITS file will always be possible to get out. I use FITS as a part of my work, and as a data storage mechanism for my thesis data. Some of my thesis data are synthetic. They are model matrices with appropriate amounts of structured information to describe what each element of the model is, how it was generated, etc. >The basic goal of a FITS software reader is to generate the >appropriate table or array.... This sentence exposes one of the worst problems with FITS "tabel or array" FITS is great for encoding any kind of multidimensional rectangular array. It is not so great for other entities. > ... So FITS readers should be able to create >correctly structured binary tables from any BINTABLE FITS file. I have no argument here. Again, anything that goes *in* to a FITS file will always be possible to get out. The problem is, that some kinds of data are very difficult to get *in* to a FITS file. I mean, specifically, data structures, linked lists, and other sorts of documentary information which would be associated with an image. It is possible now, with the BINTABLE extension, to encode these sorts of things in a FITS file. BINTABLE provides all the necessary pointers and data HEAPs. However, there really are no tools for converting a generic data structure into this format. Likewise, there are no tools for guaranteeing that the data can be extracted into a reader which will reconstruct the original structures. Bill Pence's FITSIO toolkit is perfect for dealing with the low-level operations on FITS files, and I use it. Being written in standard Fortran 77, however, means that it cannot provide the routines necessary to comprehend, encode, and decode structures of data. Using FITSIO, I have created a number of tools of this sort for my thesis data, but they are in no way standardized. I would not expect that someone else's FITS reader would have a chance of actually using my FITS files to do the work they were written to do. Basically, then, I have invented tools with some of the features of HDF, but which are based upon an "archival" underlying format. If HDF makes doing the work easier, then that is a significant advantage for it which FITS does not have. This is especially true for graduate students or other sorts of projects which do not have the time to invent some kind of wrapper code that successfuly stores and retrieves their data structures. Bill Pence's FITSIO routines are good, but FITS would benefit even more by having a much higher-level interface in a language which comprehends the kinds of non-rectangular data structures which have always been around but which are awkward to manipulate in FORTRAN. _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me. From fitsbits-request Fri Aug 6 07:02:13 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3291" "" "6" "August" "93" "01:28:39" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "56" "Re: min and max table column keywords" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07662; Fri, 6 Aug 93 07:02:13 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!Hypatia!leb References: <9307301816.AA21391 at tetra.gsfc.nasa.gov> From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: min and max table column keywords Date: 6 Aug 93 01:28:39 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: >TDMINnnn = 0.0 / the actual minimum value contained in column nnn of the table >TDMAXnnn = 1000. / the actual maximum value contained in column nnn of the table > >Does anyone have any comment on these keyword names? Or has an alternative >keyword already been proposed and/or used for this purpose? A resounding yes! This convention was mentioned some time ago, and I have been a big fan ever since. Future FITS tables from the Astronomical Data Center will definitely use this convention, and I plan to propose that they be made standard keywords whenever the next NOST FITS committee begins operation. One remaining question is about the datatype of the value. Should it always be floating point? In ASCII tables, the TNULL field is defined to be a string readable with the format given in TFORM. This may present a problem for binary tables where the value of the keyword is character, regardless of whether it is enclosed in quotes or not, whereas the actual data you'd be comparing TDMIN/TDMAX against are binary. I think that it would suffice for both ASCII and BINTABLE extensions to have the TDMIN/TDMAX be strings readable by the TFORM keyword, implying that a sensible mapping of the BINTABLE TFORMs can be made to some default formats in Fortran, C, etc. The reason I'd like to have it this way is to allow a MAX and MIN for ASCII-valued columns. I'd hate to see a really useful feature like this restricted to just numbers. The ADC has found that specifying maximum and minimum values for strings in tables, e.g. note flags that range from 'A' to 'M', provide for easy validation checking of the contents of a table. It has become extremely useful and very nearly mandatory for us to do our jobs. Does anyone have any comment on that? It's still unresolved in my own mind, and I'd really appreciate hearing from the community before we go into production on our tables. (Paul Kuin and I have just won a grant to generate FITS tables from another 150 or so ADC catalogs over the next two years, so there *will* be new FITS data from the ADC, and it *will* be using TDMIN and TDMAX and possibly TSORT to indicate sorted columns.) >Similarly, we need to define a pair of keywords which give the minimum >and maximum _legal_ value for the numbers in a column. For example, a >table column containing the X coordinate of a list of detected photon >in an image may have legal values from 0 - 255 inclusive. A good >keyword name for this purpose is less obvious, but the following pair >of keywords has been suggested: >TAMINnnn = 0.0 / the smallest possible value for column nnn of the table >TAMAXnnn = 255.0 / the largest possible value for column nnn of the table I might suggest, TLMINnnn and TLMAXnnn for "Table Legal Min" and "Table Legal Max", respectively. I think that these keywords are not needed as much as the ones mentioned above. It's much more important to know the *real* value boundaries then the *expected* boundaries, at least in the applications that I can think of. -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS From fitsbits-request Fri Aug 6 07:12:41 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2122" "" "6" "August" "1993" "05:39:52" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "58" "shell tools for FITS files, part II" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07800; Fri, 6 Aug 93 07:12:41 EDT Return-Path: Message-Id: <23sqr8INN5jf at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!news.udel.edu!udel!gvls1!dsinc!spool.mu.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla From: sla at umbra.UCSC.EDU (Steve Allen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: shell tools for FITS files, part II Date: 6 Aug 1993 05:39:52 GMT A while back I posted a little shell script that could be used to print the contents of FITS file headers. Here, with thanks to Alberto Accomazzi, is an improved version. #!/bin/sh # A little Cshell script which acts like cat. # Author: Steve Allen (sla at lick.ucsc.edu) 1992,1993 # It takes as input a FITS file, and cats out the headers of # the primary HDU and any FITS extensions which may be present. # 04/27/93 Modified to be a Bourne shell script and redirect # the statistics generated by dd to /dev/null # Alberto Accomazzi (alberto at cfa.harvard.edu). # 06/22/93 Modified to print only primary header and quit # unless flag -x is specified # Alberto Accomazzi (alberto at cfa.harvard.edu). # # Some recent Lick FITS headers have a "comment" as a part of the # END card. This is actually illegal, but by giving the -L switch # as the first argument this script will tolerate them. sed1='/^SIMPLE = /,/^END *$/p' sed2='/^END *$/q' files="" if [ $# -gt 0 ] ; then for arg in $* ; do case "$arg" in -l|-L) # be compatible with the illegal Lick FITS headers sed1='/^SIMPLE = /,/^END */p' ;; -x|-X) # print extension header sed2='/^XTENSION= /,/^END *$/p' ;; -*) # illegal option echo "Usage: $0 [-x] [-l] [fitsfile]" >&2 exit 1 ;; *) # filename files="$files $arg" ;; esac done fi # if [ -z "$files" ] ; then # act like a pipeline element ( dd conv=unblock cbs=80 | sed -n -e "$sed1" -e "$sed2" ) 2>/dev/null else set $files for file in $* ; do if [ $# -gt 1 ] ; then echo "===> "$file" <===" fi ( dd conv=unblock cbs=80 if=$file 2>/dev/null | sed -n -e "$sed1" -e "$sed2" ) 2>/dev/null done fi _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me. From fitsbits-request Fri Aug 6 07:13:40 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2320" "" "6" "August" "1993" "05:46:49" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "55" "shell tools for FITS files, part III" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07827; Fri, 6 Aug 93 07:13:40 EDT Return-Path: Message-Id: <23sr89INN5no at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!europa.eng.gtefsd.com!uunet!spool.mu.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: <23sqr8INN5jf at darkstar.UCSC.EDU> From: sla at umbra.UCSC.EDU (Steve Allen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: shell tools for FITS files, part III Date: 6 Aug 1993 05:46:49 GMT Here is yet one more little shell tool for FITS files. Given a keyword on the command line, it picks out the value of that keyword and prints it. There is lots of room for improvement of this script, but it works. #!/bin/sh # fitskey # A little bourne shell script which acts like fgrep for FITS keywords. # It only looks in the primary header; extensions are ignored. # Author: Steve Allen (sla at lick.ucsc.edu) 1993 # It takes as input a FITS file, and prints out the FITS key # values associated with the given FITS keyword. # Could be enhanced to look at XTENSIONs, and to optionally print # the keyword itself and/or the comment field. It also produces # stupid output if there is more than one identical keyword. # if [ $# -lt 1 ]; then echo "Usage: $0 FITSkeyword [FITSfile ...]" >&2 exit 1 fi # a legal FITS key must be 8 characters long with explicit trailing spaces # the awk script here ensures that arrangement # find a quoted string (but not one which contains quotes!) seds=`echo $1 | awk '{printf("s&^%-8.8s= *\(%c[^%c]%c\)&\1&p",$1,39,39,39)}'` # echo seds is $seds # find a value followed by a comment sedc=`echo $1 | awk '{printf("s&^%-8.8s= *\(.*\)/.*&\1&p",$1)}'` # echo sedc is $sedc # find a value not followed by a comment sedv=`echo $1 | awk '{printf("s&^%-8.8s= *\(.*\)&\1&p",$1)}'` # echo sedv is $sedv shift # throw away the FITS keyword in the first argument sedq='/^END */q' # detect end of primary fits header (even if from Lick) if [ -z "$*" ] ; then # act like a pipeline element ( dd conv=unblock cbs=80 | sed -n -e "$sedq" -e "$seds" -e t -e "$sedc" -e t -e "$sedv" ) 2>/dev/null else for file in $* ; do keyval=`dd cbs=80 conv=unblock if=$file 2>/dev/null | \ sed -n -e "$sedq" -e "$seds" -e t -e "$sedc" -e t -e "$sedv"` if [ ! -z "$keyval" ]; then if [ $# -gt 1 ]; then echo $file": "$keyval else echo $keyval fi fi done fi _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me. From fitsbits-request Fri Aug 6 12:14:12 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["852" "" "6" "August" "1993" "11:43" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "23" "Re: HDF as an archive format" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09487; Fri, 6 Aug 93 12:14:12 EDT Return-Path: Message-Id: <6AUG199311431903 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <5AUG199310442680 at nssdca.gsfc.nasa.gov> <23rnj7INNo7d at darkstar.UCSC.EDU> 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: HDF as an archive format Date: 6 Aug 1993 11:43 EDT In article <23rnj7INNo7d at darkstar.UCSC.EDU>, sla at umbra.UCSC.EDU (Steve Allen) writes... >In article <5AUG199310442680 at nssdca.gsfc.nasa.gov> >bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes: > >>The basic goal of a FITS software reader is to generate the >>appropriate table or array.... > >This sentence exposes one of the worst problems with FITS > "tabel or array" >FITS is great for encoding any kind of multidimensional rectangular >array. It is not so great for other entities. > > >I mean, specifically, data structures, linked lists, and other sorts of >documentary information which would be associated with an image. Tables and arrays are the only standard extensions and proposals under consideration at present. But the field is open for more development. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Fri Aug 6 14:11:02 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1693" "" "6" "August" "1993" "17:24:21" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "53" "Re: shell tools for FITS files, part II" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09556; Fri, 6 Aug 93 14:11:02 EDT Return-Path: Message-Id: <23u445INNfbs at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: <23sqr8INN5jf at darkstar.UCSC.EDU> From: sla at umbra.UCSC.EDU (Steve Allen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: shell tools for FITS files, part II Date: 6 Aug 1993 17:24:21 GMT In article <23sqr8INN5jf at darkstar.UCSC.EDU> sla at umbra.UCSC.EDU (that was me) forgot that one of Alberto Accomazzi's best additions to the original shell script was to create a man page. Kindly associate it with the shell script if you are keeping these. .TH fitshead l "22 June 1993" .IX fitshead .SH NAME fitshead - display the header of a FITS file .SH SYNOPSIS .B fitshead [ .B -l ] [ .B -x ] [ .IR fitsfile \ ... ] .SH DESCRIPTION Displays the header of a FITS file. If flag .B \-x is specified, any extensions that may be present in the input file are displayed as well. .SH OPTIONS .PP .TP .B \-l forces .I fitshead to tolerate illegal END cards in the header (these cases have been found in files generated at Lick Observatory). .PP .TP .B \-x scans the file for any FITS extensions and, if found, displays the extension header(s). .SH "SEE ALSO" dd(1), sed(1) .SH AUTHOR Steve Allen (sla at lick.ucsc.edu) 1992,1993 .br Modified by Alberto Accomazzi (alberto at cfa.harvard.edu) 1993. .\" Permission to use, copy, modify, and distribute this software and its .\" documentation for any purpose and without fee is hereby granted, provided .\" that the above copyright notice appear in all copies and that both that .\" copyright notice and this permission notice appear in supporting .\" documentation. This software is provided "as is" without express or .\" implied warranty. _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me. From fitsbits-request Fri Aug 6 15:56:49 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1025" "Fri" "6" "August" "1993" "15:54:41" "-0400" "Usque ad mortem bibendum" "GEORGE at ROSGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "26" "OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings " "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09628; Fri, 6 Aug 93 15:56:49 EDT Return-Path: Message-Id: <930806155441.20c000b3 at ROSGIP.GSFC.NASA.GOV> X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU" From: GEORGE at ROSGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings Date: Fri, 6 Aug 1993 15:54:41 -0400 (EDT) A new version of the OGIP memo (OGIP/93-001) listing the OGIP-standard strings to specify physical units within FITS files is now available. Only very minor changes have been made compared to previous versions to help clarify a number of points. The "unit" byte is also now included due to popular demand. The memo is available via anonymous ftp on legacy.gsfc.nasa.gov (128.183.8.233) as .caldb/docs/memos/ogip_93_001.tex the LaTeX source .caldb/docs/memos/ogip_93_001.ps PS version of complete doc. It is intended that this document will also be published in the next issue of "Legacy: The Journal of the HEASARC" (currently scheduled for 93 Sept/Oct). For your info, this latest version was formally endorsed by a meeting of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC on 1993 Aug 04. All future OGIP FITS files will therefore adhere to the recommendations contained therewithin. regards Ian M George (george at lheavx.gsfc.nasa.gov) HEASARC From fitsbits-request Fri Aug 6 18:18:43 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1269" "Fri" "06" "August" "93" "18:18" "EDT" "\"Wayne H. Warren Jr. 286-5419\"" "W3WHW at GIBBS.GSFC.NASA.GOV" nil "26" "TAMIN, TAMAX Keywords" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09691; Fri, 6 Aug 93 18:18:43 EDT Return-Path: Message-Id: <9308062218.AA09685 at fits.cv.nrao.edu> From: "Wayne H. Warren Jr. 286-5419" (Code 681/GSFC) Sender: fitsbits-request at fits.CV.NRAO.EDU To: FITSBITS Subject: TAMIN, TAMAX Keywords Date: Fri, 06 Aug 93 18:18 EDT leb at hypatia.gsfc.nasa.gov (Lee Brotzman) writes: >I might suggest, TLMINnnn and TLMAXnnn for "Table Legal Min" and >"Table Legal Max", respectively. I think that these keywords are not >needed as much as the ones mentioned above. It's much more important to >know the *real* value boundaries then the *expected* boundaries, at >least in the applications that I can think of. I prefer TAMINnnn and TAMAXnnn for "allowed" myself, since the other seems to imply that these "allowed" values could never change for the same data (plus they remind me of LAWYERS-"sic"). These parameters may be somewhat less important than the REAL extrema, but for validation purposes, they can be very useful to discover invalid data. For example, in a catalog of stellar parameters, one knows that stellar radial velocities can never be outside the range +/-300 k/s (just an example), whereas the actual range might be much smaller and the user might not be familiar enough with radial velocites to know the "allowed" values. Thus, the allowed extrema provide at least a certain amount of validation for data that cannot be checked at all by any other means. Wayne H. Warren Jr. Hughes STX Corporation Laboratory for Astronomy and Solar Physics NASA GSFC w3whw at gibbs.gsfc.nasa.gov From dwells Fri Aug 6 22:31:22 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1430" "Fri" "6" "August" "1993" "13:58:31" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "32" "OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings " "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10036; Fri, 6 Aug 93 22:31:22 EDT Resent-Message-Id: <9308070231.AA10036 at fits.cv.nrao.edu> Return-Path: Message-Id: <9308070231.AA10030 at fits.cv.nrao.edu> Resent-Sender: dwells From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: fitsbits-request at fits.CV.NRAO.EDU Resent-From: dwells (Don Wells) To: fitsbits Subject: OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings Date: Fri, 6 Aug 1993 13:58:31 -0400 (EDT) Resent-Date: Fri, 6 Aug 1993 13:58:31 -0400 (EDT) ------- Start of forwarded message ------- Message-Id: <930806135831.20e003a1 at HEAGIP.GSFC.NASA.GOV> From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) To: fitsbits-request at fits.CV.NRAO.EDU Subject: OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings Date: Fri, 6 Aug 1993 13:58:31 -0400 (EDT) A new version of the OGIP memo (OGIP/93-001) listing the OGIP-standard strings to specify physical units within FITS files is now available. Only very minor changes have been made compared to previous versions to help clarify a number of points. The "unit" byte is also now included due to popular demand. The memo is available via anonymous ftp on legacy.gsfc.nasa.gov (128.183.8.233) as .caldb/docs/memos/ogip_93_001.tex the LaTeX source .caldb/docs/memos/ogip_93_001.ps PS version of complete doc. It is intended that this document will also be published in the next issue of "Legacy: The Journal of the HEASARC" (currently scheduled for 93 Sept/Oct). For your info, this latest version was formally endorsed by a meeting of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC on 1993 Aug 04. All future OGIP FITS files will therefore adhere to the recommendations contained therewithin. regards Ian M George (george at lheavx.gsfc.nasa.gov) HEASARC ------- End of forwarded message ------- From fitsbits-request Sat Aug 7 09:57:01 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4740" "Sat" "7" "August" "1993" "9:55:09" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "96" "OFSP Proposal for a HDUCLASn hierarchy of keywords (v 93-Aug-08)" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11708; Sat, 7 Aug 93 09:57:01 EDT Return-Path: Message-Id: <930807095509.20e00530 at HEAGIP.GSFC.NASA.GOV> X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU" From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: OFSP Proposal for a HDUCLASn hierarchy of keywords (v 93-Aug-08) Date: Sat, 7 Aug 1993 9:55:09 -0400 (EDT) ------------------------------------------------------- | THE USE OF HDUCLASn KEYWORDS WITHIN FITS FILES | ------------------------------------------------------- Version: 1993 Aug 06 (Formerly, "THE USE OF EXTCLASn KEYWORDS WITHIN FITS FILES") At a meeting on 1993 Aug 04 of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review of the OFSPs previous proposal for the provision of a hierarchical classification scheme for various types of FITS extension to be used within the OGIP (and potentially elsewhere). As a result of a comment received from Maureen Conroy (CfA), the previous proposal (as posted to FITSBITS by George 93-jul-26) has been revised such that the proposed hierarchy is now achieved using HDUCLASn keywords (rather than the previous suggestion of EXTCLASn). The current proposal is included below in full. As ever, the OFSP would welcome any comments (via FITSBITS) on this new proposal. ====================== Current Proposal in Full ============================ ------------------------------------------------------- | THE USE OF HDUCLASn KEYWORDS WITHIN FITS FILES | ------------------------------------------------------- Version: 1993 Aug 06 Introduction ------------ We consider there to be a common need for a set of keywords which precisely define the scientific 'type', 'sub-type', 'sub-sub-type'..etc of the data contained within a given FITS extension (including the Primary Array). It should be stressed that by scientific 'type' we are referring to whether a given extension contains (say) a 'light curve', a 'PHA spectrum', a 'background map', and possibly sub-classes of these. We are NOT explicitly referring to how that data is actually stored internally within the FITS extension. As far as we are aware, no existing FITS keywords are commonly used for SOLELY for this purpose, or (can easily) provide the necessary & desirable number of hierarchical levels (at least for our intended usage). Indeed, we are aware that a variety of existing keywords have been employed for similar purposes within the community (specifically EXTNAME), but often using mutually incompatible conventions. Here we therefore propose a family of new keywords which forms such a hierarchy of descriptive strings EXPLICITLY for this usage. We believe these new keywords compliment & clarify the use of existing FITS keywords, and are likely to be of general use throughout the FITS community. The Proposal ------------ We propose that the scientific 'type', 'sub-type', 'sub-sub-type'..etc of the data contained within a given FITS extension be specified using a set of keywords of the form HDUCLASn (standing for Header-Data Unit Class), where "n" is an integer between 1 & 9. These keywords should be considered hierarchical with n = 1 as the highest level, and n = 9 the lowest level. Usage ----- The need & use of such keywords can be illustrated as follows. The input to a specific application task is a FITS file consisting of a large number of extensions. The application requires access to a particular type of (scientific) data -- lets say a "heavy particle background map" for a given observation using a given detector. Under the proposal, an extension containing such data would contain (say): HDUCLAS1 = 'BKGDMAP' HDUCLAS2 = 'PARTICLE' HDUCLAS3 = 'HEAVY' and the application would thus first search through the file looking for HDUCLASn keywords with these values. If found, the application can then check for appropriate values of OBS-DATE, TELESCOP, INSTRUME etc. [Of course for generality/safety, the application might also want to continue checking the remainder of the input file for additional extensions fulfilling the above criteria. If additional extensions are indeed found, then the application may, for example, prompt the user for which they wish to use supplying information from other keywords etc] Once the required extension has been identified, the data can obviously be accessed. Advantages ---------- We consider the advantages of these new keywords over the use existing keywords (in particular the EXTNAME keyword) for this purpose to be as follows: 1) The new keywords are explicitly designed for this purpose, and thus will not impact the ways in which other keywords are currently used. 2) The new keywords are equally appropriate for use with the Primary Array or an extension. 3) The hierarchical nature of the information is explicit, and allows smaller, user-friendly strings to be employed ----------------------------------- END ---------------------------------- Ian M George NASA/GSFC OFSP 1993 Aug 08 From fitsbits-request Sat Aug 7 10:58:48 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1917" "Sat" "7" "August" "1993" "10:56:57" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "38" "OFSP proposal Re: min and max table column keywords " "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11859; Sat, 7 Aug 93 10:58:48 EDT Return-Path: Message-Id: <930807105657.20e00530 at HEAGIP.GSFC.NASA.GOV> X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU" From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: OFSP proposal Re: min and max table column keywords Date: Sat, 7 Aug 1993 10:56:57 -0400 (EDT) ------------------------------------------------------------------------ | PROPOSED KEYWORDS TO GIVE THE MIN & MAX LEGAL VALUES WITHIN A COLUMN | ------------------------------------------------------------------------ At a meeting on 1993 Aug 04 of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review of keywords pairs used to give the minimum/maximum values actually contained and the minimum/maximum legal values within a column in a FITS table. It was confirmed that the OGIP will use the TDMINnnn/TDMAXnnn keywords already in common usage (eg Thompson FITSBITS post 93-aug-03) for the minimum/maximum values actually contained within column 'nnn' of a FITS table. In addition, the OFSP provisionally recommended that the TLMINnnn/TLMAXnnn keywords be used to give the minimum/maximum LEGAL value for the numbers in column 'nnn' of a FITS table (as suggested by Brotzman FITSBITS 93-aug-06). The OFSP also recommended the following to clarity: - The datatype of the keywords should be the same as that of the table column to which they refer. - The keywords refer to ALL elements of a vector column. - These keywords imposed no constraints or information regarding the meaning of any null data values within the data. - It should not be forbidden to have values of (say) TDMIN < TLMIN, leaving it to individual applications as to what such situations implied. - If the keyword for the minimum value be GREATER than that for the maximum value (ie TDMIN>TDMAX or TLMIN>TLMAX as appropriate), then this should be taken to mean that the values had not been defined and/or therefore needed [re-]calculating. [The OFSP meeting obviously took place prior to Wayne Warren's FITSBITS post on 93-aug-06] ----------------------------------- END ---------------------------------- Ian M George NASA/GSFC OFSP 1993 Aug 07 From fitsbits-request Sat Aug 7 11:56:14 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["797" "Sat" "7" "August" "1993" "15:10:51" "GMT" "Brad A. Pennock" "benji at netcom.com " nil "12" "FITS viewer for the Amiga?" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11894; Sat, 7 Aug 93 11:56:14 EDT Return-Path: Message-Id: Organization: NETCOM On-line Communication Services (408 241-9760 guest) Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!umn.edu!csus.edu!netcom.com!benji From: benji at netcom.com (Brad A. Pennock) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS viewer for the Amiga? Date: Sat, 7 Aug 1993 15:10:51 GMT I was just wondering if there was anyone reading this who knows of a FITS image viewer for the Amiga? If not, is there a program that works for the Mac that'llconvert a FITS image into .GIF or 24bit? Thanks for your help! -- _______----_______ Brad A. Pennock ___---~~~~~.. ... .... ... ..~~~~~---___ benji at netcom.com ============================================== ________________________- .. .. _--~~~~~-------____-------~~~~~ (____________________][__)____ - / /____---~~~.. .. ..~~-_~ "We put humans on the Moon in less time <_____________________________- than we've spent debating the space ~~~~~~----__ _- station." Daniel S. Goldin, NASA. ~~~~~~~~~~~ From fitsbits-request Wed Aug 11 14:58:14 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA22041; Wed, 11 Aug 93 14:58:14 EDT Return-Path: Message-Id: <9308111857.AA08076 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: Re: the "archival" issue Date: Wed, 11 Aug 93 14:57:18 EDT Don Wells (2 Aug 1993) quoted Archie Warnock as saying: >There are (at least) three different applications for data formats - >interchange, access and archival storage. It is not at all obvious that >any single format can meet the needs of all 3 simultaneously, even less >obvious that any single format currently _does_ meet the needs of all 3. > >In general, working formats need to emphasize access (read/write) >efficiency. Interchange formats need storage efficiency and >standardized numeric representations. Archival formats need to be >self-documenting, externally documented and simple. > >Things like HDF, netCDF and CDF are good working formats but are risky >as archival formats. (...) FITS >and PDS are pretty good interchange and archival formats, but weak >working formats. The last sentence seems questionable since we have been using FITS as a working format within the HEASARC for the past 2 years with great success. I need to give a talk on this subject in a couple weeks, so I would be very interested to hear other opinions or explanations on why FITS is not the ideal working format. -Bill Pence pence at tetra.gsfc.nasa.gov From fitsbits-request Wed Aug 11 22:32:05 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24059; Wed, 11 Aug 93 22:32:05 EDT Return-Path: Message-Id: <1993Aug11.215833.5575 at Mr-Hyde.aoc.nrao.edu> Organization: National Radio Astronomy Observatory, Socorro NM Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!Mr-Hyde.aoc.nrao.edu!dbriggs References: <9308111857.AA08076 at tetra.gsfc.nasa.gov> From: dbriggs at Mr-Hyde.aoc.nrao.edu (Daniel Briggs) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS as a working format Date: Wed, 11 Aug 93 21:58:33 GMT In article <9308111857.AA08076 at tetra.gsfc.nasa.gov> pence at tetra.gsfc.nasa.gov (William Pence) writes: >>FITS and PDS are pretty good interchange and archival formats, but weak >>working formats. > >The last sentence seems questionable since we have been using >FITS as a working format within the HEASARC for the past 2 years with >great success. I need to give a talk on this subject in a couple >weeks, so I would be very interested to hear other opinions or >explanations on why FITS is not the ideal working format. I'll just comment that we have an image processing system here at NRAO called SDE that primarily uses FITS as the working format. It's a collection of cooperating programs that are starting from the command line. All images, visibility files and what have you are stored as native files under the host OS, and are read into memory as needed by each task. Now this is a system designed for coding up experimental tasks quickly. (In fact, the acronym stands for Software Development Environment.) We have a very flexible in memory database format for objects, which can potentially have all sorts of additional things hanging off of them that are not necessarily easily representable by FITS. Our FITS reader/writer makes no effort to encode or decode unknown keywords into FITS format. It just writes out all the standard keywords, and a small list of local ones, if they are present. If we have a database object that uses the more flexible features of the format, we store the object as a (nonportable) memory image. For most other objects, we use FITS format. Since we use SAOimage for image display, there is a strong incentive to use FITS rather than the memory image format. (SAOimage can be used on the memory image files, but only with great effort.) My point is this: I use this system every day, and do a lot of software development with fairly complicated algorithms. I can't remember the last time I was forced to use the memory image format. It's amazing how much everyday work can done with a very simple FITS format, and small handful of 'optional' header keywords. Some of our software is a bit sloppy in assuming that one or more of the local keywords are present in the header, but that's only bitten me once in the last three years I've been working in this system. (That was when importing an image from a different system -- we used different keywords for pointing center.) Basically, FITS has worked out just fine as a working format for us, with the caveat that we have the option of going to a less portable, more flexible format when needed. But we rarely need it. -- | Daniel Briggs (dbriggs at nrao.edu) | USPA B-14993 | New Mexico Tech / National Radio Astronomy Observatory | DoD #387 | P.O. Box O / Socorro, NM 87801 (505) 835-7391 | Support the League for Programming Freedom (info from lpf at uunet.uu.net) From fitsbits-request Wed Aug 11 22:56:58 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1551" "Wed" "11" "August" "93" "23:06:23" "GMT" "Chris Flatters" "cflatter at cv3.CV.NRAO.EDU " nil "29" "Re: FITS as a working format" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24071; Wed, 11 Aug 93 22:56:58 EDT Return-Path: Message-Id: <1993Aug11.230623.16228 at Mr-Hyde.aoc.nrao.edu> Organization: NRAO Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!Mr-Hyde.aoc.nrao.edu!laphroaig!cflatter References: <1993Aug11.215833.5575 at Mr-Hyde.aoc.nrao.edu> 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: FITS as a working format Date: Wed, 11 Aug 93 23:06:23 GMT The limitations of FITS as a working format only become apparent if you have to modify a FITS file in place. In this case you start to hit problems due to the fact that a FITS file contains several pieces that follow one after another. If you have to extend any but the last you need to shuffle everything later in the file to make room. As a simple but contrived example suppose that you have a CCD image and are removing background stars and CCD defects using some interactive editor. Your editor adds history records to the FITS header describing every edit. After a number of edits the empty space in the header will be exhausted and the editor will have to add another 2880-byte block to the header. In order to do this it must add 2880 bytes to the end of the file and then copy all of the image data down by 2880 bytes. If the image is large this could be an expensive operation. This type of problem is made worse if the are multiple HDUs (Header and Data Units) in the file and similar problems will arise in any format where the data are encoded as a serial stream of data units. The problem is avoided if in-place modification is forbidden and every change requires a new file to be written. This is not always practical. It can also be avoided by splitting the FITS file into its component parts (but then it is no longer a FITS file). The idea of using a disected version of FITS as a common working format for AIPS, IRAF etc was floated about 3 years ago but didn't seem to get anywhere. Chris Flatters cflatter at nrao.edu From fitsbits-request Thu Aug 12 05:00:24 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5911" "Thu" "12" "August" "1993" "10:18:57" "+0200" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "113" "Re: the \"archival\" issue" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24141; Thu, 12 Aug 93 05:00:24 EDT Resent-Message-Id: <9308120900.AA24141 at fits.cv.nrao.edu> Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Reply-To: Lucio Chiappetti In-Reply-To: <9308111857.AA08076 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: the "archival" issue Date: Thu, 12 Aug 1993 10:18:57 +0200 (MET DST) Resent-Date: Thu, 12 Aug 1993 10:18:57 +0200 (MET DST) On Wed, 11 Aug 1993, William Pence wrote: > Don Wells (2 Aug 1993) quoted Archie Warnock as saying: > > >There are (at least) three different applications for data formats - > >interchange, access and archival storage. [...] > > > >Things like HDF, netCDF and CDF are good working formats but are risky > >as archival formats. (...) FITS > >and PDS are pretty good interchange and archival formats, but weak > >working formats. > > The last sentence seems questionable since we have been using > FITS as a working format within the HEASARC for the past 2 years with > great success. I need to give a talk on this subject in a couple > weeks, so I would be very interested to hear other opinions or > explanations on why FITS is not the ideal working format. > Essentially the reasons why (IMHO) FITS is not an ideal WORKING format are listed below (Bill you alrady know my opinion on this, I'm just repeating for the benefit of the list). However this is a matter of choice of the particular software package writer/user, and in my opinion has a lesser weight than the fact that FITS is at present an excellent INTERCHANGE format. I've recently got access to a newsreader and subscribed to sci.data.formats and was surprised to find that there are more data formats between heaven and earth than are used by us astronomers, but my reaction was "oh not yet another format" .... and in fact I've never seen other than FITS used for interchange (besides person-to-person arrangements using native formats of IRAF or MIDAS). Concerning ARCHIVING I am not so competent to judge, but I gather from the previous messages in this thread that FITS is good there too. LONG life to FITS !!! ----------------------------------------------------------------------------- Here are the reasons why I choose not to use FITS as working format (in this following an historical trend) a) FITS uses non-native binary representation, i.e. is more or less slower on non-IEEE machines like VMS, Ultrix (nowadays this might be not so important, but one might like to gain that little extra speed) [My working format uses native representation, and optionally allows in place conversion between different operating system formats] b) FITS headers are bulkier (because they're ASCII card images, which is good for exhcange/archiving) than a possible pure-binary representation [which I use in my working format] c) FITS headers are not extensible (this is pointed out also by Chris Flatters). In my opinion this is a major snag of a working format if one wants to add keywords taking into account a file in-place (rever- sible or not) modifications. [in my working format I use a file made of three parts : a fixed miniheader at start, a data section, and the "header" at the end. This because I do not like to keep things separate a' la .imh+.pix] d) the FITS 2880 block size is somewhat unnatural (this is totally transparent to an user of a package, but may be of some relevance to debugging while developing ... I'd like my file to have a "natural" record size, e.g. one image or table row ... so that I can easily look at a wrong file with some record oriented tool and find out what I did wrong) [in my working format I use such "natural" record sizes ... even if incidentally the data section on a non-record oriented (Unix), IEEE machine will be identical to the data section of a FITS HDU] e) Chris Flatters mentioned (as an additional inefficiency to be added to point c) the fact that sometimes a FITS file has extra extensions. I personally do not like the usage to stick more HDUs in the same file for working purposes (bseides the usual SINGLE binary table case, of course), while this might be used for interchange (in fact most s/w I know unpacks the extensions in separate native files) [in my working format each file is standalone, however I conceive to stick together some associated files when converting to FITS for exchange ... e.g. my original proposal for exchange of a response matrix was a primary HDU with the matrix, and an IMAGE extension with the associated energy grid] Of course this is nothing intrinsic in FITS (just it is TOO flexible), is just a matter of taste of software writers. Actually most of the above is matter of tastes. It was enough for me to choose a different working format, but definitely not enough to depart from FITS for interchange (in fact I enforced a number of FITS conventions and **limitations** in the definition of my format, in order to preserve easy mapping) f) one additional element may be that FITS needs conventions (in order to be long-lived), which may not always be suitable to the needs of a particular packages. If you choose FITS as working format you have either to stick to the conventions, or to propose new ones (the sort of things from OGIP seen in the last few months over fitsbits and HEAFITS). If these are mainly "insider" conventions, it could be easier to arrange things within a native format. [e.g. things like character keywords longer than 68 char, or arrays or keywords] ----------------------------------------------------------------------------- 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 Mon Aug 16 18:32:54 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5326" "" "16" "August" "93" "20:55:25" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "107" "Re: the \"archival\" issue" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06362; Mon, 16 Aug 93 18:32:54 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!Hypatia!warnock References: <9308111857.AA08076 at tetra.gsfc.nasa.gov> From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: the "archival" issue Date: 16 Aug 93 20:55:25 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: >The last sentence seems questionable since we have been using >FITS as a working format within the HEASARC for the past 2 years with >great success. I need to give a talk on this subject in a couple >weeks, so I would be very interested to hear other opinions or >explanations on why FITS is not the ideal working format. First of all, note that I claim only that it's not an ideal working format, not an unusable working format. Until the development of FITSIO (a relatively recent development in the long and illustrious history of FITS), it _was_ essentially unusable as a working format. There are still some problems, though. A number have already been mentioned. I'm still waiting for a C interface to FITSIO that doesn't require a Fortran compiler. There's no support in FITS for advanced data structures (yeah - I know about BINTABLE, but I'm still waiting to see some complex data structures encoded and utilized portably. It just _might_ work, but I'm not sure it's actually been done yet). It works pretty well as a working format in some (reasonably simple) cases, but I think you'd need to look at some of the annotation and other capabilities of HDF before you make the case that FITS is anything close to ideal. FITS is unsurpassed (I firmly believe) in doing what it was designed for. My remarks are in no way to be interpreted as an overall criticism. Heck, I've even seen a text editor written in Fortran. Just because you can do it doesn't mean you _should_ do it... -- _______________________________________________________________________ -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC Project STELAR: WAIS to do science From fitsbits-request Tue Aug 17 07:46:18 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["697" "Tue" "17" "August" "1993" "12:46:02" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "14" "Annotation capability (was Re: the \"archival\" issue)" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA08407; Tue, 17 Aug 93 07:46:18 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells References: <9308111857.AA08076 at tetra.gsfc.nasa.gov> From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Annotation capability (was Re: the "archival" issue) Date: Tue, 17 Aug 1993 12:46:02 GMT In article warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) writes: "... I think you'd need to look at some of the annotation and other capabilities of HDF before you make the case that FITS is anything close to ideal.." Archie, please tell us about annotation and other HDF features that may be lacking in present FITS practice. What is annotation, how does it work, what does it do? -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Tue Aug 17 14:26:01 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09058; Tue, 17 Aug 93 14:26:01 EDT Return-Path: Message-Id: <17AUG199314000763 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS User's Guide available in PostScript Date: 17 Aug 1993 14:00 EDT An experimental PostScript copy of the User's Guide for FITS, commissioned by NASA Headquarters and maintained by the NOST FITS Support Office, has been added to the anonymous ftp files in the FITS directory at nssdca.gsfc.nasa.gov. This version of the User's Guide (3.0) is the one that has been available in printed form since January 1993. The User's Guide is designed as a comprehensive introduction to FITS, providing, in addition to the basic rules, FITS background and history, recommended practices and hints for FITS use, and discussions of current directions of development. The style is deliberately conversational, in contrast to the NOST Standard's precise rulebook formality. This PostScript file was generated by capturing the Macintosh MS Word original in PostScript format. Reports received by the FITS office are that it has successfully printed from both VAX and Sun computers, on HP Laserjet printers (IIIsi) and Sun printers. Numerous other retrievals have been made without any printing problems reported, although a ghostwriter previewer could not deal with certain fonts. 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. Barry Schlesinger NSSDC/NOST FITS Support Office (Internet) fits at nssdca.gsfc.nasa.gov (DECnet) NCF::FITS +1-301-513-1634 From fitsbits-request Wed Aug 18 12:01:40 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["9887" "" "18" "August" "93" "15:18:00" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "249" "Identification of a FITS byte stream" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02705; Wed, 18 Aug 93 12:01:40 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!Hypatia!warnock From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Identification of a FITS byte stream Date: 18 Aug 93 15:18:00 GMT The recent discussion on suitability of formats for archiving has reminded me of the following small issue I'd like to raise here. How does someone who knows nothing about FITS identify an arbitrary byte stream as FITS? Note - if we _know_ about FITS, we can tell it's FITS by the presence of the SIMPLE keyword at the start of the byte stream. But there's nothing required in the byte stream that says "I'm a FITS file and here's where you go to find out about me." Should such a comment be mandatory? -- _______________________________________________________________________ -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC Project STELAR: WAIS to do science From fitsbits-request Wed Aug 18 12:01:42 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] ["753" "" "18" "August" "93" "15:20:47" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " "" "15" "Re: Annotation capability (was Re: the \"archival\" issue)" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02711; Wed, 18 Aug 93 12:01:42 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!usenet.ins.cwru.edu!agate!ames!skates.gsfc.nasa.gov!Hypatia!warnock References: <9308111857.AA08076 at tetra.gsfc.nasa.gov> From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Annotation capability (was Re: the "archival" issue) Date: 18 Aug 93 15:20:47 GMT dwells at fits.cv.nrao.edu (Don Wells) writes: >Archie, please tell us about annotation and other HDF features that >may be lacking in present FITS practice. What is annotation, how does >it work, what does it do? Will do, but it's going to take a couple of days before I get time to root through my HDF documentation. Obviously, it's critical to identify capabilities that exist in other formats that aren't supported in FITS so that we can address the issue of format conversion. -- _______________________________________________________________________ -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC Project STELAR: WAIS to do science From fitsbits-request Wed Aug 18 13:17:18 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1303" "Wed" "18" "August" "93" "13:16:19" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "27" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03003; Wed, 18 Aug 93 13:17:18 EDT Return-Path: Message-Id: <9308181716.AA19559 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: Identification of a FITS byte stream Date: Wed, 18 Aug 93 13:16:19 EDT Archie Warnock wrote: >Note - if we _know_ about FITS, we can tell it's FITS by the presence of >the SIMPLE keyword at the start of the byte stream. But there's nothing >required in the byte stream that says "I'm a FITS file and here's where >you go to find out about me." Should such a comment be mandatory? I think it would be a good idea to 'strongly recommend' that all FITS writers should add a standard comment citing a reference to a FITS definition document. This cannot be made manditory however without invalidating all the existing FITS files which don't have such a comment, unless there is a grandfather clause that exempts all existing FITS files. What is the best reference to cite? The old A&A Suppl. papers, which are somewhat out of date but are at least widely available in any Astronomical library? Or the new NOST FITS definition document which is much more complete, but may not be as easily accessable 50 years from now when someone is trying to decifer a dusty FITS tape? Or both? Also, should it be recommended that this comment be located as near as possible to the beginning of the FITS file, to make it easy to spot? Presumable this comment would only be needed in the primary array, and there would be little reason to repeat it in every extension. -Bill Pence From fitsbits-request Wed Aug 18 20:37:19 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5401" "Wed" "18" "August" "93" "18:36:23" "-0600" "ADS User Support" "ads at cuads.Colorado.EDU" nil "156" "The ADS Abstract Service" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05781; Wed, 18 Aug 93 20:37:19 EDT Return-Path: Message-Id: <9308190036.AA00505 at cuads.Colorado.EDU> From: ADS User Support Sender: fitsbits-request at fits.CV.NRAO.EDU To: FITSBITS at NRAO.EDU Subject: The ADS Abstract Service Date: Wed, 18 Aug 93 18:36:23 -0600 NOTE: We apologize if you have already received this message. Dear Colleague, We are pleased to announce the availability of the ADS Abstract Service for use by non-US users. To make use of this service, however, those users must make a patch update to their ADS installation (see the Installation Instructions below). Also, to help ensure the continued availability of the Abstract service outside the US, it would be worthwhile if you would also review the following Background Information. If you have non-US colleagues who would benefit from this or other ADS services, please pass this notice on to them or suggest that they contact ADS User Support ads at cuads.colorado.edu (303) 492-0466 Sincerely, ADS Operations Background Information ---------------------- The Astrophysics Data System (ADS) project has reached an agreement with NASA regarding the distribution of the abstracts to non-US users. The existing ADS Abstract Service provides access to over 125,000 abstracts written by NASA RECON (and provided by the NASA Scientific and Technical Information Program) describing the articles appearing in all major astronomical journals. According to the new agreement with NASA, we will make the Abstract Service available to non-US users for a period of 6 months. During this time we will gather statistics concerning usage patterns by non-US users. NASA will review these and will then either: Keep the abstracts open to all users, Place restrictions or requirements for compensation on some or all users/institutions, or Discontinue the distribution to non-US users. Compensation would probably be in the form of requiring articles and publications to be submitted to the NASA Aerospace Database and made available to the aerospace research community. Since the NASA archives depend on such contributions, NASA encourages voluntary contributions from users/institutions of archival material. If you have reports, journals or journal articles, conference papers or proceedings or any other form of scientific or technical information to contribute to NASA please contact: Glen Hoetker NASA Scientific and Technical Information Program 1213 Jefferson Davis Highway Suite 1200 Arlington, VA 22202 Tel: (703) 685-1350 Fax: (703) 271-5669 ghoetker at sti.nasa.gov Please mention in your contact that this is in return for the use of the ADS abstract service. Such contributions would make it much more likely that the first option above is the one chosen. If you have any questions or comments about this service and its availability, please contact: Dr. Guenther Eichhorn Project Manager Astrophysics Data System (617) 495-7260 gei at cfa.harvard.edu Installation Instructions ------------------------- All non-US users must update their ADS installations in order to make use of the Abstract service. Complete the following steps to update the Abstract service in your local installation of the ADS. Note: If your installation requires super-user privileges you may need to contact your system administrator. 1. Ensure that you are currently using ADS version 3.20. If you are currently using an earlier version of the ADS you will have to upgrade the entire installation to take advantage of the Abstract service. Check the file $ADS/ReleaseNotes.ADS if you do not know which version of the ADS you are running. 2. Change directory to $ADS/ads_lib. > cd $ADS/ads_lib 3. Pick up the new Abstract service files from the authenticated ftp site at IPAC. Be sure to use your ADS login and password when logging into the authenticated ftp directory at IPAC. % ftp ftp> open adsftp.ipac.caltech.edu 10011 [connection information ...] Name (adsftp.ipac.caltech.edu:[LOGNAME]): [ads_logname] 331 Password required for [ads_logname]. Password: [ads_password] 230 User [ads_logname] logged in. ftp> binary ftp> cd basic_system/ads320/patch ftp> get README.Abstract_Update (This File) ftp> get xads_abs ftp> quit [Note: If you are not running a name resolver at your site you will need to use "134.4.10.102 10011" in place of "adsftp.ipac.caltech.edu 10011". However, this address is subject to change without prior notice and you are strongly advised to use or install a name resolver.] 4. Start the ADS and try to submit a query to the Abstract service. You may use the Abstract examples in the first ADS science scenario to help you get started. If you no longer have this scenario, you may pick it up via anonymous ftp using the following steps. % ftp cuads.colorado.edu Connected to cuads.colorado.edu. 220 cuads FTP server (ULTRIX Version 4.1 Tue Mar 19 00:38:17 EST 1991) ready. Name (cuads.colorado.edu:[LOGNAME]): anonymous 331 Guest login ok, send ident as password. Password: [LOGNAME] 230 Guest login ok, access restrictions apply. ftp> cd pub/ads ftp> get ADS_scenario1 ftp> quit If you have any problems or questions, you may contact ADS User Support at: ads at cuads.colorado.edu or (303) 492-0466 From fitsbits-request Thu Aug 19 12:26:47 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["12325" "" "19" "August" "1993" "15:49:23" "GMT" " Frank ROUSSEL " "rousself at univ-rennes1.fr " nil "226" "FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA08109; Thu, 19 Aug 93 12:26:47 EDT Return-Path: Message-Id: <2507e4$etv at news.univ-rennes1.fr> Organization: CRI Universite' de Rennes 1 - FR Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!uwm.edu!rpi!batcomputer!ghost.dsi.unimi.it!univ-lyon1.fr!vishnu.jussieu.fr!zaphod.crihan.fr!news.univ-rennes1.fr!univ-rennes1.fr!rousself From: rousself at univ-rennes1.fr ( Frank ROUSSEL ) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS -> GIF or JPEG or TIFF converter Date: 19 Aug 1993 15:49:23 GMT Does such a converter exist for Unix ? Thanks --------------------------------------------------------------------------------- _______ _______ ________ | Firstname: Frank /______/| /______/\ /_______/| | Lastname : ROUSSEL / ______|/ / ____ \/| |__ __|/ | E-mail: rousself at univ-rennes1.fr / /| | |____| |/ | || | Telephone: + 33 99 83 26 10 | || | __ __/ | || | | |\______ | || \ \\ __| ||__ | Address: 175, rue Belle Epine \ \______/| | || \ \\ /__| |/_/| | CityStateZip: 35510 \_______|/ |_|/ \_\| |_______|/ | Cityname: CESSON SEVIGNE Centre de Ressources Informatiques | Country: FRANCE --------------------------------------------------------------------------------- ---------- Science without conscience is only soul's ruin (Rabelais) ------------ --------------------------------------------------------------------------------- - Signed: The responsible of ASTROGOF project at Rennes' University of France - - who contributes to the development of CRI-CICB Gopher's server by maintaining - - an astronomic anonymous ftp server 'ftp.univ-rennes1.fr' in /pub/Images/ASTRO - --------------------------------------------------------------------------------- From fitsbits-request Thu Aug 19 17:02:30 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["10366" "" "19" "August" "1993" "16:19" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "194" "FITS basics and information (periodic posting)" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09781; Thu, 19 Aug 93 17:02:30 EDT Return-Path: Message-Id: <19AUG199316193740 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS basics and information (periodic posting) Date: 19 Aug 1993 16:19 EDT This basic FITS information is posted and updated periodically for the benefit of new readers and the reference of old readers. FITS (Flexible Image Transport System) is a data format designed to provide a means for convenient exchange of astronomical data between installations whose standard internal formats and hardware differ. A FITS file is composed of a sequence of Header Data Units (HDUs). The header consists of keyword=value statements, which describe the format and organization of the data in the HDU and may also provide additional information, for example, about the instrument or the history of the data. The data follow, structured as the header specifies. The data section of the HDU may contain a digital image, but, except for the first, *it doesn't have to*. Other possible formats include tables and multidimensional matrices that are not images. The first HDU must contain a multidimensional matrix or no data at all; the data in subsequent HDUs, called extensions, may be of any type, consistent with certain rules. The "Image" in the name comes from the original use of the format to transport digital images, but it's not just for images any more. FITS is not principally a graphics format designed for the transfer of pictures; it does not incorporate "FITS viewers", packages for decoding the data into an image. Users must develop or obtain separate software to convert the data from the FITS file into a form that can be readily displayed. As has been discussed in this newsgroup, and in alt.sci.astro.fits before it, the Extended Portable Bitmap Toolkit (pbm+) can be used for converting many FITS files to such a format. However, support is not guaranteed for all FITS files where the data are in the form of an image. In particular, there may be problems when the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2). Archie Warnock and Ron Baalke have announced release of version 7.8 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov [128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp subdirectory. It is also available (at least for the time being) through Simtel-20 [192.88.110.20] Dominique Beauchamp, Universite Laval, Quebec City, has released a new 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, inform him at 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 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 this committee could in principle endorse a version that differs in some way from the NOST document, 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 at this writing. A proposed reorganization would move the FITS material to a FITS subdirectory under a STANDARDS directory. The FITS files include copies of the current NOST draft standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. Except that the ASCII form lacks typeface formatting, the copies in the three formats are identical; only one need be retrieved. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. There is an experimental PostScript copy of the current version of the User's Guide, generated by capturing the Macintosh MS Word original in PostScript format. While copies have been printed without problems on a variety of systems (a ghostwriter previewer could not deal with certain fonts), 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. 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 Thu Aug 19 18:01:18 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["21875" "" "19" "August" "93" "20:54:47" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "671" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10271; Thu, 19 Aug 93 18:01:18 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!cs.umd.edu!skates.gsfc.nasa.gov!Hypatia!warnock References: <9308181716.AA19559 at tetra.gsfc.nasa.gov> From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Identification of a FITS byte stream Date: 19 Aug 93 20:54:47 GMT pence at tetra.gsfc.nasa.gov (William Pence) writes: >Archie Warnock wrote: >I think it would be a good idea to 'strongly recommend' that all >FITS writers should add a standard comment citing a reference to a FITS >definition document. This cannot be made manditory however without >invalidating all the existing FITS files which don't have such a >comment, unless there is a grandfather clause that exempts all >existing FITS files. Agreed - "strongly recommend" is good. >What is the best reference to cite? The old A&A Suppl. papers, which >are somewhat out of date but are at least widely available in any >Astronomical library? Or the new NOST FITS definition document >which is much more complete, but may not be as easily accessable >50 years from now when someone is trying to decifer a dusty FITS tape? >Or both? Yeah - that's a problem isn't it. Forward referencing in the literature is hard. I think that the original A&A paper is probably enough of a lef-up on the problem for starters (since it tells you something about parsing the initial header), but I think more is probably better. The ultimate solution would be to get the NOST document into the refereed literature somehow. >Also, should it be recommended that this comment be located as near as >possible to the beginning of the FITS file, to make it easy to spot? >Presumable this comment would only be needed in the primary array, and >there would be little reason to repeat it in every extension. I don't think position is critical - we're doing this primarily for machine parsing, rather for a human reading a dump. And once is probably sufficient. Hmmm... -- _______________________________________________________________________ -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC Project STELAR: WAIS to do science From fitsbits-request Fri Aug 20 10:33:49 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1636" "Fri" "20" "August" "1993" "15:30:59" "GMT" "Pat Murphy" "pmurphy at cv3.CV.NRAO.EDU " nil "43" "Re: FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13165; Fri, 20 Aug 93 10:33:49 EDT Return-Path: Message-Id: Organization: National Radio Astronomy Observatory Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!pmurphy References: <2507e4$etv at news.univ-rennes1.fr> From: pmurphy at cv3.CV.NRAO.EDU (Pat Murphy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS -> GIF or JPEG or TIFF converter Date: Fri, 20 Aug 1993 15:30:59 GMT In article <2507e4$etv at news.univ-rennes1.fr>, rousself at univ-rennes1.fr ( Frank ROUSSEL ) writes: FR> Does such a converter exist for Unix ? Sort of. Here's an excerpt: orangutan_pmurphy<524> man fitstopgm fitstopgm(1) (20 September 89) fitstopgm(1) NAME fitstopgm - convert a FITS file into a portable graymap SYNOPSIS fitstopgm [-image N] [FITSfile] DESCRIPTION Reads a FITS file as input. Produces a portable graymap as output. The results may need to be flipped top for bottom; if so, just pipe the output through pnmflip -tb. OPTIONS The -image option is for FITS files with three axes. The assumption is that the third axis is for multiple images, and this option lets you select which one you want. You could do something like: fitstopgm | pnmflip | pgmtoppm | ppmtogif The pbmplus package is available at many fine archive sites, the nearest to you is probably cnam.cnam.fr (pub/Archives/comp.sources.misc/pbmplus/) according to xarchie. - Pat -- ========================================================================== | Patrick P. Murphy, Ph.D. Scientific Programming Analyst | | National Radio Astronomy Observatory Net: pmurphy at nrao.edu | | 520 Edgemont Road Phone: (804) 296-0372 | | Charlottesville, VA 22903-2475 VoiceMail: (804) 980-5889 | | "I don't believe in the no-win scenario" --- James T. Kirk | ========================================================================== From fitsbits-request Fri Aug 20 12:05:49 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1003" "Fri" "20" "August" "1993" "15:21:10" "GMT" "Greg Hennessy" "gsh7w at fermi.clas.Virginia.EDU " nil "23" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13372; Fri, 20 Aug 93 12:05:49 EDT Return-Path: Message-Id: Organization: University of Virginia Path: cv3.cv.nrao.edu!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gsh7w References: <9308181716.AA19559 at tetra.gsfc.nasa.gov> From: gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Identification of a FITS byte stream Date: Fri, 20 Aug 1993 15:21:10 GMT Archie Warnock writes: #I don't think position is critical - we're doing this primarily for #machine parsing, rather for a human reading a dump. And once is #probably sufficient. Hmmm... Err, I may have missed something, but I find it hard to imagine that a computer program is going to care about the reference of the FITS file. A grad student trying to figure out what is on the tape 10 years later when the spectrometer that took the data no longer exists, and the professor who took the data was not the observer, but the collaborator of the observer *IS* going to find that information useful. And yes, I actually had to do that task. Got it to work, although I had to figure out that the file was not *really* fits, since it was written in byte-swaped format to the tapes. VAXEN drive me crazy at times. -- -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w at virginia.edu UUCP: ...!uunet!virginia!gsh7w From fitsbits-request Fri Aug 20 18:12:25 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["13865" "Fri" "20" "August" "93" "21:01:34" "GMT" "Daniel Briggs" "dbriggs at Mr-Hyde.aoc.nrao.edu " nil "490" "Re: FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13574; Fri, 20 Aug 93 18:12:25 EDT Return-Path: Message-Id: <1993Aug20.210134.17910 at Mr-Hyde.aoc.nrao.edu> Organization: National Radio Astronomy Observatory, Socorro NM Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!Mr-Hyde.aoc.nrao.edu!dbriggs References: <2507e4$etv at news.univ-rennes1.fr> From: dbriggs at Mr-Hyde.aoc.nrao.edu (Daniel Briggs) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS -> GIF or JPEG or TIFF converter Date: Fri, 20 Aug 93 21:01:34 GMT In article pmurphy at nrao.edu (Pat Murphy) writes: >In article <2507e4$etv at news.univ-rennes1.fr>, rousself at univ-rennes1.fr ( > Frank ROUSSEL ) writes: > >FR> Does such a converter exist for Unix ? > >Sort of.... I hacked on the pbmplus program fitstopgm, and added a few more options. (Some generally useful, and one or several that are kind of obscure.) Most important to the folks on this group is that it can handle floating point FITS on machines whose native architecture support IEEE-754. I *think* I sent it off to Jef for incorporation into the next release, but I honestly can't remember. Certainly I never heard back from him. Anyway, here's what I did. Feel free to mess with it some more. If we want to have a decent FITS->generic image translator widely available, *we* are going to have to write it. It's no fair to ask Jef to do so, when he doesn't use FITS routinely. -----fitstopgm.1----- .TH fitstopgm 1 "21 June 93" .IX fitstopgm .SH NAME fitstopgm - convert a FITS file into a portable graymap .SH SYNOPSIS .B fitstopgm .RB [ -image .IR N ] .RB [ -noraw ] .RB [ -scanmax ] .RB [ -printmax ] .RB [ -min .IR f ] .RB [ -max .IR f ] .RI [ FITSfile ] .SH DESCRIPTION Reads a FITS file as input. .IX FITS Produces a portable graymap as output. The results may need to be flipped top for bottom; if so, just pipe the output through .B pnmflip -tb. .IX pnmflip This version of the program will accept integer FITS, and floating point FITS if the host machine architecture is IEEE 754 compliant. .SH OPTIONS .PP The .B -image option is for FITS files with three axes. The assumption is that the third axis is for multiple images, and this option lets you select which one you want. Additional axes will generate a warning message, but will otherwise be ignored. .PP If the pbm package has been compiled with the RAWBITS option, the output will be RAW PGM format. The .B -noraw option forces the output to ASCII. .PP The program assumes that the input file has been scaled to allow for maximum dynamic range, which is true for many FITS files. If not, the .B -scanmax option forces the program to prescan the file and determine the most appropriate scaling constants. The .B -printmax option causes the program to print the minimum and maximum values encountered and exit. A portion of the data range can be selected with the options .B -min .I f and .B -max .I f. Data beyond this range will be clipped appropriately. .PP All flags can be abbreviated to their shortest unique prefix. .SH REFERENCES FITS stands for Flexible Image Transport System. A full description of the basic image format can be found in Astronomy & Astrophysics Supplement Series 44 (1981), page 363. The full standard, including the "Floating Point Agreement for FITS" is available from the NASA/OSSA Office of Standards and Technology. The standards are also available for ftp on the host nssdca.gsfc.nasa.gov. .SH "SEE ALSO" pgmtofits(1), pgm(5), pnmflip(1) .SH AUTHOR Copyright (C) 1989 by Jef Poskanzer. .PP Additional code contributed by Daniel Briggs .\" Permission to use, copy, modify, and distribute this software and its .\" documentation for any purpose and without fee is hereby granted, provided .\" that the above copyright notice appear in all copies and that both that .\" copyright notice and this permission notice appear in supporting .\" documentation. This software is provided "as is" without express or .\" implied warranty. -----fitstopgm.c----- /* fitstopgm.c - read a FITS file and produce a portable graymap ** ** Copyright (C) 1989 by Jef Poskanzer. ** ** Permission to use, copy, modify, and distribute this software and its ** documentation for any purpose and without fee is hereby granted, provided ** that the above copyright notice appear in all copies and that both that ** copyright notice and this permission notice appear in supporting ** documentation. This software is provided "as is" without express or ** implied warranty. ** ** Hacked up version by Daniel Briggs (dbriggs at nrao.edu) 20-Oct-92 ** ** Include floating point formats, more or less. Will only work on ** machines that understand IEEE-754. Added -scanmax -printmax ** -min -max and -noraw. Ignore axes past 3, instead of error (many packages ** use pseudo axes). Use a finite scale when max=min. NB: Min and max ** are the real world FITS values (scaled), so watch out when bzer & bscale ** are not 0 & 1. Datamin & datamax interpreted correctly in scaled case, ** and initialization changed to less likely values. If datamin & max are ** not present in the header, the a first pass is made to determine them ** from the array values. */ #include "pgm.h" /* Do what you have to, to get a sensible value here. This may not be so */ /* portable as the rest of the program. We want to use MAXFLOAT and */ /* MAXDOUBLE, so you could define them manually if you have to. */ #include struct FITS_Header { int simple; /* basic format or not */ int bitpix; /* number of bits per pixel */ int naxis; /* number of axes */ int naxis1; /* number of points on axis 1 */ int naxis2; /* number of points on axis 2 */ int naxis3; /* number of points on axis 3 */ double datamin; /* min # (Physical value!) */ double datamax; /* max # " " */ double bzer; /* Physical value = Array value*bscale + bzero */ double bscale; }; static void read_fits_header ARGS(( FILE* fp, struct FITS_Header* hP )); static void read_card ARGS(( FILE* fp, char* buf )); static void read_val ARGS(( FILE* fp, int bitpix, double* vp )); void main( argc, argv ) int argc; char* argv[]; { FILE* ifp; gray* grayrow; register gray* gP; int argn, imagenum, image, row; register int col; gray maxval; double val, fmaxval, frmin, frmax, dmax, dmin, scale, t; int rows, cols, images; struct FITS_Header h; char* fits_name; char* usage = "[-image N] [-noraw] [-scanmax] [-printmax] [-min f] [-max f] [FITSfile]"; int doscan = 0; int forceplain = 0; int forcemin = 0; int forcemax = 0; int printmax = 0; pgm_init( &argc, argv ); argn = 1; imagenum = 1; while ( argn < argc && argv[argn][0] == '-' && argv[argn][1] != '\0' ) { if ( pm_keymatch( argv[argn], "-image", 2 ) ) { ++argn; if ( argn == argc || sscanf( argv[argn], "%d", &imagenum ) != 1 ) pm_usage( usage ); } else if ( pm_keymatch( argv[argn], "-max", 3 ) ) { ++argn; forcemax = 1; if ( argn == argc || sscanf( argv[argn], "%lf", &frmax ) != 1 ) pm_usage( usage ); } else if ( pm_keymatch( argv[argn], "-min", 3 ) ) { ++argn; forcemin = 1; if ( argn == argc || sscanf( argv[argn], "%lf", &frmin ) != 1 ) pm_usage( usage ); } else if ( pm_keymatch( argv[argn], "-scanmax", 2 ) ) doscan = 1; else if ( pm_keymatch( argv[argn], "-noraw", 2 ) ) forceplain = 1; else if ( pm_keymatch( argv[argn], "-printmax", 2 ) ) printmax = 1; else pm_usage( usage ); ++argn; } if ( argn < argc ) { fits_name = argv[argn]; ifp = pm_openr( fits_name ); ++argn; } else ifp = stdin; if ( argn != argc ) pm_usage( usage ); read_fits_header( ifp, &h ); if (forcemin) h.datamin = frmin; if (forcemax) h.datamax = frmax; if ( ! h.simple ) pm_error( "FITS file is not in simple format, can't read" ); switch ( h.bitpix ) { case 8: fmaxval = 255.0; break; case 16: fmaxval = 65535.0; break; case 32: fmaxval = 4294967295.0; break; case -32: fmaxval = MAXFLOAT; break; case -64: fmaxval = MAXDOUBLE; break; default: pm_error( "unusual bits per pixel (%d), can't read", h.bitpix ); } if ( h.naxis != 2 && h.naxis != 3 ) pm_message( "Warning: FITS file has %d axes", h.naxis ); cols = h.naxis1; rows = h.naxis2; if ( h.naxis == 2 ) images = 1; else images = h.naxis3; if ( imagenum > images ) pm_error( "only %d image%s in this file", images, images > 1 ? "s" : "" ); maxval = min( fmaxval, PGM_MAXMAXVAL ); if ( doscan || h.datamin == MAXDOUBLE || h.datamax == MAXDOUBLE ) { /* OK, We have to scale this the hard way. */ pm_message( "Scanning file for scaling parameters" ); dmax = -fmaxval; dmin = fmaxval; for ( image = 1; image <= imagenum; ++image ) { for ( row = 0; row < rows; ++row) { for ( col = 0; col < cols; ++col) { read_val (ifp, h.bitpix, &val); if ( image == imagenum ) { if ( val > dmax ) dmax = val; if ( val < dmin ) dmin = val; } } } pm_close( ifp ); if (h.bscale < 0.0) { t = dmax; dmax = dmin; dmin = t; } ifp = pm_openr( fits_name ); read_fits_header( ifp, &h ); h.datamin = forcemin ? frmin : dmin * h.bscale + h.bzer; h.datamax = forcemax ? frmax : dmax * h.bscale + h.bzer; } } /* If printmax option is true, just print and exit. */ /* For use in shellscripts. Ex: */ /* eval `fitstopgm -printmax $filename | \ */ /* awk '{min = $1; max = $2}\ */ /* END {print "min=" min; " max=" max}'` */ if (printmax) { printf( "%lf %lf\n", h.datamin, h.datamax); pm_close( ifp ); pm_close( stdout ); exit( 0 ); } /* Just in case we have a file with constant value. */ if (h.datamax != h.datamin) scale = maxval / (h.datamax - h.datamin); else scale = 1.e10; grayrow = pgm_allocrow( cols ); pgm_writepgminit( stdout, cols, rows, maxval, forceplain); for ( image = 1; image <= imagenum; ++image ) { if ( image != imagenum ) pm_message( "skipping image %d of %d", image, images ); else if ( images > 1 ) pm_message( "reading image %d of %d", image, images ); for ( row = 0; row < rows; ++row) { for ( col = 0, gP = grayrow; col < cols; ++col, ++gP ) { read_val (ifp, h.bitpix, &val); t = scale * ( val * h.bscale + h.bzer - h.datamin ); if (t < 0) *gP = (gray) 0; else if (t > maxval) *gP = (gray) maxval; else *gP = (gray) t; } if ( image == imagenum ) pgm_writepgmrow( stdout, grayrow, cols, maxval, forceplain ); } } pm_close( ifp ); pm_close( stdout ); exit( 0 ); } /* ** This code will deal properly with integers, no matter what the byte order ** or integer size of the host machine. Sign extension is handled manually ** to prevent problems with signed/unsigned characters. Floating point ** values will only be read properly when the host architecture is IEEE-754 ** conformant. If you need to tweak this code for other machines, you might ** want to snag a copy of the FITS documentation from nssdca.gsfc.nasa.gov */ static void read_val (fp, bitpix, vp) FILE *fp; int bitpix; double *vp; { int i, ich, ival; long int lval; unsigned char c[8]; switch ( bitpix ) { /* 8 bit FITS integers are unsigned */ case 8: ich = getc( fp ); if ( ich == EOF ) pm_error( "EOF / read error" ); *vp = ich; break; case 16: ich = getc( fp ); if ( ich == EOF ) pm_error( "EOF / read error" ); c[0] = ich; ich = getc( fp ); if ( ich == EOF ) pm_error( "EOF / read error" ); c[1] = ich; if (c[0] & 0x80) ival = ~0xFFFF | c[0]<<8 | c[1]; else ival = c[0]<<8 | c[1]; *vp = ival; break; case 32: for (i=0; i<4; i++) { ich = getc( fp ); if ( ich == EOF ) pm_error( "EOF / read error" ); c[i] = ich; } if (c[0] & 0x80) lval = ~0xFFFFFFFF | c[0]<<24 | c[1]<<16 | c[2]<<8 | c[3]; else lval = c[0]<<24 | c[1]<<16 | c[2]<<8 | c[3]; *vp = lval; case -32: for (i=0; i<4; i++) { ich = getc( fp ); if ( ich == EOF ) pm_error( "EOF / read error" ); c[i] = ich; } *vp = *( (float *) c); break; case -64: for (i=0; i<8; i++) { ich = getc( fp ); if ( ich == EOF ) pm_error( "EOF / read error" ); c[i] = ich; } *vp = *( (double *) c); break; default: pm_error( "Strange bitpix in read_value" ); } } static void read_fits_header( fp, hP ) FILE* fp; struct FITS_Header* hP; { char buf[80]; int seen_end; int i; char c; seen_end = 0; hP->simple = 0; hP->bzer = 0.0; hP->bscale = 1.0; hP->datamin = MAXDOUBLE; hP->datamax = MAXDOUBLE; while ( ! seen_end ) for ( i = 0; i < 36; ++i ) { read_card( fp, buf ); if ( sscanf( buf, "SIMPLE = %c", &c ) == 1 ) { if ( c == 'T' || c == 't' ) hP->simple = 1; } else if ( sscanf( buf, "BITPIX = %d", &(hP->bitpix) ) == 1 ); else if ( sscanf( buf, "NAXIS = %d", &(hP->naxis) ) == 1 ); else if ( sscanf( buf, "NAXIS1 = %d", &(hP->naxis1) ) == 1 ); else if ( sscanf( buf, "NAXIS2 = %d", &(hP->naxis2) ) == 1 ); else if ( sscanf( buf, "NAXIS3 = %d", &(hP->naxis3) ) == 1 ); else if ( sscanf( buf, "DATAMIN = %lf", &(hP->datamin) ) == 1 ); else if ( sscanf( buf, "DATAMAX = %lf", &(hP->datamax) ) == 1 ); else if ( sscanf( buf, "BZERO = %lf", &(hP->bzer) ) == 1 ); else if ( sscanf( buf, "BSCALE = %lf", &(hP->bscale) ) == 1 ); else if ( strncmp( buf, "END ", 4 ) == 0 ) seen_end = 1; } } static void read_card( fp, buf ) FILE* fp; char* buf; { if ( fread( buf, 1, 80, fp ) == 0 ) pm_error( "error reading header" ); } -- | Daniel Briggs (dbriggs at nrao.edu) | USPA B-14993 | New Mexico Tech / National Radio Astronomy Observatory | DoD #387 | P.O. Box O / Socorro, NM 87801 (505) 835-7391 | Support the League for Programming Freedom (info from lpf at uunet.uu.net) From fitsbits-request Sat Aug 21 11:54:45 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["890" "Sat" "21" "August" "1993" "15:34:14" "GMT" "David Robinson" "drtr at mail.ast.cam.ac.uk " nil "19" "Re: FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14868; Sat, 21 Aug 93 11:54:45 EDT Return-Path: Message-Id: <1993Aug21.153414.512 at infodev.cam.ac.uk> Organization: Institute of Astronomy, Cambridge Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!uknet!pavo.csi.cam.ac.uk!cast0.ast.cam.ac.uk!drtr References: <2507e4$etv at news.univ-rennes1.fr> From: drtr at mail.ast.cam.ac.uk (David Robinson) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS -> GIF or JPEG or TIFF converter Date: Sat, 21 Aug 1993 15:34:14 GMT 12345678901234567890123456789012345678901234567890123456789012345678901234567890 In article <2507e4$etv at news.univ-rennes1.fr>, rousself at univ-rennes1.fr ( Frank ROUSSEL ) writes: |> Does such a converter exist for Unix ? |> Thanks The xv package (current version 3.00a, archie search for xv-3.00a.tar.Z) supports many formats, including GIF, PBM, JPEG, TIFF and PostScript. The current version does not support FITS by default. However, I have patched it to support reading and writing of FITS files. The patches supports all BITPIX values, and do *not* assume that the host has IEEE floating point. It supports three dimensional (NAXIS=3) FITS files by treating then as containing NAXIS3 sets of two-dimensional images. The patches can be anonymously ftp'd from ftp-hst.ast.cam.ac.uk by fetching the file pub/software/xv-patches/FITS-v2.tar.Z. David Robinson. (drtr at mail.ast.cam.ac.uk) From fitsbits-request Sat Aug 21 16:54:06 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["10952" "" "21" "August" "93" "20:29:54" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "233" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14922; Sat, 21 Aug 93 16:54:06 EDT Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!wupost!sdd.hp.com!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!Hypatia!warnock References: <9308181716.AA19559 at tetra.gsfc.nasa.gov> From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Identification of a FITS byte stream Date: 21 Aug 93 20:29:54 GMT gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) writes: >Archie Warnock writes: >#I don't think position is critical - we're doing this primarily for >#machine parsing, rather for a human reading a dump. And once is >#probably sufficient. Hmmm... >Err, I may have missed something, but I find it hard to imagine that a >computer program is going to care about the reference of the FITS >file. A grad student trying to figure out what is on the tape 10 years Urp... That's what I meant. No really. Would you believe it's an obscure form of dyslexia? No? How about temporary insanity? Maybe it's not so temporary... Anyway, what I _meant_ is that we're _NOT_ talking about machine parsing. Sigh... I need another vacation to recover from my vacation... >had to figure out that the file was not *really* fits, since it was >written in byte-swaped format to the tapes. VAXEN drive me crazy at >times. You just wouldn't believe the bizarre stuff we got submitted to International Halley Watch with the claim that it was FITS. It's not nearly as universally used as we'd like to believe. I got a standard VMS ASCII file (yep - variable length records, the whole works) from one submitter claiming it was FITS - well, he could type it out and it _looked_ like the samples in the papers... -- _______________________________________________________________________ -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC Project STELAR: WAIS to do science From fitsbits-request Mon Aug 23 12:13:59 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3967" "Mon" "23" "August" "93" "12:12:58" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "84" "FITSIO V3.401 is available" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA17569; Mon, 23 Aug 93 12:13:59 EDT Return-Path: Message-Id: <9308231612.AA00464 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, wgas at hypatia.gsfc.nasa.gov Subject: FITSIO V3.401 is available Date: Mon, 23 Aug 93 12:12:58 EDT FITSIO - Version 3.401 23 August 1993 A new release of the FITSIO subroutine library, version 3.401, is now available. This new version contains a number of significant new features as described below. This new version is upwardly compatible with the previous versions, therefore all existing programs which use FITSIO should still work without any modification. For those unfamiliar with FITSIO, it is a full-featured yet simple to use Fortran subroutine interface for reading and writing files in FITS format. It runs on most common types of computers and supports FITS ASCII tables, binary tables, and image extensions as well as simple primary array FITS files. The FITSIO software, documentation, and example programs can be obtained via anonymous ftp from (note the new address compared to previous releases): legacy.gsfc.nasa.gov (128.183.8.233) Type the following commands from the ftp prompt to copy any desired files: ftp> user anonymous Password: [type your username as a password] ftp> cd software/fitsio [to move to the fitsio subdirectory] ftp> ls [to see a list of the available files] ftp> get README [contains latest information about FITSIO] ftp> get fitsio.doc [complete user documentation] ftp> get fitsio.tex [Latex version of the documentation] ftp> get ... [get any additional desired files] [ Be sure to switch to binary mode in ftp ] [ when getting the .tar files or the ] [ FITS format files. ] ftp> quit A brief summary of the the more important changes introduced with this release are described below. For more details on the changes made to this version, see the 'release.doc' file in the FITSIO distribution directory. NEW PORTS: - fitsio is now supported on IBM AIX operating systems and DEC Alpha OSF/1 and Alpha OpenVMS machines. NEW SUBROUTINES: - to modify the name of an existing keyword in a FITS header - to return the number of the current header-data-unit which is open - to read or write keyword values in 'triple precision' F28.16 format - to insert a new keyword at a specified location in a FITS header - to read a subset of a multidimensional primary array or subset of an N-dimensional vector array column in a binary table. ENHANCEMENTS: - the subroutines to write COMMENT or HISTORY keywords were enhanced to automatically write multiple keywords if the input string is longer than 70 characters. - Implemented a local convention for reading and writing character string keywords which are too long to fit in a single keyword record. The long keyword values are continued over multiple comment keywords. - enhanced the TEST1.FOR and TEST2.FOR programs to perform a more extensive test of the FITSIO interface functionality. - several efficiency improvements have been implemented - added error checking to detect attempts to move to an illegal HDU number, (either negative, or greater than the internal buffer size). - expanded the documentation in fitsio.doc, including a new section on suggestions for optimizing the I/O performance of FITSIO programs. - 12 reported bugs were fixed. These problems were relatively obscure and should not have affected many users. -------------------------------------------------------------------------- Dr. William Pence HEASARC (High Energy Astrophysics Science Archive Research Center) Code 668 NASA/Goddard Space Flight Center Internet: pence at tetra.gsfc.nasa.gov Greenbelt, MD 20771 SPAN: LHEAVX::PENCE Telephone: (301)286-4599 From fitsbits-request Mon Aug 23 17:51:06 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1505" "" "23" "August" "1993" "16:58:32" "GMT" " Frank ROUSSEL " "rousself at univ-rennes1.fr " nil "24" "FITS -> ... converter (2)" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA17705; Mon, 23 Aug 93 17:51:06 EDT Return-Path: Message-Id: <25asvp$mg2 at news.univ-rennes1.fr> Organization: CRI Universite' de Rennes 1 - FR Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!zaphod.crihan.fr!news.univ-rennes1.fr!univ-rennes1.fr!rousself From: rousself at univ-rennes1.fr ( Frank ROUSSEL ) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS -> ... converter (2) Date: 23 Aug 1993 16:58:32 GMT Thank you for all your responses ! At 'julian.uwo.ca:/pub/unix/X-windows/X.V11R5/contrib/clients/pbmplus', i've retrieved a X11R5 compiled version of fitstopgm, but i've not found one of pgmtoppm. Does anyone know where i can get one, please ? Thanks in advance --------------------------------------------------------------------------------- _______ _______ ________ | Firstname: Frank /______/| /______/\ /_______/| | Lastname : ROUSSEL / ______|/ / ____ \/| |__ __|/ | E-mail: rousself at univ-rennes1.fr / /| | |____| |/ | || | Telephone: + 33 99 83 26 10 | || | __ __/ | || | | |\______ | || \ \\ __| ||__ | Address: 175, rue Belle Epine \ \______/| | || \ \\ /__| |/_/| | CityStateZip: 35510 \_______|/ |_|/ \_\| |_______|/ | Cityname: CESSON SEVIGNE Centre de Ressources Informatiques | Country: FRANCE --------------------------------------------------------------------------------- ---------- Science without conscience is only soul's ruin (Rabelais) ------------ --------------------------------------------------------------------------------- - Signed: The responsible of ASTROGOF project at Rennes' University of France - - who contributes to the development of CRI-CICB Gopher's server by maintaining - -an astronomical anonymous ftp server 'ftp.univ-rennes1.fr' in /pub/Images/ASTRO- --------------------------------------------------------------------------------- From fitsbits-request Mon Aug 23 21:45:48 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1556" "Tue" "24" "August" "1993" "02:42:56" "GMT" "Pat Murphy" "pmurphy at cv3.CV.NRAO.EDU " nil "34" "Re: FITS -> ... converter (2)" "^From:" nil nil "8"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18039; Mon, 23 Aug 93 21:45:48 EDT Return-Path: Message-Id: Organization: National Radio Astronomy Observatory Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!pmurphy References: <25asvp$mg2 at news.univ-rennes1.fr> From: pmurphy at cv3.CV.NRAO.EDU (Pat Murphy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS -> ... converter (2) Date: Tue, 24 Aug 1993 02:42:56 GMT In article <25asvp$mg2 at news.univ-rennes1.fr>, rousself at univ-rennes1.fr ( Frank ROUSSEL ) writes: FR> At 'julian.uwo.ca:/pub/unix/X-windows/X.V11R5/contrib/clients/pbmplus', FR> i've retrieved a X11R5 compiled version of fitstopgm, but i've not found FR> one of pgmtoppm. Does anyone know where i can get one, please ? Hmm, I didn't know th