IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Opened 22 years ago

Closed 22 years ago

Last modified 22 years ago

#112 closed defect (fixed)

psImageSlice

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

Description

Upon implementing psIamgeSlice, I'm abit confused about exactly what you want.

You have a direction enum that not only specifies which axis to slice in (which
is clear enough), but a positive or negative direction as well.

Does this pos/neg component effect the region, i.e., for pos, the region is
(x,y)->(x+nx-1,y+ny-1) and for neg, it is (x,y)->(x-nx+1,y-ny+1)? If so, why
not just pass in negative nx and ny values to signify this, as it is logically
cleaner?

If that is not the proper definition of things, then does it just specify the
direction in which the vector is populated, i.e., the lowest row/col index in
the slice is the end of the vector?

If nx and ny allowed to be negative? If so, could we not redefine the function
to eliminate the POS/NEG concept in that case? (if you want to go 'NEG', pass in
the lower right corner of region as x,y and use negative nx,ny).

-rdd

Change History (14)

comment:1 by eugene, 22 years ago

Status: newassigned

the idea was (as you suggest in the second option) to specify the order of the
output values. i agree with your suggestion of allowing negative values for the
dimensions (I had ignored the posibility). I'm slightly worried about requiring
users to use that functionality to change the cut direction, as that may result
in end-post errors. they will have to know that the values go from (Xo,Yo) to
(Xo+Nx-1,Yo+Ny-1), so that the reverse direction coords become (Xo+Nx-1,Yo+Ny-1,
-Nx, -Ny) rather than (Xo+Nx,Yo+Ny, -Nx, -Ny) as one might imagine at first
glance.

Also note that if the perpendicular direction dimension is negative, this should
not affect the output values, but is just a different way to specify the same
region. ie, these two calls should return the same output vector:

psImageSlice (NULL, in, NULL, 0, Xo, Yo, Nx, Ny, PS_CUT_X, stats);
psImageSlice (NULL, in, NULL, 0, Xo, Yo + Ny - 1, Nx, -Ny, PS_CUT_X, stats);

it might also be nice to specify a parallel function which takes the same
arguments as psImageSlice and returns the vector holding the pixel coordinate
values in the cut direction. this is easy to construct by hand, but it will be
wanted pretty much anytime someone uses psImageSlice. Same for the psImageCut
and psImageRadialCut. they would take the same arguments except for the mask,
maskVal, and stats entries. perhaps names like: psImageSliceCoords?

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

For simplicity then, can I define the function to not allow negative nx or ny,
i.e. as follows?

psVector* psImageSlice(

psVector* out,
const psImage* restrict input,
const psImage* restrict mask,
psMaskType maskVal,
unsigned int col,
unsigned int row,
unsigned int numCols,
unsigned int numRows,
psImageCutDirection direction,
const psStats* stats

);

comment:3 by robert.desonia@…, 22 years ago

What would psImageSliceCoords return exactly? For

out = psImageSliceCoords(out, in, Xo, Yo, Nx, Ny, PS_CUT_X_POS);

would the return value be {Xo, Xo+1, ..., Xo+Nx-1}? And for

out = psImageSliceCoord(out, in, Xo, Yo, Nx, Ny, PS_CUT_X_NEG);

would the return value be {Xo+Nx-1, Xo+Nx-2, ..., Xo}?

If that is the case, I'd recommend rather to just add a parameter to
psImageSlice (though it already has too many really) that would return this. In
particular, a psVector* in which if NULL, nothing is done to return these
values, but if non-null, it will be filled with the vector psImageSliceCoord
would have returned.

comment:4 by eugene, 22 years ago

that is fine: we'll exclude negative values for nx and ny and we'll include an
entry (after the Vector *out) to fill up with the pixel sequence, exactly as you
specify.

comment:5 by eugene, 22 years ago

Resolution: fixed
Status: assignedclosed

updated in SDRS to have output psVector *coords (second parameter).
changed type of input coordinates to unsigned.

comment:6 by robert.desonia@…, 22 years ago

