Subject: WCS questions

From: swalton at galileo.csun.edu (Stephen Walton)
Date: 8 Dec 96 01:15:40 GMT

[Sorry if you see this twice;  the first post didn't propagate
very far, apparently.]

At the recent RISE 96 workshop at HAO in Boulder we discussed the 
possibility of adopting the standard in the solar community that the
linear part of the WCS of a solar image result in (x, y) coordinates
such that x**2 + y**2 = 1 at the solar limb, with (x=1, y=0) at the
solar West limb and (x=0, y=1) at the solar North limb.  This makes a
good deal of sense from the perspective of solar astronomers, who often
want to work with the radial distance from the center of the disk.  At
the workshop, I was asked to write a small sample program, probably in
Fortran, to show how to add WCS information to a solar image whose
geometry is given in the header in some other format.

However, I am now unsure how to proceed.  It is clear from the WCS
draft spec that the units of (x,y) are to be degrees, which is far less
convenient for solar (and I presume planetary) astronomers, for whom
the center and the limbs of the object being observed are the logical
reference points.  On the other had, we also need the ability to map
pixel coordinates to latitude and longitude, which is the intent of the
AZP mapping.

How much violence would it do to the WCS draft to have a new CTYPE
pair, perhaps "PLAT----" and "PLON----" (Planetary latitude and
longitude), for which the units of (x, y) would be normalized distance
from object center rather than degrees?  I'd prefer SLAT and SLON for
"solar," of course, but these seem to have been reserved for other
purposes :-) .

A related comment, and the reason this is cross-posted, is which matrix
to use, the PC matrix or the CD matrix.  I ask because IRAF, at the
moment, has the most complete and easy-to-use WCS implementation of
which I'm aware, including automatic update of the WCS when images are
magnified, rotated, or subsections copied, but is based on the CD
matrix.  This convenience within IRAF, and the recent WCS-based  image
matching tasks there, are, in my opinion, one of the major reasons for
adopting a WCS convention.  But I want to remain compatible with other
software such as IDL, FITSIO, WCSLIB, and so on.

It is also quite unclear from the WCS specification "how much" of the
coordinate transformation should be in the PC matrix, and how much in
the CDELT values.  It seems as if the idea is that an image rotation,
for example, would only require changing the PC matrix, but this
should be made more precise in some manner.

Sorry for the length of this.  Thanks to those of you who've read to
the end and care to comment.

--
Stephen Walton, California State University, Northridge
"Be careful what you wish for;  you might get it."	swalton at csun.edu

---

From: Mark Calabretta <mcalabre at atnf.csiro.au>
Date: Mon, 09 Dec 1996 23:03:44 +1100

On Fri 1996/12/06 04:24:02 GMT, Stephen Walton wrote
in a message to: fitsbits at fits.cv.nrao.edu

>"solar," of course, but these seem to have been reserved for other

You should be able to organize it so that the intermediate result obtained
by applying the PC matrix (but not the CDELTn) give the required (x',y').
The CDELTn would then scale these to (x,y) in "degrees" as required by WCS.
This could be made a defining characteristic of PLON/PLAT CTYPEs without
needing to alter the current proposal.  While WCSLIB does not provide the
intermediate (x',y') directly it should be a simple matter to apply the
linear transformation routines (linfwd(), and linrev()) to that end.

>software such as IDL, FITSIO, WCSLIB, and so on.

This is all historical.  The CDELTn have to be retained for backwards
compatibility with the widely used de facto AIPS WCS convention dating to the
early 1980s.  The original WCS document by Hanish and Wells proposed the CD
matrix which would override the CDELTn if both were specified together.
However, we were persuaded that the linear transformation matrix should be
used in conjunction with the CDELTn.  Since much STScI data had already been
written with the CD convention we had to introduce a new name for the matrix
elements, hence PC.  This way we provided the means for IRAF to support both
conventions for input (but hopefully only write PC headers).

>should be made more precise in some manner.

We couldn't get rid of the CDELTn because of backwards compatibility, as
explained.  To make the best of it, I view the PC matrix as providing
dimensionless matrix elements which apply rotation and skew to the pixel
coordinates producing transformed pixel coordinates, and the CDELTn as
imparting a dimension to the result.  However, we do not require any
interpretation, the only requirement is that coefficients be chosen such that
the specified algorithm produce correct results.

Mark Calabretta
ATNF

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 9 Dec 1996 21:25:56 GMT

>"solar," of course, but these seem to have been reserved for other

Good luck.  I'm personally not convinced that the WCS will ever be compatible
with datasets that are not in some way related to the celestial sphere.  It's
just a completely different mindset.  For example, the response from Mark
Calabretta

>linear transformation routines (linfwd(), and linrev()) to that end.

still seems to me to be saying that the WCS folks expect to be able to project
the data onto the sky.  Otherwise, what is meant here by degrees?

The idea of defining the coordinates to be in units of the solar radius seems
like a good one, at least at first blush.  There are some questions that do
come to mind:

1.  How do you define the solar limb?  The solar radius differs depending on
    what wavelength one is observing in.  The size of the sun in the EUV is
    significantly different from that in the visible.  The most reasonable
    thing to do would appear to be to use the photospheric value, which is well
    known.  On the other hand, some observers may prefer to determine the size
    of the sun using a limb fit.

2.  If the official value for the (photospheric) solar radius changed, would
    that invalidate older FITS files?

In spite of the above questions, there are some advantages to referencing all
data to a normalized solar limb.  It would allow for easier comparison of data
taken at different points in the Earth's orbit, with different apparent solar
sizes.  Also, and probably more critical, it would simplify intercomparison of
data taken from spacecraft not in Earth orbit with data taken from ground-based
observatories.  For example, the current Solar and Heliospheric Observatory
(SOHO) spacecraft sits at the inner Langrange point, which is about 1% of the
way towards the sun.  This means that SOHO sees a 1% bigger sun than is seen
from ground-based observatories.  This difference can cause some confusion when
pointing is discussed, and needs to be kept in mind in all data analysis.

An alternative to expressing the data in solar radii is to use kilometers, or
possibly megameters.

I don't think I like the idea of using the terms PLAT and PLON to refer to a
coordinate system which is not really a latitude/longitude system.  I think
those terms should be reserved for true latitude and longitude, e.g. S40WN9.
In that case, the data should be expressed in degrees.  There is, of course,
the possibility of confusion between heliographic and Carrington coordinates.

William Thompson

---

From: Mark Calabretta <mcalabre at atnf.csiro.au>
Date: Tue, 10 Dec 1996 16:04:25 +1100

On Mon 1996/12/09 21:25:56 GMT, William Thompson wrote
in a message to: fitsbits at fits.cv.nrao.edu

>just a completely different mindset.  For example, the response from Mark

If you're saying that WCS doesn't account for spherical deformations such as
oblateness then I agree, it wasn't designed for that purpose (although you
could apply a first-order approximation for oblateness through the PC matrix).

Otherwise, the difference between mapping a sphere from the inside (i.e. the
celestial sphere) and mapping it from the outside (e.g. planetary cartography)
is essentially just that of changing the sign of the native longitude.

The following should work for a near-sided azimuthal perspective projection:

   1) Choose the PC matrix to give (x',y') however you want it, with
      correction for rotation, skewness and unequal scaling.
   2) Set the sign of CDELT1 to flip the coordinate system (seen from outside
      rather than inside) and also scale (x',y') to (x,y) in "degrees".
   3) Use AZP with mu < -1 for a near-sided projection.

If you want to transform pixel coordinates to (x',y') then just apply the PC
matrix to (i,j).  If you want (PLON,PLAT) then apply the whole WCS algorithm.

>the data onto the sky.  Otherwise, what is meant here by degrees?

The scaling of (x,y) to "degrees" means that (PLON-PLON0, PLAT-PLAT0) is
approximately equal to (x-x0, y-y0) for small deviations from the field centre
(for default LONGPOLE).  This AIPS WCS convention is retained for backwards
compatibility.

>like a good one, at least at first blush.  There are some questions that do

The main problem I see is that the limb in a near-sided perspective projection
may fall short of a hemisphere.  You might get into trouble comparing (x',y')
coordinates of two AZP projections with differing mu if mu is not large enough
(e.g. spacecraft-generated images).  In this case you really would have to
compare planetary lng/lat.

Mark Calabretta
ATNF

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 10 Dec 1996 22:45:08 GMT

>is essentially just that of changing the sign of the native longitude.

Now I understand what you're getting at.  You expect to be able to map data to
the solar surface.  Many solar features can be expressed as having a latitude
and longitude.  For example, an active region could be said to be at position
N30, W29 on a given date.  Of course, the longitude must be adjusted with time
to account for the (differential) solar rotation.

The trouble is that the sun is not a simple sphere like a planetary body.  It's
a three dimensional object.  Chromospheric structures such as prominences
extend several tens of thousands of kilometers above the surface, and
chromospheric loops extend well beyond that.  The corona can be observed out to
30 solar radii.  One has to be able to express data in a system which is valid
both for pixels which are on the disk and for pixels which are above the limb.
It's clear from Stephen Walton's original message that it's this kind of data
which he was considering.

When one is expressing data in solar latitude and longitude, such as a synoptic
map, it's clear that the data must be expressed in degrees.  The rationale for
using degrees for solar images, however, is not so well established.  In some
sense we do something similar in that many data are expressed in arcseconds
from disk center, with the "up" axis aligned with the solar northern rotational
axis.  That may not be an ideal solution, in that the apparent solar radius
changes with the seasons, and is different for some spacecraft, such as SOHO.
The scheme that Stephen Walton described, using coordinates normalized to the
solar radius, would remove this dependence from the data.

Another way to express the data would be in units of physical distance, rather
than in arcseconds.  The solar radius is 6.96x10^5 km, or 696 Mm.  Expressing
image pixels in units relative to the solar radius is really expressing it as a
distance.

Obviously, some other names need to be used for this Cartesian (X,Y) system
rather than PLAT and PLON.  It's evident that those names must be reserved for
data which are actually in latitude and longitude coordinates.  Let me throw
out a suggestion here for debate.  Suppose that we defined the following two
CTYPEs as

	CARN----	Cartesian north, measured from disk center towards the
			solar north rotational axis, and perpendicular to the
			line of sight to the observer, in units of the solar
			photospheric radius.

	CARW----	Cartesian west, measured from disk center towards the
			west limb, in units of the solar photospheric radius,
			and at right angles to CARN----, such that CARW----,
			CARN----, and the line of sight to the observer form a
			right-handed coordinate system.

William Thompson

---

From: Mark Calabretta <mcalabre at atnf.csiro.au>
Date: Thu, 12 Dec 1996 00:57:40 +1100

On Tue 1996/12/10 22:45:08 GMT, William Thompson wrote
in a message to: fitsbits at fits.cv.nrao.edu

>both for pixels which are on the disk and for pixels which are above the limb.

Such a mapping from 2-D pixel coordinates (i,j) to 3-D spherical coordinates
(r,phi,theta) is under-determined for a single image, although a sequence of
such images taken at different viewing angles can be assembled via tomographic
techniques into a data-cube representation of a 3-D object.  See for example
http://www.atnf.csiro.au/people/toosterl/jupiter/.  However, such 3-D images
do not require WCS since the transformation from (i,j,k) -> (x,y,z) ->
(r,phi,theta) does not involve a spherical projection.

In any case, there's still nothing to prevent using WCS for heliographic
coordinates of the solar surface in a 2-D map even if it extends past the
solar limb.  The heliographic lng/lat of a feature beyond the limb would be
undefined, which I believe makes sense.  However, such features would still
have meaningful (x',y') coordinates.

>which he was considering.

It wasn't clear to me.

>image pixels in units relative to the solar radius is really expressing it as a

How do you interpret this "distance" if you don't know the angle between the
corresponding position vector and the plane of projection?  The best you can
say about the projected distance is that it is less than the true distance
from the solar centre so I think it could be misleading to assign it units of
metres.

Also, since the sun's rotational axis is not perpendicular to the ecliptic the
solar poles do not usually lie on the solar limb which means that not even
they will have fixed coordinates in this Cartesian system. 

Mark Calabretta
ATNF

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 12 Dec 1996 00:15:16 GMT

>(r,phi,theta) is under-determined for a single image, ...

Right, which is why it is incorrect to force solar data to be expressed in a
spherical coordinate system.

>undefined, which I believe makes sense.  ...

Unless of course that's the data you're interested in.

>... However, such features would still

What if all the pixels in the image were off the limb?  If I'm understanding
things correctly, there would be no way to express the physical coordinates of
that data in the WCS system.

What we need to be able to do in solar physics is to express the data in a
standardized way.  Because the data can be both on and off the limb, this
standardized coordinate system cannot be based on solar latitude and longitude.
Of course, a parallel coordinate system for data such as synoptic maps which is
organized by latitude and longitude makes sense, but I believe that's already
accommodated within the WCS system.

