[fitswcs] inherit vs. concatenate
Steve Allen
sla at ucolick.org
Tue Jan 1 04:56:02 EST 2002
On Mon 2001-12-31T16:29:10 -0700, Eric Greisen hath writ:
> I am forwarding a portion of Steve's reply to Mark and me. This
> portion needs wider consideration.
> ------- start of forwarded message (RFC 934 encapsulation) -------
> As fodder for discussion I suggest a keyword WCSBASEs which would have
> a string value consisting of a single character. The meaning of
> WCSBASEA = 'B' would be that the WCS parameters for alternative WCS
> A would default to those of WCS B unless explicitly overridden by
> keywords for WCS A.
> ------- end -------
I have a followup based on work that I have been doing subsequent to
the suggestion that Eric repeated above. I have been working on
generalizing the code of the data acquisition system for our mosaiced
CCD detectors. One of the necessary features of the generalized code
is that it be able to concatenate WCS transformations. The necessary
concatenations are simple ones that I will describe quickly here.
%%%%%%%%%%%%%%%%
The CCDs of the mosaic are mounted in the dewar in a fashion which
(for practical purposes) can be considered rigid. This means that
there is a natural WCS transformation from CCD pixel to linear
coordinate in the focal plane (i.e., meters from the axis of the
optics). Because of its stability, this CCD-pixel-to-focal-plane WCS
can be stored in a configuration file that is read by the data
acquisition system upon startup, but it is not a WCS that can be
placed into a FITS image. For the FITS image the WCS draft papers
require that the WCS keywords describe the transformation from FITS
pixel to focal plane. This requires knowing the WCS from FITS pixel
to CCD pixel.
The WCS from FITS pixel to CCD pixel depends on the number of prescan
pixels and rows (bias signal charge shifted out of the CCD prior to
charge that comes from actual potential wells in the silicon of the
CCD), the binning that is used for columns and rows, and which of the
several amplifiers on each CCD is/are in use during the readout of the
CCD.
So, in order to write a correct FITS WCS, the data acquisition system
must determine which of the possible FITS-to-CCD-pixel transformations
matches the particular CCD readout, and then it must concatenate that
WCS with the (relatively immutable) CCD-to-focal-plane WCS read from
the configuration file. Fortunately, the FITS-to-CCD-pixel WCS is
purely a linear transformation, and this is trivially concatenated
onto the CDELT/PC/CD matrix of the CCD-to-focal-plane WCS.
(In the end system this also means that there will be a transformation
from CCD pixel to bore-sight coordinates of the telescope, but for the
instrument under development we can't get there until we mate with the
telescope. Bore-sight coordinates of the telescope are related to
catalog celestial coordinates by knowing the telescope pointing and
including differential refraction.)
%%%%%%%%%%%%%%%%
I write up this exercise because I think it points out that
concatenations of WCSs should be considered as relatively common
operations. Indeed, they are so common that perhaps they should be
included as part of the WCS standard.
Example code implementing concatenations of FITS WCS has already been
written by Doug Mink at Harvard/SAO. It is part of the WCSTools
version 3 library described at
http://tdc-www.harvard.edu/software/wcstools/
The particular feature of concatenation is included in Doug's
"dependent coordinate systems" and as seen in
ftp://cfa-ftp.harvard.edu/pub/gsc/WCSTools/Versions
that is a feature that has been present since version 2.9.0 in February
of 2001.
It appears that Doug Mink has not documented the notion of WCS
concatenation as implemented in his code. If I recall correctly it
adds a keyword WCSDEPs for which the semantics are that
WCSDEPB = 'A'
means that WCS version B uses as inputs not the pixel coordinates
but rather the outputs of WCS version A.
(In passing it is worth noting that Doug Mink has solved at least some
of the heuristic problems of interpreting the plethora of proto-WCS
keywords which are currently in relatively common use in FITS files. See
http://tdc-www.harvard.edu/software/wcstools/wcstools.wcs.html
for a partial description.)
In my suggestion to Greisen and Calabretta I was trying to find a way
to prevent a need to replicate the possibly hundreds of distortion
correction function coefficients that could be part of a precision
optical WCS. My offhand suggestion was to incorporate some form of
inheritance into the WCS drafts. Upon consideration of the code that
I have started to write I now feel that concatenations of WCSs are
probably a more elegant way of solving the problem that I posed (along
with many other problems).
--
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064
sla at ucolick.org 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
More information about the fitswcs
mailing list