From fitsbits-request Sun Oct 3 17:24:32 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02489; Sun, 3 Oct 93 17:24:32 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Sun, 3 Oct 1993 19:40:49 GMT From: guest at uqam.ca Message-Id: Organization: Universite du Quebec a Montreal. Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!howland.reston.ans.net!agate!library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca!nntp.cs.ubc.ca!utcsri!newsflash.concordia.ca!cumin.telecom.uqam.ca!uqam.ca!guest Subject: test Sender: fitsbits-request at fits.CV.NRAO.EDU From fitsbits-request Fri Oct 8 11:34:57 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12321; Fri, 8 Oct 93 11:34:57 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 7 Oct 1993 10:03 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <7OCT199310031914 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!math.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Subject: AUTHOR keyword Sender: fitsbits-request at fits.CV.NRAO.EDU The AUTHOR keyword was introduced in the ASCII Table extension paper (Harten, et. al, Astron. Astrophys., 73, 365.). The description in that paper is "Name(s) of original author of catalog." It is paired with the REFERENC keyword, which provides the bibliographic reference for a published catalog. The implication is that they should go together: that the AUTHOR keyword is designed to identify an individual or group that published the data in a place given by the value of REFERENCE, data now being reproduced in electronic form in the FITS file. Thus, AUTHOR refers to the creator of the original data set, not its electronic form. Application to the author of a computer program that organized data into FITS format or to the program itself would not be consistent with the original meaning. Barry Schlesinger NOST FITS Support Office From fitsbits-request Mon Oct 11 15:19:03 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA19966; Mon, 11 Oct 93 15:19:03 EDT Return-Path: < at uga.cc.uga.edu:MMAGALLO at UCRVM2.BITNET> Message-Id: <9310111919.AA13984 at cv3.cv.nrao.edu> Date: Mon, 11 Oct 93 13:11:51 UCR From: "Marcelo Magallon Gh." Subject: FITS <->TIFF To: fitsbits at NRAO.EDU Sender: fitsbits-request at fits.CV.NRAO.EDU Does anyone know of a TIFF to FITS converter? ANY other format to FITS? I'm working on a fits-based database project, and one of the things I have to do is taking a TIFF graphic and converting it to a fits image. Another question: Do you know of some program capable of displaying a FITS image that works on a VAX under VMS. (We aren't using VWS, so it must be done using DECWindows) Thanks. From fitsbits-request Tue Oct 12 07:07:12 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA21050; Tue, 12 Oct 93 07:07:12 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Mon, 11 Oct 1993 13:39:31 GMT From: saken at stsci.edu (Jon Saken) Message-Id: <1993Oct11.133931.29171 at stsci.edu> Organization: Space Telescope Science Institute Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!darwin.sura.net!math.ohio-state.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!noao!stsci!saken Subject: World Coordinate Systems Sender: fitsbits-request at fits.CV.NRAO.EDU Is there an ftp site where I can get some documentation on the World Coordinate Systems? Thanks. jon saken saken at stsci.edu From fitsbits-request Thu Oct 14 09:47:02 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA25946; Thu, 14 Oct 93 09:47:02 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 11 Oct 1993 20:58:00 GMT From: pmurphy at cv3.CV.NRAO.EDU (Pat Murphy) Message-Id: Organization: National Radio Astronomy Observatory Path: cv3.cv.nrao.edu!uvaarpa!caen!hellgate.utah.edu!cc.usu.edu!cc.usu.edu!pmurphy References: <1993Oct6.124129.5844 at msus1.msus.edu> Subject: Re: Explanation req'd... Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1993Oct6.124129.5844 at msus1.msus.edu>, vipond at mhd.moorhead.msus.edu asked: V> Just what is this group for, exactly? Here is the original charter, available with a lot of other info, on fits.cv.nrao.edu in fits/traffic/sciastrofits/charter_sci_astro_fits.news. >From dwells at fits.CX.NRAO.EDU Fri Feb 14 11:54:35 1992 From: dwells at fits.CX.NRAO.EDU (Don Wells) Subject: CFV: sci.astro.fits Date: Tue, 11 Feb 1992 14:16:13 GMT Name: sci.astro.fits Status: Unmoderated Charter: This newsgroup will provide a forum for the discussion of all topics concerning the FITS [Flexible Image Transport System] data format. The newsgroup will be interfaced to the Email exploder fitsbits at fits.cx.nrao.edu so that traffic originating on either the newsgroup on the exploder will be automatically transmitted to the other. This new newsgroup will replace existing newsgroup alt.sci.astro.fits. Reference Entry: sci.astro.fits Issues related to the Flexible Image Transport System. - 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 Oct 15 16:17:23 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA28155; Fri, 15 Oct 93 16:17:23 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 14 Oct 1993 09:51 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <14OCT199309510562 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <1993Oct11.133931.29171 at stsci.edu> Subject: Re: World Coordinate Systems Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1993Oct11.133931.29171 at stsci.edu>, saken at stsci.edu (Jon Saken) writes... > > Is there an ftp site where I can get some documentation on the >World Coordinate Systems? Thanks. > At fits.cv.nrao.edu, directory fits/documents/wcs. Files wcs.* contain a draft proposal by E. Greisen and M. Calabretta for conventions for world coordinates, along with an exhaustive discussion of different coordinate systems. A variety of other documents are also available. The included README file by Eric Greisen provides a full explanation. Barry Schlesinger NSSDC/NOST FITS Support Office. From fitsbits-request Fri Oct 15 17:52:16 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA28220; Fri, 15 Oct 93 17:52:16 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 14 Oct 1993 18:53:19 GMT From: brewer at geop.ubc.ca (James Brewer) Message-Id: <29k76v$6cq at nntp.ucs.ubc.ca> Organization: Geophysics & Astronomy, U.B.C. Vancouver, Canada Path: cv3.cv.nrao.edu!uvaarpa!caen!math.ohio-state.edu!cs.utexas.edu!uunet!destroyer!nntp.cs.ubc.ca!unixg.ubc.ca!crisium!brewer Reply-To: brewer at geop.ubc.ca Subject: wtextimage Sender: fitsbits-request at fits.CV.NRAO.EDU I have some spectra I have extracted and wavelength calibrated using IRAF. I wish to write out a text file containing flux vs. wavelegth. When I use wtextimage, i.e. PACKAGE = dataio TASK = wtextimage input = cstar2.0001 Input image file output = test8 Output text file (header = no) Print header information? (format = 10.3f) Pixel format (maxline= 10) Maximum line length output (mode = ql) I get a text file with flux only. Any one out there know how I get what I want? Thanks for any advice! From fitsbits-request Wed Oct 20 00:17:19 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09537; Wed, 20 Oct 93 00:17:19 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 19 Oct 1993 19:12:11 GMT From: C19112 at VM1.CC.UAKRON.EDU Message-Id: <16C6CD5D0S85.C19112 at VM1.CC.UAKRON.EDU> Organization: The University of Akron Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!pipex!uunet!yeshua.marcam.com!usc!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!news.uakron.edu!VM1.CC.UAKRON.EDU!C19112 References: Subject: INFO NEEDED: Asteroid belt between Mars and Jupiter Sender: fitsbits-request at fits.CV.NRAO.EDU There is an asteriod belt between Mars and Jupiter. Does anyone know the name, scientific term, or any information on it? It's for a project. if you have any info, just e-mail me : ======================================================================== | But what the hell. This is the human race we're talking | | about. I'm an optimist as the next guy but my conclusion is: as | | long as there are humans, there will always be hate and a race who | | proclaims themselves the Homo Superior. As long as humans exist, | | the reality of a dystopia will always co-exist. But the idea of a | | Utopia will always exist too and that idea itself is the only ideal | | that is redeemable in being human. --QhasXeem | |///////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\| | QhasXeem Joce Vwj /\ "Questioning is the beginning of know- | | CS Major/Junior /\ lege." Worf - Star Trek NG | | University of Akron /\ "Humans are afraid of change" Plato - the| | C19112 at VM1.CC.UAkron.EDU /\ allegory of the cave (The Republic) | ======================================================================== From fitsbits-request Thu Oct 21 01:46:26 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12597; Thu, 21 Oct 93 01:46:26 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 20 Oct 1993 17:37 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <20OCT199317370798 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!math.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Subject: FITS basics and information (periodic posting) Sender: fitsbits-request at fits.CV.NRAO.EDU This basic FITS information is posted and updated periodically for the benefit of new readers and the reference of old readers. FITS (Flexible Image Transport System) is a data format designed to provide a means for convenient exchange of astronomical data between installations whose standard internal formats and hardware differ. A FITS file is composed of a sequence of Header Data Units (HDUs). The header consists of keyword=value statements, which describe the format and organization of the data in the HDU and may also provide additional information, for example, about the instrument or the history of the data. The data follow, structured as the header specifies. The data section of the HDU may contain a digital image, but, except for the first, *it doesn't have to*. Other possible formats include tables and multidimensional matrices that are not images. The first HDU must contain a multidimensional matrix or no data at all; the data in subsequent HDUs, called extensions, may be of any type, consistent with certain rules. The "Image" in the name comes from the original use of the format to transport digital images, but it's not just for images any more. FITS is not principally a graphics format designed for the transfer of pictures; it does not incorporate "FITS viewers", packages for decoding the data into an image. Users must develop or obtain separate software to convert the data from the FITS file into a form that can be readily displayed. As has been discussed in sci.astro.fits, and in alt.sci.astro.fits before it, the Extended Portable Bitmap Toolkit (pbm+) can be used for converting many FITS files to such a format. However, support is not guaranteed for all FITS files where the data are in the form of an image. In particular, there may be problems when the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2). Archie Warnock and Ron Baalke have announced release of version 7.8 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov [128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp subdirectory. It is also available (at least for the time being) through Simtel-20 [192.88.110.20] Dominique Beauchamp, Universite Laval, Quebec City, has released version 0.3, rel. 2 of ViewFITS, a FITS reader for OS/2 2.1 presentation manager. It is on ftp.cdrom.com in /pub/os2/incoming, file name vf03r2.zip. This program gives the user the opportunity to display FITS images (8,16 or 32 bits, integer or float), modifying the gray shade palette, doing negation and zooming out. The program now uses bitmap instead of direct drawing to the screen, with 100x faster execution time. It is still a beta version. If you try it, report the results to beaucham at phy.ulaval.ca. Additional discussion of FITS->image converters may appear in sci.astro.fits from time to time. The fundamental references on FITS are the following four papers, often referred to collectively as the "Four FITS Papers". These papers are the formal standard for FITS, endorsed by the International Astronomical Union (IAU). Wells, D. C., Greisen, E. W., and Harten, R. H., "FITS: a flexible image transport system," Astronomy and Astrophysics Supplement Series, 44, 363-370, 1981. Greisen, E. W. and Harten, R. H., "An extension of FITS for small arrays of data," Astronomy and Astrophysics Supplement Series, 44, 371-374, 1981. (NOTE: The format described in this paper has been used almost exclusively to transport radio interferometry and is likely to be replaced by other formats in the future. Writing data other than radio interferometry data using this format is not recommended.) Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., "Generalized extensions and blocking factors for FITS," Astronomy and Astrophysics Supplement Series, 73, 359-364, 1988. Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., "The FITS tables extension, Astronomy and Astrophysics Supplement Series, 73, 365-372, 1988. A User's Guide for FITS, commissioned by NASA Headquarters, is maintained by the NASA/Science Office of Standards and Technology (NOST) FITS Support Office. This Guide is intended to be a tutorial for new FITS users. In addition to presenting the rules of FITS, it provides some of the history and reasoning behind the choice of the rules, adds recommendations on good practices, and discusses current developments in FITS. The current version, 3.0, was issued in January 1993. The NOST has codified FITS as endorsed by the IAU into a formal standard, eliminating some contradictions and ambiguities in the original FITS papers. This Definition of FITS was developed by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review by the astronomical community. On June 18, 1993, it was approved as a NOST Standard by an Accreditation Panel consisting of the NOST Executive Board and an astronomical community representative; this review was to confirm that the community had been given a satisfactory opportunity to review the standard and that the Technical Panel had properly considered and responded to all comments. The NOST standard has been submitted to the IAU FITS Working Group (IAUFWG) for endorsement as the international FITS standard, to replace the four FITS papers and the Floating Point Agreement, which are the current endorsed standard. While oversights in non-controversial areas may be rectified as a result of the review by the IAUFWG, significant changes are unlikely, because members of this committee were active in the process of reviewing the standard and their comments were given significant weight in the deliberations of the Technical Panel. The IAU has endorsed the Floating Point Agreement, which defines how floating point numbers are to be expressed in FITS. The basic agreement appears verbatim in the User's Guide, and the substance is incorporated in the NOST standard. The NOST maintains a file of FITS information available by anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in the directory FITS. A proposed reorganization could move the FITS material to a FITS subdirectory under a STANDARDS directory. The FITS files include copies of the current NOST standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. The only difference among the three formats is that the ASCII form lacks typeface formatting; only one need be retrieved. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. There is a PostScript copy of the current version of the User's Guide, generated by capturing the Macintosh MS Word original in PostScript format. Nearly 100 copies have been retrieved, with only one printing problem and one preview problem reported; however, because of the well-known problems in converting Macintosh Word to PostScript, universal portability cannot be guaranteed. Please notify the FITS Support Office by electronic mail of any problems. The directory also contains a modified version of this posting. An AAREADME.DOC file describes the contents of the directory. A SOFTWARE subdirectory contains a prototype for software in C that will eventually validate FITS files, along with instructions. Because this software is still under development, it should not be run before reading the separate instructions file. The current version investigates required keywords for primary headers and prints sample data for integer data arrays. There is also C software to read and list the headers of a FITS file. Another file provides information on publicly available FITS software packages. The ERRTEST subdirectory contains several versions of the same FITS file, a valid one and several with different kinds of header errors, for use in testing software to read FITS files. Be sure to use binary transfer for ftp access of FITS test files. Both the SOFTWARE and ERRTEST subdirectories include AAREADME.DOC files describing their content. A modified version of this posting is now in the main directory. A Fortran subroutine package called FITSIO is available via anonymous ftp from legacy.gsfc.nasa.gov in the /software/fitsio/ directory. This package, for reading and writing FITS format files easily, runs on most types of machines and supports all the currently defined FITS extensions. Additional material can be obtained by anonymous ftp from the National Radio Astronomy Observatory, from fits.cv.nrao.edu, in the directory fits (case is significant). The documents subdirectory contains a number of subdirectories. A proposals subdirectory contain proposals, such as the BINTABLE Binary Tables extension proposal, which is now under consideration by the IAU FITS Working Group. A drafts subdirectory contains drafts of designs not yet submitted, for example, a proposed method for incorporating data compression under FITS. The wcs subdirectory contains material serving as the basis for continuing discussion of world coordinates issues, some of which appears on sci.astro.fits from time to time. An electronic mail listserver called HEAFITS has been set up as a specialized group for discussion of High Energy Astrophysics- specific FITS issues that would not necessarily be of interest to the majority of subscribers to the existing sci.astro.fits newsgroup and fitsbits mailing list. To *subscribe* to the HEAFITS group, send the following one-line e-mail message to listserv at legacy.gsfc.nasa.gov: subscribe heafits Your Name where 'Your Name' is your actual First and Last names. Messages to the actual mailing list are sent to heafits at legacy.gsfc.nasa.gov. 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 *The FITS office telephone number will be changing 25 October. Calls to the old number will get a recording with a pointer (though not necesarily a direct one) to the new number. The new number will be posted as soon as I know what it is. -BMS From fitsbits-request Fri Oct 22 07:56:19 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16669; Fri, 22 Oct 93 07:56:19 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Thu, 21 Oct 1993 16:29:36 GMT From: hodge at stsci.edu (Phil Hodge) Message-Id: <1993Oct21.162936.27596 at stsci.edu> Organization: Space Telescope Science Institute Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!pipex!uunet!organpipe.uug.arizona.edu!CS.Arizona.EDU!noao!stsci!hodge References: <29k76v$6cq at nntp.ucs.ubc.ca> Subject: Re: wtextimage Sender: fitsbits-request at fits.CV.NRAO.EDU James Brewer (brewer at geop.ubc.ca) asked how to get flux and wavelength information written from an image into a text file. The IRAF listpix task (in the images package) with wcs="world" will do this. Redirect the output to the file, since by default the output is written to the standard output. From fitsbits-request Fri Oct 22 10:30:10 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16831; Fri, 22 Oct 93 10:30:10 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Thu, 21 Oct 1993 17:48:28 GMT From: csillag at iem.ee.ethz.ch (Andre Csillaghy) Message-Id: Organization: ETH Zurich, Switzerland Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!mcsun!chsun!bernina!iem.ee.ethz.ch!csillag Reply-To: csillag at astro.phys.ethz.ch Subject: MIDAS to FITS Sender: fitsbits-request at fits.CV.NRAO.EDU I have a quantity of (not totally standard) MIDAS files (*.bdf) which I am convering in FITS. In the past, I read the BDF files on a VAX-VMS machine, where these BDF files were produced, and wrote them in FITS. The problem I have with this method is that the virtual memory size on VMS is in many cases too small for the conversion (so the program stops with an "error getting virtual memory etc...") I would like to make the conversion on Ultrix DEC Station. I wonder if somebody have experience in converting BDF to FITS on Ultrix and if there is any software available for that operation. Thanks in advance, Andre Csillaghy Radio Astronomy Group Institute of Astronomy ETH Zurich / Switzerland From fitsbits-request Fri Oct 22 10:44:21 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16847; Fri, 22 Oct 93 10:44:21 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Date: Fri, 22 Oct 1993 15:43:28 +0100 (MET) From: Lucio Chiappetti Subject: Re: MIDAS to FITS To: csillag at astro.phys.ethz.ch Cc: fitsbits at fits.CV.NRAO.EDU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fitsbits-request at fits.CV.NRAO.EDU On Thu, 21 Oct 1993, Andre Csillaghy wrote: > I have a quantity of (not totally standard) MIDAS files (*.bdf) which I am convering in FITS. ^^^^^^^^^^^^^^^^^^^^^ ??? what does this mean ??? > In the past, I read the BDF files on a VAX-VMS machine, > where these BDF files were produced, and wrote them in FITS. > The problem I have with this method is that the virtual memory size > on VMS is in many cases too small for the conversion (so the program > stops with an "error getting virtual memory etc...") > I would like to make the conversion on Ultrix DEC Station. > I wonder if somebody have experience in converting BDF to FITS on Ultrix > and if there is any software available for that operation. I read and write FITS and .bdf files on Ultrix using MIDAS, but the format of the .bdf files on say Ultrix, Sun and VMS will be different, so this won't help you. You can't move the VMS bdf files to Ultrix and use MIDAS on Ultrix. I suggest you either apply to the MIDAS Hot-line (midas at eso.org), or try to obtain from your VMS system manager an increase of some of your account's quotas From fitsbits-request Mon Oct 25 11:41:26 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24098; Mon, 25 Oct 93 11:41:26 EDT Return-Path: Date: Mon, 25 Oct 93 11:41:12 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9310251541.AA00628 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: AUTHOR --> CREATOR keyword Cc: pence at tetra.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU The following describes a new FITS keyword that we plan to use within the OGIP. As usual, any comments on this are welcome. -Bill Pence -------------------------------------------------------------------------------- Proposed CREATOR Keyword It is often useful to identify which software program created a particular FITS file. The reserved AUTHOR keyword has sometimes been used for this purpose, but this is not consistent with the original intent of the AUTHOR keyword to cite a publication. Instead, the following keyword should be used for this purpose: CREATOR = 'program name' / Program that created this FITS file When appropriate, the value of the CREATOR keyword should also reference the specific version of the program that created the FITS file (e.g., 'WRITEFITS V3.2'). It is intented that this keyword should refer to the program that originally defined the FITS file structure and wrote the contents. If a FITS file is subsequently copied largely intact into a new FITS by another program, then the value of the CREATOR keyword should still refer to the original program. HISTORY keywords should be used instead to document any further processing that is performed on the file after it is created. From fitsbits-request Mon Oct 25 12:25:12 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24152; Mon, 25 Oct 93 12:25:12 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Date: Mon, 25 Oct 1993 17:22:47 +0100 (MET) From: Lucio Chiappetti Subject: Re: AUTHOR --> CREATOR keyword To: fitsbits at fits.CV.NRAO.EDU In-Reply-To: <9310251541.AA00628 at tetra.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fitsbits-request at fits.CV.NRAO.EDU On Mon, 25 Oct 1993, William Pence wrote: > It is often useful to identify which software program created a > particular FITS file. The reserved AUTHOR keyword has sometimes been > used for this purpose, but this is not consistent with the original > intent of the AUTHOR keyword to cite a publication. Instead, the > following keyword should be used for this purpose: > > CREATOR = 'program name' / Program that created this FITS file > How does this fit in / conflict with / complement the usage of the ORIGIN keyword ? I have seen this used for the above purpose. MIDAS-written FITS files have ORIGIN='ESO-MIDAS', IRAF-written files have ORIGIN='KPNO-IRAF'. I thought that this was "THE" convention, my own programs set ORIGIN='XAS'. Any comment from FITS standard authorities ? (on the other hand the name CREATOR is fine, resembles the %%Creator comment in Postscript files) From fitsbits-request Mon Oct 25 12:58:40 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24245; Mon, 25 Oct 93 12:58:40 EDT Return-Path: Message-Id: <9310251658.AA24239 at fits.cv.nrao.edu> Date: Mon, 25 Oct 1993 17:57:29 +0100 From: forveill at gag.observ-gr.fr (Thierry Forveille) Posted-Date: Mon, 25 Oct 1993 17:57:29 +0100 To: pence at tetra.gsfc.nasa.gov (William Pence) Cc: fitsbits at fits.CV.NRAO.EDU, pence at tetra.gsfc.nasa.gov Subject: AUTHOR --> CREATOR keyword In-Reply-To: <9310251541.AA00628 at tetra.gsfc.nasa.gov> References: <9310251541.AA00628 at tetra.gsfc.nasa.gov> Sender: fitsbits-request at fits.CV.NRAO.EDU William Pence writes: > The following describes a new FITS keyword that we plan to use within the OGIP. > As usual, any comments on this are welcome. > > -Bill Pence > -------------------------------------------------------------------------------- > > Proposed CREATOR Keyword > > It is often useful to identify which software program created a > particular FITS file. The reserved AUTHOR keyword has sometimes been > used for this purpose, but this is not consistent with the original > intent of the AUTHOR keyword to cite a publication. Instead, the > following keyword should be used for this purpose: > > CREATOR = 'program name' / Program that created this FITS file > > When appropriate, the value of the CREATOR keyword should also > reference the specific version of the program that created the FITS > file (e.g., 'WRITEFITS V3.2'). It is intented that this keyword should > refer to the program that originally defined the FITS file structure > and wrote the contents. There is a well established usage of the ORIGIN keyword for this purpose, at least in the radio community. NRAO uses ORIGIN = 'UNIPOPS u2f/1.3 ' for its single dish data and ORIGIN = 'AIPS NRAO ' (quoted from memory) for its interferometers, we use ORIGIN = 'CLASS-Grenoble', and so on. I would rather stick to this convention unless other communities use ORIGIN for other purposes. > If a FITS file is subsequently copied largely > intact into a new FITS by another program, then the value of the > CREATOR keyword should still refer to the original program. HISTORY > keywords should be used instead to document any further processing that > is performed on the file after it is created. > I can see many good reasons to try to keep track of the original producer, but I am afraid you'll have a hard time getting computer programs to correctly decide that a FITS file has been left 'largely intact' (remember most people don't use FITS as their internal format). From fitsbits-request Mon Oct 25 13:42:33 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24323; Mon, 25 Oct 93 13:42:33 EDT Return-Path: Date: Mon, 25 Oct 93 13:42:24 EDT From: arots at xebec.gsfc.nasa.gov (Arnold Rots) Message-Id: <9310251742.AA04112 at xebec.gsfc.nasa.gov> To: fitsbits at NRAO.EDU Subject: Re: AUTHOR --> CREATOR keyword Sender: fitsbits-request at fits.CV.NRAO.EDU The NOST standard defines ORIGIN as "identifying the organization creating the FITS file". Notwithstanding what goes on in practice, I feel we should try to stick with these definitions. That means that either we have to introduce a keyword like CREATOR, or redefine ORIGIN to also include an identification of the software that created the FITS file. - Arnold Rots From fitsbits-request Tue Oct 26 06:22:35 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA26127; Tue, 26 Oct 93 06:22:35 EDT Return-Path: Message-Id: <9310261022.AA00346 at cv3.cv.nrao.edu> Via: uk.ac.leicester.starlink; Tue, 26 Oct 1993 09:57:59 +0000 Date: Tue, 26 Oct 93 9:57 GMT From: "Clive Page, Leicester University, UK" To: FITSBITS Subject: ORIGIN and CREATOR keywords Sender: fitsbits-request at fits.CV.NRAO.EDU The problem with the original FITS definition of ORIGIN as "the organization creating the FITS file" is that it's quite hard to write software to define it correctly. It is easy enough, and obviously sensible, to encode in a FITS file the program name and version number that produced it. It isn't too hard to pick up the user-name of the person running the program through the appropriate system call, but it is not as easy to obtain the name of his/her organization. Some programs that I write end up being used in a number of other organizations - if I were to hard-code the name of my organization then that would obviously be misleading much of the time. An alternative would be to force the user to enter a suitable string every time the program is run - but users are not going to understand why they have to do this. A third possibility is to require that the software be "installed" so that a suitable logical name or environment variable can be defined at install-time and picked up at run-time. None of these strikes me as very attractive. In practice, therefore, the ORIGIN keyword doesn't often get used for its original purpose. I don't see this as terribly serious: maybe we should abandon ORIGIN if it isn't easy to use or all that important. I think "CREATOR" sounds like a good name for the information that really does need to be included in each FITS file. - Clive Page From fitsbits-request Tue Oct 26 07:43:14 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27027; Tue, 26 Oct 93 07:43:14 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 26 Oct 1993 00:47:36 GMT From: tjp at bottom.caltech.edu (Tim Pearson) Message-Id: <2ahs39$n7p at gap.cco.caltech.edu> Organization: California Institute of Technology, Pasadena Path: cv3.cv.nrao.edu!uvaarpa!caen!usenet.cis.ufl.edu!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!pipex!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!bottom!tjp References: <9310251541.AA00628 at tetra.gsfc.nasa.gov> Subject: Re: AUTHOR --> CREATOR keyword Sender: fitsbits-request at fits.CV.NRAO.EDU Re proposed CREATOR keyword (Bill Pence): > >CREATOR = 'program name' / Program that created this FITS file > >HISTORY keywords should be used ... to document any further processing that >is performed on the file after it is created. It seems to me that a HISTORY record is the most appropriate way to specify the CREATOR information as well, unless a program that reads the file needs to extract the CREATOR information. Off-hand I can't think of any application where this should be the case; after all, the file is a FITS file, and how you read it should not depend on what program was used to create it. I suppose it might be important if the creator program has bugs, however, and doesn't write a correct FITS file. Tim Pearson tjp at astro.caltech.edu From fitsbits-request Tue Oct 26 07:56:58 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27047; Tue, 26 Oct 93 07:56:58 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 26 Oct 1993 02:38:09 GMT From: miller at lor.stsci.edu (Glenn Miller) Message-Id: Organization: Space Telescope Science Institute Path: cv3.cv.nrao.edu!uvaarpa!caen!usenet.cis.ufl.edu!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!pipex!uunet!cs.utexas.edu!asuvax!ncar!noao!stsci!stsci.edu!miller Subject: Re: AUTHOR --> CREATOR keyword Sender: fitsbits-request at fits.CV.NRAO.EDU >>>>> On 26 Oct 1993 00:47:36 GMT, tjp at bottom.caltech.edu (Tim Pearson) said: In article <2ahs39$n7p at gap.cco.caltech.edu> tjp at bottom.caltech.edu (Tim Pearson) writes: >Re proposed CREATOR keyword (Bill Pence): >> >>CREATOR = 'program name' / Program that created this FITS file >> >>HISTORY keywords should be used ... to document any further processing that >>is performed on the file after it is created. >It seems to me that a HISTORY record is the most appropriate way to >specify the CREATOR information as well, unless a program that reads the >file needs to extract the CREATOR information. Off-hand I can't think of >any application where this should be the case; after all, the file is a >FITS file, and how you read it should not depend on what program was used >to create it. I suppose it might be important if the creator program has >bugs, however, and doesn't write a correct FITS file. >Tim Pearson >tjp at astro.caltech.edu You are correct that such a keyword wouldn't be used to assert the format of the FITS file. It could however tell you something very important about the contents. You would be interested to know what program created a file since that tells you about what was done to the file. That is, there are any number of reduction algorithms and knowing the program that was used could tell you which one. For example, cosmic ray removal from CCD images and image restoration techniques are two common reduction problems which have a variety of algorithms available and no single "right" answer. Not only might a human be interested in this information (either to remember what s/he did last week or 3 years ago), but another program might need this information to determine what processing or reprocessing is needed. I don't know if there are other FITS keywords which already fill this role. I just want to point out that knowing what program (and in fact what version of the program) can be critical to understanding the scientific nature of a FITS file. -- Glenn E. Miller miller at stsci.edu Advance Planning Systems Branch 410-338-4738 Space Telescope Science Institute 410-338-1592 (fax) 3700 San Martin Dr. Baltimore, MD 21218 USA From fitsbits-request Tue Oct 26 08:42:33 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27105; Tue, 26 Oct 93 08:42:33 EDT Return-Path: Date: Tue, 26 Oct 93 08:42:15 EDT From: arots at xebec.gsfc.nasa.gov (Arnold Rots) Message-Id: <9310261242.AA04448 at xebec.gsfc.nasa.gov> To: CGP at starlink.leicester.ac.uk Subject: Re: ORIGIN and CREATOR keywords Cc: fitsbits at NRAO.EDU Sender: fitsbits-request at fits.CV.NRAO.EDU Clive Page writes: > In practice, therefore, the ORIGIN keyword doesn't often get used for > its original purpose. I don't see this as terribly serious: maybe we > should abandon ORIGIN if it isn't easy to use or all that important. I > think "CREATOR" sounds like a good name for the information that really > does need to be included in each FITS file. In reaching this conclusion he points out that it is often difficult for software to figure out which organization is running it. One of the reasons this issue came up, though, is that there are situations where the use of ORIGIN according to its original intent *is* quite meaningful. This is especially true for FITS files that contain raw observational data or calibration information. The software that generates these files usually runs at a limited number of institutions and is not exported by users, so special provisions to ensure a correct ORIGIN do not pose a severe restriction. Since there is this legitimate, albeit somewhat limited, use of ORIGIN in its original meaning, we are proposing the introduction of this new keyword, CREATOR, to fulfill the role that people have sometimes given to ORIGIN (i.e., a program name) in situations where an institution's name did not make a whole lot of sense. - Arnold Rots From fitsbits-request Tue Oct 26 11:07:49 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27297; Tue, 26 Oct 93 11:07:49 EDT Return-Path: Date: Tue, 26 Oct 93 11:07:41 EDT From: Marc Postman Message-Id: <9310261507.AA05716 at SOL.STSCI.EDU> To: fitsbits at NRAO.EDU Subject: Digitized Sky Survey CD-ROMs Sender: fitsbits-request at fits.CV.NRAO.EDU The Space Telescope Science Institute (Operated by AURA, Inc. for NASA) AND The Astronomical Society of the Pacific jointly announce the pre-production sale of the compressed digi- tized sky survey on CD-ROMs. THIS IS ONE OF THE MOST IMPORTANT NEW RESEARCH TOOLS IN ASTRONOMY. The cost of the entire 101 CD set will be $US 2900 if ordered prior to Feb. 15, 1994. After Feb. 15th the price will be $US 3500 (Airmail shipments to non-US addresses will be surcharged at a later date immediately prior to delivery). Manufacture of the first 61 CDs from the southern SERC J band survey will occur as soon as sufficient presale payments have been received. Distribution will follow immediately. The remain- ing 40 CDs from the northern Palomar Observatory E-band survey will be produced and distributed by early 1995. Separate purchase of the north and south sets is NOT possible. Orders by check or purchase order should be sent to: ASTRONOMICAL SOCIETY OF THE PACIFIC DEPT. 10X 390 ASHTON AVE. SAN FRANCISCO, CA 94112-1787 U.S.A. Visa or Mastercard orders will also be accepted by phone by calling (415) 337-2624 between 9AM and 3PM PST from Monday to Friday only. Alternatively, credit card orders may be FAXed to (415) 337-5205 and be sure to include expiration date and authorizing signature. PLEASE ORDER NOW TO AVOID DELAYS IN PRODUCTION/DISTRIBUTION AND TO OBTAIN THE PRICE DISCOUNT. The images on the CDs have been compressed by a factor of about 10 and are practically indistinguishable in quality from the original digitized scans. The CD sets also contain image decompression software that can be installed and operated on machines running the UNIX or VMS operating systems. All CDs are formatted according to the ISO 9660 standard. An astrometric calibration database is provided. If the number of CD set orders is sufficient, a photometric calibration database will also be shipped to all subscribers in late 1995. The digitized data scale is 1.7 arcsec per pixel. The SERC J band plate limit is ~21.5; the POSS E band plate limit is ~20.5. A full description of the data and software will be published in upcoming issues of the STScI and AAS Newsletters. **** PLEASE DO NOT REPLY TO THIS MESSAGE VIA E-MAIL **** **** ADDRESS ALL INQUIRIES TO ASP **** From fitsbits-request Tue Oct 26 11:54:24 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27357; Tue, 26 Oct 93 11:54:24 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Date: Tue, 26 Oct 1993 16:49:23 +0100 (MET) From: Lucio Chiappetti Subject: Re: AUTHOR --> CREATOR keyword To: fitsbits at fits.CV.NRAO.EDU In-Reply-To: <2ahs39$n7p at gap.cco.caltech.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fitsbits-request at fits.CV.NRAO.EDU On 26 Oct 1993, Tim Pearson wrote: > Re proposed CREATOR keyword (Bill Pence): > > > >CREATOR = 'program name' / Program that created this FITS file > > > >HISTORY keywords should be used ... to document any further processing that > >is performed on the file after it is created. > > It seems to me that a HISTORY record is the most appropriate way to > specify the CREATOR information as well, unless a program that reads the > file needs to extract the CREATOR information. Off-hand I can't think of > any application where this should be the case; after all, the file is a > FITS file, and how you read it should not depend on what program was used ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > to create it. I suppose it might be important if the creator program has I do not agree in some extent. To me it matters if the file was created by the 'ESO-MIDAS' environment, or by 'KPNO-IRAF', or by my own XAS environment, or by a GSFC-OGIP program, because the conventions used depend on the environment, and I may need to massage the file to convert from such (known) conventions to my local environment conventions. So far I have assumed that one could use the ORIGIN keyword to do this (in case of MIDAS and IRAF any installation anywhere will put the strings indicated above ... and not e.g. IFCTR-MIDAS ... nobody is interested to know that a file was written using MIDAS at IFCTR or elsewhere). To me it does not matter to know which particular command was used to write the file (ORIGIN or CREATOR='intape/fits' or 'wfits', or 'stwfits' won't tell me anything), although as a matter of routine I record such information (and any manipulation) to HISTORY keywords. (If you want, the history matters to an human reader, not to a program; the "environment" matters to programs (be it expressed as ORIGIN or CREATOR), the "originating institutions" (in the sense of the place where the tape or disk drive was located) does not matter to anybody). I believe it is quite important to identify the "conventions" according which the file was written (via ORIGIN, CREATOR, EXTNAME, EXTCLASS or whatever) From fitsbits-request Tue Oct 26 22:02:41 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02132; Tue, 26 Oct 93 22:02:41 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 26 Oct 1993 16:07:46 GMT From: hodge at stsci.edu (Phil Hodge) Message-Id: <1993Oct26.160746.29234 at stsci.edu> Organization: Space Telescope Science Institute Path: cv3.cv.nrao.edu!uvaarpa!caen!usenet.cis.ufl.edu!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!organpipe.uug.arizona.edu!CS.Arizona.EDU!noao!stsci!hodge References: <9310251541.AA00628 at tetra.gsfc.nasa.gov> Subject: Re: AUTHOR --> CREATOR keyword Sender: fitsbits-request at fits.CV.NRAO.EDU Bill Pence suggested a CREATOR FITS keyword to record the name of the program that wrote the FITS file. One disadvantage of a character-string keyword rather than a HISTORY record is that a FITS reader does not have to read more than the first eight characters of a character string, and this is likely to be insufficient for many programs. From fitsbits-request Tue Oct 26 22:09:38 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02160; Tue, 26 Oct 93 22:09:38 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 26 Oct 1993 16:36:50 GMT From: tjp at bottom.caltech.edu (Tim Pearson) Message-Id: <2ajjn2$in8 at gap.cco.caltech.edu> Organization: California Institute of Technology, Pasadena Path: cv3.cv.nrao.edu!uvaarpa!caen!usenet.cis.ufl.edu!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!pipex!uunet!tadpole.com!news.dell.com!swrinde!elroy.jpl.nasa.gov!nntp-server.caltech.edu!bottom!tjp References: Subject: Re: AUTHOR --> CREATOR keyword Sender: fitsbits-request at fits.CV.NRAO.EDU miller at lor.stsci.edu (Glenn Miller) writes: > I just want to point out that knowing what program (and in fact >what version of the program) can be critical to understanding the >scientific nature of a FITS file. I quite agree with this, but I think you need to know the entire processing history, not just the first or last step. I don't think a single CREATOR keyword is sufficient. I generally put the information in HISTORY records (usually several records per step, to specify all the processing parameters used). Of course, CREATOR will do no harm if used consistently by all FITS writers. Tim Pearson tjp at astro.caltech.edu From fitsbits-request Tue Oct 26 22:52:19 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02200; Tue, 26 Oct 93 22:52:19 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 26 Oct 1993 18:37:29 GMT From: phjj at ruchem.ru.ac.za Message-Id: Organization: Rhodes University, Grahamstown, SA Path: cv3.cv.nrao.edu!uvaarpa!caen!usenet.cis.ufl.edu!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!ee.und.ac.za!hippo.ru.ac.za!ruchem.ru.ac.za!PHJJ References: <9310251541.AA00628 at tetra.gsfc.nasa.gov>,<2ahs39$n7p at gap.cco.caltech.edu> Reply-To: phjj at ruchem.ru.ac.za Subject: Re: AUTHOR --> CREATOR keyword Sender: fitsbits-request at fits.CV.NRAO.EDU In article <2ahs39$n7p at gap.cco.caltech.edu>, tjp at bottom.caltech.edu (Tim Pearson) writes: > >It seems to me that a HISTORY record is the most appropriate way to >specify the CREATOR information as well, unless a program that reads the >file needs to extract the CREATOR information. Off-hand I can't think of >any application where this should be the case; after all, the file is a >FITS file, and how you read it should not depend on what program was used >to create it. I suppose it might be important if the creator program has >bugs, however, and doesn't write a correct FITS file. > It would be convenient to have a structured way of finding out what has been done to an image. I think NOD2 had/has some sort of mechanism like this. Perhaps even some sort of enumerated keyword could be invoked, so the total passage of an image through a suite of programs could be monitored? Just an idea. Justin ====================================================~~~~~*~~~~~~~~~~~*~~~~~~~~~ Justin Jonas Radio Astronomy Group, /V\ _____ __ __ Dept. Physics & Electronics, \ / \ / /____/ \ /_/| /_/| Rhodes University, \/ |v| \/ | __ \ /| | | | | | | Grahamstown 6140, South Africa \__|#|__/ 26m | |__) |/ | | | | | | Internet: phjj at ruchem.ru.ac.za HartRAO /X\ dish | ___ \ \ | \_\/ | | phjj at hippo.ru.ac.za /\/|\/\ |_|/ \__\/ \___/|_|/ Tel: +27(461)318452 ____/\/__|__\/\____ From fitsbits-request Wed Oct 27 10:28:29 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03670; Wed, 27 Oct 93 10:28:29 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 27 Oct 93 01:27:48 GMT From: thompson at serts.gsfc.nasa.gov (William Thompson) Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!caen!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson References: <9310261022.AA00346 at cv3.cv.nrao.edu> Subject: Re: ORIGIN and CREATOR keywords Sender: fitsbits-request at fits.CV.NRAO.EDU "Clive Page, Leicester University, UK" writes: >The problem with the original FITS definition of ORIGIN as "the >organization creating the FITS file" is that it's quite hard to write >software to define it correctly. It is easy enough, and obviously >sensible, to encode in a FITS file the program name and version number >that produced it. It isn't too hard to pick up the user-name of the >person running the program through the appropriate system call, but it >is not as easy to obtain the name of his/her organization. Some >programs that I write end up being used in a number of other >organizations - if I were to hard-code the name of my organization then >that would obviously be misleading much of the time. ... (rest deleted) Of course, the same could be said about the keywords TELESCOP and INSTRUME, which in my opinion are critically important. It can also be important, from a data management point of view, to know which of several co-investigator institutions processed a specific file. I use IDL to process data, but it wouldn't tell you much to say that IDL wrote a FITS file. It would mean more to tell one that it was written by the CDS data processing software, because that would mean that certain specific steps were taken in processing the data. Bill Thompson From fitsbits-request Wed Oct 27 12:32:33 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04126; Wed, 27 Oct 93 12:32:33 EDT Return-Path: Date: Wed, 27 Oct 93 12:32:17 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9310271632.AA17116 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: 8 character limit Sender: fitsbits-request at fits.CV.NRAO.EDU Phil Hodge wrote: > One disadvantage of a character-string > keyword rather than a HISTORY record is that a FITS reader does not have > to read more than the first eight characters of a character string, and > this is likely to be insufficient for many programs. From the practical point of view, I can see little excuse for FITS readers not to support the maximum 68-character long string values. There are important cases where a FITS reader would get into serious trouble if it only read the first 8 characters. For example, TFORM1 = '1PE(10000)' TDIM2 = '(1024,1024)' The only place in the FITS Standard where I could find any mention of an 8-character limit was in section 5.3.2.1 in the discussion of Fixed Format Character Strings where it recommends: "Reading the data values in a FITS file should not require decoding any more than the first eight characters of a character string value of a keyword". I don't understand what this means exactly, but given the above examples where it is important to read more than 8 characters, this recommendation seems to be out of date, and should perhaps be deleted or at least clarified in future versions of the Standard. From fitsbits-request Wed Oct 27 13:26:00 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04443; Wed, 27 Oct 93 13:26:00 EDT Return-Path: Message-Id: <9310271725.AA04437 at fits.cv.nrao.edu> Date: Wed, 27 Oct 1993 18:24:58 +0100 From: forveill at gag.observ-gr.fr (Thierry Forveille) Posted-Date: Wed, 27 Oct 1993 18:24:58 +0100 To: fitsbits at fits.CV.NRAO.EDU Subject: ORIGIN and CREATOR keywords Sender: fitsbits-request at fits.CV.NRAO.EDU My impression is that the definition of ORIGIN as the organisation writing the file dates back to days when there was to a large extent a one-to-one mapping between institutions/telescopes and data reduction programs. With fewer packages spreading to more places, the meaning probably shifted to follow the usefull information. I cannot come up with an example where the place a file was written at is relevant, rather than the program (with its control parameters if any). A FITS file written at ESO la Silla could as well be a theoretical simulation as the output of any telescope there... I would thus we keep ORIGIN to mean the writing program/package (and accordingly adjust the standard) unless somebody uses it with its initial definition. It is on the other hand unfortunately not true that the writing program is irrelevant when decoding a FITS file. FITS is mostly a grammar, and only to a very limited extent a vocabulary. It is still quite common to see images with no axis description (thus implicitely CRVALi=0,CDELTi=1,CRPIXi=0) storing the RA and Dec of the central pixel as something like RA-POINT (or RA_PNTG, RA-OBS, RA_TELES....), plus the focal scale and orientation of the pixel array. They are perfectly valid FITS files and the axis information is there, though arguably not in a very convenient shape. The 8 character limit as worded in the Standard does mean that a FITS reader is at present only requested to read the first 8 characters. I have fortunately never encountered any program that enforces this limitation, but I do agree that it should be suppressed as soon as feasible. Thierry Forveille From fitsbits-request Wed Oct 27 14:35:42 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04757; Wed, 27 Oct 93 14:35:42 EDT Return-Path: Message-Id: <9310271835.AA04751 at fits.cv.nrao.edu> Via: uk.ac.leicester.starlink; Wed, 27 Oct 1993 18:01:03 +0000 Date: Wed, 27 Oct 93 18:00 GMT From: "Clive Page, Leicester University, UK" To: FITSBITS Subject: 8-character limit Sender: fitsbits-request at fits.CV.NRAO.EDU I'd like to support Messrs Forveille and Pence on this. I suspect that the 8-character limit on character values (specified in section 5.3.2.1) dates back to Fortran-66, when the only way of handling character strings was to store them in numerical variables, and a DOUBLE PRECISION could be relied upon to hold at least 8 characters on all known machines. This clause in the current standard can be interpreted to mean that the names of columns in a FITS table (ASCII or BINARY) cannot be longer than 8 characters. This is not entirely clear, because even if the column name were more than 8 characters long it would not necessarily stop you reading in the data values from the column. I've no objection to having a length limit on names of columns, but 8 characters seems to me a bit on the short side, and I'd prefer to see such limits defined more explicitly in the Standard. Clive Page From fitsbits-request Thu Oct 28 04:20:52 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06508; Thu, 28 Oct 93 04:20:52 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Date: Thu, 28 Oct 1993 09:16:27 +0100 (MET) From: Lucio Chiappetti Subject: Re: 8-character limit To: FITSBITS In-Reply-To: <9310271835.AA04751 at fits.cv.nrao.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fitsbits-request at fits.CV.NRAO.EDU On Wed, 27 Oct 1993, Clive Page, Leicester University, UK wrote: > I'd like to support Messrs Forveille and Pence on this. I suspect that > the 8-character limit on character values (specified in section 5.3.2.1) ... > > This clause in the current standard can be interpreted to mean that > the names of columns in a FITS table (ASCII or BINARY) cannot be longer > than 8 characters. This is not entirely clear, because even if the ... > > I've no objection to having a length limit on names of columns, but 8 > characters seems to me a bit on the short side, and I'd prefer to see > such limits defined more explicitly in the Standard. > When I first read this an objection arose in the back of my mind, but after a careful reading this is gone. It looks like there may be three limits (TO BE perhaps MORE CLEARLY SPECIFIED as Clive Page says). a) limit of 8 characters on KEYWORD names. (this was where I was going to object ... I read "names of keywords" instead of "names of columns") This should not be changed, for the principle "once FITS always FITS", it would be inconvenient to change for almost all s/w around. b) limit of 8 characters on values of TTYPEn columns (aka column names) I have actually never considered this, along with the following (c). It could be useful to know that a limit (if shorter than 68) exists. At the moment I use a limit which changes program to program. c) limit on values of any other character keywords Well, the only limit which makes sense here is the 68-character limit due to the card image layout. There was a discussion a while ago about "continuation cards", which ended, as far as I remember, in having that as a "local convention" for the site proposing it. Me, I'm happy to live with the 68-character limit From fitsbits-request Fri Oct 29 12:59:14 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11880; Fri, 29 Oct 93 12:59:14 EDT Return-Path: < at uga.cc.uga.edu:MMAGALLO at UCRVM2.BITNET> Message-Id: <9310291659.AA08382 at cv3.cv.nrao.edu> Date: Fri, 29 Oct 93 10:34:20 UCR From: "Marcelo Magallon Gh." Subject: FITSIO: ASCII tables definition To: FITSBITS at NRAO.EDU Sender: fitsbits-request at fits.CV.NRAO.EDU Hello everybody! I have a question concerning FITSIO. I'm trying to put some information into an ASCII table, but I don't know how much rows I have to write, unless I read the entire data file... the data file is very long and I have to do a lot of parsing before writing the information to the ASCII table. Before trying to solve the whole problem at once (ASCII table, parsing, some calculations), I decided to break it appart and solve each part separatedly. Now, I'm trying to create an ASCII table in the same way that I'll have to do it later, i.e. without knowing the number of rows I'll have to write. Now, the problem: I have to call FTPHTB and FTADEF in order to define table's characteristics. That's ok, but I have to state the number of rows in the table. I'm putting a dummy number (5)... it works ok. FITSIO makes no complaint. Now I write about 500 rows, so I have to change NAXIS2 keyword, but I don't want to change the keyword directly (I don't know if I'm allowed to do that), rather, I want to UPDATE table's header... the question is (finally!) how do I do that!? Some of my solutions (DW= Didn't work; AP=Apparently worked, something failed) 1) Call FTADEF again after writing the data. DW, no change in NAXIS2 2) Call FTPHTB again. AP, NAXIS2 changed but the header is dupplicated. 3) Call FTPHTB *and* FTADEF again. AP, but the data is gone! 4) Call FTPHTB and FTADEF *after* the data is written to the file. AP, but, again, the data is gone. 5) Call FTPHTB before and FTADEF after the data is written. DW. 6) Invert procedure in 5), same result. 7) I'm going nuts... This is the only thing that's working... %) ANY help... May I rewrite NAXIS2? Thaks A LOT, really. From fitsbits-request Fri Oct 29 14:07:46 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12062; Fri, 29 Oct 93 14:07:46 EDT Return-Path: Date: Fri, 29 Oct 1993 14:07:44 -0400 (EDT) From: SWEETLAND at rsdps.gsfc.nasa.gov To: fitsbits at NRAO.EDU Message-Id: <931029140744.2020da33 at rsdps.gsfc.nasa.gov> Subject: Rewriting NAXIS2 Sender: fitsbits-request at fits.CV.NRAO.EDU Nothin' to it, guy! After the: ftcrhd ftphtb ftmcom (optional) ftadef ftpcls (probably) you can then: FTMKYJ(unit,'NAXIS2',new_naxis2_value,'&',status) (new_naxis2_value is I*4, the '&' says don't change the comment field) Then you FTDDEF(unit,bytlen,status) (to redefine the size of the extension. bytlen is the count of your records going into your file times the byte length of the records, obviously mush easier when they are fixed-length). BTW, the FTMKYJ and FTDDEF are calls, of course.\ And, when all is said and done, you call FTCLOS (trusting that you have done an FTINIT to open the sucker, of course, and that's all there is to it. --Sallyo From fitsbits-request Fri Oct 29 14:16:43 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12099; Fri, 29 Oct 93 14:16:43 EDT Return-Path: Date: Fri, 29 Oct 93 14:16:31 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9310291816.AA03935 at tetra.gsfc.nasa.gov> To: FITSBITS at NRAO.EDU Subject: Re: FITSIO: ASCII tables definition Sender: fitsbits-request at fits.CV.NRAO.EDU >I have a question concerning FITSIO. I'm trying to put some information >into an ASCII table, but I don't know how much rows I have to write, >unless I read the entire data file... The recommended procedure for creating an ASCII or binary FITS table using FITSIO when the total number or rows to be written to the table is unknown at the start, is described in some detail in section 4.3 (Advanced Usage) of the FITSIO documentation. Here is a brief outline of the procedure: 1. Write the required header keywords with ftphtb or ftphbn. Set the NAXIS2 keyword value (=the number of rows in the table) to zero (or any other positive integer dummy value). 2. Define the structure of the table with ftadef or ftbdef. Again, set the number of rows equal to zero, or some other positive dummy value (see additional note about this below). 3. Write the data to the table, while keeping track of the total number of rows that have been written. 4. After all the rows have been written, 2 more steps must be performed before the table can be cleanly closed: a) update the correct value of the NAXIS2 keyword using the ftmkyj subroutine b) update the total size of the table (in bytes) using the ftddef subroutine. Normally FITSIO determines the table size from the ftadef of ftbdef subroutine arguments, but since the number of rows have changed, one must explicitly redefine the size of of the table. 5. Close the FITS file with ftclos (or move on to write another new extension). There is just one possible problem with this procedure when writing an ASCII FITS table. The FITS Standard From fitsbits-request Fri Oct 29 15:04:43 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12267; Fri, 29 Oct 93 15:04:43 EDT Return-Path: Date: Fri, 29 Oct 93 15:04:37 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9310291904.AA04511 at tetra.gsfc.nasa.gov> To: fitsbits at NRAO.EDU Subject: re: rewriting NAXIS2 Sender: fitsbits-request at fits.CV.NRAO.EDU [Sorry, my previous message on this subject mysteriously posted itself before I had completed it! Also "Sallyo" gave basicaly the same answer to the original question.] There is one thing to watch out for when creating ASCII FITS tables with FITSIO that initially have an unknown number of rows. The FITS Standard requires that any fill bytes at the end of an ASCII table be set equal to ASCII Spaces, not NULs as is done in all other types of extensions. FITSIO does this in the ftadef subroutine, so obviously if the correct number of rows are not passed to the subroutine, then it will not correctly initialize the table. In practice this does not matter as long as a) the writing program explicitly writes a value to every element of the table. Otherwise, any unwritten table cell will contain ASCII NUL values, which are illegal b) there are no gaps between the defined columns of the table. Sometimes the ASCII table columns are defined such that there are one or more spaces between each data column, to improve human readibility. If this this case, then these gaps bytes could end up uninitialized and have an illegal ASCII NUL value. There still remains a technical problem in that the fill bytes after the last row in the table may not be set to ASCII Spaces, but FITS readers have no reason to ever read these fill bytes, so this makes no difference in practice (but it is still technically illegal!). If this is a problem, it is possible for the FITS writing program to explicitly set all the fill bytes to ASCII Spaces using the ftptbs subroutine, but it is a little tedious figuring out how many fill bytes need to be written. I may be able to find a workaround to this problem and put a fix in future releases of FITSIO, but no guarantees. Note that this is not a problem with Binary FITS tables, since they are padded with ASCII NULs which happens by default in FITSIO. -Bill Pence From fitsbits-request Fri Oct 29 18:41:13 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12976; Fri, 29 Oct 93 18:41:13 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 28 Oct 1993 09:27 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Message-Id: <28OCT199309275842 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <9310271725.AA04437 at fits.cv.nrao.edu> Subject: Re: ORIGIN and CREATOR keywords Sender: fitsbits-request at fits.CV.NRAO.EDU In article <9310271725.AA04437 at fits.cv.nrao.edu>, forveill at gag.observ-gr.fr (Thierry Forveille) writes... >My impression is that the definition of ORIGIN as the organisation writing >the file dates back to days when there was to a large extent a one-to-one >mapping between institutions/telescopes and data reduction programs. With >fewer packages spreading to more places, the meaning probably shifted to >follow the usefull information. FITS Paper I defines ORIGIN to be "Tape writing institution." That meaning is the one that has been intended all along. >I cannot come up with an example where >the place a file was written at is relevant, rather than the program (with >its control parameters if any). One usage, touched on by Lucio Chiappetti, is that when particular institutions or groups have defined keywords to have particular meanings, and the same keyword may be used in different ways by different organizations, the ORIGIN keyword identifies whose conventions are being used. >I would thus we keep ORIGIN to mean the writing program/package (and >accordingly adjust the standard) unless somebody uses it with its initial >definition. > We would then have a keyword with an ambiguous definition. And we can't *change* the meaning because doing so would cause existing FITS files to be out of conformance. Any existing usage of ORIGIN with a meaning other than that defined in the first FITS paper is simply not in conformance with standard FITS. If we are going to have a keyword to identify the software that produced a file, it should be a new keyword; we should not redefine an existing one. >It is on the other hand unfortunately not true that the writing program is >irrelevant when decoding a FITS file. FITS is mostly a grammar, and only >to a very limited extent a vocabulary. It is still quite common to see >images with no axis description (thus implicitely CRVALi=0,CDELTi=1,CRPIXi=0) >storing the RA and Dec of the central pixel as something like RA-POINT >(or RA_PNTG, RA-OBS, RA_TELES....), plus the focal scale and orientation >of the pixel array. They are perfectly valid FITS files and the axis >information is there, though arguably not in a very convenient shape. I would discourage the practice of using keywords other than the standard keywords to express concepts for which a standard keyword exists. In the NOST User's Guide, we say, "Different keywords should not be used in the place of reserved keywords to express the same concepts." FITS Paper I describes the purpose of reserving keywords in FITS as "to facilitate and encourage the specification of detailed intensity, coordinate, and documentary information with each image." Expression of concepts in ways other than that defined in the standard complicates the task of the reader, defeating the purpose of standardization. As Wells, Greisen and Harten noted in the first FITS paper, "... we will all have to be careful to avoid compromising this tool by basic departures from the basic FITS standard. > >The 8 character limit as worded in the Standard does mean that a FITS reader >is at present only requested to read the first 8 characters. I have fortunately >never encountered any program that enforces this limitation, but I do >agree that it should be suppressed as soon as feasible. > The 8 character limit on values of a character keyword applies only when the information from that keyword is needed by the software to actually read the data from the file. It does not apply to information required only for scientific interpretation of the header and data. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Fri Oct 29 20:17:38 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13270; Fri, 29 Oct 93 20:17:38 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 28 Oct 93 18:36:38 GMT From: thompson at serts.gsfc.nasa.gov (William Thompson) Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!usenet.ins.cwru.edu!agate!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson References: Subject: Re: 8-character limit Sender: fitsbits-request at fits.CV.NRAO.EDU Lucio Chiappetti writes: >On Wed, 27 Oct 1993, Clive Page, Leicester University, UK wrote: >> I'd like to support Messrs Forveille and Pence on this. I suspect that >> the 8-character limit on character values (specified in section 5.3.2.1) > ... >> >> This clause in the current standard can be interpreted to mean that >> the names of columns in a FITS table (ASCII or BINARY) cannot be longer >> than 8 characters. This is not entirely clear, because even if the > ... >> >> I've no objection to having a length limit on names of columns, but 8 >> characters seems to me a bit on the short side, and I'd prefer to see >> such limits defined more explicitly in the Standard. >> > When I first read this an objection arose in the back of my mind, but > after a careful reading this is gone. It looks like there may be three > limits (TO BE perhaps MORE CLEARLY SPECIFIED as Clive Page says). > a) limit of 8 characters on KEYWORD names. (this was where I was going > to object ... I read "names of keywords" instead of "names of columns") > This should not be changed, for the principle "once FITS always FITS", > it would be inconvenient to change for almost all s/w around. > b) limit of 8 characters on values of TTYPEn columns (aka column names) > I have actually never considered this, along with the following (c). > It could be useful to know that a limit (if shorter than 68) exists. > At the moment I use a limit which changes program to program. > c) limit on values of any other character keywords > Well, the only limit which makes sense here is the 68-character limit > due to the card image layout. There was a discussion a while ago > about "continuation cards", which ended, as far as I remember, in > having that as a "local convention" for the site proposing it. Me, > I'm happy to live with the 68-character limit For some reason Clive Page's article doesn't seem to have reached this site. I for one would be very dismayed if it was decided that the column names (specified by TTYPEn keywords) had to be less than eight characters. I believe that this would not be consistent with Barry Schlesinger's statement that the eight character limit only applies to the values of keywords needed to read the data. I believe that the use of TTYPEn should be unrestricted, other than those imposed by conventions, local or otherwise, which are outside the scope of the FITS standard. Bill Thompson From fitsbits-request Sun Oct 31 23:51:45 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA17997; Sun, 31 Oct 93 23:51:45 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 29 Oct 1993 17:19:34 GMT From: jansen at onyx.astro.wisc.edu (Stephan Jansen) Message-Id: Organization: University of Wisconsin - Astronomy Department Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!sdd.hp.com!saimiri.primate.wisc.edu!news.doit.wisc.edu!news.doit.wisc.edu!jansen Subject: FITS browsers for PC Sender: fitsbits-request at fits.CV.NRAO.EDU I work in a small astronomy library that is trying to provide access to astronomical catalogs on CD-ROM. So I'm looking for recommendations on FITS browsers for the PC, with information on what they display: images, tables, etc. The only one I've seen is imdisp 7.9. Recommendations? Dave Wuolu -- Woodman Astronomical Library -- astrolib at madraf.astro.wisc.edu -- -Stephan jansen at uwast.astro.wisc.edu From fitsbits-request Mon Nov 1 01:13:27 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18037; Mon, 1 Nov 93 01:13:27 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 30 Oct 93 00:56:48 GMT From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!caen!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!spool.mu.edu!agate!ames!skates.gsfc.nasa.gov!Hypatia!leb References: Subject: Re: FITS browsers for PC Sender: fitsbits-request at fits.CV.NRAO.EDU jansen at onyx.astro.wisc.edu (Stephan Jansen) writes: >I work in a small astronomy library that is trying to provide access to >astronomical catalogs on CD-ROM. So I'm looking for recommendations on >FITS browsers for the PC, with information on what they display: images, >tables, etc. The only one I've seen is imdisp 7.9. Recommendations? >Dave Wuolu -- Woodman Astronomical Library -- astrolib at madraf.astro.wisc.edu >-- >-Stephan >jansen at uwast.astro.wisc.edu The National Space Science Data Center at NASA Goddard Space Flight Center provides a little tool for browsing through the FITS ASCII tables on the Astronomical Data Center CD-ROM, Selected Astronomical Catalogs, Volume I, a collection of 114 of the most popular and scientifically useful astronomical catalogs in the ADC archives. It is called the ADC FITS Table Browser and is available by anonymous FTP from hypatia.gsfc.nasa.gov (IP address 128.183.101.54) in directory /pub/software/ftb. The program uses the curses screen management library and runs under MS-DOS and Unix. There will be a new minor release of FTB soon. I have been notified of a few bugs and fixed them, but would like to take some more time in testing. Notification of bug fixes and new releases are announced in the Astronomical Data Center Electronic Newsletter, a quarterly journal of the ADC distributed by electronic mail. To subscribe to the ADC E-News, send E-mail to "listserv at hypatia.gsfc.nasa.gov" and in the body of the mail message (not the subject line) put _only_ the following command: SUBSCRIBE ADCNEWS where is your full name, not your E-mail address (LISTSERV can figure out the return address itself). I am currently evaluating libraries that allow GUI development for both Microsoft Windows, the X Window system, and (possibly) DOS. My intent is to provide a GUI interface to FTB that is source-code compatible with both MS Windows and X. Right now, I'm looking at the Simple User Interface Toolkit (SUIT) and mxWindows. If anyone has a suggestion for a public domain library that fills the bill, please send me E-mail (let's not clutter up sci.astro.fits with GUI talk). -- -- Lee E. Brotzman Internet: leb at nssdca.gsfc.nasa.gov -- Hughes STX, NSSDC DECNET: NSSDCA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS From fitsbits-request Mon Nov 1 08:19:22 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA19374; Mon, 1 Nov 93 08:19:22 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 31 Oct 93 00:15:29 GMT From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!sol.ctr.columbia.edu!math.ohio-state.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!Hypatia!leb References: Subject: Re: FITS browsers for PC Sender: fitsbits-request at fits.CV.NRAO.EDU leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) writes: >-- Lee E. Brotzman Internet: leb at nssdca.gsfc.nasa.gov ^^^ <--- wrong It would be more useful if I gave the correct E-mail address, wouldn't it? See my corrected .signature below. Sorry about that. -- -- Lee E. Brotzman Internet: brotzman at nssdca.gsfc.nasa.gov -- Hughes STX, NSSDC DECNET: NSSDCA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS