.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "Transform 3pm"
.TH Transform 3pm "2023-06-17" "perl v5.36.0" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
PDL::Transform \- Coordinate transforms, image warping, and N\-D functions
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
use PDL::Transform;
.PP
.Vb 1
\& my $t = PDL::Transform::<type>\->new(<opt>)
\&
\& $out = $t\->apply($in)  # Apply transform to some N\-vectors (Transform method)
\& $out = $in\->apply($t)  # Apply transform to some N\-vectors (PDL method)
\&
\& $im1 = $t\->map($im);   # Transform image coordinates (Transform method)
\& $im1 = $im\->map($t);   # Transform image coordinates (PDL method)
\&
\& $t2 = $t\->compose($t1);  # compose two transforms
\& $t2 = $t x $t1;          # compose two transforms (by analogy to matrix mult.)
\&
\& $t3 = $t2\->inverse();    # invert a transform
\& $t3 = !$t2;              # invert a transform (by analogy to logical "not")
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
PDL::Transform is a convenient way to represent coordinate
transformations and resample images.  It embodies functions mapping
R^N \-> R^M, both with and without inverses.  Provision exists for
parametrizing functions, and for composing them.  You can use this
part of the Transform object to keep track of arbitrary functions
mapping R^N \-> R^M with or without inverses.
.PP
The simplest way to use a Transform object is to transform vector
data between coordinate systems.  The \*(L"apply\*(R" method
accepts a \s-1PDL\s0 whose 0th dimension is coordinate index (all other
dimensions are broadcasted over) and transforms the vectors into the new
coordinate system.
.PP
Transform also includes image resampling, via the \*(L"map\*(R" method.
You define a coordinate transform using a Transform object, then use
it to remap an image \s-1PDL.\s0  The output is a remapped, resampled image.
.PP
You can define and compose several transformations, then apply them
all at once to an image.  The image is interpolated only once, when
all the composed transformations are applied.
.PP
In keeping with standard practice, but somewhat counterintuitively,
the \*(L"map\*(R" engine uses the inverse transform to map coordinates
\&\s-1FROM\s0 the destination dataspace (or image plane) \s-1TO\s0 the source dataspace;
hence PDL::Transform keeps track of both the forward and inverse transform.
.PP
For terseness and convenience, most of the constructors are exported
into the current package with the name \f(CW\*(C`t_<transform>\*(C'\fR, so the following
(for example) are synonyms:
.PP
.Vb 1
\&  $t = PDL::Transform::Radial\->new;  # Long way
\&
\&  $t = t_radial();                    # Short way
.Ve
.PP
Several math operators are overloaded, so that you can compose and
invert functions with expression syntax instead of method syntax (see below).
.SH "EXAMPLE"
.IX Header "EXAMPLE"
Coordinate transformations and mappings are a little counterintuitive
at first.  Here are some examples of transforms in action:
.PP
.Vb 3
\&   use PDL::Transform;
\&   $x = rfits(\*(Aqm51.fits\*(Aq);   # Substitute path if necessary!
\&   $ts = t_linear(Scale=>3); # Scaling transform
\&
\&   $w = pgwin(xs);
\&   $w\->imag($x);
\&
\&   ## Grow m51 by a factor of 3; origin is at lower left.
\&   $y = $ts\->map($x,{pix=>1});    # pix option uses direct pixel coord system
\&   $w\->imag($y);
\&
\&   ## Shrink m51 by a factor of 3; origin still at lower left.
\&   $c = $ts\->unmap($x, {pix=>1});
\&   $w\->imag($c);
\&
\&   ## Grow m51 by a factor of 3; origin is at scientific origin.
\&   $d = $ts\->map($x,$x\->hdr);    # FITS hdr template prevents autoscaling
\&   $w\->imag($d);
\&
\&   ## Shrink m51 by a factor of 3; origin is still at sci. origin.
\&   $e = $ts\->unmap($x,$x\->hdr);
\&   $w\->imag($e);
\&
\&   ## A no\-op: shrink m51 by a factor of 3, then autoscale back to size
\&   $f = $ts\->map($x);            # No template causes autoscaling of output
.Ve
.SH "OPERATOR OVERLOADS"
.IX Header "OPERATOR OVERLOADS"
.IP "'!'" 3
The bang is a unary inversion operator.  It binds exactly as
tightly as the normal bang operator.
.IP "'x'" 3
.IX Item "'x'"
By analogy to matrix multiplication, 'x' is the compose operator, so these
two expressions are equivalent:
.Sp
.Vb 2
\&  $f\->inverse()\->compose($g)\->compose($f) # long way
\&  !$f x $g x $f                           # short way
.Ve
.Sp
Both of those expressions are equivalent to the mathematical expression
f^\-1 o g o f, or f^\-1(g(f(x))).
.IP "'**'" 3
By analogy to numeric powers, you can apply an operator a positive
integer number of times with the ** operator:
.Sp
.Vb 2
\&  $f\->compose($f)\->compose($f)  # long way
\&  $f**3                         # short way
.Ve
.SH "INTERNALS"
.IX Header "INTERNALS"
Transforms are perl hashes.  Here's a list of the meaning of each key:
.IP "func" 3
.IX Item "func"
Ref to a subroutine that evaluates the transformed coordinates.  It's
called with the input coordinate, and the \*(L"params\*(R" hash.  This
springboarding is done via explicit ref rather than by subclassing,
for convenience both in coding new transforms (just add the
appropriate sub to the module) and in adding custom transforms at
run-time. Note that, if possible, new \f(CW\*(C`func\*(C'\fRs should support
inplace operation to save memory when the data are flagged
inplace.  But \f(CW\*(C`func\*(C'\fR should always return its result even when
flagged to compute in-place.
.Sp
\&\f(CW\*(C`func\*(C'\fR should treat the 0th dimension of its input as a dimensional
index (running 0..N\-1 for R^N operation) and broadcast over all other input
dimensions.
.IP "inv" 3
.IX Item "inv"
Ref to an inverse method that reverses the transformation.  It must
accept the same \*(L"params\*(R" hash that the forward method accepts.  This
key can be left undefined in cases where there is no inverse.
.IP "idim, odim" 3
.IX Item "idim, odim"
Number of useful dimensions for indexing on the input and output sides
(ie the order of the 0th dimension of the coordinates to be fed in or
that come out).  If this is set to 0, then as many are allocated as needed.
.IP "name" 3
.IX Item "name"
A shorthand name for the transformation (convenient for debugging).
You should plan on using UNIVERAL::isa to identify classes of
transformation, e.g. all linear transformations should be subclasses
of PDL::Transform::Linear.  That makes it easier to add smarts to,
e.g., the \fBcompose()\fR method.
.IP "itype" 3
.IX Item "itype"
An array containing the name of the quantity that is expected from the
input ndarray for the transform, for each dimension.  This field is advisory,
and can be left blank if there's no obvious quantity associated with
the transform.  This is analogous to the CTYPEn field used in \s-1FITS\s0 headers.
.IP "oname" 3
.IX Item "oname"
Same as itype, but reporting what quantity is delivered for each
dimension.
.IP "iunit" 3
.IX Item "iunit"
The units expected on input, if a specific unit (e.g. degrees) is expected.
This field is advisory, and can be left blank if there's no obvious
unit associated with the transform.
.IP "ounit" 3
.IX Item "ounit"
Same as iunit, but reporting what quantity is delivered for each dimension.
.IP "params" 3
.IX Item "params"
Hash ref containing relevant parameters or anything else the func needs to
work right.
.IP "is_inverse" 3
.IX Item "is_inverse"
Bit indicating whether the transform has been inverted.  That is useful
for some stringifications (see the PDL::Transform::Linear
stringifier), and may be useful for other things.
.PP
Transforms should be inplace-aware where possible, to prevent excessive
memory usage.
.PP
If you define a new type of transform, consider generating a new stringify
method for it.  Just define the sub \*(L"stringify\*(R" in the subclass package.
It should call SUPER::stringify to generate the first line (though
the PDL::Transform::Composition bends this rule by tweaking the
top-level line), then output (indented) additional lines as necessary to
fully describe the transformation.
.SH "NOTES"
.IX Header "NOTES"
Transforms have a mechanism for labeling the units and type of each
coordinate, but it is just advisory.  A routine to identify and, if
necessary, modify units by scaling would be a good idea.  Currently,
it just assumes that the coordinates are correct for (e.g.)  \s-1FITS\s0
scientific-to-pixel transformations.
.PP
Composition works \s-1OK\s0 but should probably be done in a more
sophisticated way so that, for example, linear transformations are
combined at the matrix level instead of just strung together
pixel-to-pixel.
.SH "MODULE INTERFACE"
.IX Header "MODULE INTERFACE"
There are both operators and constructors.  The constructors are all
exported, all begin with \*(L"t_\*(R", and all return objects that are subclasses
of PDL::Transform.
.PP
The \*(L"apply\*(R", \*(L"invert\*(R", \*(L"map\*(R",
and \*(L"unmap\*(R" methods are also exported to the \f(CW\*(C`PDL\*(C'\fR package: they
are both Transform methods and \s-1PDL\s0 methods.
.SH "FUNCTIONS"
.IX Header "FUNCTIONS"
.SS "apply"
.IX Subsection "apply"
.Vb 1
\&  Signature: (data(); PDL::Transform t)
.Ve
.PP
.Vb 2
\&  $out = $data\->apply($t);
\&  $out = $t\->apply($data);
.Ve
.PP
Apply a transformation to some input coordinates.
.PP
In the example, \f(CW$t\fR is a PDL::Transform and \f(CW$data\fR is a \s-1PDL\s0 to
be interpreted as a collection of N\-vectors (with index in the 0th
dimension).  The output is a similar but transformed \s-1PDL.\s0
.PP
For convenience, this is both a \s-1PDL\s0 method and a Transform method.
.SS "invert"
.IX Subsection "invert"
.Vb 1
\&  Signature: (data(); PDL::Transform t)
.Ve
.PP
.Vb 2
\&  $out = $t\->invert($data);
\&  $out = $data\->invert($t);
.Ve
.PP
Apply an inverse transformation to some input coordinates.
.PP
In the example, \f(CW$t\fR is a PDL::Transform and \f(CW$data\fR is an ndarray to
be interpreted as a collection of N\-vectors (with index in the 0th
dimension).  The output is a similar ndarray.
.PP
For convenience this is both a \s-1PDL\s0 method and a PDL::Transform method.
.SS "map"
.IX Subsection "map"
.Vb 2
\&  Signature: (k0(); pdl *in; pdl *out; pdl *map; SV *boundary; SV *method;
\&                    long big; double blur; double sv_min; char flux; SV *bv)
.Ve
.SS "match"
.IX Subsection "match"
.Vb 3
\&  $y = $x\->match($c);                  # Match $c\*(Aqs header and size
\&  $y = $x\->match([100,200]);           # Rescale to 100x200 pixels
\&  $y = $x\->match([100,200],{rect=>1}); # Rescale and remove rotation/skew.
.Ve
.PP
Resample a scientific image to the same coordinate system as another.
.PP
The example above is syntactic sugar for
.PP
.Vb 1
\& $y = $x\->map(t_identity, $c, ...);
.Ve
.PP
it resamples the input \s-1PDL\s0 with the identity transformation in
scientific coordinates, and matches the pixel coordinate system to
\&\f(CW$c\fR's \s-1FITS\s0 header.
.PP
There is one difference between match and map: match makes the
\&\f(CW\*(C`rectify\*(C'\fR option to \f(CW\*(C`map\*(C'\fR default to 0, not 1.  This only affects
matching where autoscaling is required (i.e. the array ref example
above).  By default, that example simply scales \f(CW$x\fR to the new size and
maintains any rotation or skew in its scientific-to-pixel coordinate
transform.
.SS "map"
.IX Subsection "map"
.Vb 2
\&  $y = $x\->map($xform,[<template>],[\e%opt]); # Distort $x with transform $xform
\&  $y = $x\->map(t_identity,[$pdl],[\e%opt]); # rescale $x to match $pdl\*(Aqs dims.
.Ve
.PP
Resample an image or N\-D dataset using a coordinate transform.
.PP
The data are resampled so that the new pixel indices are proportional
to the transformed coordinates rather than the original ones.
.PP
The operation uses the inverse transform: each output pixel location
is inverse-transformed back to a location in the original dataset, and
the value is interpolated or sampled appropriately and copied into the
output domain.  A variety of sampling options are available, trading
off speed and mathematical correctness.
.PP
For convenience, this is both a \s-1PDL\s0 method and a PDL::Transform method.
.PP
\&\f(CW\*(C`map\*(C'\fR is FITS-aware: if there is a \s-1FITS\s0 header in the input data,
then the coordinate transform acts on the scientific coordinate system
rather than the pixel coordinate system.
.PP
By default, the output coordinates are separated from pixel coordinates
by a single layer of indirection.  You can specify the mapping between
output transform (scientific) coordinates to pixel coordinates using
the \f(CW\*(C`orange\*(C'\fR and \f(CW\*(C`irange\*(C'\fR options (see below), or by supplying a
\&\s-1FITS\s0 header in the template.
.PP
If you don't specify an output transform, then the output is
autoscaled: \f(CW\*(C`map\*(C'\fR transforms a few vectors in the forward direction
to generate a mapping that will put most of the data on the image
plane, for most transformations.  The calculated mapping gets stuck in the
output's \s-1FITS\s0 header.
.PP
Autoscaling is especially useful for rescaling images \*(-- if you specify
the identity transform and allow autoscaling, you duplicate the
functionality of rescale2d, but with more
options for interpolation.
.PP
You can operate in pixel space, and avoid autoscaling of the output,
by setting the \f(CW\*(C`nofits\*(C'\fR option (see below).
.PP
The output has the same data type as the input.  This is a feature,
but it can lead to strange-looking banding behaviors if you use
interpolation on an integer input variable.
.PP
The \f(CW\*(C`template\*(C'\fR can be one of:
.IP "\(bu" 3
a \s-1PDL\s0
.Sp
The \s-1PDL\s0 and its header are copied to the output array, which is then
populated with data.  If the \s-1PDL\s0 has a \s-1FITS\s0 header, then the \s-1FITS\s0
transform is automatically applied so that \f(CW$t\fR applies to the output
scientific coordinates and not to the output pixel coordinates.  In
this case the \s-1NAXIS\s0 fields of the \s-1FITS\s0 header are ignored.
.IP "\(bu" 3
a \s-1FITS\s0 header stored as a hash ref
.Sp
The \s-1FITS NAXIS\s0 fields are used to define the output array, and the
\&\s-1FITS\s0 transformation is applied to the coordinates so that \f(CW$t\fR applies to the
output scientific coordinates.
.IP "\(bu" 3
a list ref
.Sp
This is a list of dimensions for the output array.  The code estimates
appropriate pixel scaling factors to fill the available space.  The
scaling factors are placed in the output \s-1FITS\s0 header.
.IP "\(bu" 3
nothing
.Sp
In this case, the input image size is used as a template, and scaling
is done as with the list ref case (above).
.PP
\&\s-1OPTIONS:\s0
.PP
The following options are interpreted:
.IP "b, bound, boundary, Boundary (default = 'truncate')" 3
.IX Item "b, bound, boundary, Boundary (default = 'truncate')"
This is the boundary condition to be applied to the input image; it is
passed verbatim to range or
interpND in the sampling or interpolating
stage.  Other values are 'forbid','extend', and 'periodic'.  You can
abbreviate this to a single letter.  The default 'truncate' causes the
entire notional space outside the original image to be filled with 0.
.IP "pix, Pixel, nf, nofits, NoFITS (default = 0)" 3
.IX Item "pix, Pixel, nf, nofits, NoFITS (default = 0)"
If you set this to a true value, then \s-1FITS\s0 headers and interpretation
are ignored; the transformation is treated as being in raw pixel coordinates.
.IP "j, J, just, justify, Justify (default = 0)" 3
.IX Item "j, J, just, justify, Justify (default = 0)"
If you set this to 1, then output pixels are autoscaled to have unit
aspect ratio in the output coordinates.  If you set it to a non\-1
value, then it is the aspect ratio between the first dimension and all
subsequent dimensions \*(-- or, for a 2\-D transformation, the scientific
pixel aspect ratio.  Values less than 1 shrink the scale in the first
dimension compared to the other dimensions; values greater than 1
enlarge it compared to the other dimensions.  (This is the same sense
as in the \s-1PGPLOT\s0 interface.)
.IP "ir, irange, input_range, Input_Range" 3
.IX Item "ir, irange, input_range, Input_Range"
This is a way to modify the autoscaling.  It specifies the range of
input scientific (not necessarily pixel) coordinates that you want to be
mapped to the output image.  It can be either a nested array ref or
an ndarray.  The 0th dim (outside coordinate in the array ref) is
dimension index in the data; the 1st dim should have order 2.
For example, passing in either [[\-1,2],[3,4]] or pdl([[\-1,2],[3,4]])
limites the map to the quadrilateral in input space defined by the
four points (\-1,3), (\-1,4), (2,4), and (2,3).
.Sp
As with plain autoscaling, the quadrilateral gets sparsely sampled by
the autoranger, so pathological transformations can give you strange
results.
.Sp
This parameter is overridden by \f(CW\*(C`orange\*(C'\fR, below.
.IP "or, orange, output_range, Output_Range" 3
.IX Item "or, orange, output_range, Output_Range"
This sets the window of output space that is to be sampled onto the
output array.  It works exactly like \f(CW\*(C`irange\*(C'\fR, except that it specifies
a quadrilateral in output space.  Since the output pixel array is itself
a quadrilateral, you get pretty much exactly what you asked for.
.Sp
This parameter overrides \f(CW\*(C`irange\*(C'\fR, if both are specified.  It forces
rectification of the output (so that scientific axes align with the pixel
grid).
.IP "r, rect, rectify" 3
.IX Item "r, rect, rectify"
This option defaults \s-1TRUE\s0 and controls how autoscaling is performed.  If
it is true or undefined, then autoscaling adjusts so that pixel coordinates
in the output image are proportional to individual scientific coordinates.
If it is false, then autoscaling automatically applies the inverse of any
input \s-1FITS\s0 transformation *before* autoscaling the pixels.  In the special
case of linear transformations, this preserves the rectangular shape of the
original pixel grid and makes output pixel coordinate proportional to input
coordinate.
.IP "m, method, Method" 3
.IX Item "m, method, Method"
This option controls the interpolation method to be used.
Interpolation greatly affects both speed and quality of output.  For
most cases the option is directly passed to
interpND for interpolation.  Possible
options, in order from fastest to slowest, are:
.RS 3
.IP "\(bu" 3
s, sample (default for ints)
.Sp
Pixel values in the output plane are sampled from the closest data value
in the input plane.  This is very fast but not very accurate for either
magnification or decimation (shrinking).  It is the default for templates
of integer type.
.IP "\(bu" 3
l, linear (default for floats)
.Sp
Pixel values are linearly interpolated from the closest data value in the
input plane.  This is reasonably fast but only accurate for magnification.
Decimation (shrinking) of the image causes aliasing and loss of photometry
as features fall between the samples.  It is the default for floating-point
templates.
.IP "\(bu" 3
c, cubic
.Sp
Pixel values are interpolated using an N\-cubic scheme from a 4\-pixel
N\-cube around each coordinate value.  As with linear interpolation,
this is only accurate for magnification.
.IP "\(bu" 3
f, fft
.Sp
Pixel values are interpolated using the term coefficients of the
Fourier transform of the original data.  This is the most appropriate
technique for some kinds of data, but can yield undesired \*(L"ringing\*(R" for
expansion of normal images.  Best suited to studying images with
repetitive or wavelike features.
.IP "\(bu" 3
h, hanning
.Sp
Pixel values are filtered through a spatially-variable filter tuned to
the computed Jacobian of the transformation, with hanning-window
(cosine) pixel rolloff in each dimension.  This prevents aliasing in the
case where the image is distorted or shrunk, but allows small amounts
of aliasing at pixel edges wherever the image is enlarged.
.IP "\(bu" 3
g, gaussian, j, jacobian
.Sp
Pixel values are filtered through a spatially-variable filter tuned to
the computed Jacobian of the transformation, with radial Gaussian
rolloff.  This is the most accurate resampling method, in the sense of
introducing the fewest artifacts into a properly sampled data set.
This method uses a lookup table to speed up calculation of the Gaussian
weighting.
.IP "\(bu" 3
G
.Sp
This method works exactly like 'g' (above), except that the Gaussian
values are computed explicitly for every sample \*(-- which is considerably
slower.
.RE
.RS 3
.RE
.IP "blur, Blur (default = 1.0)" 3
.IX Item "blur, Blur (default = 1.0)"
This value scales the input-space footprint of each output pixel in
the gaussian and hanning methods. It's retained for historical
reasons.  Larger values yield blurrier images; values significantly
smaller than unity cause aliasing.  The parameter has slightly
different meanings for Gaussian and Hanning interpolation.  For
Hanning interpolation, numbers smaller than unity control the
sharpness of the border at the edge of each pixel (so that blur=>0 is
equivalent to sampling for non-decimating transforms).  For
Gaussian interpolation, the blur factor parameter controls the
width parameter of the Gaussian around the center of each pixel.
.IP "sv, \s-1SV\s0 (default = 1.0)" 3
.IX Item "sv, SV (default = 1.0)"
This value lets you set the lower limit of the transformation's
singular values in the hanning and gaussian methods, limiting the
minimum radius of influence associated with each output pixel.  Large
numbers yield smoother interpolation in magnified parts of the image
but don't affect reduced parts of the image.
.IP "big, Big (default = 0.5)" 3
.IX Item "big, Big (default = 0.5)"
This is the largest allowable input spot size which may be mapped to a
single output pixel by the hanning and gaussian methods, in units of
the largest non-broadcast input dimension.  (i.e. the default won't let
you reduce the original image to less than 5 pixels across).  This places
a limit on how long the processing can take for pathological transformations.
Smaller numbers keep the code from hanging for a long time; larger numbers
provide for photometric accuracy in more pathological cases.  Numbers larer
than 1.0 are silly, because they allow the entire input array to be compressed
into a region smaller than a single pixel.
.Sp
Wherever an output pixel would require averaging over an area that is too
big in input space, it instead gets NaN or the bad value.
.IP "phot, photometry, Photometry" 3
.IX Item "phot, photometry, Photometry"
This lets you set the style of photometric conversion to be used in the
hanning or gaussian methods.  You may choose:
.RS 3
.IP "\(bu" 3
0, s, surf, surface, Surface (default)
.Sp
(this is the default): surface brightness is preserved over the transformation,
so features maintain their original intensity.  This is what the sampling
and interpolation methods do.
.IP "\(bu" 3
1, f, flux, Flux
.Sp
Total flux is preserved over the transformation, so that the brightness
integral over image regions is preserved.  Parts of the image that are
shrunk wind up brighter; parts that are enlarged end up fainter.
.RE
.RS 3
.RE
.PP
\&\s-1VARIABLE FILTERING:\s0
.PP
The 'hanning' and 'gaussian' methods of interpolation give
photometrically accurate resampling of the input data for arbitrary
transformations.  At each pixel, the code generates a linear
approximation to the input transformation, and uses that linearization
to estimate the \*(L"footprint\*(R" of the output pixel in the input space.
The output value is a weighted average of the appropriate input spaces.
.PP
A caveat about these methods is that they assume the transformation is
continuous.  Transformations that contain discontinuities will give
incorrect results near the discontinuity.  In particular, the 180th
meridian isn't handled well in lat/lon mapping transformations (see
PDL::Transform::Cartography) \*(-- pixels along the 180th meridian get
the average value of everything along the parallel occupied by the
pixel.  This flaw is inherent in the assumptions that underly creating
a Jacobian matrix.  Maybe someone will write code to work around it.
Maybe that someone is you.
.PP
\&\s-1BAD VALUES:\s0
.PP
\&\f(CW\*(C`map()\*(C'\fR supports bad values in the data array. Bad values in the input
array are propagated to the output array.  The 'g' and 'h' methods will
do some smoothing over bad values:  if more than 1/3 of the weighted
input-array footprint of a given output pixel is bad, then the output
pixel gets marked bad.
.PP
map does not process bad values.
It will set the bad-value flag of all output ndarrays if the flag is set for any of the input ndarrays.
.SS "unmap"
.IX Subsection "unmap"
.Vb 1
\& Signature: (data(); PDL::Transform a; template(); \e%opt)
.Ve
.PP
.Vb 2
\&  $out_image = $in_image\->unmap($t,[<options>],[<template>]);
\&  $out_image = $t\->unmap($in_image,[<options>],[<template>]);
.Ve
.PP
Map an image or N\-D dataset using the inverse as a coordinate transform.
.PP
This convenience function just inverts \f(CW$t\fR and calls \*(L"map\*(R" on
the inverse; everything works the same otherwise.  For convenience, it
is both a \s-1PDL\s0 method and a PDL::Transform method.
.SS "t_inverse"
.IX Subsection "t_inverse"
.Vb 4
\&  $t2 = t_inverse($t);
\&  $t2 = $t\->inverse;
\&  $t2 = $t ** \-1;
\&  $t2 = !$t;
.Ve
.PP
Return the inverse of a PDL::Transform.  This just reverses the
func/inv, idim/odim, itype/otype, and iunit/ounit pairs.  Note that
sometimes you end up with a transform that cannot be applied or
mapped, because either the mathematical inverse doesn't exist or the
inverse func isn't implemented.
.PP
You can invert a transform by raising it to a negative power, or by
negating it with '!'.
.PP
The inverse transform remains connected to the main transform because
they both point to the original parameters hash.  That turns out to be
useful.
.SS "t_compose"
.IX Subsection "t_compose"
.Vb 3
\&  $f2 = t_compose($f, $g,[...]);
\&  $f2 = $f\->compose($g[,$h,$i,...]);
\&  $f2 = $f x $g x ...;
.Ve
.PP
Function composition: f(g(x)), f(g(h(x))), ...
.PP
You can also compose transforms using the overloaded matrix-multiplication
(nee repeat) operator 'x'.
.PP
This is accomplished by inserting a splicing code ref into the \f(CW\*(C`func\*(C'\fR
and \f(CW\*(C`inv\*(C'\fR slots.  It combines multiple compositions into a single
list of transforms to be executed in order, fram last to first (in
keeping with standard mathematical notation).  If one of the functions is
itself a composition, it is interpolated into the list rather than left
separate.  Ultimately, linear transformations may also be combined within
the list.
.PP
No checking is done that the itype/otype and iunit/ounit fields are
compatible \*(-- that may happen later, or you can implement it yourself
if you like.
.SS "t_wrap"
.IX Subsection "t_wrap"
.Vb 2
\&  $g1fg = $f\->wrap($g);
\&  $g1fg = t_wrap($f,$g);
.Ve
.PP
Shift a transform into a different space by 'wrapping' it with a second.
.PP
This is just a convenience function for two
\&\*(L"t_compose\*(R" calls. \f(CW\*(C`$x\->wrap($y)\*(C'\fR is the same as
\&\f(CW\*(C`(!$y) x $x x $y\*(C'\fR: the resulting transform first hits the data with
\&\f(CW$y\fR, then with \f(CW$x\fR, then with the inverse of \f(CW$y\fR.
.PP
For example, to shift the origin of rotation, do this:
.PP
.Vb 5
\&  $im = rfits(\*(Aqm51.fits\*(Aq);
\&  $tf = t_fits($im);
\&  $tr = t_linear({rot=>30});
\&  $im1 = $tr\->map($tr);               # Rotate around pixel origin
\&  $im2 = $tr\->map($tr\->wrap($tf));    # Rotate round FITS scientific origin
.Ve
.SS "t_identity"
.IX Subsection "t_identity"
.Vb 2
\&  my $xform = t_identity
\&  my $xform = PDL::Transform\->new;
.Ve
.PP
Generic constructor generates the identity transform.
.PP
This constructor really is trivial \*(-- it is mainly used by the other transform
constructors.  It takes no parameters and returns the identity transform.
.SS "t_lookup"
.IX Subsection "t_lookup"
.Vb 1
\&  $f = t_lookup($lookup, {<options>});
.Ve
.PP
Transform by lookup into an explicit table.
.PP
You specify an N+1\-D \s-1PDL\s0 that is interpreted as an N\-D lookup table of
column vectors (vector index comes last).  The last dimension has
order equal to the output dimensionality of the transform.
.PP
For added flexibility in data space, You can specify pre-lookup linear
scaling and offset of the data.  Of course you can specify the
interpolation method to be used.  The linear scaling stuff is a little
primitive; if you want more, try composing the linear transform with
this one.
.PP
The prescribed values in the lookup table are treated as
pixel-centered: that is, if your input array has N elements per row
then valid data exist between the locations (\-0.5) and (N\-0.5) in
lookup pixel space, because the pixels (which are numbered from 0 to
N\-1) are centered on their locations.
.PP
Lookup is done using interpND, so the boundary conditions
and broadcasting behaviour follow from that.
.PP
The indexed-over dimensions come first in the table, followed by a
single dimension containing the column vector to be output for each
set of other dimensions \*(-- ie to output 2\-vectors from 2 input
parameters, each of which can range from 0 to 49, you want an index
that has dimension list (50,50,2).  For the identity lookup table
you could use  \f(CW\*(C`cat(xvals(50,50),yvals(50,50))\*(C'\fR.
.PP
If you want to output a single value per input vector, you still need
that last index broadcasting dimension \*(-- if necessary, use \f(CW\*(C`dummy(\-1,1)\*(C'\fR.
.PP
The lookup index scaling is: out = lookup[ (scale * data) + offset ].
.PP
A simplistic table inversion routine is included.  This means that
you can (for example) use the \f(CW\*(C`map\*(C'\fR method with \f(CW\*(C`t_lookup\*(C'\fR transformations.
But the table inversion is exceedingly slow, and not practical for tables
larger than about 100x100.  The inversion table is calculated in its
entirety the first time it is needed, and then cached until the object is
destroyed.
.PP
Options are listed below; there are several synonyms for each.
.IP "s, scale, Scale" 3
.IX Item "s, scale, Scale"
(default 1.0) Specifies the linear amount of scaling to be done before
lookup.  You can feed in a scalar or an N\-vector; other values may cause
trouble.  If you want to save space in your table, then specify smaller
scale numbers.
.IP "o, offset, Offset" 3
.IX Item "o, offset, Offset"
(default 0.0) Specifies the linear amount of offset before lookup.
This is only a scalar, because it is intended to let you switch to
corner-centered coordinates if you want to (just feed in o=\-0.25).
.IP "b, bound, boundary, Boundary" 3
.IX Item "b, bound, boundary, Boundary"
Boundary condition to be fed to interpND
.IP "m, method, Method" 3
.IX Item "m, method, Method"
Interpolation method to be fed to interpND
.PP
\&\s-1EXAMPLE\s0
.PP
To scale logarithmically the Y axis of m51, try:
.PP
.Vb 4
\&  $x = float rfits(\*(Aqm51.fits\*(Aq);
\&  $lookup = xvals(128,128) \-> cat( 10**(yvals(128,128)/50) * 256/10**2.55 );
\&  $t = t_lookup($lookup);
\&  $y = $t\->map($x);
.Ve
.PP
To do the same thing but with a smaller lookup table, try:
.PP
.Vb 3
\&  $lookup = 16 * xvals(17,17)\->cat(10**(yvals(17,17)/(100/16)) * 16/10**2.55);
\&  $t = t_lookup($lookup,{scale=>1/16.0});
\&  $y = $t\->map($x);
.Ve
.PP
(Notice that, although the lookup table coordinates are is divided by 16,
it is a 17x17 \*(-- so linear interpolation works right to the edge of the original
domain.)
.PP
\&\s-1NOTES\s0
.PP
Inverses are not yet implemented \*(-- the best way to do it might be by
judicious use of \fBmap()\fR on the forward transformation.
.PP
the type/unit fields are ignored.
.SS "t_linear"
.IX Subsection "t_linear"
\&\f(CW$f\fR = t_linear({options});
.PP
Linear (affine) transformations with optional offset
.PP
t_linear implements simple matrix multiplication with offset,
also known as the affine transformations.
.PP
You specify the linear transformation with pre-offset, a mixing
matrix, and a post-offset.  That overspecifies the transformation, so
you can choose your favorite method to specify the transform you want.
The inverse transform is automagically generated, provided that it
actually exists (the transform matrix is invertible).  Otherwise, the
inverse transform just croaks.
.PP
Extra dimensions in the input vector are ignored, so if you pass a
3xN vector into a 3\-D linear transformation, the final dimension is passed
through unchanged.
.PP
The options you can usefully pass in are:
.IP "s, scale, Scale" 3
.IX Item "s, scale, Scale"
A scaling scalar (heh), vector, or matrix.  If you specify a vector
it is treated as a diagonal matrix (for convenience).  It gets
left-multiplied with the transformation matrix you specify (or the
identity), so that if you specify both a scale and a matrix the
scaling is done after the rotation or skewing or whatever.
.IP "r, rot, rota, rotation, Rotation" 3
.IX Item "r, rot, rota, rotation, Rotation"
A rotation angle in degrees \*(-- useful for 2\-D and 3\-D data only.  If
you pass in a scalar, it specifies a rotation from the 0th axis toward
the 1st axis.  If you pass in a 3\-vector as either a \s-1PDL\s0 or an array
ref (as in \*(L"rot=>[3,4,5]\*(R"), then it is treated as a set of Euler
angles in three dimensions, and a rotation matrix is generated that
does the following, in order:
.RS 3
.IP "\(bu" 3
Rotate by rot\->(2) degrees from 0th to 1st axis
.IP "\(bu" 3
Rotate by rot\->(1) degrees from the 2nd to the 0th axis
.IP "\(bu" 3
Rotate by rot\->(0) degrees from the 1st to the 2nd axis
.RE
.RS 3
.Sp
The rotation matrix is left-multiplied with the transformation matrix
you specify, so that if you specify both rotation and a general matrix
the rotation happens after the more general operation \*(-- though that is
deprecated.
.Sp
Of course, you can duplicate this functionality \*(-- and get more
general \*(-- by generating your own rotation matrix and feeding it in
with the \f(CW\*(C`matrix\*(C'\fR option.
.RE
.IP "m, matrix, Matrix" 3
.IX Item "m, matrix, Matrix"
The transformation matrix.  It does not even have to be square, if you want
to change the dimensionality of your input.  If it is invertible (note:
must be square for that), then you automagically get an inverse transform too.
.IP "pre, preoffset, offset, Offset" 3
.IX Item "pre, preoffset, offset, Offset"
The vector to be added to the data before they get multiplied by the matrix
(equivalent of \s-1CRVAL\s0 in \s-1FITS,\s0 if you are converting from scientific to
pixel units).
.IP "post, postoffset, shift, Shift" 3
.IX Item "post, postoffset, shift, Shift"
The vector to be added to the data after it gets multiplied by the matrix
(equivalent of \s-1CRPIX\-1\s0 in \s-1FITS,\s0 if youre converting from scientific to pixel
units).
.IP "d, dim, dims, Dims" 3
.IX Item "d, dim, dims, Dims"
Most of the time it is obvious how many dimensions you want to deal
with: if you supply a matrix, it defines the transformation; if you
input offset vectors in the \f(CW\*(C`pre\*(C'\fR and \f(CW\*(C`post\*(C'\fR options, those define
the number of dimensions.  But if you only supply scalars, there is no way
to tell and the default number of dimensions is 2.  This provides a way
to do, e.g., 3\-D scaling: just set \f(CW\*(C`{s=\*(C'\fR<scale\-factor>, dims=>3}> and
you are on your way.
.PP
\&\s-1NOTES\s0
.PP
the type/unit fields are currently ignored by t_linear.
.SS "t_scale"
.IX Subsection "t_scale"
.Vb 1
\&  $f = t_scale(<scale>)
.Ve
.PP
Convenience interface to \*(L"t_linear\*(R".
.PP
t_scale produces a transform that scales around the origin by a fixed
amount.  It acts exactly the same as \f(CW\*(C`t_linear(Scale=\*(C'\fR\e<scale\e>)>.
.SS "t_offset"
.IX Subsection "t_offset"
.Vb 1
\&  $f = t_offset(<shift>)
.Ve
.PP
Convenience interface to \*(L"t_linear\*(R".
.PP
t_offset produces a transform that shifts the origin to a new location.
It acts exactly the same as \f(CW\*(C`t_linear(Pre=\*(C'\fR\e<shift\e>)>.
.SS "t_rot"
.IX Subsection "t_rot"
.Vb 1
\&  $f = t_rot(\e@rotation_in_degrees)
.Ve
.PP
Convenience interface to \*(L"t_linear\*(R".
.PP
t_rot produces a rotation transform in 2\-D (scalar), 3\-D (3\-vector), or
N\-D (matrix).  It acts exactly the same as \f(CW\*(C`t_linear(rot=\*(C'\fRshift)>.
.SS "t_fits"
.IX Subsection "t_fits"
.Vb 1
\&  $f = t_fits($fits,[option]);
.Ve
.PP
\&\s-1FITS\s0 pixel-to-scientific transformation with inverse
.PP
You feed in a hash ref or a \s-1PDL\s0 with one of those as a header, and you
get back a transform that converts 0\-originated, pixel-centered
coordinates into scientific coordinates via the transformation in the
\&\s-1FITS\s0 header.  For most \s-1FITS\s0 headers, the transform is reversible, so
applying the inverse goes the other way.  This is just a convenience
subclass of PDL::Transform::Linear, but with unit/type support
using the \s-1FITS\s0 header you supply.
.PP
For now, this transform is rather limited \*(-- it really ought to
accept units differences and stuff like that, but they are just
ignored for now.  Probably that would require putting units into
the whole transform framework.
.PP
This transform implements the linear transform part of the \s-1WCS FITS\s0
standard outlined in Greisen & Calabata 2002 (A&A in press; find it at
\&\*(L"http://arxiv.org/abs/astro\-ph/0207407\*(R").
.PP
As a special case, you can pass in the boolean option \*(L"ignore_rgb\*(R"
(default 0), and if you pass in a 3\-D \s-1FITS\s0 header in which the last
dimension has exactly 3 elements, it will be ignored in the output
transformation.  That turns out to be handy for handling rgb images.
.SS "t_code"
.IX Subsection "t_code"
.Vb 1
\&  $f = t_code(<func>,[<inv>],[options]);
.Ve
.PP
Transform implementing arbitrary perl code.
.PP
This is a way of getting quick-and-dirty new transforms.  You pass in
anonymous (or otherwise) code refs pointing to subroutines that
implement the forward and, optionally, inverse transforms.  The
subroutines should accept a data \s-1PDL\s0 followed by a parameter hash ref,
and return the transformed data \s-1PDL.\s0  The parameter hash ref can be
set via the options, if you want to.
.PP
Options that are accepted are:
.IP "p,params" 3
.IX Item "p,params"
The parameter hash that will be passed back to your code (defaults to the
empty hash).
.IP "n,name" 3
.IX Item "n,name"
The name of the transform (defaults to \*(L"code\*(R").
.IP "i, idim (default 2)" 3
.IX Item "i, idim (default 2)"
The number of input dimensions (additional ones should be passed through
unchanged)
.IP "o, odim (default 2)" 3
.IX Item "o, odim (default 2)"
The number of output dimensions
.IP "itype" 3
.IX Item "itype"
The type of the input dimensions, in an array ref (optional and advisiory)
.IP "otype" 3
.IX Item "otype"
The type of the output dimension, in an array ref (optional and advisory)
.IP "iunit" 3
.IX Item "iunit"
The units that are expected for the input dimensions (optional and advisory)
.IP "ounit" 3
.IX Item "ounit"
The units that are returned in the output (optional and advisory).
.PP
The code variables are executable perl code, either as a code ref or
as a string that will be eval'ed to produce code refs.  If you pass in
a string, it gets eval'ed at call time to get a code ref.  If it compiles
\&\s-1OK\s0 but does not return a code ref, then it gets re-evaluated with \*(L"sub {
\&... }\*(R" wrapped around it, to get a code ref.
.PP
Note that code callbacks like this can be used to do really weird
things and generate equally weird results \*(-- caveat scriptor!
.SS "t_cylindrical"
.IX Subsection "t_cylindrical"
\&\f(CW\*(C`t_cylindrical\*(C'\fR is an alias for \f(CW\*(C`t_radial\*(C'\fR
.SS "t_radial"
.IX Subsection "t_radial"
.Vb 1
\&  $f = t_radial(<options>);
.Ve
.PP
Convert Cartesian to radial/cylindrical coordinates.  (2\-D/3\-D; with inverse)
.PP
Converts 2\-D Cartesian to radial (theta,r) coordinates.  You can choose
direct or conformal conversion.  Direct conversion preserves radial
distance from the origin; conformal conversion preserves local angles,
so that each small-enough part of the image only appears to be scaled
and rotated, not stretched.  Conformal conversion puts the radius on a
logarithmic scale, so that scaling of the original image plane is
equivalent to a simple offset of the transformed image plane.
.PP
If you use three or more dimensions, the higher dimensions are ignored,
yielding a conversion from Cartesian to cylindrical coordinates, which
is why there are two aliases for the same transform.  If you use higher
dimensionality than 2, you must manually specify the origin or you will
get dimension mismatch errors when you apply the transform.
.PP
Theta runs \fBclockwise\fR instead of the more usual counterclockwise; that is
to preserve the mirror sense of small structures.
.PP
\&\s-1OPTIONS:\s0
.IP "d, direct, Direct" 3
.IX Item "d, direct, Direct"
Generate (theta,r) coordinates out (this is the default); incompatible
with Conformal.  Theta is in radians, and the radial coordinate is
in the units of distance in the input plane.
.IP "r0, c, conformal, Conformal" 3
.IX Item "r0, c, conformal, Conformal"
If defined, this floating-point value causes t_radial to generate
(theta, ln(r/r0)) coordinates out.  Theta is in radians, and the
radial coordinate varies by 1 for each e\-folding of the r0\-scaled
distance from the input origin.  The logarithmic scaling is useful for
viewing both large and small things at the same time, and for keeping
shapes of small things preserved in the image.
.IP "o, origin, Origin [default (0,0,0)]" 3
.IX Item "o, origin, Origin [default (0,0,0)]"
This is the origin of the expansion.  Pass in a \s-1PDL\s0 or an array ref.
.IP "u, unit, Unit [default 'radians']" 3
.IX Item "u, unit, Unit [default 'radians']"
This is the angular unit to be used for the azimuth.
.PP
\&\s-1EXAMPLES\s0
.PP
These examples do transformations back into the same size image as they
started from; by suitable use of the \*(L"transform\*(R" option to
\&\*(L"unmap\*(R" you can send them to any size array you like.
.PP
Examine radial structure in M51:
Here, we scale the output to stretch 2*pi radians out to the
full image width in the horizontal direction, and to stretch 1 radius out
to a diameter in the vertical direction.
.PP
.Vb 4
\&  $x = rfits(\*(Aqm51.fits\*(Aq);
\&  $ts = t_linear(s => [250/2.0/3.14159, 2]); # Scale to fill orig. image
\&  $tu = t_radial(o => [130,130]);            # Expand around galactic core
\&  $y = $x\->map($ts x $tu);
.Ve
.PP
Examine radial structure in M51 (conformal):
Here, we scale the output to stretch 2*pi radians out to the full image width
in the horizontal direction, and scale the vertical direction by the exact
same amount to preserve conformality of the operation.  Notice that
each piece of the image looks \*(L"natural\*(R" \*(-- only scaled and not stretched.
.PP
.Vb 4
\&  $x = rfits(\*(Aqm51.fits\*(Aq)
\&  $ts = t_linear(s=> 250/2.0/3.14159);  # Note scalar (heh) scale.
\&  $tu = t_radial(o=> [130,130], r0=>5); # 5 pix. radius \-> bottom of image
\&  $y = $ts\->compose($tu)\->unmap($x);
.Ve
.SS "t_quadratic"
.IX Subsection "t_quadratic"
.Vb 1
\&  $t = t_quadratic(<options>);
.Ve
.PP
Quadratic scaling \*(-- cylindrical pincushion (n\-d; with inverse)
.PP
Quadratic scaling emulates pincushion in a cylindrical optical system:
separate quadratic scaling is applied to each axis.  You can apply
separate distortion along any of the principal axes.  If you want
different axes, use \*(L"t_wrap\*(R" and \*(L"t_linear\*(R" to rotate
them to the correct angle.  The scaling options may be scalars or
vectors; if they are scalars then the expansion is isotropic.
.PP
The formula for the expansion is:
.PP
.Vb 1
\&    f(a) = ( <a> + <strength> * a^2/<L_0> ) / (abs(<strength>) + 1)
.Ve
.PP
where <strength> is a scaling coefficient and <L_0> is a fundamental
length scale.   Negative values of <strength> result in a pincushion
contraction.
.PP
Note that, because quadratic scaling does not have a strict inverse for
coordinate systems that cross the origin, we cheat slightly and use
\&\f(CW$x\fR * abs($x)  rather than \f(CW$x\fR**2.  This does the Right thing for pincushion
and barrel distortion, but means that t_quadratic does not behave exactly
like t_cubic with a null cubic strength coefficient.
.PP
\&\s-1OPTIONS\s0
.IP "o,origin,Origin" 3
.IX Item "o,origin,Origin"
The origin of the pincushion. (default is the, er, origin).
.IP "l,l0,length,Length,r0" 3
.IX Item "l,l0,length,Length,r0"
The fundamental scale of the transformation \*(-- the radius that remains
unchanged.  (default=1)
.IP "s,str,strength,Strength" 3
.IX Item "s,str,strength,Strength"
The relative strength of the pincushion. (default = 0.1)
.IP "honest (default=0)" 3
.IX Item "honest (default=0)"
Sets whether this is a true quadratic coordinate transform.  The more
common form is pincushion or cylindrical distortion, which switches
branches of the square root at the origin (for symmetric expansion).
Setting honest to a non-false value forces true quadratic behavior,
which is not mirror-symmetric about the origin.
.IP "d, dim, dims, Dims" 3
.IX Item "d, dim, dims, Dims"
The number of dimensions to quadratically scale (default is the
dimensionality of your input vectors)
.SS "t_cubic"
.IX Subsection "t_cubic"
.Vb 1
\&  $t = t_cubic(<options>);
.Ve
.PP
Cubic scaling \- cubic pincushion (n\-d; with inverse)
.PP
Cubic scaling is a generalization of t_quadratic to a purely
cubic expansion.
.PP
The formula for the expansion is:
.PP
.Vb 1
\&    f(a) = ( a\*(Aq + st * a\*(Aq^3/L_0^2 ) / (1 + abs(st)) + origin
.Ve
.PP
where a'=(a\-origin).  That is a simple pincushion
expansion/contraction that is fixed at a distance of L_0 from the
origin.
.PP
Because there is no quadratic term the result is always invertible with
one real root, and there is no mucking about with complex numbers or
multivalued solutions.
.PP
\&\s-1OPTIONS\s0
.IP "o,origin,Origin" 3
.IX Item "o,origin,Origin"
The origin of the pincushion. (default is the, er, origin).
.IP "l,l0,length,Length,r0" 3
.IX Item "l,l0,length,Length,r0"
The fundamental scale of the transformation \*(-- the radius that remains
unchanged.  (default=1)
.IP "d, dim, dims, Dims" 3
.IX Item "d, dim, dims, Dims"
The number of dimensions to treat (default is the
dimensionality of your input vectors)
.SS "t_quartic"
.IX Subsection "t_quartic"
.Vb 1
\&  $t = t_quartic(<options>);
.Ve
.PP
Quartic scaling \*(-- cylindrical pincushion (n\-d; with inverse)
.PP
Quartic scaling is a generalization of t_quadratic to a quartic
expansion.  Only even powers of the input coordinates are retained,
and (as with t_quadratic) sign is preserved, making it an odd function
although a true quartic transformation would be an even function.
.PP
You can apply separate distortion along any of the principal axes.  If
you want different axes, use \*(L"t_wrap\*(R" and
\&\*(L"t_linear\*(R" to rotate them to the correct angle.  The
scaling options may be scalars or vectors; if they are scalars then
the expansion is isotropic.
.PP
The formula for the expansion is:
.PP
.Vb 1
\&    f(a) = ( <a> + <strength> * a^2/<L_0> ) / (abs(<strength>) + 1)
.Ve
.PP
where <strength> is a scaling coefficient and <L_0> is a fundamental
length scale.   Negative values of <strength> result in a pincushion
contraction.
.PP
Note that, because quadratic scaling does not have a strict inverse for
coordinate systems that cross the origin, we cheat slightly and use
\&\f(CW$x\fR * abs($x)  rather than \f(CW$x\fR**2.  This does the Right thing for pincushion
and barrel distortion, but means that t_quadratic does not behave exactly
like t_cubic with a null cubic strength coefficient.
.PP
\&\s-1OPTIONS\s0
.IP "o,origin,Origin" 3
.IX Item "o,origin,Origin"
The origin of the pincushion. (default is the, er, origin).
.IP "l,l0,length,Length,r0" 3
.IX Item "l,l0,length,Length,r0"
The fundamental scale of the transformation \*(-- the radius that remains
unchanged.  (default=1)
.IP "s,str,strength,Strength" 3
.IX Item "s,str,strength,Strength"
The relative strength of the pincushion. (default = 0.1)
.IP "honest (default=0)" 3
.IX Item "honest (default=0)"
Sets whether this is a true quadratic coordinate transform.  The more
common form is pincushion or cylindrical distortion, which switches
branches of the square root at the origin (for symmetric expansion).
Setting honest to a non-false value forces true quadratic behavior,
which is not mirror-symmetric about the origin.
.IP "d, dim, dims, Dims" 3
.IX Item "d, dim, dims, Dims"
The number of dimensions to quadratically scale (default is the
dimensionality of your input vectors)
.SS "t_spherical"
.IX Subsection "t_spherical"
.Vb 1
\&    $t = t_spherical(<options>);
.Ve
.PP
Convert Cartesian to spherical coordinates.  (3\-D; with inverse)
.PP
Convert 3\-D Cartesian to spherical (theta, phi, r) coordinates.  Theta
is longitude, centered on 0, and phi is latitude, also centered on 0.
Unless you specify Euler angles, the pole points in the +Z direction
and the prime meridian is in the +X direction.  The default is for
theta and phi to be in radians; you can select degrees if you want
them.
.PP
Just as the \*(L"t_radial\*(R" 2\-D transform acts like a 3\-D
cylindrical transform by ignoring third and higher dimensions,
Spherical acts like a hypercylindrical transform in four (or higher)
dimensions.  Also as with \*(L"t_radial\*(R", you must manually specify
the origin if you want to use more dimensions than 3.
.PP
To deal with latitude & longitude on the surface of a sphere (rather
than full 3\-D coordinates), see
t_unit_sphere.
.PP
\&\s-1OPTIONS:\s0
.IP "o, origin, Origin [default (0,0,0)]" 3
.IX Item "o, origin, Origin [default (0,0,0)]"
This is the Cartesian origin of the spherical expansion.  Pass in a \s-1PDL\s0
or an array ref.
.IP "e, euler, Euler [default (0,0,0)]" 3
.IX Item "e, euler, Euler [default (0,0,0)]"
This is a 3\-vector containing Euler angles to change the angle of the
pole and ordinate.  The first two numbers are the (theta, phi) angles
of the pole in a (+Z,+X) spherical expansion, and the last is the
angle that the new prime meridian makes with the meridian of a simply
tilted sphere.  This is implemented by composing the output transform
with a PDL::Transform::Linear object.
.IP "u, unit, Unit (default radians)" 3
.IX Item "u, unit, Unit (default radians)"
This option sets the angular unit to be used.  Acceptable values are
\&\*(L"degrees\*(R",\*(L"radians\*(R", or reasonable substrings thereof (e.g. \*(L"deg\*(R", and
\&\*(L"rad\*(R", but \*(L"d\*(R" and \*(L"r\*(R" are deprecated).  Once genuine unit processing
comes online (a la Math::Units) any angular unit should be \s-1OK.\s0
.SS "t_projective"
.IX Subsection "t_projective"
.Vb 1
\&    $t = t_projective(<options>);
.Ve
.PP
Projective transformation
.PP
Projective transforms are simple quadratic, quasi-linear
transformations.  They are the simplest transformation that
can continuously warp an image plane so that four arbitrarily chosen
points exactly map to four other arbitrarily chosen points.  They
have the property that straight lines remain straight after transformation.
.PP
You can specify your projective transformation directly in homogeneous
coordinates, or (in 2 dimensions only) as a set of four unique points that
are mapped one to the other by the transformation.
.PP
Projective transforms are quasi-linear because they are most easily
described as a linear transformation in homogeneous coordinates
(e.g. (x',y',w) where w is a normalization factor: x = x'/w, etc.).
In those coordinates, an N\-D projective transformation is represented
as simple multiplication of an N+1\-vector by an N+1 x N+1 matrix,
whose lower-right corner value is 1.
.PP
If the bottom row of the matrix consists of all zeroes, then the
transformation reduces to a linear affine transformation (as in
\&\*(L"t_linear\*(R").
.PP
If the bottom row of the matrix contains nonzero elements, then the
transformed x,y,z,etc. coordinates are related to the original coordinates
by a quadratic polynomial, because the normalization factor 'w' allows
a second factor of x,y, and/or z to enter the equations.
.PP
\&\s-1OPTIONS:\s0
.IP "m, mat, matrix, Matrix" 3
.IX Item "m, mat, matrix, Matrix"
If specified, this is the homogeneous-coordinate matrix to use.  It must
be N+1 x N+1, for an N\-dimensional transformation.
.IP "p, point, points, Points" 3
.IX Item "p, point, points, Points"
If specified, this is the set of four points that should be mapped one to the other.
The homogeneous-coordinate matrix is calculated from them.  You should feed in a
2x2x4 \s-1PDL,\s0 where the 0 dimension runs over coordinate, the 1 dimension runs between input
and output, and the 2 dimension runs over point.  For example, specifying
.Sp
.Vb 1
\&  p=> pdl([ [[0,1],[0,1]], [[5,9],[5,8]], [[9,4],[9,3]], [[0,0],[0,0]] ])
.Ve
.Sp
maps the origin and the point (0,1) to themselves, the point (5,9) to (5,8), and
the point (9,4) to (9,3).
.Sp
This is similar to the behavior of fitwarp2d with a quadratic polynomial.
.SH "AUTHOR"
.IX Header "AUTHOR"
Copyright 2002, 2003 Craig DeForest.  There is no warranty.  You are allowed
to redistribute this software under certain conditions.  For details,
see the file \s-1COPYING\s0 in the \s-1PDL\s0 distribution.  If this file is
separated from the \s-1PDL\s0 distribution, the copyright notice should be
included in the file.