In previous versions of CCDPACK a different method was used for registration, which relied only on object matching and stored coordinate mapping information in TRANSFORM (SUN/61) structures in the CCDPACK extension of the images. If you are used to this way of doing things do not despair! In the first place, the object matching methods appear to work just the same as before (i.e. a CCDPACK script which used to perform registration, resampling and combination should still do so), although the routines are now storing coordinate system information in a different way. Furthermore, all the programs retain their ability to read transformation information written as TRANSFORM structures, for backward compatibility with files which have already been partially processed by CCDPACK.

The applications FINDOFF, REGISTER, TRANLIST, and TRANNDF write and (by default) read coordinate system information using coordinate systems attached to images, but retain options which allow them to read the old TRANSFORM structures on request.

All the things which can be done using TRANSFORM structures however can be as well or better done with attached coordinate systems, and the ability of CCDPACK programs to read TRANSFORM structures may be withdrawn altogether in a future release.

If the old method of handling coordinate transformations is used they are stored in HDS – SUN/92 – objects known as ‘transform structures’. These objects are produced by the TRANSFORM – SUN/61 – package and contain a full description (in an algebraic form which may be examined using the HDSTRACE – SUN/102 – utility, or more concisely by the KAPPA application TRANTRACE) of the transformation. Usually transform structures are written into the CCDPACK part of the extension of the image to which they apply (under the item TRANSFORM) and can be accessed without any further action. Note that if you are using a foreign format of some kind then CCDPACK arranges to store this information in amongst the general header items (as it does for all other extension information it relies on) and you should check these if required (none of the methods described here will actually work for foreign data types).

An example trace of a transform structure is shown next:

NDF.MORE.CCDPACK.TRANSFORM <TRN_TRANSFORM>

TRN_VERSION <_REAL> 0.9

FORWARD <_CHAR*9> ’DEFINED’

INVERSE <_CHAR*9> ’DEFINED’

MODULE_ARRAY(1) <TRN_MODULE> {structure}

NVAR_IN <_INTEGER> 2

NVAR_OUT <_INTEGER> 2

COMMENT <_CHAR*44> ’name of data file’

PRECISION <_CHAR*7> ’_DOUBLE’

FORWARD_FUNC(2) <_CHAR*37> ’XX=37.981916884451D0+1D0*X+0.D00*Y,’

’YY=8.79311726090132D-02+0.D00*X+1D0*Y’

INVERSE_FUNC(2) <_CHAR*41> ’X=(-37.981916884451D0)+1D0*XX+0.D00*YY’,

’Y=(-8.79311726090132D-02)+0.D00*XX+1D0*YY’

CLASSIFICATION <TRN_CLASS> {structure}

LINEAR <_LOGICAL> TRUE

INDEPENDENT <_LOGICAL> TRUE

ISOTROPIC <_LOGICAL> TRUE

POSITIVE_DET <_LOGICAL> TRUE

CONSTANT_DET <_LOGICAL> TRUE

UNIT_DET <_LOGICAL> TRUE

End of Trace.

TRN_VERSION <_REAL> 0.9

FORWARD <_CHAR*9> ’DEFINED’

INVERSE <_CHAR*9> ’DEFINED’

MODULE_ARRAY(1) <TRN_MODULE> {structure}

NVAR_IN <_INTEGER> 2

NVAR_OUT <_INTEGER> 2

COMMENT <_CHAR*44> ’name of data file’

PRECISION <_CHAR*7> ’_DOUBLE’

FORWARD_FUNC(2) <_CHAR*37> ’XX=37.981916884451D0+1D0*X+0.D00*Y,’

’YY=8.79311726090132D-02+0.D00*X+1D0*Y’

INVERSE_FUNC(2) <_CHAR*41> ’X=(-37.981916884451D0)+1D0*XX+0.D00*YY’,

’Y=(-8.79311726090132D-02)+0.D00*XX+1D0*YY’

CLASSIFICATION <TRN_CLASS> {structure}

LINEAR <_LOGICAL> TRUE

INDEPENDENT <_LOGICAL> TRUE

ISOTROPIC <_LOGICAL> TRUE

POSITIVE_DET <_LOGICAL> TRUE

CONSTANT_DET <_LOGICAL> TRUE

UNIT_DET <_LOGICAL> TRUE

End of Trace.

Note that a full transform is defined with a forward and an inverse mapping (these are produced
automatically by CCDPACK when using linear transforms). All transformations (and positions) are
stored in double precision. The number of variables is two for the forward and inverse functions (`X`

,`Y`

and `XX`

,`YY`

). Finally the transformation is classified so that future applications know its properties and
may take action to speed up or stop processing if a required property is not apparent (CCDPACK
produces classifications for linear transformations).

As explained in §8.2.5, when a position list is associated with an image which has suitable coordinate systems attached to it, explicit transformation of positions in the list is usually not necessary, since the CCDPACK programs which use the lists will transform them into the Current coordinate system automatically.

