Subject: Re: Thoughts from WGAS (1) ... images and pictures

From: Lucio Chiappetti - IFC Milano <[email-masked]>
Date: Tue, 23 Jun 92 05:24:28 -0400

>Lucio Chiappetti ([email-masked]) 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 ....
>
>[email-masked](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
>
>      [email-masked] 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: [email-masked]            |           FORTUNAE SUAE
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |
Bitnet:   EXOSAT@IMISIAM                   |
-----------------------------------------------------------------------------
Acknowledge-To: <EXOSAT@IMISIAM>