IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Opened 21 years ago

Closed 21 years ago

Last modified 21 years ago

#327 closed defect (fixed)

psImageTransform determination of proper output size

Reported by: robert.desonia@… Owned by: Paul Price
Priority: high Milestone:
Component: PSLib SDRS Version: unspecified
Severity: normal Keywords:
Cc:

Description

As the psImageTransform is specified, I will need to invert the outToIn
transform, calculate the input->output coordinate transforms for the image
boundary, etc. This could be a fairly costly operation plus since I need to
invert the transform anyway, it may make sense to just give the more intuitive
inToOut transform as a parameter.

Even if an output image is given, it may make sense to calculate the boundary of
the input image in the output domain (i.e., invert the transform, etc) to get
the subset of the output that needs to by cycled through to transform the input
image.

Do you agree with this assessment? Did you envision that both transform
directions are needed to implement this function, or am I making this more
robust than need be?

-rdd

Change History (2)

comment:1 by Paul Price, 21 years ago

Resolution: fixed
Status: newclosed

Yes, I realised this recently and updated the definition of psImageTransform for
the next cycle. Don't worry about the "blankPixels" and "pixels" parameters for
now --- they will be more clear on reading the next Modules SDRS.

\begin{verbatim}
psImage *psImageTransform(psImage *output, psPixels blankPixels, const psImage
*input,

const psImage *inputMask, int inputMaskVal, const

psPlaneTransform *outToIn,

const psRegion *region, const psPixels *pixels, psImageInterpolateMode mode,
double exposedValue);

\end{verbatim}
Transform the \code{input} image according the supplied
transformation. The size of the transformed image is defined by the
supplied \code{output} image, if non-\code{NULL}, or the \code{region}
otherwise (size \code{region->x1 - region->x0} by \code{region->y1 -
region->y0}, with \code{out->x0 = region->x0} and \code{out->y0 =
region->y0}).

If the \code{inputMask} is non-\code{NULL}, those pixels in the
\code{inputMask} matching \code{inputMaskVal} are to be ignored in the
transformation. The \code{inputMask} must be of type \code{psU8}, and
of the same size as the \code{input}, otherwise the function shall
generate an error and return \code{NULL}. The transformation
\code{outToIn} specifies the coordinates in the input image of a pixel
in the output image --- note that this is the reverse of what might be
naively expected, but it is what is required in order to use
\code{psImagePixelInterpolate}. If \code{pixels} is non-\code{NULL},
then only those pixels in the output image are transformed; otherwise,
the entire image is generated. The interpolation is performed using
the specified interpolation \code{mode}. Where a pixel in the output
image does not correspond to a pixel in the input image (or all
appropriate pixels in the input image are masked), the value shall be
set to \code{exposed}, and the pixel added to the list of
\code{blankPixels} for return to the user. This function must be
capable of handling the following types for the \code{input} (with
corresponding types for the \code{output}): \code{psF32},
\code{psF64}.

comment:2 by robert.desonia@…, 21 years ago

OK, I'll hold off on the implementation of this until the next version of the
SDRS is out.

-rdd

Note: See TracTickets for help on using tickets.