IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Opened 21 years ago

Closed 21 years ago

Last modified 21 years ago

#582 closed defect (fixed)

psImageTransform

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

Description

In the latest SDRS, the blankPixels argument is now a psArray, but it is not clear why. Frankly, I don't
know why it can not just be a psPixels*.

Can you expand on the description of this function so that it is absolutely clear what blankPixels should
return. Is it a list of pixel locations in the output image that do not correspond to a pixel in the input
image?

Also, was it changed to a double-pointer from single-pointer because you wanted the function to
allocate the appropriate psArray or psPixels (depending on the outcome of the last question)? Right
now, it assumes that if you pass a NULL, you don't want this information returned, which seems handy.
It does, however, put the responsibility on the user to allocate the output object prior to invokation.

-rdd

Change History (1)

comment:1 by Paul Price, 21 years ago

Resolution: fixed
Status: newclosed

I think this is a leftover of a previous version of psPixels (that only carried
one pixel position, not an array). Let's make it psPixels blankPixels. The
double star is so that the function can allocate it. I don't think there's much
harm in having it only *blankPixels, but I thought it would be convenient to the
user.

It contains, as you said, a list of all pixels on the output image that don't
correspond to any pixel (or rather, any valid pixel) in the input image.

\begin{prototype}
psImage *psImageTransform(psImage *output,

psPixels blankPixels,
const psImage *input,
const psImage *inputMask,
psMaskType inputMaskVal,
const psPlaneTransform *outToIn,
psRegion region,
const psPixels *pixels,
psImageInterpolateMode mode,
double exposedValue);

\end{prototype}
Transform the \code{input} image according the supplied
transformation. The size of the transformed image is defined by the
\code{region} (size \code{region.x1 - region.x0} by \code{region.y1 -
region.y0}, with \code{out->x0 = region.x0} and \code{out->y0 =
region.y0}). \tbd{is this subimage-safe}

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{psMaskType}, 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 the \code{pixels} array is
non-\code{NULL}, it shall consist of \code{psPixelCoord}s, and only
those pixels in the output image shall be 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 appropriate list of
pixels, \code{blankPixels} (which shall be allocated if
\code{blankPixels} is \code{non-NULL} and \code{*blankPixels} is
\code{NULL}), 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}.

Note: See TracTickets for help on using tickets.