|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] Representation of polarimetry data in WCS
An important consideration is what will the recipients of your FITS
files expect or can hasndle. If they're going to be using certain applications packages, you might find out what formats those packages support. My preference was not to have a Stokes axis, because each element measures a different thing. I know the purists are outnumbered by the pragmatists, and it's now in the standard, so I'm not going to win that argument. Still... I like a MEF with each Stokes-parameter array in its own IMAGE extension with suitable extension type information* to indicate which array is provided. The secondary arrays like the polarization intensity can also be included in this arrangement. As they're not Stoke parameters, but derivatives, they weren't included in CTYPEn = 'STOKES' in WCS Paper I. Another approach is to use a `Greenbank Convention' binary table, where each row contains the different polarization array along with array-specific metadata, and primary HDU contains the dataset's global metadata. Disadvantages of these suggestions include the fact that there's no conventional agreement on recognising the various array types. An arbitrary FITS reader can still import the data, but won't necessarily know what to do with or the meaning of the various components. Some documentation will be needed. You can of course, have a Stokes axis for the Stokes-parameter arrays, and store the additional arrays like polarization intensity in IMAGE or binary-table extensions. For the Stokes parameters I'd advocate following the documented convention, not least because others are likely to do the same. [I'm a grumpy old man who thinks FITS is for data interchange.] I don't know of a standard or widely used convention for handling the ancillary arrays. It is something of a specialist field. In Starlink, although our Standard Data Formats document did advocate not to use a Stokes axis but separate arrays, one of our two polarimetry packages ignores that recommendation. That's a good question about the 4-3 notation. Now that you mention it, I only recall seeing CTYPEn = 'STOKES'. Surely other algorithms that operate on 'STOKES' would be documented. Malcolm Currie Rutherford Appleton Laboratory * EXTTYPE is a keyword omitted in the FITS extension paper---sorry Don---that I needed to export from our hierarchical data structures in order to retain the structure information, and if necessary recreate the hierarchy from the FITS extensions. Omitting EXTTYPE has caused EXTNAME to be used for both the name of a component and its type, e.g. VARIANCE, QUALITY, integration-time map. I raised this with Bill Pence a while back. Another bolted horse I fear. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
swift grb data rules out beamed theory | sean | Astronomy Misc | 11 | April 3rd 06 10:29 PM |
BWAAHAHA!!! 51L questions answered... | [email protected] | History | 10 | March 13th 05 02:26 AM |
Pioneer 10 test of light speed delay | ralph sansbury | Astronomy Misc | 131 | March 3rd 05 10:15 PM |
Space Shuttle | ypauls | Misc | 3 | March 15th 04 01:12 AM |
A single data point. | Rich | SETI | 2 | October 8th 03 06:02 AM |