It's common in solar physics to refer to coordinates as a pair of distances
from solar disk center, with one axis aligned with solar north, and the other
perpendicular to that.  If we can agree on a meaningful way to embed those kind
of data into the WCS system, then we have something.

>from the solar centre so I think it could be misleading to assign it units of

Obviously, it is a projected distance rather than a true distance from the
center of the sun.  That's immaterial.  It still gives the correct X,Y
positions in an X,Y,Z coordinate system.  From a scientific viewpoint, the
physical size in kilometers is the most relevant way to express the data.  One
wants to measure the height of a spicule, or the dimensions of a coronal loop.

>they will have fixed coordinates in this Cartesian system. 

You are absolutely correct that additional information is needed.
Specifically, one needs the solar B angle, which is the tilt of the solar
rotational axis out of the projected plane.  For spacecraft such as SOHO which
are not in low earth orbit this can be different from the same value as
observed from earth.

It's possible that we're talking at cross purposes.  What I'm saying is that
the most natural coordinate system for solar images is a projected one.  It
should be straightforward to determine the spherical coordinates of a pixel
which is on the disk, but the coordinate system itself cannot be directly tied
to those spherical coordinates because of the need to also meaningfully
describe off-limb data.

I don't see any reason why we couldn't adopt a convention where solar data were
described in a coordinate system normalized to the solar photospheric radius,
or one using kilometers.

William Thompson

---

From: Mark Calabretta <mcalabre at atnf.csiro.au>
Date: Mon, 16 Dec 1996 15:46:48 +1100

On Thu 1996/12/12 00:15:16 GMT, William Thompson wrote
in a message to: fitsbits at fits.cv.nrao.edu

>spherical coordinate system.

We appear to going around in circles here.  We have a 2-D spherical surface 
embedded in a 3-D space seen in projection on the celestial sphere.  We want
to coordinatise points on the surface in one way and points in the surrounding
space in another way.  All I am saying is that, contrary to your original
statement, and I believe answering Steven Walton's original query, WCS
provides the tools to do this.  If you have to have Cartesian coordinates
with units of metres rather than solar radii, then use secondary axis
descriptors.

I'm not saying that you won't need to define a simple convention tied to the
CTYPEn (e.g. PLON/PLAT) which describes this system to the extent that points
outside the limb are valid and what their interpretation is to be.

Mark Calabretta
ATNF

---

From: swalton at galileo.csun.edu (Stephen Walton)
Date: 17 Dec 96 19:47:32 GMT

It is time for me to chime in again, now that finals are over.  Thanks to
William Thompson and Mark Calabretta for discussions that clarified many
of the issues in my absence.  I've trimmed the quotes quite a bit, I hope
enough to provide context without misquoting anyone.

In article <58niqk$2uh at post.gsfc.nasa.gov>,
>spherical coordinate system.

My original goal was to explore a format for the header in which the
linear part would translate to normalized distance from solar disk center
along the north and west axes, and the non-linear part would allow one to
take the additional step to solar longitude and latitude for features on
the disk. In one of Mark's earlier posts, he pointed out that the PC
matrix could define the former and the CDELT, CRVAL, and CTYPE values the
latter.  This sounds good to me.  Mark also points out that the AZP
projection is the appropriate one to describe the sun, though the negative
value for "mu" (defined as the number of radii from the surface of the
sphere to the viewer) for a sphere seen from the outside is an important
clarification which is not at all obvious from the WCS draft, at least not
to me.

>>>than in arcseconds.
>>corresponding position vector and the plane of projection?
>
>center of the sun.  That's immaterial.

I think distances in kilometers is an interesting alternative.  It gets
around the fact that the size of the solar limb depends on the wavelength
of observation, and would only depend on the observer's distance to the
Sun, which is known very accurately.  The CDELT values would then be equal
to (x degrees/solar radius), where x is the angle between the observer's
tangent to the solar limb and the line from the solar disk center to the
same point.  

>rotational axis out of the projected plane.

But if I read the WCS spec correctly, the values of CRVAL1 and CRVAL2
would simply be the values of latitude and longitude at the pixels given
by CRPIX1 and CRPIX2.  However, this raises another problem:  for the
linear WCS I propose, CRVAL1 and CRVAL2 would both be zero.  It may still
be that two WCS's in the same header would be needed.

