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

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
http://spider.ipac.caltech.edu/staff/jarrett

On Wed 2005/02/16 16:44:12 -0800, Tom Jarrett wrote
in a message to:

Hi Tom,

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

I believe that various packages have methods for doing this but I'm not
aware of any attempt to standardize it (not being a WCS issue).

Has this problem already been solved? I have heard (from a source of a

It is recognized that WCS Paper IV will need to deal with something like
this, e.g. to allow distortion functions to be described separately for
each CCD in an image composed of a mosaic of CCDs. However, no real
thought has been given to it.

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

I think this, or something similar to it, is probably about the best you
could do for now.

However, a general scheme for Paper IV would have to differ in a number
of respects:

* It could not be limited to two coordinate axes, and not just to RA &
Dec, so the "R" and "D" in R/DAPi_j would have to become integer
indices.

* To handle a mosaic of CCDs, for example, you'd need to tack on an
alternate WCS specifier to associate each region with a particular
coordinate description.

* I suspect that it would be better to specify the vertices in pixel
coordinates rather than world coordinates. I'm thinking of the long-
slit example in Paper II where each point in a 2-D image (with a
degenerate third axis) has independent ra, dec, and wavelength.

So the keyword would have to contain the following components:

* A name part,
* The polygon number,
* The vertex number,
* The axis number,
* An alternate WCS specifier,

and, for the BINTABLE version,

* A column number.

It seems inevitable that the eight character FITS keyword limit would
prove too restrictive, especially for the BINTABLE version of the
keywords. A solution would be to use the record-valued keyword syntax
described in the current draft of Paper IV. However, this is highly
experimental and it would certainly be premature to use it for your
current data.

Cheers, Mark

On Wed 2005-02-16T16:44:12 -0800, Tom Jarrett hath writ:
2. How to encode the 'extraction area' into the header?

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?

Have you seen the Euro3D data format at
http://www.aip.de/Euro3D/software.html

It specifies some shapes for IFUs, although not general polygons.

--
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064
Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93

Tom,

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?

See

http://hea-www.harvard.edu/~arots/nvometa/

although I know of no FITS serialisation as yet, just XML.

David



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
http://spider.ipac.caltech.edu/staff/jarrett
_______________________________________________
fitsbits mailing list

http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits

On Thu, 17 Feb 2005, Mark Calabretta wrote:

It is recognized that WCS Paper IV will need to deal with something like
this, e.g. to allow distortion functions to be described separately for
each CCD in an image composed of a mosaic of CCDs. However, no real
thought has been given to it.

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

I think this, or something similar to it, is probably about the best you
could do for now.

However, a general scheme for Paper IV would have to differ in a number
of respects:

* It could not be limited to two coordinate axes, and not just to RA &
Dec, so the "R" and "D" in R/DAPi_j would have to become integer
indices.

Support for N-dimensional polygons sounds hard! The IVOA STC model
restricts polygons to 2D.

David

I can recommend the FITS Region convention that is being used by
Chandra for spatial region definitions. It would have the added
advantage of not increasing the number of conventions while fostering
interoperability.

See:

http://cxc.harvard.edu/contrib/arots/fits/region.ps

We will be happy to provide more details.
And, btw, it is nicely compatible with the VO region standard.

- Arnold

Tom Jarrett wrote:
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
http://spider.ipac.caltech.edu/staff/jarrett
_______________________________________________
fitsbits mailing list

http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits

--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

Oops, I missed this part.
See the region description in the STC documentation:

http://us-vo.org/projects/project.cfm?ID=62

- Arnold

Tom Jarrett wrote:

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?


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

http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits

--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

Arnold Rots wrote:
I can recommend the FITS Region convention that is being used by
Chandra for spatial region definitions. It would have the added
advantage of not increasing the number of conventions while fostering
interoperability.

See:

http://cxc.harvard.edu/contrib/arots/fits/region.ps


This looks very promising. We have some (naive) questions:

1. we need a real example to understand where/how to
encode this into FITS header. can you point us to a fits file
that uses this spatial region convention?

2. regarding *multiple* regions. How do you indicate
more than one region for a single file (here we are thinking
of N-dim spectral cubes)?

How do we indicate that the region of extraction is given in
REGION extension names "WHATEVER", and what should "WHATEVER" be? We
get to decide this essentially, but I suppose it depends somewhat on
what some mythical ds9 of the future, or super-VOBS tool, would want to
see. We bet the ds9-of-the-future would be happy to have lots of
different regions, distinguished by the extension name they occur in
(1 region=1 FITS extension).

3. last question: regarding the X-Y dimension, how to encode this
with pure celestial coordinates? We think Chandra uses
pixel coordinates + WCS, but which makes less sense for 1D Spitzer spectra.

Thanks again for help out,
-tom jarrett & J.D. Smith