Resolution: fixed
Status: closedreopened

The latest SDRS didn't have the addition of the coords parameter, but you
stated you updated the SDRS to put it in.

Does that mean you changed your mind from the time you wrote that or did the
change get lost or something? The rel2 code has the following prototype
according to our conversation in this bug report:

psVector* psImageSlice(psVector* out,

psVector* slicePositions,
const psImage* restrict in,
const psImage* restrict mask,
unsigned int maskVal,
unsigned int col,
unsigned int row,
unsigned int numCols,
unsigned int numRows,
psImageCutDirection direction,
const psStats* stats);


Is this wrong?

-rdd

comment:7 by robert.desonia@…, 22 years ago

Resolution: fixed
Status: reopenedclosed

It is in v6 (Thursday's release).

comment:8 by Paul Price, 22 years ago

Cc: price@… added
Resolution: fixed
Status: closedreopened

We have decided that there is no need for psImageSlice to compress pixels in the
direction perpendicular to the cut direction, but what we really want is to get
a slice through an image at any arbitrary direction. Hence we have dropped
psImageCutDirection, and re-specified psImageSlice:

psVector *
psImageSlice(psVector *out, /< Vector to output, or NULL

const psImage *input, /< Input image
const psImage *mask,
/< Ignore those pixels where mask & maskVal == 1.

May be NULL

unsigned int maskVal, /< Value in mask to ignore
unsigned int xs,
/< starting x coord
unsigned int ys, /< starting y coord
unsigned int xe,
/< ending x coord
unsigned int ys, /< ending y coord
unsigned int nSamples,
/< Number of samples along the slice
psImageInterpolateMode mode /< defines statistics used to find output values

);

Extract pixels along a line segment, \code{(xs,ys)} to \code{(xe,ye)},
on the image to a vector (array of the appropriate data type). The
line segment is sampled \code{nSamples} times, hence the output vector
contains \code{nSamples} elements. The interpolation method used to
derive the output vector value at each sample along the line segment
is specified by \code{mode}. If the \code{mask} is non-\code{NULL},
then pixels for which the corresponding mask value is \code{maskVal}
are not included in the interpolation. This function must be defined
for the following types: \code{psS8}, \code{psU16}, \code{psF32},
\code{psF64}.

comment:9 by robert.desonia@…, 22 years ago

This looks to be somewhat simular to psImageCut now. Does this new psImageSlice
functionality negate the need for psImageCut?

comment:10 by Paul Price, 22 years ago

Status: reopenedassigned

Sorry, my mistake. I confused psImageCut and psImageSlice. psImageCut is to
take a cut through the data (in effect, we have removed the dw parameter for
psImageCut and replaced the psStats with a psImageInterpolateMode):
psVector *psImageCut(psVector *out, const psImage *input,

const psImage *mask, unsigned int maskVal,
float xs, float ys, float xe, float ye,
unsigned int nSamples, psImageInterpolateMode mode);

psImageSlice is intended to take a rectilinear region and reduce it into a
vector along the specified direction, applying the nominated statistic in the
direction perpendicular to that specified. It's like what you'd want to do on a
bias region: given some rectangle on the image, collapse it along the rows using
some statistic, ending up with a vector that represents the bias value as a
function of row. Since it's dealing strictly on a row/column basis, there's no
need for anything fancy (like interpolation, unlike psImageCut).

If a negative direction is specified, then the order of the output vector is
simply reversed relative to the positive direction (instead of going from 1 to
2048, say, it would go from 2048 to 1).

comment:11 by eugene, 22 years ago

Owner: changed from eugene to Paul Price
Status: assignednew

comment:12 by Paul Price, 22 years ago

Resolution: fixed
Status: newclosed

comment:13 by Paul Price, 22 years ago

Keywords: VERIFIED added

Should be fixed in SDRS-07 and ADD-06 (7 September 2004).

comment:14 by Paul Price, 22 years ago

Keywords: VERIFIED removed
Note: See TracTickets for help on using tickets.