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: <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: Lucio Chiappetti - IFC Milano <EXOSAT%IMISIAM.BITNET@GIBBS.GSFC.NASA.GOV>
Sender: wgas@Hypatia.gsfc.nasa.gov
To: Multiple recipients of list <wgas@Hypatia.gsfc.nasa.gov>
Subject:      Re: Thoughts from WGAS (1)
Date: Mon, 22 Jun 92 04:33:00 -0400


 <warnock@Hypatia.gsfc.nasa.gov> 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 <EXOSAT@IMISIAM.MI.CNR.IT>
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 <pgrosbol@eso.org>

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: <EXOSAT@IMISIAM>



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: <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
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 <wgas@Hypatia.gsfc.nasa.gov>
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 <EXOSAT@IMISIAM.MI.CNR.IT>
> 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 <pgrosbol@eso.org>
> 
> 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: <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: tody@noao.edu
Sender: wgas@Hypatia.gsfc.nasa.gov
To: Multiple recipients of list <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
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 <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
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 <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
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: <wgas@Hypatia.gsfc.nasa.gov>
Version: 5.41 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: Lucio Chiappetti - IFC Milano <LUCIO%IFCTR.MI.CNR.IT@GIBBS.GSFC.NASA.GOV>
Sender: wgas@Hypatia.gsfc.nasa.gov
To: Multiple recipients of list <wgas@Hypatia.gsfc.nasa.gov>
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: <EXOSAT@IMISIAM>