From fitsbits-request Tue Nov 2 07:21:18 1993 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 33 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 AA21817; Tue, 2 Nov 93 07:21:18 EST Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!hearst.acc.Virginia.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: 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: FITS browsers for PC Date: 30 Oct 93 00:56:48 GMT 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 Wed Nov 3 07:53:46 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["532" "" "31" "October" "93" "00:15:29" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "11" "Re: FITS browsers for PC" "^From:" nil nil "10"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24662; Wed, 3 Nov 93 07:53:46 EST Return-Path: Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!hearst.acc.Virginia.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: 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: FITS browsers for PC Date: 31 Oct 93 00:15:29 GMT 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 From fitsbits-request Wed Nov 3 11:19:51 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1013" "Wed" "3" "November" "93" "11:19:44" "EST" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "23" "CTYPE for pixel image" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA24931; Wed, 3 Nov 93 11:19:51 EST Return-Path: Message-Id: <9311031619.AA14984 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: CTYPE for pixel image Date: Wed, 3 Nov 93 11:19:44 EST Does anyone have a recommendation for what values to assign to the WCS FITS keywords when describing an image of the detector flat-field (or similar image in the detector reference frame)? In this case, there is no projection onto the sky, and the pixel increments (CDELTn) are in units of millimeters on the detector surface. Would the following minimum set of keyword be acceptable? NAXIS = 2 NAXIS1 = 256 NAXIS2 = 256 ... ... CTYPE1 = 'PIXEL ' / no projection is involved CTYPE2 = 'PIXEL ' / no projection is involved CDELT1 = .0027 / increment in mm/pixel on the detector CDELT2 = .0027 / increment in mm/pixel on the detector CUNIT1 = 'mm ' / physical units of the first image axis CUNIT2 = 'mm ' / physical units of the second image axis The other WCS keywords (CRPIXn, CRVALn, CROTAn, CDiiijjj) would just have default values, so there is no reason to explicitly list them in the header. From fitsbits-request Wed Nov 3 12:19:16 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["9711" "Wed" "3" "November" "93" "12:19:05" "EST" "Arnold Rots" "arots at xebec.gsfc.nasa.gov " nil "183" "Re: CTYPE for pixel image" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA25078; Wed, 3 Nov 93 12:19:16 EST Return-Path: Message-Id: <9311031719.AA09203 at xebec.gsfc.nasa.gov> From: arots at xebec.gsfc.nasa.gov (Arnold Rots) Sender: fitsbits-request at fits.CV.NRAO.EDU To: pence at tetra.gsfc.nasa.gov Cc: fitsbits at fits.CV.NRAO.EDU Subject: Re: CTYPE for pixel image Date: Wed, 3 Nov 93 12:19:05 EST I would submit that the flatfield image you are referring to is not terribly different from a "real" image generated by the detector, at least not where the coordinates are concerned: both contain a variable (intensity, counts, flatfield correction) on the detector's pixel grid. In the case of the real image, this is projected onto the sky, with the projection determined by the telescope optics and the reference pixel on the telescope's optical axis. If you now decide to measure the flatfield coordinates in mm, you will have to provide somewhere information on how to transform this coordinate system to that of an image - that is, if you intend to apply corrections to such an image. It would be much simpler and less error-prone if the flatfield were given in the same coordinate system as the images, i.e., the projection of the detector pixels on the sky, with the reference pixel along the optical axis, the position angle at 0, and defaults for the RA and Dec of the reference pixel. - Arnold Rots From fitsbits-request Thu Nov 4 06:32:01 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6480" "Thu" "4" "November" "1993" "12:30:49" "+0100" "Thierry Forveille" "forveill at gag.observ-gr.fr " nil "113" "Re: ORIGIN and CREATOR keywords" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA26277; Thu, 4 Nov 93 06:32:01 EST Return-Path: Message-Id: <9311041131.AA26271 at fits.cv.nrao.edu> Posted-Date: Thu, 4 Nov 1993 12:30:49 +0100 In-Reply-To: <28OCT199309275842 at nssdca.gsfc.nasa.gov> References: <28OCT199309275842 at nssdca.gsfc.nasa.gov> <9310271725.AA04437 at fits.cv.nrao.edu> From: forveill at gag.observ-gr.fr (Thierry Forveille) Sender: fitsbits-request at fits.CV.NRAO.EDU To: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Cc: fitsbits at fits.CV.NRAO.EDU Subject: Re: ORIGIN and CREATOR keywords Date: Thu, 4 Nov 1993 12:30:49 +0100 BARRY M. SCHLESINGER writes: > 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 certainly agree that different organization may use the same keywords with different meanings, and actually surprised this doesn't create trouble more frequently. My point is that the tape writing institution (i.e. the institution owning the computer running the program, or the tape drive, or the disk) is irrelevant. AIPS running at STScI will produce AIPS looking FITS with AIPS keywords, not IRAF (or STSDAS) looking FITS. Keywords are pretty much hard-coded into writing programs in practice. With the advent of wide area networks, the writing institution also becomes a rather fuzzy concept: I sometimes run on my institution's computer a program stored on the disk of another institution (nfs mounted on mine) and write the output on the disk of a third institution. Which of these should be considered as the "tape writing institution"? > >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. > My feeling is that we already have a keyword with an ambiguous definition anyway. One definition is printed in paper I, and a second incompatible definition is set by the zillions of existing FITS files which use it with the meaning of the proposed CREATOR keyword (I have yet to encounter a real FITS file using it with the original meaning). We thus have to decide which of these should be kept. If, as you suggest, the main objective is that existing FITS files should remain valid, we should change the standard to put it in line with common practice, unless of course somebody comes up with thousands of files really using the original 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. > > 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. > I certainly agree with this statement and hate patching a FITS reader to decode lousy coordinate information, but we sometimes have to live with existing files. Once major packages like IHAP did produce truck loads of 9 track tapes with this type of coordinate information, and may still be in use at some places. The main point however is that different programs use different keywords for the same information (which of course is bad style if a reserved keyword would fit), and that knowing the program sometimes help. > > > >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. > As pointed out in the original mail on the 8 character limit (I cannot remember who the author was), enforcement of the limit would wreck decoding of a 1024x1024 (actually even 128x128) matrix in a binary table. It would have TDIMi = '(1024,1024)' and would need at least an 11 character string to correctly read the data. Unless of course you consider the difference between a 1024x1024 2D array and a 1048576 1D vector to be part of the scientific interpretation... Given the negligible cost of a 68 byte buffer on today's computer, I can see no reason for keeping this limitation. Thierry Forveille From fitsbits-request Thu Nov 4 08:20:53 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["889" "Thu" "4" "November" "1993" "14:19:41" "+0100" "Thierry Forveille" "forveill at gag.observ-gr.fr " nil "22" "Re: CTYPE for pixel image" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27188; Thu, 4 Nov 93 08:20:53 EST Return-Path: Message-Id: <9311041320.AA27182 at fits.cv.nrao.edu> Posted-Date: Thu, 4 Nov 1993 14:19:41 +0100 In-Reply-To: <9311031719.AA09203 at xebec.gsfc.nasa.gov> References: <9311031719.AA09203 at xebec.gsfc.nasa.gov> From: forveill at gag.observ-gr.fr (Thierry Forveille) Sender: fitsbits-request at fits.CV.NRAO.EDU To: arots at xebec.gsfc.nasa.gov (Arnold Rots) Cc: fitsbits at fits.CV.NRAO.EDU, pence at tetra.gsfc.nasa.gov Subject: Re: CTYPE for pixel image Date: Thu, 4 Nov 1993 14:19:41 +0100 It seems a strange convention to ascribe dummy angular coordinates to a flat field. Which value should one one then choose for the RA and Dec of the reference pixel? A flat field is one of the clear cases where the only adequate unit along the axes is the pixel. My choice for the header is however rather the following, since the linear scale on the detector is irrelevant. NAXIS = 2 NAXIS1 = 256 NAXIS2 = 256 .......................................... CTYPE1 = 'PIXEL ' / no projection is involved CTYPE2 = 'PIXEL ' / no projection is involved CDELT1 = 1 CRPIX1 = 1 CRVAL1 = 1 CDELT2 = 1 CRPIX2 = 1 CRVAL2 = 1 CUNIT1 = ' ' / physical units of the first image axis CUNIT2 = ' ' / physical units of the second image axis From fitsbits-request Thu Nov 4 13:59:41 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2761" "Thu" "4" "November" "93" "13:59:28" "EST" "Jonathan McDowell" "jcm at urania.harvard.edu " nil "63" "" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27681; Thu, 4 Nov 93 13:59:41 EST Return-Path: Message-Id: <9311041859.AA05882 at urania.harvard.edu> From: jcm at urania.harvard.edu (Jonathan McDowell) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Date: Thu, 4 Nov 93 13:59:28 EST > Received: from fits.cv.nrao.edu by urania.harvard.edu (4.1/SMI-4.1) > id AA28297; Wed, 3 Nov 93 11:27:04 EST > Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) > id AA24931; Wed, 3 Nov 93 11:19:51 EST > Return-Path: > Date: Wed, 3 Nov 93 11:19:44 EST > From: pence at tetra.gsfc.nasa.gov (William Pence) > Message-Id: <9311031619.AA14984 at tetra.gsfc.nasa.gov> > To: fitsbits at fits.CV.NRAO.EDU > Subject: CTYPE for pixel image > Cc: pence at tetra.gsfc.nasa.gov > Sender: fitsbits-request at fits.CV.NRAO.EDU > > Does anyone have a recommendation for what values to assign to the WCS > FITS keywords when describing an image of the detector flat-field (or > similar image in the detector reference frame)? In this case, there is > no projection onto the sky, and the pixel increments (CDELTn) are in > units of millimeters on the detector surface. > > Would the following minimum set of keyword be acceptable? > > NAXIS = 2 > NAXIS1 = 256 > NAXIS2 = 256 > ... > ... > CTYPE1 = 'PIXEL ' / no projection is involved > CTYPE2 = 'PIXEL ' / no projection is involved > CDELT1 = .0027 / increment in mm/pixel on the detector > CDELT2 = .0027 / increment in mm/pixel on the detector > CUNIT1 = 'mm ' / physical units of the first image axis > CUNIT2 = 'mm ' / physical units of the second image axis > > The other WCS keywords (CRPIXn, CRVALn, CROTAn, CDiiijjj) would just have > default values, so there is no reason to explicitly list them > in the header. > > Bill, I think the WCS document would prefer an explicit acknowledgement that the trivial projection CAR (Cartesian) is in use. The last four characters of CTYPEn should be '-CAR'. I would therefore suggest CTYPE1 ='X----CAR' CTYPE2 ='Y----CAR' or CTYPE1 ='PIX--CAR' CTYPE2 ='PIX--CAR' I have been using a similar thing: I have a detector image which is blocked relative to the usual detector coordinates, and only covers a subset of the whole detector. So to register this image on the default detector coordinate grid I use CTYPE1 = 'DETX-CAR' / no projection is involved CTYPE2 = 'DETY-CAR' / no projection is involved CDELT1 = 2 / increment in standard pixels/image pixels CDELT2 = 2 / increment in standard pixels/image pixels CUNIT1 = 'pixel ' / Standard IPC detector pixels CUNIT2 = 'pixel ' / Standard IPC detector pixels CRVAL1 = 1.5 / Coord in standard grid of center of first image pixel CRVAL2 = 1.5 / Coord in standard grid of center of first image pixel CRPIX1 = 1.0 CRPIX2 = 1.0 - Jonathan From fitsbits-request Thu Nov 4 15:22:09 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["8660" "Thu" "4" "November" "93" "15:21:58" "EST" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "222" "Example HDUCLASn values" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27785; Thu, 4 Nov 93 15:22:09 EST Return-Path: Message-Id: <9311042021.AA20666 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: Example HDUCLASn values Date: Thu, 4 Nov 93 15:21:58 EST Example HDUCLASn keyword values in OGIP FITS files The following table gives some example values for the HDUCLASn keywords to be used for various kinds of FITS files within the Office of Guest Investigator Programs (OGIP) at GSFC/NASA. These examples are being distributed only to illustrate how the HDUCLASn hierarchy of keywords (which was proposed in a previous message to this group) may be used; These values have not been finalized within the OGIP and may be changed in the future. The particular HDUCLASn keyword values that are finally adopted within the OGIP will not be binding on any other institution. Other institutions are free to adopt any other HDUCLASn keyword values, or to reuse these same values with a different interpretation, as long as the associated HDUCLASS keyword does not have a value of 'OGIP '. Table of HDUCLASn FITS Keyword Values used by the OGIP ---------------------------------------------------------------------- HDUCLAS1 HDUCLAS2 HDUCLAS3 COMMENTS ---------------------------------------------------------------------- EVENTS A Photon event list that conforms to format defined in "The Proposed Timing FITS File Format", Angelini et al. 1993, and "Rationalized Data Files: an Approach to a Multi- Mission Data Format for High Energy Astrophysics", Corcoran et al. 1993 ALL List contains all the detected events ACCEPTED only accepted photons REJECTED only rejected photons ---------------------------------------------------------------------- LIGHTCURVE conforms to format defined in "The Proposed Timing FITS File Format", Angelini et al. 1993. TOTAL source + background ltcurv RATE counts/time interval COUNT count BKG background only RATE counts/time interval COUNT count NET net source ltcurv RATE counts/time interval COUNT count EXPOSURE exposure times vs. time TEMPORALDATA any table of non-science quantities vs. time Should conform to guidelines given by Angelini et al. where possible. HKP housekeeping parameters DELTAS in compressed format TSI temporal status intervals DELTAS TSI list in compressed format ASPECT spacecraft aspect EPHEM spacecraft orbit info EVRATE accepted, rejected, particle rates, etc. ---------------------------------------------------------------------- NOTE: DELTAS form means that entries in the table only list the name of the parameter, the time of the parameter change, and the value of the parameter at that time. ---------------------------------------------------------------------- GTI STANDARD acceptable science times screened by standard quality flags/limits at minimum giving start and stop time for interval ALL science time without regard to quality flags/limits at minimum giving start and stop time for interval ---------------------------------------------------------------------- SPECTRUM conforms to "The OGIP Spectral File Format", Arnaud et al. 1992 TOTAL gross spectrum (source + bkg) RATE counts/time interval COUNT count NET Net source spectrum RATE counts/time interval COUNT count BKG Background spectrum RATE counts/time interval COUNT count DETECTOR Detector extension for gross, source or bkg spectrum ---------------------------------------------------------------------- IMAGE TOTAL gross image NET Net source image EXPOSURE exposure map DETMAP map of detector focal plane BKG background image GENERIC miscellaneous image PRF PREDICTED predicted PRF image TOTAL total PRF image NET net PRF image VIGNETTING image of vignetting ---------------------------------------------------------------------- SRCLIST list of derived source characteristics Conforms to "Rationalized Data Files: an Approach to a Multi- Mission Data Format for High Energy Astrophysics", Corcoran et al. 1993 ---------------------------------------------------------------------- RESPONSE Conforms to "The OGIP RMF & ARF File Formats", George et al. 1992 EBOUNDS specifies energy boundaries for response matrix. SPECRESP extension contains spectral response vs. energy RSP_MATRIX REDIST "Pure" redistribution matrix w/o anything else folded in FULL Redist matrix with "everything" folded in DETECTOR Redist matrix with all detector components folded in (but NOT XRT + Filters). From fitsbits-request Thu Nov 4 15:21:04 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27776; Thu, 4 Nov 93 15:21:04 EST Return-Path: Date: Thu, 4 Nov 93 15:20:47 EST From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9311042020.AA20663 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: HDUCLASn keywords (again) Cc: pence at tetra.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU A while ago we circulated a proposal for using a hierarchical set of HDUCLASn keywords to identify the contents of a particular FITS HDU (Header Data Unit). This proposal was extensively debated within the OGIP, resulting in a modified version which is attached below for additional comments. The main changes to the proposal are the addition of the HDUCLASS, HDUDOC, and HDUVERS keywords that document the origin and meaning of the HDUCLASn keyword structure used within that FITS file. In a separate document (to be posted here shortly) we will list some example values for the HDUCLASn keywords that we plan to use to describe our data files. We would appreciate any comments on this, preferably within the next 10 days. -The OGIP FITS Working Group ------------------------------------------------------------------------- Proposed Keywords to Identify FITS File Formats AUTHOR: Office of Guest Investigator Programs FITS Working Group, NASA/GSFC PROBLEM: At the OGIP we have been developing general formats for high-energy astrophysics data which can accomodate data from different satellite observatories. However, it is not sufficient to merely USE one of the defined formats. We need a way to TELL the reader (either human or software) that we are in fact using a defined format, and to identify the format being used. The purpose of this proposal is to describe our plans for providing this information. PROPOSAL: We propose to use the following set of keywords to identify file formats: Keyword Type Comment --------- ------ ------------------------------------------- HDUCLASS string General identifier of the institution that defined this file format and the related HDUCLASn keyword values. HDUDOC string Document (preferably published) that describes the format/classification used here HDUVERS string version of the above document HDUCLASn string classification of data in the file EXAMPLE OF USAGE: HDUCLASS = 'OGIP ' / Institution that defined this file format HDUDOC = 'Arnaud et al. 1993, Legacy 3, p 32.' / format reference HDUVERS = '1.0.0 ' / version number of this format HDUCLAS1= 'SPECTRUM' / This is a spectral data format file HDUCLAS2= 'BACKGROUND' / This is a background spectrum file COMMENTS ON USAGE: A) HDUCLASn is an indexed keyword. HDUCLAS1 should provide the general data classification. HDUCLAS2-n specify hierarchical subclasses within the general classification. Such subclasses can specify either modifications to the general classification or modifications to the data contained in the file. B) The value of HDUVERS should have the form X.Y.Z, where X, Y, and Z are integers, with the following understanding: change in X: format has been completely redefined - software take note change in Y: bug fix or new keyword(s) added which may impact software change in Z: minor change, usually no impact on software C) Designers of new FITS data files have the option of either adopting a previously defined set of HDUCLASn keywords or defining a new set if the data file does not fit into an existing format definition. Should it be necessary to define a new file format, the file designer(s) should provide the values of HDUCLASS, HDUDOC, HDUVERS and HDUCLASn keywords appropriate to that format if it is desired that the format be adopted as a "standard". From fitsbits-request Thu Nov 4 17:58:55 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["16568" "Thu" "4" "November" "93" "17:58:45" "EST" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "342" "re: rewriting NAXIS2" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA28310; Thu, 4 Nov 93 17:58:55 EST Return-Path: Message-Id: <9311042258.AA20888 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 NRAO.EDU Cc: pence at tetra.gsfc.nasa.gov Subject: re: rewriting NAXIS2 Date: Thu, 4 Nov 93 17:58:45 EST Last week I wrote: > 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 ... Since then I've found a way within FITSIO to initialize the FITS ASCII tables with Spaces, even in the case where the total number of rows in the table is initially unknown. Thus users no longer have to take any special precautions to guard against any illegal NUL characters in the extension. This fix is available in the latest micro-release (V3.407) of FITSIO, available from the /software/fitsio directory in the legacy.gsfc.nasa.gov anonymous ftp account. Also, this release provides a new subroutine, ftrdef, which makes it easier to recalculate the size of the table extension after the total number of rows is known and the NAXIS2 keyword had been correctly updated. Previously, users had to calculate the size of the extension themselves and pass it to FITSIO with the ftddef subroutine. Now users can just call the ftrdef subroutine and FITSIO will recalculate the extension size itself, based on the current value of the NAXISn keywords. See the new FITSIO.DOC or .TEX file for more details. -Bill Pence From fitsbits-request Wed Nov 10 13:31:44 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1339" "Wed" "10" "November" "93" "17:57:00" "GMT" "Marcos J.J. Montes" "marcos at embezzle.stanford.edu " nil "25" "Trying to read from a FITS format exabyte tape" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11301; Wed, 10 Nov 93 13:31:44 EST Return-Path: Message-Id: <1993Nov10.175700.29945 at leland.Stanford.EDU> Organization: Stanford University Physics Dept. Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!sol.ctr.columbia.edu!spool.mu.edu!agate!headwall.Stanford.EDU!nntp.Stanford.EDU!embezzle.stanford.edu!marcos From: marcos at embezzle.stanford.edu (Marcos J.J. Montes) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Trying to read from a FITS format exabyte tape Date: Wed, 10 Nov 93 17:57:00 GMT *********PLEASE REPLY to marcos at embezzle.stanford.edu************************ Hello- I was wondering if anyone out there would be able to help. We have a problem here. There are tapes of observations that in the past have been successfully read with the command dd if=/dev/nrmt0h of=x ibs=28800 obs=2880 However, we have rearranged the system for various reasons, and the exabyte drive is attatched to a VAXStation3100 running Ultrix 4.3 . Apparently the version of dd under this Ultrix on VAXStations cannot handle ibs>16k . Does anyone have some suggestions for a way to read the tape in its current setup and be able to read all the blocks? We would hate moving the tape drive to another machine (for access reasons) but it is a possibility. Is fits always written with ibs=28800? Any help would be appreciated. Marcos ***********Please replay to marcos at embezzle.stanford.edu****************** -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Treat the earth well; |Marcos Montes it was not given to us by our parents: |qozer at leland.stanford.edu it was loaned to us by our children. |marcos at mensch.stanford.edu -Kenyan proverb |marcos at embezzle.stanford.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From fitsbits-request Wed Nov 10 16:17:47 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1482" "Wed" "10" "November" "1993" "20:42:08" "GMT" "Doug Tody" "tody at lepus.tuc.noao.edu " nil "29" "Re: Trying to read from a FITS format exabyte tape" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11672; Wed, 10 Nov 93 16:17:47 EST Return-Path: Message-Id: <1993Nov10.204208.5617 at noao.edu> Organization: National Optical Astronomy Observatories Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-1.peachnet.edu!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!noao!lepus.tuc.noao.edu!tody References: <1993Nov10.175700.29945 at leland.Stanford.EDU> Reply-To: tody at noao.edu From: tody at lepus.tuc.noao.edu (Doug Tody) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Trying to read from a FITS format exabyte tape Date: Wed, 10 Nov 1993 20:42:08 GMT In article <1993Nov10.175700.29945 at leland.Stanford.EDU>, marcos at embezzle.stanford.edu (Marcos J.J. Montes) writes: > *********PLEASE REPLY to marcos at embezzle.stanford.edu************************ > Hello- > I was wondering if anyone out there would be able to help. > We have a problem here. There are tapes of observations that in the past have > been successfully read with the command > dd if=/dev/nrmt0h of=x ibs=28800 obs=2880 > However, we have rearranged the system for various reasons, and the exabyte drive > is attatched to a VAXStation3100 running Ultrix 4.3 . Apparently the version > of dd under this Ultrix on VAXStations cannot handle ibs>16k . Does anyone > have some suggestions for a way to read the tape in its current setup and > be able to read all the blocks? We would hate moving the tape drive to another > machine (for access reasons) but it is a possibility. > > Is fits always written with ibs=28800? Any help would be appreciated. Marcos, The problem is not with DD, but with the SCSI tape interface on VAX/Ultrix systems. This system is unusual in that it has a maximum record length of 16K bytes. There may be some trick you can use to read the tape, but I doubt it. The device driver will want to return an error if the read request does not read a full tape record, but you can't read a full record without exceeding the max transfer size, so probably you are stuck. Probably you will need to move the drive to another host. Doug Tody From fitsbits-request Thu Nov 11 13:01:52 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1173" "Thu" "11" "November" "93" "17:32:32" "GMT" "Marcos J.J. Montes" "marcos at embezzle.stanford.edu " nil "22" "Exabyte tapes and VAXStations" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14926; Thu, 11 Nov 93 13:01:52 EST Return-Path: Message-Id: <1993Nov11.173232.11896 at leland.Stanford.EDU> Organization: Stanford University Physics Dept. Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-2.peachnet.edu!emory!sol.ctr.columbia.edu!spool.mu.edu!agate!headwall.Stanford.EDU!nntp.Stanford.EDU!embezzle.stanford.edu!marcos From: marcos at embezzle.stanford.edu (Marcos J.J. Montes) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Exabyte tapes and VAXStations Date: Thu, 11 Nov 93 17:32:32 GMT Thanks to all of those people who sent replies to my post: Lucio Chiapetti, Dave Wells and Doug Tody. They were all informative and included some good suggestions. It turns out that as far as I can tell (like the mtio (4) man page), the device drivers for SCSI tapes on VAX systems only handle block sizes <= 16Kbytes. I was NOT able to find a quick software fix (cp, cat, and other programs run up against the device driver maximum block size, too, so you always miss some of the data), so the best solution given time constraints was to move the tape drive to another machine. I have not tried to contact DEC about solutions, so I am not sure that there is NO software fix, but I believe that we have found the best solution. Thanks you for your time! Marcos -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Treat the earth well; |Marcos Montes it was not given to us by our parents: |qozer at leland.stanford.edu it was loaned to us by our children. |marcos at mensch.stanford.edu -Kenyan proverb | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From fitsbits-request Fri Nov 12 15:50:53 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6346" "Fri" "12" "November" "1993" "20:50:01" "GMT" "Jim Horstkotte" "jhorstko at rosebud.CV.NRAO.EDU " nil "127" "AIPS++ library release announcement - a templated C++ class library" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18280; Fri, 12 Nov 93 15:50:53 EST Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells From: jhorstko at rosebud.CV.NRAO.EDU (Jim Horstkotte) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: AIPS++ library release announcement - a templated C++ class library Date: Fri, 12 Nov 1993 20:50:01 GMT I am reposting this to sci.astro.fits (fitsbits) because the AIPS++ library includes FITS software coded in C++. -Don -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Newsgroups: alt.sci.astro.aips From: jhorstko at rosebud.CV.NRAO.EDU (Jim Horstkotte) Subject: AIPS++ library release announcement - a templated C++ class library Organization: National Radio Astronomy Observatory Date: Fri, 12 Nov 1993 18:23:18 GMT The AIPS++ consortium is pleased to announce the beta release of a portion of its C++ LIBRARY. The AIPS++ project is engaged in designing and building an "Astronomical Information Processing System," primarily for radio astronomical use. As a part of this project a support library is being developed; a portion of which is now being made available. This release is the first public release from the AIPS++ project. Current project plans anticipate a release of an operational version of AIPS++ by December of 1994. This library is being developed to support our applications, and may change in the future. This is very early in the library's life-cycle. Moreover, THE LIBRARY SHOULD BE CONSIDERED BETA LEVEL SOFTWARE. The AIPS++ consortium makes no guarantees about the library whatsoever. That having been said, we intend to continue expanding and improving the library; and any comments or bug reports will be seriously reviewed. We actively seek such comments and reports to help us improve the library. The library is available under the terms of the Free Software Foundation's (FSF) General Public License (GPL). Presently the library compiles with CFront 3.0.2 based compilers. An effort to port it to IBM's native (AIX) compiler is well underway, and may appear as a patch to this release or at least in a subsequent release. Presently the library is not portable to g++. In the longer term we will provide this, but we will not be able to work on this before 1994. Any and all ports would be very welcome of course. The largest difficulty in porting the library is dealing with templates, of which the library makes heavy use. The library includes: 1. Math: An arbitrary n-dimensional Array class, with Vector, Matrix, and Cube specializations. All the normal arithmetic operations are available (+,-,*,/,+=,-=,*=,/=) in an element by element fashion, as well as the normal "linear algebra" multiplications (dot,cross,matrix multiply). Presently the logical operators (==,!=,...) are available only in forms which return a single boolean. Subsequent releases of the library will provide "mask" results. The usual transcendental functions are available, as well as simple statistics and LU decomposition. Specialized FFT and Gridding (onto a regular grid) and other miscellaneous classes and functions (e.g. to convert to and from Khoros Viff format) exist. A templated Complex class and a Random number class, originally from GNU libg++, are provided. A tutorial document for the Array classes is in the distribution. 2. Tables: An AIPS++ table logically consists of a set of rows and columns and a header. The content of each column is described by a "Field" object. The fields in a table may be a "scalar" (integral type, float, double, Complex, DComplex, String), or an Array of scalars, or a table itself. The header consists of "keyword=value" pairs, where the value may be of any field type. The array and table fields may be stored either directly or indirectly; in the latter case the size and shape may vary from row to row. The tables may be sorted, searched, and selected upon using C++ operators. Tables may be iterated through in various ways. Presently the tables reside entirely in memory; subsequent releases will remove this restriction. A document describing the table system is available. A (very!) preliminary table browser written using the InterViews toolkit is available. 3. Containers: We have some containers (Map, singly and double linked lists, Block) - these are all templated. 4. Other Classes: We use the libg++ String class (slightly modified). We provide an exception implementation which is nearly plug compatible with the ARM standard, and should be easily replaced with "real" exceptions when available. There is an RTTI mechanism which allows down casts in the face of multiple inheritance. There is also a simple persistence mechanism. 5. Other Tools: We have a "perl" based documentation extractor. It uses an SGML based language to structure documentation within C++ comments, and generates Texinfo. 6. A preliminary set of FITS (an astronomical interchange format) classes are available, with wrapper functions to convert AIPS++ arrays to and from FITS. Subsequent releases will have greatly improved support. 7. And more! The release can be obtained via anonymous ftp. The anonymous ftp host is aips2.cv.nrao.edu . The anonymous ftp directory is /pub/aips++/RELEASED/libaips-3 . We anticipate that we will provide patches to the library, and new releases from time to time when major new features are available. Any bugs, installation problems, or other difficulties should be emailed to aips2-bugs at nrao.edu. There is an email reflector for discussion of the library (aips2-lib) as well as one for general announcements (aips2). To be added or deleted from either reflector, send email to aips2-request at nrao.edu. Additionally, information is available from the World Wide Web at: http://info.cv.nrao.edu/html/computing/aips++/html/aips++.html Finally, communications with the AIPS++ project may also be directed to: Internet email: aips2-request at nrao.edu. Postal address: AIPS++ Project Office National Radio Astronomy Observatory 520 Edgemont Road Charlottesville, VA 22903-2475 USA We hope this library proves useful to you, and we seek suggestions on how to improve it. -- 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 Nov 15 14:46:35 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["184" "" "15" "November" "1993" "14:04" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "13" "New FITS Support Office Telephone Number" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA23912; Mon, 15 Nov 93 14:46:35 EST Return-Path: Message-Id: <15NOV199314043724 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.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: New FITS Support Office Telephone Number Date: 15 Nov 1993 14:04 EDT The FITS Support Office telephone number has been changed. The new number is +1-301-441-4205 Please make a note of it. Barry Schlesinger NSSDC/NOST FITS Support Office From fitsbits-request Tue Nov 16 16:16:00 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["100" "Tue" "16" "November" "1993" "20:48:05" "GMT" "Tom Pauls" "pauls at altas.nrl.navy.mil " nil "4" "FITS<->netCDF" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27689; Tue, 16 Nov 93 16:16:00 EST Return-Path: Message-Id: Organization: Naval Research Laboratory Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!ra!atlas!pauls Reply-To: pauls at atlas.nrl.navy.mil From: pauls at altas.nrl.navy.mil (Tom Pauls) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS<->netCDF Date: Tue, 16 Nov 1993 20:48:05 GMT Is there a FITS to netCDF conversion program available, or is anyone working on one? - Tom From fitsbits-request Fri Nov 19 07:08:58 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["11599" "" "18" "November" "1993" "15:24" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "213" "FITS basics and information (periodic posting)" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04497; Fri, 19 Nov 93 07:08:58 EST Return-Path: Message-Id: <18NOV199315245584 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!saimiri.primate.wisc.edu!ames!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: 18 Nov 1993 15:24 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 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. Two proposed extensions, binary tables (type name BINTABLE) and images, like the data in the primary HDU but in an extension (type name IMAGE) are currently under consideration for endorsement by the IAU FITS Working Group. A draft text of conventions for World Coordinates is currently under community review. It proposes rules for relating a FITS data array to the physical quantities the numbers represent, with detailed discussion of projections from the celestial sphere to the array plane. 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. 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 a draft of the current proposal for world coordinate system conventions now under community review. 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 7:30 a. m. - 4:30 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-441-4205 fits at nssdca.gsfc.nasa.gov NCF::FITS From fitsbits-request Fri Nov 19 21:32:29 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1086" "Sat" "20" "November" "1993" "02:20:51" "GMT" "Pat Murphy" "pmurphy at orangutan.CV.NRAO.EDU " nil "21" "Re: FITS<->netCDF" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05194; Fri, 19 Nov 93 21:32:29 EST Return-Path: Message-Id: Organization: National Radio Astronomy Observatory, Charlottesville, Virginia Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!murdoch!murdoch.acc.virginia.edu!pmurphy References: From: pmurphy at orangutan.CV.NRAO.EDU (Pat Murphy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS<->netCDF Date: Sat, 20 Nov 1993 02:20:51 GMT In article pauls at altas.nrl.navy.mil (Tom Pauls) writes: TP> Is there a FITS to netCDF conversion program available, or is TP> anyone working on one? There is a FITS to pgm converter (email me and I'll poke around, don't remember offhand where it came from) but it can only handle a subset of the FITS standard (no extensions, groups, ascii or binary tables). If that's enough, and if there is a ppmtonetcdf, it might be worth pursuing. - 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 | | WWW: "ftp://orangutan.cv.nrao.edu/pub/html/pm-home.html" | | "I don't believe in the no-win scenario" --- James T. Kirk | ========================================================================== From fitsbits-request Sat Nov 20 16:20:59 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["462" "Sat" "20" "November" "93" "16:14:48" "-0500" "chaganti at ssl.DNET.NASA.GOV" "chaganti at ssl.DNET.NASA.GOV" nil "20" "Re: FITS<->netCDF" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06744; Sat, 20 Nov 93 16:20:59 EST Return-Path: Message-Id: <9311202114.AA21030 at east.gsfc.nasa.gov> From: chaganti at ssl.DNET.NASA.GOV Sender: fitsbits-request at fits.CV.NRAO.EDU To: " fitsbits at fits.cv.nrao.edu" at EAST.DNET.NASA.GOV Subject: Re: FITS<->netCDF Date: Sat, 20 Nov 93 16:14:48 -0500 If you have IDL. IDL supports FITS,netCDF,HDF,... Try reading FITS using IDL and store them in netCDF using IDL. another way is NCSA tool kit has functions to transfer FITS->HDF. Many of NCSA tools work efficiently for netCDF. check out whether there is any HDF->netCDF there? the NCSA ftp address is ftp.ncsa.uiuc.edu hope it helps kris --------- Kris Chaganti Dept. of Physics, U. of Alabama in Huntsville, Huntsville, Al 35899 chaganti at ssl.msfc.nasa.gov From fitsbits-request Sun Nov 21 18:45:57 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["481" "Sun" "21" "November" "1993" "23:16:52" "GMT" "anderson at stsci.edu" "anderson at stsci.edu" nil "13" "Converting FITS to other image formats?" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA08671; Sun, 21 Nov 93 18:45:57 EST Return-Path: Message-Id: <1993Nov21.181652.1 at stsci.edu> Organization: Space Telescope Science Institute Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!howland.reston.ans.net!agate!ames!ncar!noao!stsci!stosc!anderson From: anderson at stsci.edu Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Converting FITS to other image formats? Date: Sun, 21 Nov 1993 23:16:52 GMT I hope this isn't a FAQ (didn't see it in the "FITS Basics and Info" posting): Does anyone know of any tools for converting FITS image files to any of the more common display standards, such as GIF, TIFF, JPEG, etc.? Thanks in advance, ------------------------------------------------------------------------ Chris Anderson Science Operations Specialist ANDERSON at STSCI.EDU Science Planning & Scheduling Computer Sciences Corporation Space Telescope Science Institute From fitsbits-request Mon Nov 22 06:18:04 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1352" "" "22" "November" "93" "10:21:31" "GMT" "seds at Violet.CCIT.Arizona.EDU" "seds at Violet.CCIT.Arizona.EDU" nil "45" "NEW SPACE FTP/GOPHER" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10824; Mon, 22 Nov 93 06:18:04 EST Return-Path: Article-I.D.: Violet.00975E6F.238EF5F2 Message-Id: <00975E6F.238EF5F2 at Violet.CCIT.Arizona.EDU> Organization: University of Arizona Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-2.peachnet.edu!emory!ogicse!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!news.cs.indiana.edu!arizona.edu!Violet.CCIT.Arizona.EDU!SEDS Reply-To: seds at Violet.CCIT.Arizona.EDU From: seds at Violet.CCIT.Arizona.EDU Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: NEW SPACE FTP/GOPHER Date: 22 Nov 93 10:21:31 GMT ************************************************* * NEW SPACE-RELATED FTP/GOPHER SITE AT * *** SEDS.LPL.ARIZONA.EDU *** **************** 128.196.64.66 ****************** A new space-related FTP + and + GOPHER site has been started!!! The site is maintained by the University of Arizona chapter of SEDS (Students for the Exploration and Development of Space) Currently, this site is offering: +IMAGES in GIF, JPG, FITS, TIFF and other formats +ANIMATIONS (space and weather) in FLI, FLC, anim, quicktime +SATELLITE elements in molczan, tle and other two and three-line formats +PROGRAMS and binary executables for most platforms +INFORMATION on current programs like the DC-X +MISCELLANEOUS items that don't fit any category! OVER 500 MEGS OF STUFF!!! (with much room to expand!) We are the American mirror for the archives at: ftp.univ-rennes1.fr and ftp.cnam.fr If you don't have access to a gopher client, use ours! Telnet to seds.lpl.arizona.edu and log in as gopher with gopher as your password. We've been experimenting for a while and we feel that we are now ready to go on line. This is our first time running such an archive and we welcome any suggestions or contributions to the site. Send mail to ftp at seds.lpl.arizona.edu From fitsbits-request Mon Nov 22 09:01:19 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["775" "Mon" "22" "November" "1993" "08:59:18" "-0500" "Bruce O'Neel" "oneel at athena.gsfc.nasa.gov " nil "24" "Re: Converting FITS to other image formats?" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10924; Mon, 22 Nov 93 09:01:19 EST Return-Path: Message-Id: In-Reply-To: <1993Nov21.181652.1 at stsci.edu> from "anderson at stsci.edu" at Nov 21, 93 11:16:52 pm X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 775 From: oneel at athena.gsfc.nasa.gov (Bruce O'Neel) Sender: fitsbits-request at fits.CV.NRAO.EDU To: anderson at stsci.edu Cc: fitsbits at fits.CV.NRAO.EDU Subject: Re: Converting FITS to other image formats? Date: Mon, 22 Nov 1993 08:59:18 -0500 (EST) > > I hope this isn't a FAQ (didn't see it in the "FITS Basics and Info" > posting): > > Does anyone know of any tools for converting FITS image files to any of > the more common display standards, such as GIF, TIFF, JPEG, etc.? > Hi, The PBM toolkit has a fits reader and a number of different writers (gif and tiff at least). Available at better FTP sites. I've written a fitstoppm converter as well using Bill Pence's FTISIO library which seems to work ok. It seems to work with more fits images than the PBM toolkit version. bruce -- As I understand it from eyewitness reports, the Scheme initiation ritual is to sit in a circle around the Common Lisp manual and make gagging sounds and jokes about how thick it is. -- Scott E. Fahlman sef+ at cs.cmu.edu From fitsbits-request Mon Nov 22 22:00:35 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["140" "Mon" "22" "November" "93" "22:02:56" "-0500" "Julian Daniels" "daniels at msx3.pha.jhu.edu " nil "3" "" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12185; Mon, 22 Nov 93 22:00:35 EST Return-Path: Message-Id: <9311230302.AA05780 at msx3.pha.jhu.edu> From: daniels at msx3.pha.jhu.edu (Julian Daniels) Sender: fitsbits-request at fits.CV.NRAO.EDU Apparently-To: fitsbits at nrao.edu Date: Mon, 22 Nov 93 22:02:56 -0500 try spacecraft attitude determination and control ed. by james wertz > published by kluwer academic publishers : boston > julian daniels From fitsbits-request Wed Nov 24 08:47:16 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["27391" "Wed" "24" "November" "1993" "13:31:53" "GMT" "David Robinson" "drtr at mail.ast.cam.ac.uk " nil "798" "Re: Converting FITS to other image formats?" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA15983; Wed, 24 Nov 93 08:47:16 EST Return-Path: Message-Id: <1993Nov24.133153.15184 at infodev.cam.ac.uk> Organization: Institute of Astronomy, Cambridge Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!gatech!europa.eng.gtefsd.com!uunet!pipex!pavo.csi.cam.ac.uk!cast0.ast.cam.ac.uk!drtr References: <1993Nov21.181652.1 at stsci.edu> 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: Converting FITS to other image formats? Date: Wed, 24 Nov 1993 13:31:53 GMT In article <1993Nov21.181652.1 at stsci.edu>, anderson at stsci.edu writes: |> I hope this isn't a FAQ (didn't see it in the "FITS Basics and Info" |> posting): |> |> Does anyone know of any tools for converting FITS image files to any of |> the more common display standards, such as GIF, TIFF, JPEG, etc.? |> |> Thanks in advance, |> |> ------------------------------------------------------------------------ |> Chris Anderson Science Operations Specialist |> ANDERSON at STSCI.EDU Science Planning & Scheduling |> Computer Sciences Corporation |> Space Telescope Science Institute A good solution is to use a patched version of the xv program. xv version 3.00a can load and save GIF, PM, PBM (+PGM PPM etc.) X11 bitmap Sun Rasterfile, BMP, IRIS, JPEG, TIFF and PostScript. xv is available by anonymous ftp from ftp.cis.upenn.edu in /pub/xv/xv-3.00a.tar.Z. At the moment FITS support in xv is provided by a set of patches. The FITS support is more robust than that provided by the pbm library; it will work on any machine irrespective of its floating point format - including Vax VMS. The patches are available by anonymous ftp from ftp-hst.ast.cam.ac.uk in /pub/software/xv-patches/FITS-v2.tar.Z. David Robinson. (drtr at mail.ast.cam.ac.uk) From fitsbits-request Wed Nov 24 11:31:43 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["792" "" "24" "November" "1993" "16:17:28" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "12" "Re: Converting FITS to other image formats?" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16364; Wed, 24 Nov 93 11:31:43 EST Return-Path: Message-Id: <2d01eo$7ss at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!europa.eng.gtefsd.com!library.ucla.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: <1993Nov21.181652.1 at stsci.edu> <1993Nov24.133153.15184 at infodev.cam.ac.uk> 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: Converting FITS to other image formats? Date: 24 Nov 1993 16:17:28 GMT In article <1993Nov24.133153.15184 at infodev.cam.ac.uk> drtr at mail.ast.cam.ac.uk (David Robinson) writes: >xv version 3.00a can load and save GIF, PM, PBM (+PGM PPM etc.) X11 bitmap >Sun Rasterfile, BMP, IRIS, JPEG, TIFF and PostScript. xv is available by >anonymous ftp from ftp.cis.upenn.edu in /pub/xv/xv-3.00a.tar.Z. Folks who get xv 3.00 should take care to read the copyright statements which accompany it. Site managers may not install it unless they purchase the right to do so. -- -- -- -- -- -+- -- -- -- -- -- -- -- -+- -- -- -- -- -- Steve Allen | "Shameless Morris Enthusiasm" | sla at lick.ucsc.edu UCO/Lick Observatory | Yep, that's me. 6 up for | +1 408 459 3046 Santa Cruz, CA 95064 | Orange in Bloom, Sherborne, eh? | Seabright Morris From fitsbits-request Wed Nov 24 13:18:22 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6141" "Wed" "24" "November" "1993" "17:12:49" "GMT" "Cristy" "cristy at eplrx7.es.duPont.com " nil "154" "Re: Converting FITS to other image formats?" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA16827; Wed, 24 Nov 93 13:18:22 EST Return-Path: Message-Id: <1993Nov24.171249.26417 at eplrx7.es.duPont.com> Organization: DuPont Central Research & Development Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!gatekeeper.es.dupont.com!eplrx7!cristy References: <1993Nov21.181652.1 at stsci.edu> <1993Nov24.133153.15184 at infodev.cam.ac.uk> <2d01eo$7ss at darkstar.UCSC.EDU> From: cristy at eplrx7.es.duPont.com (Cristy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Converting FITS to other image formats? Date: Wed, 24 Nov 1993 17:12:49 GMT In article <2d01eo$7ss at darkstar.UCSC.EDU> sla at umbra.UCSC.EDU (Steve Allen) writes: >Folks who get xv 3.00 should take care to read the copyright statements >which accompany it. Site managers may not install it unless they >purchase the right to do so. Try ImageMagick. It can display and convert FITS (and other images formats) but is not encumbered with a restrictive license. --- ImageMagick is a collection of X11 image processing and display utilities. It is available on ftp.x.org as contrib/ImageMagick.tar.Z. Display Display is a machine architecture independent image processing and display program. It can display an image on any workstation display running an X server. Display first determines the hardware capabilities of the workstation. If the number of unique colors in the image is less than or equal to the number the workstation can support, the image is displayed in an X window. Otherwise the number of colors in the image is first reduced to match the color resolution of the workstation before it is displayed. This means that a continuous-tone 24 bits/pixel image can display on a 8 bit pseudo-color device or monochrome device. In most instances the reduced color image closely resembles the original. Alternatively, a monochrome or pseudo-color image can display on a continuous-tone 24 bits/pixels device. Import Import reads an image from any visible window on an X server and outputs it as an image file. You can capture a single window, the entire screen, or any rectangular portion of the screen. You can use display (see display(1)) utility for redisplay, printing, editing, formatting, archiving, image processing, etc. of the captured image. The target window can be specified by id, name, or may be selected by clicking the mouse in the desired window. If you press a button and then drag, a rectangle will form which expands and contracts as the mouse moves. To save the portion of the screen defined by the rectangle, just release the button. The keyboard bell is rung once at the beginning of the screen capture and twice when it completes. Animate Animate displays a sequence of images on any workstation display running an X server. Animate first determines the hardware capabilities of the workstation. If the number of unique colors in an image is less than or equal to the number the workstation can support, the image is displayed in an X window. Otherwise the number of colors in the image is first reduced to match the color resolution of the workstation before it is displayed. This means that a continuous-tone 24 bits/pixel image can display on a 8 bit pseudo-color device or monochrome device. In most instances the reduced color image closely resembles the original. Alternatively, a monochrome or pseudo-color image sequence can display on a continuous-tone 24 bits/pixels device. Montage Montage creates a composite image by combining several separate images. The images are tiled on the composite image with the name of the image optionally appearing just below the individual tile. Mogrify Mogrify transforms an image or a sequence of images. These transforms include image scaling, image rotation, color reduction, and others. The transmogrified image overwrites the original image. Convert Convert converts an input file using one image format to an output file with a differing image format. By default, the image format is determined by it's magic number. To specify a particular image format, precede the filename with an image format name and a colon (i.e. ps:image) or specify the image type as the filename suffix (i.e. image.ps). Specify file as - for standard input or output. If file has the extension .Z, the file is decoded with uncompress. Convert recognizes the following image formats: Tag Description ---------------------------------------------------- ALPHA Raw alpha bytes AVS AVS X image file BMP Microsoft Windows bitmap image file CMYK Raw cyan, magenta, yellow, and black bytes EPS Adobe Encapsulated Postscript FAX Group 3 FITS Flexible Image Transport System GIF Compuserve Graphics image file GRAY Raw gray bytes JPEG MIFF Magick image file format MTV PCX ZSoft IBM PC Paintbrush file PICT Apple Macintosh QuickDraw/PICT file PNM Portable bitmap PS Adobe PostScript file PS2 Adobe PostScript Level II file RGB Raw red, green, and blue bytes RLE Utah Raster Toolkit SUN SUN raster TGA Truevision Targa image file TEXT raw text file; read only TIFF Tagged Image File Format VICAR VIFF Khoros Visualization image file. X select image from X server screen XC constant image of X server background color XBM X11 bitmap XPM X11 pixmap XWD X11 window dump YUV Raw Y, U, and V bytes Combine Combine combines images to create new images. Segment Segment segments an image by analyzing the histograms of the color components and identifying units that are homogeneous with the fuzzy c-means technique. The scale-space filter analyzes the histograms of the three color components of the image and identifies a set of classes. The extents of each class is used to coarsely segment the image with thresholding. The color associated with each class is determined by the mean color of all pixels within the extents of a particular class. Finally, any unclassified pixels are assigned to the closest class with the fuzzy c- means technique. -- cristy at dupont.com From fitsbits-request Thu Nov 25 05:39:52 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["13798" "Thu" "25" "November" "93" "09:27:25" "GMT" "Daniel Briggs" "dbriggs at Mr-Hyde.aoc.nrao.edu " nil "486" "Re: Converting FITS to other image formats?" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18847; Thu, 25 Nov 93 05:39:52 EST Return-Path: Message-Id: <1993Nov25.092725.8168 at Mr-Hyde.aoc.nrao.edu> Organization: National Radio Astronomy Observatory, Socorro NM Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-1.peachnet.edu!umn.edu!lynx.unm.edu!Mr-Hyde.aoc.nrao.edu!dbriggs References: <1993Nov21.181652.1 at stsci.edu> <1993Nov24.133153.15184 at infodev.cam.ac.uk> 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: Converting FITS to other image formats? Date: Thu, 25 Nov 93 09:27:25 GMT In article <1993Nov24.133153.15184 at infodev.cam.ac.uk> drtr at mail.ast.cam.ac.uk (David Robinson) writes: >A good solution is to use a patched version of the xv program. >xv version 3.00a can load and save GIF, PM, PBM (+PGM PPM etc.) X11 bitmap >Sun Rasterfile, BMP, IRIS, JPEG, TIFF and PostScript. xv is available by >anonymous ftp from ftp.cis.upenn.edu in /pub/xv/xv-3.00a.tar.Z. > >At the moment FITS support in xv is provided by a set of patches. >The FITS support is more robust than that provided by the pbm library; >it will work on any machine irrespective of its floating point format - >including Vax VMS. The xv patches are good stuff. But for completeness, here's a hacked up version of fitstopgm that I cobbled together. I never got around to adding architecture independent floating point, but if you're on something that speaks IEEE-754, it works just fine. -----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 C-23367 | New Mexico Tech / National Radio Astronomy Observatory | DoD #387 | P.O. Box O / Socorro, NM 87801 (505) 835-7391 | | Dart: MC Ot+W H 3 Y L+ W C+ I++ T++ A+ H+ S+ V+ P++/P B+ | From fitsbits-request Fri Nov 26 16:46:11 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["774" "" "26" "November" "93" "13:36:19" "-0700" "jmcgaha at pimacc.pima.edu" "jmcgaha at pimacc.pima.edu" nil "14" "Converting FITS with MIRA" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA20979; Fri, 26 Nov 93 16:46:11 EST Return-Path: Message-Id: <1993Nov26.133620.8913 at pimacc.pima.edu> Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!organpipe.uug.arizona.edu!CS.Arizona.EDU!pimacc.pima.edu!jmcgaha From: jmcgaha at pimacc.pima.edu Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Converting FITS with MIRA Date: 26 Nov 93 13:36:19 -0700 There is a much nicer way to convert FITS to TIFF. Try using MIRA. I use MIRA for all my image processing.I will never use IRAF again, MIRA is so much easier to use ,faster (on a 486), does everything that IRAF does except for some of the more obscure IRAF packages,and has a better user interface. ********************************************************************************* | | James McGaha | Grasslands Observatory | Adjunct Faculty Voice (602)760-2100 | 5100 Sabino Foothills | Pima Community College jmcgaha at pimacc.pima.edu | Tucson, Az 85715 | | | ****************************************************************************** From fitsbits-request Fri Nov 26 18:46:05 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1277" "Fri" "26" "November" "1993" "23:16:14" "GMT" "Dominique Beauchamp" "beaucham at leo.ulaval.ca " nil "35" "Re: Converting FITS with MIRA" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA21037; Fri, 26 Nov 93 18:46:05 EST Return-Path: Message-Id: Organization: Sun Microsystems, Inc. Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!europa.eng.gtefsd.com!uunet!newsflash.concordia.ca!sifon!athena.ulaval.ca!leo!beaucham References: <1993Nov26.133620.8913 at pimacc.pima.edu> Reply-To: beaucham at leo.ulaval.ca From: beaucham at leo.ulaval.ca (Dominique Beauchamp) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Converting FITS with MIRA Date: Fri, 26 Nov 1993 23:16:14 GMT In article 8913 at pimacc.pima.edu, jmcgaha at pimacc.pima.edu () writes: > There is a much nicer way to convert FITS to TIFF. Try using MIRA. I > use MIRA for all my image processing.I will never use IRAF again, > MIRA is so much easier to use ,faster (on a 486), does everything that IRAF > does except for some of the more obscure IRAF packages,and has a better user > interface. > > Probably you didn't use IRAF often... Or MIRA is VERY powerful! Why did you use IRAF? Your job? Just a question... Dominique Beauchamp Lab d'astrophysique U. Laval, Quebec City --- ---------------------------------------------------------------------- Dominique Beauchamp | "Fais ce que peux", telle est ma devise! Labo. d'astrophysique, | Universite Laval | developpeur de / developper of Quebec | V i e w F I T S G1K 7P4 | Afficheur FITS pour OS/2 PM | FITS viewer for OS/2 PM beaucham at phy.ulaval.ca | | Prochaine/next version: Faites un/do a "finger" | Janvier ou fevrier 94 sur mon compte! | January or February 94 on my account! | | Surveillez/watch: ftp.cdrom.com | V i e w F I T S est du domaine public/is freeware. From fitsbits-request Sat Nov 27 05:18:31 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["8075" "" "27" "November" "1993" "09:01:30" "GMT" "Martin Shepherd" "mcs at goblin.caltech.edu " nil "192" "FITS table version numbers." "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA22048; Sat, 27 Nov 93 05:18:31 EST Return-Path: Message-Id: <2d751a$l2u at gap.cco.caltech.edu> Organization: California Institute of Technology, Pasadena Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!sgiblab!swrinde!elroy.jpl.nasa.gov!nntp-server.caltech.edu!goblin!mcs From: mcs at goblin.caltech.edu (Martin Shepherd) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS table version numbers. Date: 27 Nov 1993 09:01:30 GMT For the sake of argument, say that one has a FITS file containing a number of table extensions which all have the same EXTNAME name, but some are represented as ASCII tables and others as binary tables. My question is should the EXTVER numbers be distinct regardless of the representation of the table, or should the ASCII table versions follow a different sequence of EXTVER numbers than the binary table versions? Until today my assumption had been that ASCII and binary table extensions were effectively just specific implementations of a generic (non-instantiable) table extension, and that regardless of the representation, the EXTVER numbers would be distinct if the tables had the same EXTNAME and EXTLEV values. Having now encountered a FITS file that doesn't fit this point of view, I am now questioning the validity of this assumption before making the necessary modifications to my software. Martin Shepherd (mcs at phobos.caltech.edu) From fitsbits-request Sun Nov 28 20:13:07 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2245" "" "28" "November" "93" "15:21:08" "-0700" "jmcgaha at pimacc.pima.edu" "jmcgaha at pimacc.pima.edu" nil "57" "Re: Converting FITS with MIRA" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03519; Sun, 28 Nov 93 20:13:07 EST Return-Path: Message-Id: <1993Nov28.152109.8917 at pimacc.pima.edu> Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!asuvax!ncar!noao!CS.Arizona.EDU!pimacc.pima.edu!jmcgaha References: <1993Nov26.133620.8913 at pimacc.pima.edu> From: jmcgaha at pimacc.pima.edu Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Converting FITS with MIRA Date: 28 Nov 93 15:21:08 -0700 In article , beaucham at leo.ulaval.ca (Dominique Beauchamp) writes: > In article 8913 at pimacc.pima.edu, jmcgaha at pimacc.pima.edu () writes: >> There is a much nicer way to convert FITS to TIFF. Try using MIRA. I >> use MIRA for all my image processing.I will never use IRAF again, >> MIRA is so much easier to use ,faster (on a 486), does everything that IRAF >> does except for some of the more obscure IRAF packages,and has a better user >> interface. >> >> > > Probably you didn't use IRAF often... Or MIRA is VERY powerful! Why > did you use IRAF? Your job? Just a question... The answer to both of your statements is yes. I used IRAF\MIRA to do data reduction of BVR images, taken with the 90"telescope at Kitt Peak, to produce true color tri-color images of planetary nebulae. No, it is not my job, just a love of astronomy. I also use a 24" telescope with a 1024x1024 ccd camera at my obseratory. > > Dominique Beauchamp > Lab d'astrophysique > U. Laval, > Quebec City > > --- > ---------------------------------------------------------------------- > Dominique Beauchamp | "Fais ce que peux", telle est ma devise! > Labo. d'astrophysique, | > Universite Laval | developpeur de / developper of > Quebec | V i e w F I T S > G1K 7P4 | Afficheur FITS pour OS/2 PM > | FITS viewer for OS/2 PM > beaucham at phy.ulaval.ca | > | Prochaine/next version: > Faites un/do a "finger" | Janvier ou fevrier 94 > sur mon compte! | January or February 94 > on my account! | > | Surveillez/watch: ftp.cdrom.com > | > V i e w F I T S est du domaine public/is freeware. > > -- ********************************************************************************* | | James McGaha | Grasslands Observatory | Adjunct Faculty Voice (602)760-2100 | 5100 Sabino Foothills | Pima Community College jmcgaha at pimacc.pima.edu | Tucson, Az 85715 | | | ****************************************************************************** From fitsbits-request Mon Nov 29 07:42:12 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["571" "Sun" "28" "November" "1993" "22:50:00" "GMT" "RALPH WARD" "ralph.ward at pubcon.fort-worth.tx.us " nil "19" "Converting FITS with MIRA" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04696; Mon, 29 Nov 93 07:42:12 EST Return-Path: Message-Id: <93112906363817 at pubcon.fort-worth.tx.us> Organization: Public Connection BBS 817-738-7336 Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!agate!iat.holonet.net!pubcon!ralph.ward From: ralph.ward at pubcon.fort-worth.tx.us (RALPH WARD) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Converting FITS with MIRA Date: Sun, 28 Nov 1993 22:50:00 GMT James said: [deleted] JM>Date: 26 Nov 93 13:36:19 -0700 JM>Message-ID: <1993Nov26.133620.8913 at pimacc.pima.edu> [deleted] JM>There is a much nicer way to convert FITS to TIFF. Try using MIRA. I [deleted\] JM>James McGaha | Grasslands Observatory | Adjunct Faculty JM>Voice (602)760-2100 | 5100 Sabino Foothills | Pima Community College JM>jmcgaha at pimacc.pima.edu | Tucson, Az 85715 | Hi, I do not have FTP access, where can I get MIRA? Thanks, Ralph.ward at pubcon.fort-worth.tx.us * SLMR 2.1a * Faster than light is like bigger than green. From fitsbits-request Tue Nov 30 02:48:06 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1417" "" "29" "November" "93" "22:35:26" "-0700" "jmcgaha at pimacc.pima.edu" "jmcgaha at pimacc.pima.edu" nil "35" "Re: Converting FITS with MIRA" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01087; Tue, 30 Nov 93 02:48:06 EST Return-Path: Message-Id: <1993Nov29.223526.8921 at pimacc.pima.edu> Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!cs.utexas.edu!uunet!organpipe.uug.arizona.edu!CS.Arizona.EDU!pimacc.pima.edu!jmcgaha References: <93112906363817 at pubcon.fort-worth.tx.us> From: jmcgaha at pimacc.pima.edu Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Converting FITS with MIRA Date: 29 Nov 93 22:35:26 -0700 In article <93112906363817 at pubcon.fort-worth.tx.us>, ralph.ward at pubcon.fort-worth.tx.us (RALPH WARD) writes: > James said: > > [deleted] > JM>Date: 26 Nov 93 13:36:19 -0700 > JM>Message-ID: <1993Nov26.133620.8913 at pimacc.pima.edu> > [deleted] > JM>There is a much nicer way to convert FITS to TIFF. Try using MIRA. I > [deleted\] > JM>James McGaha | Grasslands Observatory | Adjunct Faculty > JM>Voice (602)760-2100 | 5100 Sabino Foothills | Pima Community College > JM>jmcgaha at pimacc.pima.edu | Tucson, Az 85715 | > > > Hi, I do not have FTP access, where can I get MIRA? > > Thanks, > Ralph.ward at pubcon.fort-worth.tx.us > > * SLMR 2.1a * Faster than light is like bigger than green. -- MIRA is a commercial program that costs $695. It can be order from : Axiom Research 1304 E. 8th St Tucson,Az 85719 (602) 791-2864 ********************************************************************************* | | James McGaha | Grasslands Observatory | Adjunct Faculty Voice (602)760-2100 | 5100 Sabino Foothills | Pima Community College jmcgaha at pimacc.pima.edu | Tucson, Az 85715 | | | ****************************************************************************** From fitsbits-request Tue Nov 30 13:47:21 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["452" "" "30" "November" "1993" "13:13" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "10" "Plans for a FAQ" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02819; Tue, 30 Nov 93 13:47:21 EST Return-Path: Message-Id: <30NOV199313132174 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!udel!gatech!swrinde!elroy.jpl.nasa.gov!ames!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: Plans for a FAQ Date: 30 Nov 1993 13:13 EDT We would like to promote the FITS basics and information posting to a full fledged FAQ. As part of the process, we would like to know what additional information or other changes readers would like to have included. Also, the posting has now reached the size where it would be best divided into two. This division will begin in December. Suggestions as to how best to split it are welcome. Barry Schlesinger NOST FITS Support Office