[fitsbits] Spectral FITS -- encoding extraction area/continuum

[Tom Jarrett]

FITS experts,
I have two questions that pertain to spectral
2-D data that is derived from the
Spitzer Space Telescope "IRS" spectrometer.
The Spitzer Science Center (of which I am the
archive scientist) is now considering how to
package this data for public consumption.
So we now turn to the FITS experts for advice.
Many thanks ahead of time (and thanks to
Bill Pence for pointing me to this group). -tom jarrett

Spectral "maps" are constructed from IRS long-slit
scans across a source (which provide both spatial
and spectral coverage).  Coming this spring, Spitzer
will be releasing its first spectral maps (courtesy of
the SINGS Legacy Project).  The FITS will either be
binary tables (for 1-D spectra) or the new
"table lookup" for 2-D maps and 3-D cubes.
But there are two FITS header issues that have not been
settled yet:

1. How to encode the the wavelength range(s)
where the background (continuum) was determined?
How to encode the polynomial fitting parameters?

This info could of course be written as a COMMENT in the
header.  But we would like to know if there is a way
to properly encode it using FITS keywords.

2. How to encode the 'extraction area' into the header?
The WCS rectangle may not be appropriate for complex
extractions (where multiple pointings with a long slit are combined)
One of the SINGS members, J.D. Smith (Univ. Arizona)
has a proposal that I've included below.

Has this problem already been solved?  I have heard (from a source of a
source) that the NVO is now developing a standard for describing
areas using multiple circles.  Can anyone point me to some
of this work?

J.D. Smith (U of A):
For spectral maps, unlike for staring mode observations, the extraction
aperture on the sky is not a fixed size.  For our SINGS releases, we're
typically delivering rectangular extractions (in the tangent-plane space
of our small spectral maps).  But to be general, I thought allowing
arbitrary polygonal extraction regions would be valuable, and multiple
disjoint regions as well.  Something like:

RAPi_j = 1.2345  / RA of Polygonal Aperture [deg]
DAPi_j = 2.3448  / RA of Polygonal Aperture [deg]

where i ranges over different polygons, and j ranges over the points in
a single polygon `i'.  Not terribly transparent naming, but that would
allow for i,j=1..99 to fit under 8 characters.  For SINGS, then, we'd
have something like:

RAP1_1 = 339.27008
DAP1_1 = 34.407056
RAP1_2 = 339.25979
DAP1_2 = 34.421139
RAP1_3 = 339.26458
DAP1_3 = 34.423528
RAP1_4 = 339.27487
DAP1_4 = 34.409444

with the option of adding, e.g.

RAP2_1
DAP2_1
...

for a future release with disjointed extraction apertures.  This same
specification could describe photometric apertures on images as well.
I'm not sure if the standard numbered keywords, e.g. PCi_j, include up
front a count of how far i and j will range.  It's possible this could
be generalized even further, to allow for arbitrary dimensional units
(not just RA/DEC, e.g. pixels, wavelength, etc.).  Perhaps one of the
experts could weight in on this.

Note from Jarrett:
 >Do we care about the multitude of slit angles that were
 > used to create the map?  I guess not since this information
 > is encoded in the map itself.

J.D.SMith:
Anyway, rectangles are probably fine, but the point is that
this pertains to 1D spectral FITS data, and can have no relation to some
FITS cube or image of a given size.  Just like specifying WCS has
nothing to do with the detector used to observed an image.  I could
probably do with a rectangle, i.e. specifying, center, width, height,
and roll angle of the long axis, but I thought polygons would be more
general.  In particular, averaging together 3 disjoint polygonal
extractions.  In the ideal world, other shapes like circles would be
specifiable as well.


-- 
********************
Dr. Thomas Jarrett                              phone: (626)395-1844
IPAC/Caltech, Pasadena, CA                       fax: (626) 397-7018
jarrett at ipac.caltech.edu   http://spider.ipac.caltech.edu/staff/jarrett