Region for psImageCut

[David.Robbins@…]

It's unclear from the SDRS whether or not psImageCut should function similar to
other related functions in it's interpretation of region coordinates.
Specifically, indexing from the tail is currently unsupported and seems like it
should be. Currently, we seem to be discussing/deciding on whether or not the
lower bounds (x0, y0) should allow indexing from the end. However, in most
functions, at least the upper bounds (x1, y1) are allowed to use negative numbers.
In ImageCut it also seems to be the case that the current implementation allows
for the upper bounds to be smaller than the lower bounds, ie, x0 > x1, etc. I
am assuming that this type of behavior should NOT be allowed and it is simply
working this way by mistake?

[eugene]

psImageCut is really a different beast, operating on fractional pixels and
identifying a specific line, rather than a true rectangular region. We
definitely do NOT want to apply the same rules of the regions to the region
supplied for this function: we want to be able to specify the start and stop
coordinates abritrarily on the image.

I propose in fact modifying the API to explicitly supply the start and stop
coordinates rather than use a region: this was probably a poor choice in the
first place. We have the psPlane structure to represent a coordinate pair; I
propose we re-define psImageCut as follows:

psVector* psImageSlice(psVector* out,

psPixels* coords,
const psImage* input,
const psImage* mask,
psMaskType maskVal,
psPlane start,
psPlane stop,
psImageCutDirection direction,
const psStats* stats)

[David.Robbins@…]

I agree that changing the API in this case is the best move. However, you've
included the prototype for psImageSlice, not psImageCut. From what I can tell,
it appears that psImageSlice is actually okay. For psImageCut, I like the idea
of 'start' and 'stop' but I have a suggestion to that end. Instead of using
psPlane's, I would suggest psPixelCoord's, most likely static.
ie,
psImageCut(...,

psPixelCoord start;
psPixelCoord stop;

or,

psPixelCoord *start;
psPixelCoord *stop;

The second makes more sense since we recently discussed wanting all variables to
be dynamically allocated. However if we take that approach and use
psPixelCoord, I would have to suggest also creating allocate and free functions:
ie, psPixelCoordAlloc, freePixelCoord.

Furthermore, regardless of the choice of data structures, what types of rules
are we following here? I'm not sure why negative indexing here should be
unsupported or whether the coordinates of the line segment need be inside even
the parent image.

If we change psImageCut to use psPixelCoord's, I suggest changing
psImageRadialCut as well. (float x, float y => psPixelCoord coord)
For psImageRadialCut, can we allow negative coords? I don't see any reason not
to do so here. Should this function allow for the center to be outside of the
subimage? outside of the parent image?

[David.Robbins@…]

Another similar issue i've encountered in certain image functions such as
psImageTransform is the use of [0,0,0,0] for region. Some functions allow for
this region to be specified and upon doing so, includes the entire image area.
If this is a valid case in some functions, it should probably be valid in as
many functions as applicable. For instance, I have added this functionality to
psImageTransform.
Also in transform, there is a question on what the limits of the psRegion should
be. Can the region be outside of the subimage or parent image in this function?

Currently I see no initial error checks for the bounds being too large or too

small.

[Paul Price]

I don't think the region in psImageTransform should be allowed to extend beyond
the boundary of the output image.

[David.Robbins@…]

Have we made any decisions on the replacement of region with start/stop?

[eugene]

these issues were dropped, and these functions have not been used as expected. My preference is for psImageCut to use a pair of values: psImageCut (...., psPixelCoord start, psPixelCoord stop,..) rather than a pointer.

For these functions a negative pixel value is simply a location off the edge of an image and should result in values with NaNs in the output vector for the invalid portions.