When dealing with the old TRANSFORM-based methods however this can be required, and it may occasionally be wanted when using the new coordinate system methods, for instance for examination of image coordinates by a human or a program other than a CCDPACK one, or if position lists are still needed for some reason after the image is resampled. In these cases, the coordinates of each point in a position list can be transformed using the routine:

TRANLIST can use transformations expressed in four different forms:

- pairs of coordinate systems attached to an image
- TRANSFORM structures
- linear transform coefficients
- general algebraic expressions.

The first method uses the usual format for passing transformation information between CCDPACK applications and the second uses the format which served that purpose in previous versions of CCDPACK. The third uses the coefficients of a linear transform and the fourth allows you to transform a list using the algebraic expressions which are understood by the TRANSFORM package (SUN/61).

Transforming positions using transform structures is usually straight-forward, provided you’ve registered your data and entered this information into the images using REGISTER, or have added coordinate systems or TRANSFORM structures in some other way.

Transforming positions selected from one dataset (say using the IDICURS application) to a reference coordinate system (or vice-versa), is fairly straight-forward given registered datasets. It is also possible to transform to the coordinates of another dataset. The sequence of commands for this operation goes like:

% display img [1]

% idicurs in=img outlist=img.approx [2]

% findcent inlist=img outlist=img.acc [3]

% tranlist trtype=wcs inlist=img framein=pixel [4]

frameout=ccd_reg

% tranlist trtype=wcs inlist=img inext=false [5]

outlist=img.look wcsfile=newimg

framein=pixel frameout=ccd_reg

% idicurs in=img outlist=img.approx [2]

% findcent inlist=img outlist=img.acc [3]

% tranlist trtype=wcs inlist=img framein=pixel [4]

frameout=ccd_reg

% tranlist trtype=wcs inlist=img inext=false [5]

outlist=img.look wcsfile=newimg

framein=pixel frameout=ccd_reg

Notes:

- (1)
- The KAPPA (SUN/95) routine DISPLAY is used for image display.
- (2)
- IDICURS is used to select positions which are written into a position list
`image.approx`

and associated with the image. - (3)
- FINDCENT centroids the positions. The new position list is
`img.acc`

which is now associated with the image. - (4)
- TRANLIST transforms the new positions from pixel coordinates to the CCD_REG coordinate system
- (5)
- TRANLIST now transforms the positions from pixel coordinates to the Current
coordinate system of
`newimg`

.

The final command is more complex as the mapping to be used is not associated with the image with which the position list to be transformed is associated, so it is necessary to give the location of the WCS component where the coordinate system information can be found. This exemplifies why storing the transformations in a standard way that all the CCDPACK applications know about is such a good idea.

Using linear coefficients is a quick way of applying offsets, scales and rotations to data. The linear transform form is:

The `TR(1-6)`

correspond to the coefficients you give to TRANLIST. The identity transformation is
`[0,1,0,0,0,1]`

which corresponds to the coefficients `[TR(1),TR(2),TR(3),TR(4),TR(5),TR(6)]`

. So
an offset in X and Y would be `[TR(1),1,0,TR(4),0,1]`

. Scaling uses the `TR(2,3,5, & 6)`

coefficients.
Rotation uses the coefficients:

$\left(\begin{array}{c}\hfill \end{array}\right)$

where $\theta $
is the angle to rotate (counter-clockwise). So a rotation of 45 degrees counter-clockwise about `(0,0)`

is
`[0,0.7071,-0.7071,0,0.7071,0.7071]`

.

General transformations are expressed in a ‘Fortran-like’ form and may use the functions `SIN`

, `TAN`

,
`COS`

, `ASIN`

, `ACOS`

, `LOG`

, `LOG10`

and many others which are listed in SUN/61 appendix A. An
example of using this capability is to transform positions by a parameterised pin-cushion
distortion:

% tranlist xfor = ( fx * ( 1 + pa * ( fx*fx + fy*fy ) ) ) * ps + px

yfor = ( fy * ( 1 + pa * ( fx*fx + fy*fy ) ) ) * ps + py

fx = ( x - px ) / ps fy = ( y - py ) / ps

pa = 21.4 px = 100.0 py = 200.0 ps=11.5

yfor = ( fy * ( 1 + pa * ( fx*fx + fy*fy ) ) ) * ps + py

fx = ( x - px ) / ps fy = ( y - py ) / ps

pa = 21.4 px = 100.0 py = 200.0 ps=11.5

This also shows how to use sub-expressions to reduce complex formulae to more manageable levels (`x`

and `y`

are offset and scaled to some arbitrary level and now masquerade as `fx`

and `fy`

). This also allows
quick modifications since only the values of the parameters need to be changed on re-runs. Note that a
coordinate system representing a pincushion distortion could be added instead to an image using
WCSEDIT (described in §8.3).