I'd like to address a couple of more points, more or less from memory,
rasised in earlier posts.  In a full-disk solar image, the position of the
limb can be determined very accurately.  An initial guess accurate to a
fraction of a pixel can be found by fitting an ellipse to limb points
found by looking for zero crossings of the Laplacian of the image, and can
then be refined by the technique in Toner and Jefferies 1993, Ap.J. 415,
852.  This measurement is at least as accurate as assumed sizes of the
solar disk in kilometers or arc seconds from ephemerides.  For data taken
of a small portion of the disk, or of sky points only, the WCS would
depend on the accuracy of one's offset pointing, but this is already the
case.

Mark made the point that the original goal of my proposal was not clear. 
It is to make easy intercomparisons between data from different sources. 
In particular, Lindsey Davis of the IRAF group has worked hard on an image
matching package which, among many other things, will do the geometric
rectifications required so that two images have matched WCS's.  This is
something I would find extremely useful, and I assume others would as
well.  To use this would, though, require coding in the CD matrix
formalism, which I'd assume would be back-supported by any software
developed once the present WCS draft is made final.

Steve Walton
------------

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 17 Dec 1996 20:25:27 GMT

>space in another way.  

As a solar astronomer, I disagree with this.  First of all, I don't believe
that the characterization of the Sun as a 2-D spherical surface is entirely
accurate.  Nor do I think that it's the most important way to characterize
solar data.  There are two reasons for this:

1.  As I have pointed out before, the Sun is a three dimensional object, with
    an atmosphere extending well beyond the solar photospheric "surface".  You
    suggest referencing pixels on the disk in one way, and pixels off the disk
    in another way.  However, these are not really separate and distinct data
    sets--solar features blend smoothly from one regime to the other.  Often
    one wants to compare data which is on the disk to data which is off the
    disk.

    Also, the concept of a solar surface is a somewhat fuzzy concept.  The
    apparent size of the Sun is different depending on what wavelengths one is
    looking at.  If one is looking in visible light, then one is looking at the
    photosphere, which is what most people think of as the solar surface.
    However, at certain wavelengths such as hydrogen H-alpha line, one is
    looking at the chromosphere, which is above the photosphere.  Even when
    discounting obviously elevated features such as prominences, the apparent
    size of the Sun is different.  This is especially true in other wavelengths
    in the UV and EUV where one the solar radius is driven by the transition
    region and lower corona.

2.  Although it is useful to convert pixels in image space to solar latitude
    and longitude, this is not the most accurate way to express the pointing of
    the data.  In order to make the conversion, one must know exactly where the
    center of the Sun is in your field of view.  This is not always a trivial
    task--many data come with only a rough determination of where disk center
    is.  Inaccuracies in the absolute pointing will lead to ever increasing
    errors in the latitude/longitude calculation as one approaches the limb.

    Data given in a projected coordinate system as an X,Y pair of distances
    from disk center, either angular or kilometers, also have a built-in
    uncertainty.  However, this uncertainty is easy to characterize, and is
    constant for all pixels.

At this point, one might ask what reasons one might have for converting from
projected coordinates to spherical coordinates.  The following come to mind:

a.  To generate synoptic maps of an entire solar rotation.

b.  To produce "butterfly" maps showing the evolution of the distribution of
    features such as sunspots over the 22 year solar cycle.

c.  To correct for solar differential rotation when comparing two images taken
    at different times, or to project where a given feature will appear at the
    time an observation will be made.  In the case of comparing two images, a
    conversion will be made from projected to 

d.  To explore center-to-limb variations, such as limb darkening.

Note that there are at least three different coordinate systems being discussed
here.  Items a, b, and c above all agree on the definition of latitude, while
items a and c use different definitions of longitude.  In fact, the latitude
and longitude used in synoptic maps isn't really a spherical coordinate system,
because the differential rotation of the sun has to be taken into account.
Item d essentially uses a completely different coordinate system with the
"pole" pointing straight at the observer.

(Note by the way that Steven Walton's original query was primarily addressing
item d.  To that end, he suggested a projected coordinate system similar to the
one I described in an earlier message.  The only difference was the
normalization to the solar (presumably photospheric) radius.)

>All I am saying is that, contrary to your original

>outside the limb are valid and what their interpretation is to be.

My understanding of the purpose of the World Coordinate System is to assist in
the comparison of data taken at different sites and with different instruments.
>From the standpoint of solar physics, we must ask ourselves what is the best
way to characterize our data to assist in this goal.

