From wgas@Hypatia.gsfc.nasa.gov Mon Jun 22 04:35:06 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3702" "Mon" "22" "June" "92" "04:33:00" "-0400" "Lucio Chiappetti - IFC Milano" "EXOSAT%IMISIAM.BITNET@GIBBS.GSFC.NASA.GOV" nil "78" "Re: Thoughts from WGAS (1)" "^From:" nil nil "6"]) Return-Path: Received: from cv3.cv.nrao.edu by fits.cx.nrao.edu (4.1/SMI-DDN) id AA19374; Mon, 22 Jun 92 04:35:04 EDT Received: from Hypatia.gsfc.nasa.gov by cv3.cv.nrao.edu (4.1/DDN-DLB/1.12) id AA14631; Mon, 22 Jun 92 04:36:31 EDT Received: from localhost.gsfc.nasa.gov by Hypatia.gsfc.nasa.gov (911016.SGI/1.35) id AA17026; Mon, 22 Jun 92 04:33:00 -0400 Message-Id: <9206220831.AA16992@Hypatia.gsfc.nasa.gov> Comment: AAS Working Group for Astronomical Software Originator: wgas@hypatia.gsfc.nasa.gov Errors-To: leb@Hypatia.gsfc.nasa.gov Reply-To: Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: Lucio Chiappetti - IFC Milano Sender: wgas@Hypatia.gsfc.nasa.gov To: Multiple recipients of list Subject: Re: Thoughts from WGAS (1) Date: Mon, 22 Jun 92 04:33:00 -0400 writes >I want to spur a discussion on namings, in connection with the proposed >IMAGE extension. While .... > >The word "IMAGE", as commonly used by astronomers, and as used in the >IMAGE extension proposal actually has two meanings. The first .... > >What I'm aiming for here is to point out that we place an undue burden >on the end-user by confounding the two meanings. ..... which KIND of end-user ? Kind 1 : the "stupid" or "average" user, or common astronomer who is contented of using IRAF or MIDAS or whatever, read a FITS tape, etc. Kind 2 : the astronomer knowledgeable in programming, the sort of person which can tell a FITS file looking at a tape analysis etc. and likes good, efficient BUT SIMPLE programming (Fortran ..?) Kind 3 : the super-gurus who care most (if not exclusively) about "informatics" and elegant programming (C ..?), and little (if not nothing at all) about the underlying astronomy, or the ease of the Kind 1 users Now I believe the proportions are approximately 85 % - 14 % - 1 % , so the issues should be driven by Kind 1 and 2 users ( I personally rank my self in the average Kind 2 users) >Right now, it's simply the {\em name} IMAGE which bothers me. To the >end-user with some computer science knowledge, there are any number of >ways images can be stored besides the conventional pixel-by-pixel, I believe the IMAGE name in the IMAGE extension proposal to FITS is just the sort of thing which will NOT confuse the Kind 1 (and 2) users, and is part of the simplicity for which I like such proposal > >This imparts a burden on the end-user which can easily be off-loaded to >the machine if we can develop a scheme to name underlying data ... so using a simple name, which the Kind 1 user is used (sic) to use (everybody deals with FITS images on tapes and images in IRAF, MIDAS etc.) is a way to reduce the burden on the user. I enclose here below part of a previous posting to FITSBITS --------------------------------------------------------------------------- Date: Mon, 09 Mar 92 12:08:33 ITA From: Lucio Chiappetti - IFC Milano Subject: Re: Proposal for an IMAGE extension To: fitsbits-request@fits.CX.NRAO.EDU In-Reply-To: Message of Fri, 28 Feb 92 16:40:56 +0100 from I have read the proposal for the FITS IMAGE extension and the associated discussion on fitsbits. I find the proposal by Ponz, Thompson and Munoz perfect in its simplicity (in fact I marvelled long ago that the IMAGE extension, which I knew was used by IUE ULDA, was not one of the standard ones), particularly in the case one wants to put in the same file images which are clearly associated. I do not mind about the name being IMAGE or ARRAY or whatever (but IMAGE is self-explanatory, and is already being used), but I would strongly prefer to use IMAGE rather than BINTABLE to pack several associated images in one file. ----------------------------------------------------------------------------- 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@IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: EXOSAT@IMISIAM | ----------------------------------------------------------------------------- Acknowledge-To: From wgas@Hypatia.gsfc.nasa.gov Mon Jun 22 14:30:44 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2767" "Mon" "22" "June" "92" "14:29:50" "-0400" "William Thompson" "thompson@serts.gsfc.nasa.gov " nil "59" "Re: Thoughts from WGAS (1)" "^From:" nil nil "6"]) Return-Path: Received: from cv3.cv.nrao.edu by fits.cx.nrao.edu (4.1/SMI-DDN) id AA20104; Mon, 22 Jun 92 14:30:42 EDT Received: from Hypatia.gsfc.nasa.gov by cv3.cv.nrao.edu (4.1/DDN-DLB/1.12) id AA03242; Mon, 22 Jun 92 14:32:00 EDT Received: from localhost.gsfc.nasa.gov by Hypatia.gsfc.nasa.gov (911016.SGI/1.35) id AA18344; Mon, 22 Jun 92 14:29:50 -0400 Message-Id: <9206221822.AA02640@serts.gsfc.nasa.gov> Comment: AAS Working Group for Astronomical Software Originator: wgas@hypatia.gsfc.nasa.gov Errors-To: leb@Hypatia.gsfc.nasa.gov Reply-To: Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: thompson@serts.gsfc.nasa.gov (William Thompson) Sender: wgas@Hypatia.gsfc.nasa.gov To: Multiple recipients of list Subject: Re: Thoughts from WGAS (1) Date: Mon, 22 Jun 92 14:29:50 -0400 Lucio Chiappetti (LUCIO@IFCTR.MI.CNR.IT) writes: > I believe the IMAGE name in the IMAGE extension proposal to FITS is > just the sort of thing which will NOT confuse the [average] users, > and is part of the simplicity for which I like such proposal > > > >This imparts a burden on the end-user which can easily be off-loaded to > >the machine if we can develop a scheme to name underlying data > > ... so using a simple name, which the Kind 1 user is used (sic) to use > (everybody deals with FITS images on tapes and images in IRAF, MIDAS etc.) > is a way to reduce the burden on the user. > > I enclose here below part of a previous posting to FITSBITS > > --------------------------------------------------------------------------- > Date: Mon, 09 Mar 92 12:08:33 ITA > From: Lucio Chiappetti - IFC Milano > Subject: Re: Proposal for an IMAGE extension > To: fitsbits-request@fits.CX.NRAO.EDU > In-Reply-To: Message of Fri, 28 Feb 92 16:40:56 +0100 from > > I have read the proposal for the FITS IMAGE extension and the associated > discussion on fitsbits. > > I find the proposal by Ponz, Thompson and Munoz perfect in its simplicity > (in fact I marvelled long ago that the IMAGE extension, which I knew > was used by IUE ULDA, was not one of the standard ones), particularly in > the case one wants to put in the same file images which are clearly > associated. > > I do not mind about the name being IMAGE or ARRAY or whatever (but IMAGE is > self-explanatory, and is already being used), but I would strongly prefer > to use IMAGE rather than BINTABLE to pack several associated images in one > file. To my mind, the extension name IMAGE is *deceptively* simple. It implies something that just isn't necessarily true, i.e. that the extension contains a picture. Are we going to have to have another extension, which is exactly the same except that XTENSION='SPECTRUM'? I'm sure that at least 90% of the FITS data files out there do contain just that--images. But not all do, and the IMAGE extension seems intended for more than just pictures. There are, however, people who do think that FITS is only for images, and who are surprised when they discover that it doesn't include support for those features which are common for standard raster image formats like GIF, TIFF, etc., e.g. embedded color tables, or RGB color separation. I've seen this confusion in people both on the (alt.)sci.astro.fits newsgroup, and in support personnel who have been working with us in developing hardware and software for astronomical observations. Let's nip this misconception in the bud. FITS already has too many other misconceptions associated with it. Bill Thompson From wgas@Hypatia.gsfc.nasa.gov Mon Jun 22 15:18:33 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2158" "Mon" "22" "June" "92" "15:16:14" "-0400" "tody@noao.edu" "tody@noao.edu" nil "47" "IMAGE extension" "^From:" nil nil "6"]) Return-Path: Received: from cv3.cv.nrao.edu by fits.cx.nrao.edu (4.1/SMI-DDN) id AA20165; Mon, 22 Jun 92 15:18:31 EDT Received: from Hypatia.gsfc.nasa.gov by cv3.cv.nrao.edu (4.1/DDN-DLB/1.12) id AA03553; Mon, 22 Jun 92 15:19:57 EDT Received: from localhost.gsfc.nasa.gov by Hypatia.gsfc.nasa.gov (911016.SGI/1.35) id AA18780; Mon, 22 Jun 92 15:16:14 -0400 Message-Id: <9206221910.AA01594@coma.tuc.noao.edu.noao> Comment: AAS Working Group for Astronomical Software Originator: wgas@hypatia.gsfc.nasa.gov Errors-To: leb@Hypatia.gsfc.nasa.gov Reply-To: Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: tody@noao.edu Sender: wgas@Hypatia.gsfc.nasa.gov To: Multiple recipients of list Subject: IMAGE extension Date: Mon, 22 Jun 92 15:16:14 -0400 > To my mind, the extension name IMAGE is *deceptively* simple. It > implies something that just isn't necessarily true, i.e. that the > extension contains a picture. It doesn't imply that to me. I suppose you are right that people in other fields might be confused by the terminology but I think FITS should be oriented towards astronomy. In any case, I don't see any problem with generalizing the concept of "image" (or "data image") to mean something more complex than a picture. > Are we going to have to have another extension, which is exactly the same > except that XTENSION='SPECTRUM'? A simple spectrum is a one dimensional image. (there are also 2 and 3 dimensional spectra). The proposed IMAGE extension could be used to store spectra. > There are, however, people who do think that FITS is only for images, ^^^^^^ you mean pictures... > and who are surprised when they discover that it doesn't include > support for those features which are common for standard raster image > formats like GIF, TIFF, etc., e.g. embedded color tables, or RGB color > separation. I've seen this confusion in people both on the > (alt.)sci.astro.fits newsgroup, and in support personnel who have been > working with us in developing hardware and software for astronomical > observations. FITS doesn't have to try to be all things to all people - I don't think it would be successful it if did. It was developed for astronomical data, and the terminology should be oriented towards astronomy. In current astronomical use, "image" refers to a complex object (N-dimensional data array with associated header etc.). The terms array and picture refer to simpler things. This issue was discussed at both the European FITS meeting last May, and again at the WGAS. At the European meeting no one objected to the name "IMAGE" for this extension, and in fact most people there preferred the term. The issue wasn't discussed explicitly at the WGAS meeting; if I recall correctly the IMAGE extension was brought up for discussion and there were no objections raised. Doug Tody tody@noao.edu From wgas@Hypatia.gsfc.nasa.gov Mon Jun 22 16:05:58 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] ["2863" "Mon" "22" "June" "92" "16:01:35" "-0400" "William Thompson" "thompson@serts.gsfc.nasa.gov " "<9206221952.AA02669@serts.gsfc.nasa.gov>" "59" "IMAGE extension" "^From:" nil nil "6"]) Return-Path: Received: from cv3.cv.nrao.edu by fits.cx.nrao.edu (4.1/SMI-DDN) id AA20244; Mon, 22 Jun 92 16:05:56 EDT Received: from Hypatia.gsfc.nasa.gov by cv3.cv.nrao.edu (4.1/DDN-DLB/1.12) id AA04228; Mon, 22 Jun 92 16:07:23 EDT Received: from localhost.gsfc.nasa.gov by Hypatia.gsfc.nasa.gov (911016.SGI/1.35) id AA20024; Mon, 22 Jun 92 16:01:35 -0400 Message-Id: <9206221952.AA02669@serts.gsfc.nasa.gov> Comment: AAS Working Group for Astronomical Software Originator: wgas@hypatia.gsfc.nasa.gov Errors-To: leb@Hypatia.gsfc.nasa.gov Reply-To: Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: thompson@serts.gsfc.nasa.gov (William Thompson) Sender: wgas@Hypatia.gsfc.nasa.gov To: Multiple recipients of list Subject: IMAGE extension Date: Mon, 22 Jun 92 16:01:35 -0400 Doug Tody (tody@noao.edu) quotes me as saying: > > To my mind, the extension name IMAGE is *deceptively* simple. It > > implies something that just isn't necessarily true, i.e. that the > > extension contains a picture. > > It doesn't imply that to me. I suppose you are right that people in > other fields might be confused by the terminology but I think FITS should > be oriented towards astronomy. In any case, I don't see any problem with > generalizing the concept of "image" (or "data image") to mean something > more complex than a picture. > > > Are we going to have to have another extension, which is exactly the same > > except that XTENSION='SPECTRUM'? > > A simple spectrum is a one dimensional image. (there are also 2 and 3 > dimensional spectra). The proposed IMAGE extension could be used to > store spectra. > > > There are, however, people who do think that FITS is only for images, > ^^^^^^ > you mean pictures... > > > and who are surprised when they discover that it doesn't include > > support for those features which are common for standard raster image > > formats like GIF, TIFF, etc., e.g. embedded color tables, or RGB color > > separation. I've seen this confusion in people both on the > > (alt.)sci.astro.fits newsgroup, and in support personnel who have been > > working with us in developing hardware and software for astronomical > > observations. > > FITS doesn't have to try to be all things to all people - I don't think > it would be successful it if did. It was developed for astronomical > data, and the terminology should be oriented towards astronomy. In current > astronomical use, "image" refers to a complex object (N-dimensional data > array with associated header etc.). The terms array and picture refer > to simpler things. > > This issue was discussed at both the European FITS meeting last May, and > again at the WGAS. At the European meeting no one objected to the name > "IMAGE" for this extension, and in fact most people there preferred the > term. The issue wasn't discussed explicitly at the WGAS meeting; if I > recall correctly the IMAGE extension was brought up for discussion and > there were no objections raised. I just did an informal poll of nine astronomers here at the NASA Goddard Space Flight Center. I asked them if they could draw a distinction between the terms "picture" and "image". Not one of them could, at least in any way applicable to the digital storing of data. Only one of them had ever heard of the term "image" being applied in the way you use it, but only after I brought it up. I don't intend to produce a flame, but I do want to get the facts straight. The most cogent reason for sticking with the name "IMAGE" is that it is already in use, and I can live with that. Bill Thompson From wgas@Hypatia.gsfc.nasa.gov Mon Jun 22 16:25:18 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1788" "Mon" "22" "June" "92" "16:22:44" "-0400" "Archie Warnock" "warnock@Hypatia.gsfc.nasa.gov " nil "35" "Re: IMAGE extension" "^From:" nil nil "6"]) Return-Path: Received: from cv3.cv.nrao.edu by fits.cx.nrao.edu (4.1/SMI-DDN) id AA20281; Mon, 22 Jun 92 16:25:16 EDT Received: from Hypatia.gsfc.nasa.gov by cv3.cv.nrao.edu (4.1/DDN-DLB/1.12) id AA04647; Mon, 22 Jun 92 16:26:42 EDT Received: from localhost.gsfc.nasa.gov by Hypatia.gsfc.nasa.gov (911016.SGI/1.35) id AA20541; Mon, 22 Jun 92 16:22:44 -0400 Message-Id: <9206222019.AA20366@Hypatia.gsfc.nasa.gov> Comment: AAS Working Group for Astronomical Software Originator: wgas@hypatia.gsfc.nasa.gov Errors-To: leb@Hypatia.gsfc.nasa.gov Reply-To: Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: warnock@Hypatia.gsfc.nasa.gov (Archie Warnock) Sender: wgas@Hypatia.gsfc.nasa.gov To: Multiple recipients of list Subject: Re: IMAGE extension Date: Mon, 22 Jun 92 16:22:44 -0400 > I don't intend to produce a flame, but I do want to get the facts > straight. The most cogent reason for sticking with the name "IMAGE" is > that it is already in use, and I can live with that. I agree with Bill here. What prompted my original note was that the adoption of the name IMAGE does, in fact, blur the distinction between data structure and data interpretation. We (the FITS community) are, of course, free to do this. We should also make sure we understand that we _are_ blurring that distinction, and that it is something we are doing intentionally. It makes me uncomfortable to use IMAGE in this way. It would make me even more uncomfortable if someone were to seriously propose to use SPECTRUM in a similar way. You could, after all, store a 1-D spectrum as ordered pairs, as pairs of vectors, as a single flux vector and two scalars. They're all spectra. If we decide to continue to ignore the distinction between structures and interpretation, they'd all need different names. My contention is that they should all be referred to as "SPECTRUM", with some additional syntax to indicate (to the software, not necessarily to the end user) how they have been stored. Do I object to the name IMAGE enough to vote to reject the proposal on that basis alone? No, of course not. It's not something that's necessarily wrong. It's just an issue to be addressed and discussed. It's a bit glib and perhaps naive to dismiss the discussion simply because it hasn't been raised until now. ---------------------------------------------------------------------------- -- Archie Warnock Internet: warnock@hypatia.gsfc.nasa.gov -- Hughes STX "Unix --- JCL For The 90s" -- NASA/GSFC From wgas@Hypatia.gsfc.nasa.gov Tue Jun 23 05:23:40 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["7346" "Tue" "23" "June" "92" "05:24:28" "-0400" "Lucio Chiappetti - IFC Milano" "LUCIO%IFCTR.MI.CNR.IT@GIBBS.GSFC.NASA.GOV" nil "134" "Re: Thoughts from WGAS (1) ... images and pictures" "^From:" nil nil "6"]) Return-Path: Received: from cv3.cv.nrao.edu by fits.cx.nrao.edu (4.1/SMI-DDN) id AA21691; Tue, 23 Jun 92 05:23:37 EDT Received: from Hypatia.gsfc.nasa.gov by cv3.cv.nrao.edu (4.1/DDN-DLB/1.12) id AA12398; Tue, 23 Jun 92 05:24:56 EDT Received: from localhost.gsfc.nasa.gov by Hypatia.gsfc.nasa.gov (911016.SGI/1.35) id AA23180; Tue, 23 Jun 92 05:24:28 -0400 Message-Id: <9206230923.AA23147@Hypatia.gsfc.nasa.gov> Comment: AAS Working Group for Astronomical Software Originator: wgas@hypatia.gsfc.nasa.gov Errors-To: leb@Hypatia.gsfc.nasa.gov Reply-To: Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: Lucio Chiappetti - IFC Milano Sender: wgas@Hypatia.gsfc.nasa.gov To: Multiple recipients of list Subject: Re: Thoughts from WGAS (1) ... images and pictures Date: Tue, 23 Jun 92 05:24:28 -0400 >Lucio Chiappetti (LUCIO@IFCTR.MI.CNR.IT) writes: > >> I believe the IMAGE name in the IMAGE extension proposal to FITS is >> just the sort of thing which will NOT confuse the [average] users, >> and is part of the simplicity for which I like such proposal > .... omissis .... > >thompson@SERTS.GSFC.NASA.GOV(William Thompson) replies > >To my mind, the extension name IMAGE is *deceptively* simple. It >implies something that just isn't necessarily true, i.e. that the >extension contains a picture. Are we going to have to have another >extension, which is exactly the same except that XTENSION='SPECTRUM'? >I'm sure that at least 90% of the FITS data files out there do contain >just that--images. But not all do, and the IMAGE extension seems >intended for more than just pictures. See below for comment on images and pictures and spectra. To the question for XTENSION='SPECTRUM' my answer would be definitely no. I have always been very fond about Ockham's razor : "DATA STRUCTURES NON SUNT MULTIPLICANDA PRAETER NECESSITATEM (are not to be multiplied beyond what needed)" and I believe that with "images" and "tables" we are through, and can do all what we need. (In practice the FITS IMAGE extension is just a STRAIGHTFORWARD extension to the "classical" FITS files, and the TABLE and BINTABLE extensions are implementation of "tables" ; this looks conforming to the choices in most widespread astronomical packages, i.e. IRAF/STSDAS and MIDAS) > >There are, however, people who do think that FITS is only for images, >and who are surprised when they discover that it doesn't include >support for those features which are common for standard raster image > >To the above statement : > >> To my mind, the extension name IMAGE is *deceptively* simple. It > > tody@NOAO.EDU replies > >It doesn't imply that to me. I suppose you are right that people in >other fields might be confused by the terminology but I think FITS should >be oriented towards astronomy. In any case, I don't see any problem with >generalizing the concept of "image" (or "data image") to mean something >more complex than a picture. I fully agree on both statements (FITS astronomy-oriented, and image is different - more complex or simpler - than a picture) >> There are, however, people who do think that FITS is only for images, > ^^^^^^ >you mean pictures... > Neither I nor any of my colleagues around here have ever used technically ----------- the word "picture" in an astronomical context (the only case is talking - usually with a contemptuous meaning - of "pretty pictures") We handle "images", "spectra" and "light curves" (to which, in an X-ray astronomy environment, I would add "photon lists"). Personally I have always interpreted "image" as z=f(x,y), that is a quantity as a function of two other quantities, with constant x and y steps. I never cared whether z was flux, counts, chi-square or any other parameter, and used an "image" format (in whatever package I was using at the moment, including my own) for things like an X-ray sky image (counts vs detector x y pixels), a chi-square map (chi-square vs spectral index and log hydrogen column density for instance), the parameter of a spectral fit as a function of any other couple of parameters, count rates as a function of energy and time, "power" (intended as the result of a Fourier transform) as a function of frequency and time, chi-square as a function of period and energy etc. (the last three examples refer to the case of temporal analysis done simul- taneously for many energy bands or many time intervals) Some of my colleagues reserve the word "image" to the case z=f(x,y) where x,y are SPATIAL coordinates (detector pixels, or related to celestial coordinates) and use "pseudo-image" when x,y are non-spatial (e.g. counts as a function of energy and risetime for a phoswich detector). In all cases "images" are the sort of things which are displayed as colour or gray scales, contour plots, isometric plots etc. (the sort of things you do in any packages, IRAF, MIDAS or IDL ... which looks aquite straightforward way of using this z=f(x,y) definition) ... irrespective of their content. Concerning "spectra" they stand at a different rank. Most optical-UV astronomers are contented to see "spectra" a z=f(x), that is, 1-dimensional images in the sense described above, and this is what usually IRAF, MIDAS etc. do. I personally tend to use the word "histogram" to define a generic z=f(x) usually with constant x-step, irrespective of the content (it can be counts vs wavelength, energy, risetime, time etc. etc.) I always felt that the above definition were too limited for the high-energy case, where the error sigma(z) associated to the value z=f(x) (with z count rates and x energy) is important. In this case a "spectrum" is a set of values WITH an associated error, and the software shall act on a spectrum as an unit (ie. adding two spectra shall imply error propagation, that's why I always felt uneasy with s/w packages developed for optical. Nevertheless the application of Ockham's razor to X-ray astronomy comes out with four "logical" data structures (images, spectra, light curves and photon lists), and a repeated application of the razor allows to map them to two "physical" (if the term is allowed) data structures (that is images and tables; for transport - the T in FITS - they map nicely to classical FITS files, perhaps with IMAGE extension, and BINTABLEs). I must add that I am personally quite WORRIED already of the wealth of possible different logical structures which can be accomodated as binary tables ... looking at the discussions on WGAS and FITSBITS, and I would strongly encourage to use Ockham's razor here too. It is also likely, I'm afraid, that particular/peculiar/strange/funny extensions/interpretations are likely to be confined to a particular envi- ronment or software package. Most of the users will accept only structures which they are supported by 'readers' already incorporated in "major" data packages, or that can be "converted" with a few simple user commands, and will at least scream, and most likely try not to use the data at all, if each new structure requires a brand new tool to be written by them. >This issue was discussed at both the European FITS meeting last May, and >again at the WGAS. At the European meeting no one objected to the name -------- ah, that's why I like it | ----------------------------------------------------------------------------- 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@IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: EXOSAT@IMISIAM | ----------------------------------------------------------------------------- Acknowledge-To: