A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

[fitsbits] which WCS keywords?



 
 
Thread Tools Display Modes
  #1  
Old September 14th 05, 08:14 PM
Phil Hodge
external usenet poster
 
Posts: n/a
Default [fitsbits] which WCS keywords?

I have a question about what world coordinate system (WCS) keywords to
use for some image data that do not fit neatly into any of the three
categories listed in "Representations of world coordinates in FITS,"
Greisen and Calabretta 2002, Astron & Astrophys, volume 395, pp 1061 -
1075 (Paper I).


The three image formats for FITS files listed in Table 2 of Paper I
a (a) a primary array or IMAGE extension (i.e. a conventional
image), (b) a multidimensional array in a BINTABLE column, and (c) a
tabulated list of pixels in a BINTABLE. Different keywords are needed
for these three cases because keywords for (b) include a column number
and keywords for (c) include one or two column numbers.


The image format in question is for the Kepler spacecraft. An array of
CCD detectors will be used to take of images of a region of the sky.
See http://www.kepler.arc.nasa.gov/
Because of the large data volume, most of the data will be discarded;
pixel values in a small region around each of the 170,000 or so targets
will be returned from the spacecraft to Earth. The (proposed) FITS data
format is a BINTABLE extension for each chip, with two columns; one
column has the raw pixel values and the other column has the calibrated
pixel values. It will not be possible to tell from the data file alone
where a given table element is on the CCD; to avoid redundancy the pixel
numbers are given in a separate reference table which is identified by a
header keyword. If the pixel numbers were in the data file, this would
be case (c), a tabulated list of pixels. The keywords for case (c)
cannot be used for the Kepler data format,
however, because the keywords include the column numbers of the pixel
coordinates, and those columns don't exist. It seems to me that case
(b) is reasonably close, even though the element at a given row and
column is only a single value (1-D array of length 1). The value in
each row really is an image, albeit a very small one! The keywords for
case (b) include a column number, which in this case would be 1 for the
raw data and 2 for the calibrated data.


My question is whether I would be stretching the limits of the FITS
standard to use the WCS keywords for a "multidimensional array in a
BINTABLE column" for Kepler data. If so, is there a more reasonable
alternative? One point that I haven't mentioned but may be relevant is
that the values of the WCS keywords will be nearly constant over a
period of three months (the spacecraft will be rolled 90 degrees every
three months). There will be small, predictable shifts and scale
changes due to velocity aberration, and such effects as pointing errors
and temperature variations could introduce small, unpredictable shifts.


Phil
  #2  
Old September 15th 05, 05:39 PM
Doug Mink
external usenet poster
 
Posts: n/a
Default

Phil Hodge wrote about Kepler data for which data and WCS information
are in separate files, if I understand correctly. What I would do is
to archive the data on the ground in files with data and WCS in the
same file in a BINTABLE. The files sent down from the spacecraft
don't have to be FITS standard, just the archived information.

-Doug Mink
  #3  
Old September 15th 05, 06:10 PM
Phil Hodge
external usenet poster
 
Posts: n/a
Default

Doug,

The question was more about which set of WCS keywords to use, for the
case that the data and the keywords were in the same file. My original
message was probably too wordy; the question was buried by the
background info!

Phil
  #4  
Old September 16th 05, 08:50 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default


On Wed 2005/09/14 15:14:21 -0400, Phil Hodge wrote
in a message to:

Because of the large data volume, most of the data will be discarded;
pixel values in a small region around each of the 170,000 or so targets
will be returned from the spacecraft to Earth. The (proposed) FITS data
format is a BINTABLE extension for each chip, with two columns; one
column has the raw pixel values and the other column has the calibrated
pixel values. It will not be possible to tell from the data file alone
where a given table element is on the CCD; to avoid redundancy the pixel
numbers are given in a separate reference table which is identified by a
header keyword.


In splitting the files I assume that you will associate each row of one
with the corresponding row of the other? Why not just have a bintable
with four columns: the two pixel coords, and the raw and calibrated
pixel values (and maybe other columns as well)? This is in keeping
with the model established in Sect. 3.2 of Paper I.

If the pixel numbers were in the data file, this would
be case (c), a tabulated list of pixels. The keywords for case (c)
cannot be used for the Kepler data format,
however, because the keywords include the column numbers of the pixel
coordinates, and those columns don't exist.


The pixlist WCS keywords must be associated with the pixel coordinate
values, even if they're in a separate file, not with the pixel
brightness values. Specifically the "n" in keywords like TCTYPn refers
to the column containing the pixel coordinate value, p_j.

It seems to me that case
(b) is reasonably close, even though the element at a given row and
column is only a single value (1-D array of length 1). The value in
each row really is an image, albeit a very small one! The keywords for
case (b) include a column number, which in this case would be 1 for the
raw data and 2 for the calibrated data.


You would need to add four columns to record iCRVLn for both the raw
(1CRVL1, 2CRVL1) and calibrated values (1CRVL2, 2CRVL2) - the other
bintable WCS keywords, being constant, could be stored in the header
via the Greenbank convention. But in fact you'd be better off just
storing the ra and dec in separate columns, i.e. no WCS at all.

My question is whether I would be stretching the limits of the FITS
standard to use the WCS keywords for a "multidimensional array in a
BINTABLE column" for Kepler data.


One-element arrays are within the limits of the formalism, it's just
that it doen't make much sense to use them. What you have is a clear-
cut case of a pixel-list.

Mark Calabretta
ATNF

  #5  
Old September 16th 05, 01:52 PM
Phil Hodge
external usenet poster
 
Posts: n/a
Default

Mark Calabretta wrote:

In splitting the files I assume that you will associate each row of one
with the corresponding row of the other?


Yes.

Why not just have a bintable
with four columns: the two pixel coords, and the raw and calibrated
pixel values (and maybe other columns as well)? This is in keeping
with the model established in Sect. 3.2 of Paper I.


In order to save about 7 TB of archive space per year. The pixel
coordinates are constant for three months, so putting them in the
same file with the data would introduce a great deal of redundancy.
And there will be other columns in the separate reference table, yes.

The pixlist WCS keywords must be associated with the pixel coordinate
values, even if they're in a separate file, not with the pixel
brightness values. Specifically the "n" in keywords like TCTYPn refers
to the column containing the pixel coordinate value, p_j.


Right. That's why I can't use the keywords for a pixel list.

You would need to add four columns to record iCRVLn for both the raw
(1CRVL1, 2CRVL1) and calibrated values (1CRVL2, 2CRVL2) - the other
bintable WCS keywords, being constant, could be stored in the header
via the Greenbank convention. But in fact you'd be better off just
storing the ra and dec in separate columns, i.e. no WCS at all.


Then we would have the ra and dec for each row, but we wouldn't be
able to convert from ra and dec to pixel coordinates. It would be
better to add the two columns of pixel coordinates and then use the
keywords for a pixel list.

I was proposing to use header keywords that would define the
transformation between pixel coordinates and ra & dec. The data block
of the FITS file won't contain an image array, just individual pixel
values, so what's missing is the connection between pixel value and
pixel location on the detector. The WCS keywords will still make it
possible to compute, say, the location on the detector corresponding
to a given ra and dec, or vice versa.

One-element arrays are within the limits of the formalism, it's just
that it doen't make much sense to use them. What you have is a clear-
cut case of a pixel-list.


Yes, but without the pixel coordinates, and I think we've both agreed
that the keywords for a pixel list cannot be used because they refer
to the numbers of columns that don't exist.

Phil

  #6  
Old September 19th 05, 01:55 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default


On Fri 2005/09/16 08:52:34 -0400, Phil Hodge wrote
in a message to:

coordinates are constant for three months, so putting them in the


OK that clarifies things a little - you have the same set of pixels for
months on end and their world coordinates may change, but only a little.

If that is so, then define the pixlist WCS keywords for the pixel
coordinate table and use alternate WCS specifications to get up to 27
coordinate descriptions. If you needed more than 27 you might have to
duplicate the pixel location file but at least you'd have cut down your
7TB by a factor of x27, to about 260GB. You'd also need to record in
the pixel location file which of the alternates was valid for a
particular time-span (or whatever), and possibly record in the pixel
value file which of the alternates should be used.

Then we would have the ra and dec for each row, but we wouldn't be
able to convert from ra and dec to pixel coordinates. It would be
better to add the two columns of pixel coordinates and then use the
keywords for a pixel list.


It was meant to be a reductio ad absurdum argument, but I was forgetting
about bintable cross-references (Paper I, Sect. 3.5) so at least you
wouldn't have to repeat the WCS for the raw and calibrated data, i.e.
you'd only need to store the ra/dec once and create a cross-reference
using WCSTna and WCSXna. The point though is that it doesn't work at
all well to use the bintable array WCS keywords.

What you'd really like is for cross-references to work between files,
but that's not defined.

Mark Calabretta
ATNF

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Robert Foot's mirror matter hypothesis relevant to dark accelerators? Murray 2003.03.30 Rich Murray Astronomy Misc 1 March 31st 05 10:50 AM
Robert Foot's mirror matter hypothesis relevant to dark accelerators? Murray 2003.03.30 Rich Murray UK Astronomy 1 March 31st 05 10:50 AM
[fitsbits] WCS Paper III MJD-AVG vs. DATE-AVG Steve Allen FITS 1 October 22nd 04 07:53 PM
[fitsbits] WCSLIB 3.5 Mark Calabretta FITS 0 June 28th 04 08:16 AM
[fitsbits] BLANK keyword misinterpretation Steve Allen FITS 4 November 21st 03 05:42 PM


All times are GMT +1. The time now is 12:09 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.