I agree with your earlier statement that the Sun is a three dimensional object
seen projected onto the celestial sphere.  To my mind, this is the most
important starting point.  Also, I think we can all agree that the ability to
convert image pixel data to traditional celestial coordinates such as RA and
DEC is rarely of any importance.  To my mind, unless the data has already been
projected into spherical coordinates, solar latitude and longitude has to be
considered a secondary

To a large respect, this is how most solar data is expressed, except that data
tends to be expressed in arcseconds or arcminutes rather than degress.  Also,
generally speaking, the exact type of projection (e.g. TAN or ARC) has not
always necessarily been made clear, because one is generally operating at small
angles.

Thus, the coordinate system that I argue makes the most sense for solar
observations has the following properties:

1.  The Sun would be at the equivalent of "RA" and "DEC" both being zero.

2.  The Sun, the zenith, and the projection of the north solar rotational pole
    would all fall on the same great circle.

Observed locally, this would be equivalent to the coordinate system I described
before, with North being "up" and the west limb being to the "right".  The
contribution made by using the WCS formalism for this, besides standardization,
would be in regularizing the description of exactly what projection system is
used.  I can imagine, as resolutions improve, that this could be a benefit in
future solar data.  Of course, the four letter designation that would appear in
the CTYPE keyword needs to be established.

Besides the above positions, the following information is also necessary when
analyzing solar data.

* The distance from the observer to the Sun.  (If the data were expressed in
  kilometers, or in units relative to the solar photospheric radius, then there
  would be no need for this parameter.  For groundbased and low-Earth-orbit
  satellites, the distance from the Earth to the Sun would suffice.
  Conversely, this could be expressed as the apparent size of the solar
  photospheric disk.

* The tilt of the solar north axis towards or away from the observer, known as
  the B angle.

* For observations made from vantage points other than the Earth's environs,
  one needs to know the latitude and longitude of the observers subsolar point,
  where the subsolar point of the Earth is at longitude zero.

We need to standardize on what keywords will be used for these parameters.

William Thompson

P.S.  I've looked at the most recent version of the WCS paper, and don't see
the terms PLAT/PLON described anywhere.  I can only imagine that they describe
the normal kind of latitude and longitude when applied to the Earth.  Where are
these described and reserved?  What about SLAT and SLON which was also
described as being reserved in a previous message?

---

From: Mark Calabretta <mcalabre at atnf.csiro.au>
Date: Wed, 18 Dec 1996 09:59:43 +1100

On Tue 1996/12/17 19:47:32 GMT, Stephen Walton wrote
in a message to: fitsbits at fits.cv.nrao.edu

>be that two WCS's in the same header would be needed.

If you want to measure distances in metres, rather than solar radii as
originally proposed, then use alternate axis descriptions (Section 2.3 of WCS
paper).

>developed once the present WCS draft is made final.

The current draft recognises the CD matrix for backward compatibility but
states that it must not be written.  In particular, use of a CD matrix would
imply that the CmDELTn secondary descriptor cards should be ignored
(presumably, but in fact the behaviour is undefined) which is certainly not
what you want in light of the above.

Mark Calabretta
ATNF

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 19 Dec 1996 16:22:29 GMT

swalton at galileo.csun.edu (Stephen Walton) writes:

>latter.  This sounds good to me.  

I'm confused here.  My reading of the WCS document is that the PC matrix must
agree with the CDELT, CRVAL, and CTYPE values.  Or did you mean CmELT, etc.?

Bill

---

From: Mark Calabretta <mcalabre at atnf.csiro.au>
Date: Fri, 20 Dec 1996 11:35:32 +1100

On Thu 1996/12/19 16:22:29 GMT, William Thompson wrote
in a message to: fitsbits at fits.cv.nrao.edu

>agree with the CDELT, CRVAL, and CTYPE values.  Or did you mean CmELT, etc.?

WCS is defined as a chain of independent algorithms as described in fig. 1 of
the draft.  What does it mean to say that one step in this chain "agrees" with
another?  The suggestion is to tap into the intermediate products of that
chain.

One point which does need clarifying though is whether the PC matrix is or is
not used in conjunction with the secondary axis descriptors.  I have assumed
it is but the current draft does not say explicitly.  Image rotation would be
the main issue here.

Mark Calabretta
ATNF