From fitsbits-request Thu Oct 1 02:50:59 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1542" "Thu" "1" "October" "92" "05:51:27" "GMT" "Daniel Briggs" "dbriggs at zia.aoc.nrao.edu " nil "29" "Re: FITS to GIF Image Conversion?" "^From:" nil nil "10"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14866; Thu, 1 Oct 92 02:50:59 EDT Return-Path: Message-Id: <1992Oct1.055127.18231 at zia.aoc.nrao.edu> Organization: National Radio Astronomy Observatory, Socorro NM Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!umn.edu!lynx!zia.aoc.nrao.edu!dbriggs References: <1992Sep29.043951.13504 at news.iastate.edu> <193 at neftis.CSS.GOV> From: dbriggs at zia.aoc.nrao.edu (Daniel Briggs) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: FITS to GIF Image Conversion? Date: Thu, 1 Oct 92 05:51:27 GMT In article <193 at neftis.CSS.GOV> stevem at neftis.CSS.GOV (Steve Masters) writes: >In article <1992Sep29.043951.13504 at news.iastate.edu> F1.DAO at isumvs.iastate.edu (David Oesper) writes: >>Is there a FITS to GIF conversion program available for the IBM or >>Macintosh? > >The PBMPLUS suite of programs can get you from FITS to GIF. I believe >there is a port for the IBM-PC...perhaps others on the net can verify >this. Well, the FITS reader built into the PBM+ package is very primitive. I have a slightly enhanced version that I wrote for my own purposes. In particular, it handles floating point values for machines which use IEEE-754, (I think that the 80x87 hardware uses this, so unless the byte order is screwed up, it might work on a PC with hardware floating point.) I added a prescan for scaling constants, in the absence of DATAMIN & DATAMAX, forceable min and max, and cleaned up the scaling code, which was incorrect for non-identity BZER & BSCALE. I make no claim that this code is suitable for any purpose other than that for which I wrote it. Eventually I'll get around to sending it back to Jef, but I wanted to see if routine use turned up any more problems. However, if anyone wants the code now, I'll send it to them. -- | Daniel Briggs (dbriggs at nrao.edu) | USPA B-14993 | New Mexico Tech / National Radio Astronomy Observatory | DoD #387 | P.O. Box O / Socorro, NM 87801 (505) 835-7391 | Support the League for Programming Freedom (info from league at prep.ai.mit.edu) From fitsbits-request Thu Oct 1 13:25:45 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["873" "Thu" "1" "October" "1992" "16:49:00" "GMT" "301" "landsman at stars.gsfc.nasa.gov (Wayne Landsman -286-3625)" nil "22" "Re: triple precision keywords" "^From:" nil nil "10"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA15637; Thu, 1 Oct 92 13:25:45 EDT Return-Path: Message-Id: <1OCT199212490103 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!spool.mu.edu!agate!ames!nsisrv!stars.gsfc.nasa.gov!landsman References: From: landsman at stars.gsfc.nasa.gov (Wayne Landsman (301)-286-3625) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: triple precision keywords Date: Thu, 1 Oct 1992 16:49:00 GMT In article , pence at heawk1.gsfc.nasa.gov (William Pence) writes... > >In principle there is no reason that this information could not all >be expressed in a single keyword value, like: > >MJD = 48043.8797453703700742 / MJD My current IDL FITS reader takes the NOST manual literally. It only extracts the 20 characters in columns 11-30 to determine the FITS keyword value. Any characters in columns 31-50 are interpreted as being the imaginary part of a complex number. My suggestion would be to express this value as a string. MJD = '48043.8797453703700742' / MJD This would guarentee that all FITS readers preserve the full precision. The calling program could then parse the string into its integer plus fractional component. --Wayne Landsman landsman at stars.gsfc.nasa.gov From bschlesinger at nssdca.gsfc.nasa.gov Fri Oct 2 11:55:05 1992 Newsgroups: sci.astro.fits From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Subject: Re: triple precision keywords Summary: Fixed format is required only for mandatory keywords News-Software: VAX/VMS VNEWS 1.41 Keywords: fixed format, double precision Nntp-Posting-Host: nssdca.gsfc.nasa.gov Organization: NASA - Goddard Space Flight Center Date: Fri, 2 Oct 1992 15:38:00 GMT In article <1OCT199212490103 at stars.gsfc.nasa.gov>, landsman at stars.gsfc.nasa.gov (Wayne Landsman (301)-286-3625) writes... > My current IDL FITS reader takes the NOST manual literally. It >only extracts the 20 characters in columns 11-30 to determine the FITS >keyword value. Any characters in columns 31-50 are interpreted as being >the imaginary part of a complex number. > This requirement applies only to fixed format. The fixed format is required only for values of mandatory keywords. (At present, there are no mandatory keywords with floating point values.) For other keyword values, it is recommended but not required. See FITS Paper I, which says "recommended, and partly required." This language is interpreted in 5.3.1 of the NOST standard by saying, "The fixed format is required for values of mandatory keywords and recommended for all others." A well-recognized problem is that columns 11-30 do not contain enough space to express the full precision of a double precision floating point number. The most common, but not standard or required solution, is to extend the value beyond column 30. A number of proposed designs reviewed by the FITS office use this solution. A FITS reader that assumes that values of standard optional keywords or user-defined keywords end in column 30 will not extract correct values for some user-defined keywords in these data sets. Incidentally, EVERYBODY should be certain that their copy of the NOST Standard is current. The most recent version is 0.3b. Some misunderstandings have arisen because users are referring to superseded versions. Barry Schlesinger NOST FITS Support Office From fitsbits-request Mon Oct 5 10:05:44 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA21121; Mon, 5 Oct 92 10:05:44 EDT Resent-Date: Mon, 05 Oct 92 14:12:12 ITA Resent-From: fitsbits-request Resent-Message-Id: <9210051405.AA21121 at fits.cv.nrao.edu> Return-Path: < at vm.cnuce.cnr.it:EXOSAT at IMISIAM.BITNET> Message-Id: <9210051405.AA21114 at fits.cv.nrao.edu> Date: Mon, 05 Oct 92 14:12:12 ITA From: Lucio Chiappetti Organization: Istituto di Fisica Cosmica e Tecnologie Relative Subject: Re: triple precision keywords To: fitsbits at fits.CV.NRAO.EDU In-Reply-To: Message of Wed, 30 Sep 1992 17:15:10 GMT from X-Acknowledge-To: Resent-Sender: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU On Wed, 30 Sep 1992 17:15:10 GMT said: > >Here at the HEASARC we often need to express keyword values which have >more significant figures than can be stored in a double precision I actually wonder how this is SPECIFICALLY related to the example of MJD discussed below, or is really general. >A common example of this problem is the Modified Julian Date >which has a value something like 48043.8797453703700742 I am inclined to think this is somehow related to the need of expressing time quantities like this. What I believe is needed is a way of defining some "compound" or "non- primitive" data types. By non-primitive I mean they should go beyond the usual CHARACTER, INTEGER, REAL and DOUBLE PRECISION supported by FITS. I raised this point already in a previous posting. In my view this concerns BOTH header keywords AS WELL AS data quantities (e.g. columns in binary tables). The sort of data types I am thinking of are quantities like : ANGLE : an angle in degrees, expressed e.g. as a DOUBLE PRECISION floating point number (but liable to be displayed as ddd:mm:ss.ff... and/or read as an array of ddd mm ss etc.) HANGLE : an angle in hours, possibly stored as the previous one, but liable to be displayed as hh:mm:ss.ff (with an implicit multiplication/division by 15 whenever needed) DATE : a quantity liable to be displayed as YYYY-Mon-DD (or YYYY-MM-DD or DD-MM-YYYY or MM-DD-YYYY according to whatever European or US or other form ... I personally prefer YYYY-MM-DD because it is simpler to sort). This quantity is likely to be more used in headers (e.g. to time stamp a file) than in data areas. However it might be worthwhile to represent it natively as a numeric quantity on which one can perform arithmetic operations. Any choice of a running count of days since an arbitrary zero is good, so IAU MJDs are a reasonable choice. Since one is interested only at a precision at the day level here, an INTEGER*4 is sufficient (using MJD instead of JD is preferred) DATETIME : a quantity liable to be displayed as YYYY-MM-DD-hh:mm:ss that is, similar to the previous one in usage, but with a precision at the level of seconds. Again more likely to be used in headers than in data areas. A running count of seconds since an arbitrary zero, expressed as an INTEGER*4, is good. I would recommend using seconds since 1 Jan 1970 - which is what most Unix systems do - and which will cover about 68 years since then. TIME : here is where I am in trouble. I want to express times with an arbitrarily high precision (say 1 ms or less). This is more the case of a column in a binary table (say, representing the time of a bin in a time profile, or the arrival time of a photon). I am very reluctant to renounce the usage of traditional data types, namely either INTEGER*4 or DOUBLE PRECISION. One way to cut out the number of significant figures needed is therefore to subtract a standard offset from the values. I would be personally inclined to use a representation like the following : - time in an arbitrary unit (this most likely will be either a negative power of 2, 2**-N seconds, in an INTEGER quantity, or a decimal fraction like 1 ms, 10 ms, 0.1 ms in a DOUBLE PRECISION quantity) since 0 UT of the day containing the first bin or first photon of the dataset. This is the quantity stored as "data". - a keyword in the header will define the time units (e.g. a real number as a fraction of seconds) - another keyword in the header will define the reference time corresponding to "0" units, this could be a quantity of type DATETIME as above In general one does not need the full range of figures when doing processing, nor the units to be seconds (if one is doing a Fourier transform, one would anyhow subtract the time of the first bin, and one would have a power spectrum vs a frequency in 1/timeunit instead of Hz), but just when displaying the data and in such case one can do the conversion using the info in the header keywords >Currently, we express this number as 2 separate >This however has several disadvantages: > - it requires 2 keywords = 160 bytes to express the value Ah ... sorry Bill. This is the usual "FITS as storage system vs FITS as transport system" ... of course using a native internal representation for local storage will allow a more compact representation than FITS allows .... while for transport one can gladly spare 160 bytes > - it clutters up the header with extra keywords which makes it > more difficult for people to read >In principle there is no reason that this information could not all >be expressed in a single keyword value, like: > >MJD = 48043.8797453703700742 / MJD > >The only difficultly with this is that there has been no convenient way >to read or write values in this format, so I have proposed to add (in > The real problem is NOT that there is no convenient way to READ or WRITE values in this format, but there is no portable way of STORING them in memory (REAL*16 is not standard). That's why I would try the best effort to avoid using quantities either than I*4 or R*8. The above line of reasoning tries to demonstrate that, at least in the area of expressing times and angles, one could do without using "exotic" representations. One is left however with an important problem, which is at a SEMANTIC level. That is, how to know a quantity (a binary table column, or an header keyword) is of a specific type (particularly if the type is a nonstandard one like DATETIME or ANGLE). In a non-FITS system this might be easier (for instance I store all kewyords as , and I could code as I wish). But I am still left with the problem of expressing them into FITS kewyords for export (either a single "hyper-precision" one, like in Bill Pence's proposal, or a couple of associated keywords, which is after all not so awful). The only solution I may think of is of semantic nature, that is to know beforehand that a keyword with a particular NAME has a specific TYPE associated to it. This is already the case e.g. of NAXISn or TFIELDS, which everybody know are integers, or of DATE and DATE-OBS which are strings of a particular format, or of OBSERVER and ORIGIN, which are strings, etc. etc. Definition of additional conventions at this level should remain completely within the FITS spirit, and would be highly beneficial to facilitate data interchange. I would therefore endorse the case that such conventions be defined. ----------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR Milano | U N I C U I Q U E via Bassini 15 - I-20133 Milano - Italy | System Manager Internet: LUCIO at IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: EXOSAT at IMISIAM | ----------------------------------------------------------------------------- From fitsbits-request Mon Oct 5 14:59:37 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA21526; Mon, 5 Oct 92 14:59:37 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Mon, 5 Oct 1992 18:01:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <5OCT199214015451 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!agate!ames!nsisrv!stars.gsfc.nasa.gov!thompson References: <9210051405.AA21114 at fits.cv.nrao.edu> Subject: Re: Re: triple precision keywords Sender: fitsbits-request at fits.CV.NRAO.EDU In article <9210051405.AA21114 at fits.cv.nrao.edu>, Lucio Chiappetti writes... >On Wed, 30 Sep 1992 17:15:10 GMT said: >> >>Here at the HEASARC we often need to express keyword values which have >>more significant figures than can be stored in a double precision > > I actually wonder how this is SPECIFICALLY related to the example of > MJD discussed below, or is really general. > >>A common example of this problem is the Modified Julian Date >>which has a value something like 48043.8797453703700742 > > I am inclined to think this is somehow related to the need of expressing > time quantities like this. > What I believe is needed is a way of defining some "compound" or "non- > primitive" data types. By non-primitive I mean they should go beyond the > usual CHARACTER, INTEGER, REAL and DOUBLE PRECISION supported by FITS. > I raised this point already in a previous posting. > In my view this concerns BOTH header keywords AS WELL AS data quantities > (e.g. columns in binary tables). > The sort of data types I am thinking of are quantities like : > (He goes on to describe suggested definitions of the quantities ANGLE, HANGLE, DATE, DATETIME, and TIME. Definitions omitted to save space.) I strongly suggest looking into the document "Time Code Formats" from the Consultative Committee for Space Data Systems, CCSDS 301.0-B-2, April 1990. This is available from CCSDS Secretariat Communications and Data Systems Division (Code-OS) National Aeronatuics and Space Administration Washington, DC 20546, USA The topic of encoding date and time values into binary and ASCII values is discussed there in some detail. The suggested format for ASCII encoding is briefly outlined below for the following example (5 Oct 1992 at 1:23:45 UT) 1992-10-05T01:23:45.000Z The number of decimal places after the seconds field ("45") can be whatever is appropriate, or can be omitted entirely. Encoding only date, or only time, values is also discussed. It's always better to use a pre-existing standard than to reinvent the wheel. On another note, I agree with Wayne Landsman that encoding the more-than-double precision value as a character string, i.e. MJD = '48043.8797453703700742' / MJD is preferable to MJD = 48043.8797453703700742 / MJD Bill Thompson From fitsbits-request Wed Oct 7 11:04:34 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA26535; Wed, 7 Oct 92 11:04:34 EDT Return-Path: Message-Id: <199210071503.AA12607 at chenas.inria.fr> Date: Wed, 7 Oct 92 16:03:42 +0100 From: forveill at gag.observ-gr.fr (Thierry Forveille) Posted-Date: Wed, 7 Oct 92 16:03:42 +0100 To: fitsbits at fits.CV.NRAO.EDU, lucio at ifctr.mi.cnr.it Subject: Re: Some FITS tables suggestions Sender: fitsbits-request at fits.CV.NRAO.EDU Lucio Chiappetti (LUCIO at IFCTR.MI.CNR.IT) writes > YES, conventions are needed to avoid those incompatibilities, which can > be very annoying. > And I would say those conventions are needed beyond the area of databases, > but, for instance, in the area of keywords describing the content of a > photon list. > At the moment I am using provisional, local conventions for the designation > of columns for a photon list : for instance I call THETA and PHI the angular > cooordinates of a photon (from the optical axis), X and Y the coordinates in > micron on the focal plane, and XPOSITN YPOSITN the coordinates in detector > pixels ...or I call ENERGY true energy in keV, but PHA energy in channels, > and I ignore whether they are consistent e.g. with EXSAS or PROS - which > I am told are not compatible among them) I certainly agree that conventions for keywords names should be agreed upon in the various subfields of astronomy, but they should at least be compatible with the existing standard. Specifically, A VALID FITS FILE MUST USE SI UNITS. This tends to be repeatedly forgotten, even though it was already explicitly specified in the original FITS paper. X and Y should therefore be stored in metres, not microns, ENERGY in Joules not kev (or cm**-1, or Kelvin, or GHz), and so on... Also, there are some well established conventions to store projected angular coordinates (RA---GLS or GLAT-ATF or...) though I am not sure they are part of the standard yet. Thierry Forveille Observatoire de Grenoble forveill at gag.observ-gr.fr From fitsbits-request Wed Oct 7 11:55:48 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA26553; Wed, 7 Oct 92 11:55:48 EDT Resent-Date: Wed, 07 Oct 92 16:19:26 ITA Resent-From: fitsbits-request Resent-Message-Id: <9210071555.AA26553 at fits.cv.nrao.edu> Return-Path: < at vm.cnuce.cnr.it:EXOSAT at IMISIAM.BITNET> Message-Id: <9210071555.AA26547 at fits.cv.nrao.edu> Date: Wed, 07 Oct 92 16:19:26 ITA From: Lucio Chiappetti Organization: Istituto di Fisica Cosmica e Tecnologie Relative Subject: Re: Some FITS tables suggestions To: fitsbits at fits.CV.NRAO.EDU In-Reply-To: Message of Wed, 7 Oct 92 16:03:42 +0100 from X-Acknowledge-To: Resent-Sender: Lucio Chiappetti Resent-Sender: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU In reply to a posting of mine (which in turn replied to some questions by Bill Pence) : On Mon, 5 Oct 1992 18:01:00 GMT thompson at stars.gsfc.nasa.gov said: >> >>>A common example of this problem is the Modified Julian Date >>>which has a value something like 48043.8797453703700742 >> >> I am inclined to think this is somehow related to the need of expressing >> time quantities like this. > > (He goes on to describe suggested definitions of the quantities ANGLE, > HANGLE, DATE, DATETIME, and TIME. Definitions omitted to save space.) > >I strongly suggest looking into the document "Time Code Formats" from the >Consultative Committee for Space Data Systems, CCSDS 301.0-B-2, April 1990. I knew about this standard from a previous posting (may be by the same author, I have not looked it up) in fitsbits or WGAS, which I have noted down (perhaps for the disastrous state of our postal system unfortunately I tend to consider any document NOT available via network as not existing) > >discussed there in some detail. The suggested format for ASCII encoding is >briefly outlined below for the following example (5 Oct 1992 at 1:23:45 UT) > > 1992-10-05T01:23:45.000Z > However perhaps I gave the WRONG impression that the topic of my mail was to establish conventions for ASCII encoding | That was not my primary aim | I intended to solicit a discussion about NAMES and CONTENTS of keywords from a semantic and logical point of view (the fact that those keywords need an ASCII encoding is specific to a FITS implementation, while my concern goes beyond FITS into the native representations used by analysis systems ... which MAY be non FITS but SHOULD be FITS-compatible) I am ready to comply with whatever ASCII encoding for date-times will be agreed for FITS in addition to the one currently used in DATE and DATE-OBS. My interim solution was not so different from the CCSDS scheme and had that in mind since it is very easy to map it ; 1992-10-05-01:23:45.00 actually it is the notation used by VMS. I find more LEGIBLE to have an hyphen instead of a T, and no Z at the end (which makes me think of "Zulu" timezone notation), but it is really trivial to switch to the other notation. See more below on standards .... On Wed, 7 Oct 92 16:03:42 +0100 said: > >with the existing standard. Specifically, A VALID FITS FILE MUST USE SI >UNITS. This tends to be repeatedly forgotten, even though it was already >explicitly specified in the original FITS paper. >X and Y should therefore be stored in metres, not microns, ENERGY in Joules >not kev (or cm**-1, or Kelvin, or GHz), and so on... Again I gave the WRONG impression that my concern was on units of measurement, while I was more concerned about the fact the file be self-documenting about the units used, and about establishing conventions for names, contents and "binary" representation. Concerning SI units and alike, when I was a student I was an enthusiast of the SI, and I swore never to use cgs and similar things. When I later started my research life I realized one needs to be more flexible. I am not scandalized to use Angstroms or keVs (actually I cannot THINK of an X-ray spectrum if not in photon/cm2/s/keV vs keV, and of an UV spectrum if not in erg/cm2/s/A vs A ... and I believe this is what everybody does ... I have never seen a paper on Ap.J. with photons/m2/s/J or J/m2/s/m Similarly the examples I made in my posting were just examples (although I will not find very useful to give photon energies in Joules or to use metres instead of microns to measure positions on a CCD plate: the latter example is particularly specific to Bill Pence's posting, since it avoids an unnecessary factor 10**6 and therefore 6 digits of - fictitious - precision) Concerning standards, therefore they also are subject to a silent judgement from the community, based on comfort and legibility. There is a nice paper by Arnold Toynbee, the historian, explaining why the French Revolution Calendar was not able to supplant the traditional calendar. Everybody uses Internet domains for e-mail addressing, which are legible, instead of the awful X.400 notations. Some years ago there was some proposed standard to express ALL decimal numbers in exponential notation in power of 1000, so a date in year 1992 had to expressed as 1.992d3 or something like that : it fell in the place where everything is forgotten. On the contrary other standards, of which FITS looks a working example, meet the general agreement and ARE used. I would however just reiterate my concept, that I regard the two points treated above (ASCII-encoding and units) as completely minor in my line of thought, while I would once again solicit a discussion on names of keywords (and their content). I feel that this would be beneficial AT LEAST to the X-ray community which is now working separately at many separate missions, in fields like : list of photons : should we call photon detector-pixel positions X and Y, or XPOSITN and YPOSITN (8-char FITS names) or whatever ? should we call photon energy expressed as a PHA channel (not keV) with the name of ENERGY (I would say no and reserve it for keV, Joule or whatever physical unit) or PHA or what else ? time profiles (this perhaps also beyond X-ray astronomy) : it is important to agree a convention on the format of such files as binary tables, on the names of the columns and on the additional keywords needed to specify time of each bin I hope to listen to some discussion on the latter topics in the near future. ----------------------------------------------------------------------------- A member of G.ASS : Group for Astronomical Software Support ----------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR Milano | U N I C U I Q U E via Bassini 15 - I-20133 Milano - Italy | System Manager Internet: LUCIO at IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: EXOSAT at IMISIAM | ----------------------------------------------------------------------------- From fitsbits-request Wed Oct 7 18:26:19 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27073; Wed, 7 Oct 92 18:26:19 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Wed, 7 Oct 1992 22:02:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <7OCT199218024426 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!caen!sdd.hp.com!think.com!ames!nsisrv!stars.gsfc.nasa.gov!thompson References: <9210071555.AA26547 at fits.cv.nrao.edu> Subject: Re: Re: Some FITS tables suggestions Sender: fitsbits-request at fits.CV.NRAO.EDU In article <9210071555.AA26547 at fits.cv.nrao.edu>, Lucio Chiappetti writes... (stuff deleted) >I would however just reiterate my concept, that I regard the two points >treated above (ASCII-encoding and units) as completely minor in my line >of thought, while I would once again solicit a discussion on names of >keywords (and their content). > >I feel that this would be beneficial AT LEAST to the X-ray community which >is now working separately at many separate missions, in fields like : > > list of photons : > > should we call photon detector-pixel positions X and Y, or XPOSITN and > YPOSITN (8-char FITS names) or whatever ? > should we call photon energy expressed as a PHA channel (not keV) with > the name of ENERGY (I would say no and reserve it for keV, Joule or > whatever physical unit) or PHA or what else ? > > time profiles (this perhaps also beyond X-ray astronomy) : > > it is important to agree a convention on the format of such files as > binary tables, on the names of the columns and on the additional > keywords needed to specify time of each bin > I would just like to make two comments on this general topic. No, three comments--the zeroth comment being that it's a very difficult thing to do. One thing to avoid is the mistake I've been told the Planetary Data System made with their Object Descriptor Language (although I haven't had any experience with it directly). As I understand it, basic names got frozen in at an early stage, so that for example the keyword "FLUX" could only be used with particle fluxes, and light measurements could only be referred to as a "BRIGHTNESS" (which is a different thing). Of course, you might say that brightness is the quantity that astronomers are really interested in, but I argue that one does not want to limit oneself to specific "most-common" observation modes and data types. I can think of situations where flux would be the fundamental quantity of measurements, e.g. solar UV luminosity monitoring, or the flux distribution as a function of height in a planetary atmosphere from a planetary probe. Flux is the fundamental quantity when concerned with energy transport in a plane-parallel atmosphere, and a standard file format should be able to handle data from theoretical calculations as well as from actual observations. Secondly, I would just like to emphasize that such standardization should proceed outside of the formalization process of the FITS standard itself (which I'm sure was Lucio Chiappetti's intent as well). Any such effort could only consider a subset of the possible types of observations and the forms the data could take. Granted, it could possibly cover a large fraction of the astronomical data actually taken, but there will always be data products and observations which don't fall into the mold. It may be best for this effort to proceed along disciplinary lines, rather than to try to encompass all possible astronomical data into one grand scheme. For instance, I'm aware of a standardization process of this sort for radio interferometry data, I believe organized by the Green Bank group. Simple image data already has some standardization applied to it, since that's what FITS was originally designed for. Just in general, I think more progress will be made if the goals remain more focused. Bill Thompson From fitsbits-request Thu Oct 8 00:21:08 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27496; Thu, 8 Oct 92 00:21:08 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 8 Oct 92 03:25:11 GMT From: murison at cfa203.HARVARD.EDU (Marc A. Murison, RG) Message-Id: <1992Oct8.032511.2423 at cfa203.harvard.edu> Organization: Smithsonian Astrophysical Observatory, Cambridge, MA, USA Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!wupost!ukma!hsdndev!cfa203!news Subject: C++ FITS classes? Sender: fitsbits-request at fits.CV.NRAO.EDU Does anyone know of any C++ FITS classes available? I'd rather not re-invent any wheels... ------------------------------------------------------------------------ Marc A. Murison | #include Smithsonian Astrophysical Obs. | void main( void ) { From fitsbits-request Fri Oct 23 12:31:29 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11724; Fri, 23 Oct 92 12:31:29 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Fri, 23 Oct 1992 16:45:00 GMT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Message-Id: <23OCT199211452730 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!sdd.hp.com!elroy.jpl.nasa.gov!ames!nsisrv!nssdca.gsfc.nasa.gov!bschlesinger Subject: FITS basics and information (periodic posting) Sender: fitsbits-request at fits.CV.NRAO.EDU This basic FITS information is posted and updated periodically for the benefit of new readers and the reference of old readers. FITS (Flexible Image Transport System) is a data format designed to provide a means for convenient exchange of astronomical data between installations whose standard internal formats and hardware differ. A FITS file is composed of a sequence of Header Data Units (HDUs). The header consists of keyword=value statements, which describe the format and organization of the data in the HDU and may also provide additional information, for example, about the instrument or the history of the data. The data follow, structured as the header specifies. The data section of the HDU may contain a digital image, but, except for the first, IT DOESN'T HAVE TO. Other possible formats include tables and multidimensional matrices that are not images. The first HDU must contain a multidimensional matrix or no data at all; the data in subsequent HDUs, called extensions, may be of any type, consistent with certain rules. The "Image" in the name comes from the original use of the format to transport digital images, but it's not just for images any more. FITS is not principally a graphics format designed for the transfer of pictures; it does not incorporate "FITS viewers", packages for decoding the data into an image. Users must develop or obtain separate software to convert the data from the FITS file into a form that can be readily displayed. As has been discussed in this newsgroup, and in alt.sci.astro.fits before it, the Extended Portable Bitmap Toolkit (pbm+) can be used for converting many FITS files to such a format. However, support is not guaranteed for all FITS files where the data are in the form of an image. In particular, there may be problems when the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2). Archie Warnock and Ron Baalke have announced release of version 7.8 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov [128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp subdirectory. It is also available through Simtel-20 [192.88.110.20] at PD1:IMDISP78.ZIP. Additional discussion of FITS -> image converters appears in this newsgroup from time to time. The fundamental references on FITS are the following four papers, often referred to collectively as the "Four FITS Papers". These papers are the formal standard for FITS, endorsed by the International Astronomical Union (IAU). Wells, D. C., Greisen, E. W., and Harten, R. H., "FITS: a flexible image transport system," Astronomy and Astrophysics Supplement Series, 44, 363-370, 1981. Greisen, E. W. and Harten, R. H., "An extension of FITS for small arrays of data," Astronomy and Astrophysics Supplement Series, 44, 371-374, 1981. (NOTE: The format described in this paper has been used almost exclusively to transport radio interferometry and is likely to be replaced by other formats in the future. Writing data other than radio interferometry data using this format is not recommended.) Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., "Generalized extensions and blocking factors for FITS," Astronomy and Astrophysics Supplement Series, 73, 359-364, 1988. Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., "The FITS tables extension, Astronomy and Astrophysics Supplement Series, 73, 365-372, 1988. A User's Guide for FITS, commissioned by NASA Headquarters, is maintained by the NASA/OSSA Office of Standards and Technology (NOST) FITS Support Office. This Guide is intended to be a tutorial for new FITS users. In addition to presenting the rules of FITS, it provides some of the history and reasoning behind the choice of the rules, adds recommendations on good practices, and discusses current developments in FITS. This document is available only in hard copy form. NASA is sponsoring development of a formal standard for FITS. The goal of this process is a document consistent with FITS as endorsed by the IAU, eliminating some contradictions and ambiguities in the original FITS papers, that can be endorsed by the IAU FITS Working Group as the FITS standard. The document is being developed by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review by the astronomical community. Only minor revisions are expected to the current draft, version 0.3b, but the form of the standard is not final, and it does not supersede the four papers and Floating Point Agreement endorsed by the IAU as the official standard for FITS. The IAU has endorsed the Floating Point Agreement, which defines how floating point numbers are to be expressed in FITS. The basic agreement appears verbatim in the User's Guide, and the substance is incorporated in the Draft NASA Standard. The NOST maintains a file of FITS information available by anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in the directory FITS. It includes copies of the current draft NASA Standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. A README. file describes the contents of the directory. A SOFTWARE subdirectory, described by an included README.FIRST file, contains a program in C to read and list the headers of a FITS file and another file with information on publicly available FITS software packages. The ERRTEST subdirectory contains several versions of the same FITS file, a valid one and several with different kinds of header errors, for use in testing software to read FITS files. An included README.FIRST file contains details. Additional material can be obtained by anonymous ftp from the National Radio Astronomy Observatory, from fits.cv.nrao.edu, in the directory FITS. The Documents subdirectory (case is significant) contains copies of the proposed BINTABLE Binary Tables extension, which is now under consideration by the FITS committees, and a draft describing a suggested method for data compression under FITS. These documents are available in both LaTeX and PostScript forms. A number of additional documents are available in ASCII text forms, including the proposal on physical blocking of FITS files on media other than tape and material on FITS, its history, and the FITS community. Paper copies of many of the documents listed above can be obtained from the NOST Librarian. Paper copies of the User's Guide and either paper or electronic copies of the Draft NOST Standard, for those without ftp access, are available. Because of restrictions set by the copyright holder, NOST can send copies of the four FITS papers only to non-profit organizations. The NOST can be reached as follows: (Postal) NASA/OSSA Office of Standards and Technology Code 633.2 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Telephone: (301)286-3575 8 a. m. - 5 p. m., U. S. Eastern Time If the Librarian is unavailable, a phone mail system takes the call after four rings. Please mention this posting in your request. Barry M. Schlesinger Coordinator, NASA/NSSDC NOST FITS Support Office (301) 513-1634 fits at nssdca.gsfc.nasa.gov NCF::FITS From fitsbits-request Mon Oct 26 10:09:59 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA17612; Mon, 26 Oct 92 10:09:59 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Mon, 26 Oct 1992 15:09:39 GMT From: dwells at fits.CV.NRAO.EDU (Don Wells) Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells Subject: FITS support for MacOS? Sender: fitsbits-request at fits.CV.NRAO.EDU Recently I have received two queries asking about FITS support for Macintosh systems. What is available? I would like to create a subdirectory /FITS/OSsupport/MacOS under anonFTP on fits.cv.nrao.edu from the response to this question. -- 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 Oct 26 16:32:47 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00369; Mon, 26 Oct 92 16:32:47 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 26 Oct 1992 21:01:17 GMT From: raffi at aero.org (Raffi Krikorian) Message-Id: <1chmatINN9tn at news.aero.org> Organization: The Aerospace Corporation, El Segundo, CA Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news.aero.org!raffi Subject: Saving a 2D image w/ C Sender: fitsbits-request at fits.CV.NRAO.EDU I'm intresested in using FITS format to save 256X256 floating point values to disk on a PC. Are there any C routines that would do this? Raffi Krikorian raffi at aero.org From fitsbits-request Mon Oct 26 22:24:44 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01632; Mon, 26 Oct 92 22:24:44 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 27 Oct 1992 03:00:15 GMT From: sla at umbra.ucsc.edu (Steve Allen) Message-Id: <1cibc0INNpjq at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!decwrl!hal.com!darkstar.UCSC.EDU!umbra!sla Subject: Which characters are legal in a string? Sender: fitsbits-request at fits.CV.NRAO.EDU I am looking through the NOST 100-0.3b standard document trying to be very sure about one point: Section 5.3.2.1 specifies that a "character string shall be composed only of ASCII text." Section 6.1 specifies that characters shall be 7-bit ASCII These specifications do not preclude the existence of unprintable characters (ASCII 0 through 31 and 127) in a character string. Is it intended that unprintable characters be legal? Are there FITS readers which will be confounded by unprintables? A further question might be asked about the reason why 8-bit ASCII is not allowed, but I would rather defer that until later. _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me. From fitsbits-request Tue Oct 27 12:05:31 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03042; Tue, 27 Oct 92 12:05:31 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 27 Oct 1992 17:05:01 GMT From: cflatter at cv3.CV.NRAO.EDU (Chris Flatters) Message-Id: <1992Oct27.170501.2980 at nrao.edu> Organization: NRAO Path: cv3.cv.nrao.edu!laphroaig!cflatter References: <1cibc0INNpjq at darkstar.UCSC.EDU> Reply-To: cflatter at cv3.CV.NRAO.EDU Subject: Re: Which characters are legal in a string? Sender: fitsbits-request at fits.CV.NRAO.EDU In article 1cibc0INNpjq at darkstar.UCSC.EDU, sla at umbra.ucsc.edu (Steve Allen) writes: >I am looking through the NOST 100-0.3b standard document trying to be >very sure about one point: > > Section 5.3.2.1 specifies that a "character string shall be composed > only of ASCII text." > > Section 6.1 specifies that characters shall be 7-bit ASCII > >These specifications do not preclude the existence of unprintable characters >(ASCII 0 through 31 and 127) in a character string. Is it intended that >unprintable characters be legal? Are there FITS readers which will be >confounded by unprintables? Many C and C++ based readers will have problems with ASCII 0 in character strings. Many FORTRAN readers will also have problems on Unix systems (the Fortran RTL often uses C standard library functions that attach a special meaning to character zero). Chris Flatters cflatter at nrao.edu From fitsbits-request Tue Oct 27 13:25:52 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03214; Tue, 27 Oct 92 13:25:52 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 27 Oct 1992 17:47:57 GMT From: hanisch at stsci.edu (Bob Hanisch, ST ScI) Message-Id: <1992Oct27.174757.18460 at stsci.edu> Organization: Space Telescope Science Institute, Baltimore MD Path: cv3.cv.nrao.edu!uvaarpa!caen!destroyer!ncar!noao!stsci!iris.stsci.edu!hanisch References: <1992Oct27.170501.2980 at nrao.edu> Reply-To: hanisch at stsci.edu Subject: Re: Which characters are legal in a string? Sender: fitsbits-request at fits.CV.NRAO.EDU In article 1cibc0INNpjq at darkstar.UCSC.EDU, sla at umbra.ucsc.edu (Steve Allen) writes: >I am looking through the NOST 100-0.3b standard document trying to be >very sure about one point: > > Section 5.3.2.1 specifies that a "character string shall be composed > only of ASCII text." > > Section 6.1 specifies that characters shall be 7-bit ASCII > >These specifications do not preclude the existence of unprintable characters >(ASCII 0 through 31 and 127) in a character string. Is it intended that >unprintable characters be legal? Are there FITS readers which will be >confounded by unprintables? If you look on p. 5 of the same document, "ASCII text" is defined as ASCII characters in the range of hex 20 to 7E. This was done in order to have to avoid repeating this every time we wanted to refer to printable ASCII text. So the statement does NOT allow unprintable characters. The distinction is further clarified in Appendix E (pp. 63-43). --- Robert J. Hanisch Tel. (410)338-4910 Fax. (410)338-5090 Space Telescope Science Institute NSI: hanisch at stsci.edu [130.167.1.2] 3700 San Martin Drive DECNet: STSCIC::HANISCH [6549::] Baltimore, MD 21218 USA Bitnet: hanisch at stsci From fitsbits-request Tue Oct 27 13:53:51 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03263; Tue, 27 Oct 92 13:53:51 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 27 Oct 1992 14:40:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <27OCT199210400385 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!wupost!decwrl!ames!nsisrv!stars.gsfc.nasa.gov!thompson References: <1cibc0INNpjq at darkstar.UCSC.EDU> Subject: Re: Which characters are legal in a string? Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1cibc0INNpjq at darkstar.UCSC.EDU>, sla at umbra.ucsc.edu (Steve Allen) writes... >I am looking through the NOST 100-0.3b standard document trying to be >very sure about one point: > > Section 5.3.2.1 specifies that a "character string shall be composed > only of ASCII text." > > Section 6.1 specifies that characters shall be 7-bit ASCII > >These specifications do not preclude the existence of unprintable characters >(ASCII 0 through 31 and 127) in a character string. Is it intended that >unprintable characters be legal? Are there FITS readers which will be >confounded by unprintables? > I've always gone by the philosophy that only ordinary printable characters should appear in a FITS header. For instance, my software will expand tab characters out to the appropriate number of spaces before writing it into the header. One might argue that more leniency could be permitted in ASCII fields in FITS binary tables. >A further question might be asked about the reason why 8-bit ASCII is not >allowed, but I would rather defer that until later. That's simple: 8-bit ASCII isn't really a standard, is it? You get different characters on different machines. Bill Thompson From fitsbits-request Tue Oct 27 17:54:24 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04234; Tue, 27 Oct 92 17:54:24 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 27 Oct 1992 21:00:00 GMT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Message-Id: <27OCT199216002831 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!ames!nsisrv!nssdca.gsfc.nasa.gov!bschlesinger References: <1cibc0INNpjq at darkstar.UCSC.EDU> Subject: Re: Which characters are legal in a string? Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1cibc0INNpjq at darkstar.UCSC.EDU>, sla at umbra.ucsc.edu (Steve Allen) writes... >I am looking through the NOST 100-0.3b standard document trying to be >very sure about one point: > > Section 5.3.2.1 specifies that a "character string shall be composed > only of ASCII text." > This section is referring to values of header keywords. > Section 6.1 specifies that characters shall be 7-bit ASCII > This section refers to data >These specifications do not preclude the existence of unprintable characters >(ASCII 0 through 31 and 127) in a character string. Is it intended that >unprintable characters be legal? Are there FITS readers which will be >confounded by unprintables? > In Section 3, the term ASCII text is defined to mean "ASCII characters hexadecimal 20-7E" (decimal 32-127) for the NOST standard. These characters are the printable ASCII characters. Section 4.2 states "The primary HDU and every extension HDU shall consist of an integral number of header records consisting of ASCII text, which may be followed by an integral number of data records." Thus ASCII decimal 0-31,127 are excluded from headers. The specification for character data does not restrict the permitted characters. Specifications for individual structures may. For example, for ASCII Tables, 8.1.5 reads "All data in an ASCII tables extension data record shall be ASCII text...." A restriction to printable ASCII characters and NULL (decimal and hexadecimal zero) is proposed for binary tables. Barry Schlesinger NOST FITS Support Office From fitsbits-request Thu Oct 29 17:47:41 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA12071; Thu, 29 Oct 92 17:47:41 EST Return-Path: Date: Thu, 29 Oct 92 17:47:58 EST From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9210292247.AA12180 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: FITSIO V3.3 is available Sender: fitsbits-request at fits.CV.NRAO.EDU FITSIO - Version 3.3 29 October 1992 This is to announce that Version 3.3 of the FITSIO package is now available from the HEASARC. FITSIO is a powerful yet simple to use Fortran subroutine interface for reading and writing files in FITS format. This 3.3 version of FITSIO is completely compatible with the previous version and contains the following new features: - Added a major new port to run FITSIO within the IRAF environment. A set of SPP-callable interface routines is also provided. - Added a new port to run on Macintosh computers with Absoft's MacFortran II. - The maximumn allowed number of open FITS files has been doubled from the previous 6 files to 12 files. - Added further checks to permit only printable ASCII characters to be written to a FITS header. - Made 7 other small enhancements and fixed 5 minor bugs. For further details on these new features, see the 'release.doc' file in the FITSIO distribution directory. Programmers interested in using the new IRAF/SPP version of FITSIO should note that the HEASARC plans the first release of its FTOOLS software utility package next week. This will contain a complete example of how to build and use the FITSIO library within IRAF. The FITSIO software, documentation, and example programs are available via anonymous ftp from: ftp tetra.gsfc.nasa.gov (128.183.8.77) Then type the following: ftp> user anonymous Password: [type your username as a password] ftp> cd pub/fitsio3 [to move to the version 3 subdirectory] ftp> ls [to see a list of the available files] ftp> get read.me [contains latest information about FITSIO] ftp> get fitsio.doc [complete user documentation] ftp> get fitsio.ps [Postscript version of the documentation] ftp> get ... [get any additional desired files] ftp> quit -------------------------------------------------------------------------- Dr. William Pence USRA/HEASARC (High Energy Astrophysics Science Archive Research Center) Code 668 NASA/Goddard Space Flight Center SPAN: LHEAVX::PENCE Greenbelt, MD 20771 Internet: pence at tetra.gsfc.nasa.gov Telephone: (301)286-4599