|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[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 |
#2
|
|||
|
|||
|
#3
|
|||
|
|||
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 |
#4
|
|||
|
|||
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 |
#5
|
|||
|
|||
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 |
#6
|
|||
|
|||
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/ -------------------------------------------------------------------------- |
#7
|
|||
|
|||
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/ -------------------------------------------------------------------------- |
#8
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FITS long integer support (was [fitsbits] ADASS FITS BoFon Sunday) | William Pence | FITS | 6 | October 22nd 04 08:23 PM |
[fitsbits] Comment Period on 2 FITS Proposals | William Pence | FITS | 0 | October 21st 04 09:56 PM |
[fitsbits] Start of the FITS MIME type Public Comment Period | William Pence | FITS | 8 | June 17th 04 06:08 AM |
[fitsbits] Happy Birthday, FITS! | Don Wells | FITS | 0 | March 28th 04 01:58 PM |
Reading floating point FITS files | John Green | FITS | 34 | November 29th 03 12:31 AM |