Yup. I should have gone on to say that making those keywords into
constant valued columns simply shuts up fitsverify, it doesn't make it
any more of a valid way of conveying the WCS information. Note that in
the SDFITS convention, each row is a N-dimensional image with all but
the first axis being degenerate (i.e. each row is a spectrum). Since
some of the WCS information for each row may change per row (the most
common being CRVAL1 when the spectral axis is in the topocentric frame)
it's convenient to store that as a column so that you can still store
many spectra in each table. But the bottom line is that the original
SDFITS convention (late 80's) predates the WCS papers and it needs to be
tweaked a bit to follow the WCS papers. There are other issues with
SDFITS that I haven't felt like revisiting so I've been reluctant to
restart that conversation with the interested parties.
Bob
William Pence wrote:
The new FITS Standard document, in table 8.2, defines the keyword naming
convention (taken from the WCS papers) that one should use if the image
is stored as a multidimensional vector in a binary table column. (See
http://fits.gsfc.nasa.gov/standard30...rd30index.html
page 77).
Here are some examples, where 'i' is the axis number, 'n' is the column
number that contains the image, and 'a' is the optional alternate axis
label from A to Z):
Primary Array Bintable vector
------------- ---------------
CTYPEia iCTYPn or iCTYna
CRVALia iCRVLn or iCRVna
CDELTia iCDLTn or iCDEna
-Bill
Bob Garwood wrote:
That appears to be the SDFITS convention, which predates the WCS papers
and agreements. The WCS information in those tables is unlikely to be
widely understood as a result. The SDFITS convention needs to be
updated to take into account the accepted ways of conveying WCS
information in binary tables. If the DATA array column dominates the
table size, then I suspect adding a few extra scalar columns won't
greatly increase the table size.
-Bob
Mike Nolan wrote:
We're writing radio data in binary tables, and fitsverify hates them:
133) fitsverify /share/pdata1/pdev/x108.20080826.b0s1g0.
00800.fits
fitsverify 4.13 (CFITSIO V3.090)
--------------------------------
File: /share/pdata1/pdev/x108.20080826.b0s1g0.00800.fits
2 Header-Data Units in this file.
=================== HDU 1: Primary Array ===================
16 header keywords
Null data array; NAXIS = 0
=================== HDU 2: BINARY Table ====================
*** Error: Keyword #29, CTYPE1 is not allowed in the Bin/ASCII table.
*** Error: Keyword #31, CTYPE2 is not allowed in the Bin/ASCII table.
*** Error: Keyword #44, CTYPE2G is not allowed in the Bin/ASCII table.
... many more similar errors
Some of the WCS parameters are table columns:
COMMENT axis 1 is the frequency axis
TTYPE6 = 'CRVAL1 ' / Center frequency
TFORM6 = '1D ' /
TUNIT6 = 'Hz ' /
TDISP6 = 'D13.5 ' /
TTYPE7 = 'CDELT1 ' / Frequency interval
TFORM7 = '1D ' /
TUNIT7 = 'Hz ' /
TDISP7 = 'D13.5 ' /
TTYPE8 = 'CRPIX1 ' / Pixel of center frequency
TFORM8 = '1D ' /
TUNIT8 = ' ' /
TDISP8 = 'D13.5 ' /
but others are constant, so we're putting them in the table header
per the "Green Bank Convention".
CTYPE1 = 'FREQ ' / Type of coordinate
CUNIT1 = 'Hz ' / Unit of center frequency
These files are massive and written at 80 MB/s, so we really don't want to make them any bigger than they have to be.
Does that really make us bad people? Or have I missed something?
Thanks,
-Mike
_______________________________________________
fitsbits mailing list
http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits