IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Opened 20 years ago

Closed 20 years ago

Last modified 20 years ago

#631 closed defect (fixed)

pslib <-> SDRS API convergance

Reported by: jhoblitt Owned by: David.Robbins@…
Priority: high Milestone:
Component: types Version: 0.9.0
Severity: blocker Keywords:
Cc:

Description

I'd like to start this process by fixing the low hanging fruit first:

psFitsMoveLast [ inconsistent ]

spec :
bool psFitsMoveLast(

psFits * fits);

code :
bool psFitsMoveLast(

const psFits * fits);

The HDU cursor is being moved so this really shouldn't be a constant

psFitsUpdateImage [ inconsistent ]

spec :
bool psFitsUpdateImage(

psFits * fits,
const psImage * input,
int x0,
int y0,
int z);

code :
bool psFitsUpdateImage(

psFits * fits,
const psImage * input,
psRegion region,
int z);

psRegion is overkill here.

psImageSlice [ inconsistent ]

psVector *psImageSlice(

psVector * out,
psPixels * coords,
const psImage * input,
const psImage * mask,
psMaskType maskVal,
psRegion region,
psImageCutDirection direction,
const psStats * stats);

code :
psVector *psImageSlice(

psVector * out,
psVector * coords,
const psImage * input,
const psImage * mask,
psMaskType maskVal,
psRegion region,
psImageCutDirection direction,
const psStats * stats);

cords should be of type psPixels

psImageTransform [ inconsistent ]

spec :
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);

code :
psImage *psImageTransform(

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

blankPixels should be psPixels

psMinimizeChi2Powell [ inconsistent ]

spec :
bool psMinimizeChi2Powell(

psMinimization * min,
psVector * params,
psMinConstrain * constrain,
const psArray * coords,
const psVector * value,
const psVector * error,
psMinimizeChi2PowellFunc model);

code :
bool psMinimizeChi2Powell(

psMinimization * min,
psVector * params,
const psVector * paramMask,
const psArray * coords,
const psVector * value,
const psVector * error,
psMinimizeChi2PowellFunc model);

Replace const psVector * paramMask with psMinConstrain * constrain.

psMinimizeLMChi2 [ inconsistent ]

spec :
bool psMinimizeLMChi2(

psMinimization * min,
psImage * covar,
psVector * params,
psMinConstrain * constrain,
const psArray * x,
const psVector * y,
const psVector * yWt,
psMinimizeLMChi2Func func);

code :
bool psMinimizeLMChi2(

psMinimization * min,
psImage * covar,
psVector * params,
const psVector * paramMask,
const psArray * x,
const psVector * y,
const psVector * yErr,
psMinimizeLMChi2Func func);

same change as psMinimizeChi2Powell()

psPlaneDistortAlloc [ inconsistent ]

spec :
psPlaneDistort *psPlaneDistortAlloc(

int order1,
int order2,
int order3,
int order4);

code :
psPlaneDistort *psPlaneDistortAlloc(

int n1,
int n2,
int n3,
int n4);

We prefer order[1-4] over n[1-4].

psPlaneTransformAlloc [ inconsistent ]

spec :
psPlaneTransform *psPlaneTransformAlloc(

int order1,
int order2);

code :
psPlaneTransform *psPlaneTransformAlloc(

int n1,
int n2);

same as psPlaneDistortAlloc()

psPolynomial1DAlloc [ inconsistent ]

spec :
psPolynomial1D *psPolynomial1DAlloc(

psPolynomialType type,
unsigned int nX);

code :
psPolynomial1D *psPolynomial1DAlloc(

unsigned int n,
psPolynomialType type);

Is there a good reason not to use psPolynomialType?

psSpline1DAlloc [ inconsistent ]

spec :
psSpline1D *psSpline1DAlloc(

unsigned int n,
unsigned int order,
float min,
float max);

code :
psSpline1D *psSpline1DAlloc(

);

psSpline1DAlloc() does not appear to be implimented correctly.

psImage [ inconsistent ]

spec :
typedef struct psImage {

psMathType type;
const int numCols;
const int numRows;
int col0;
int row0;
union {

psS8 S8;
psS16
S16;
psS32 S32;
psS64
S64;
psU8 U8;
psU16
U16;
psU32 U32;
psU64
U64;
psF32 F32;
psF64
F64;
psC32 C32;
psC64
C64;
psPtr V;

} data;
const struct psImage *parent;
psPtr p_rawDataBuffer;
psArray *children;
void *lock;

} psImage;
code :
typedef struct psImage {

const psMathType type;
const int numCols;
const int numRows;
int col0;
int row0;
union {

psS8 S8;
psS16
S16;
psS32 S32;
psS64
S64;
psU8 U8;
psU16
U16;
psU32 U32;
psU64
U64;
psF32 F32;
psF64
F64;
psC32 C32;
psC64
C64;
psPtr *V;

} data;
const struct psImage *parent;
psPtr p_rawDataBuffer;
psArray *children;
void *lock;

} psImage;

Please make type const

psList [ inconsistent ]

spec :
typedef struct {

long n;
psListElem *head;
psListElem *tail;
psArray *iterators;
void *lock;

} psList;
code :
typedef struct {

long n;
psListElem *head;
psListElem *tail;
psArray *iterators;
pthread_mutex_t p_lock;
void *lock;

} psList;

Please remove p_lock. it is redudant with lock.

Change History (7)

comment:1 by robert.desonia@…, 20 years ago

Owner: changed from robert.desonia@… to David.Robbins@…

comment:2 by David.Robbins@…, 20 years ago

We are actually aware of all these tasks and they have been in gforge already.
Some have been done already and a few have been scheduled. A couple may not
actually be valid either.
In psImage, it says to make type const. It is const in the code, it is NOT
const in the spec now. Also, we have discussed this a bit in the past, but the
psPtr V in psImage should be psPtr *V as it is in the code. This avoids some
issues in using psImages in certain functions.
For psList, we felt the best thing to do with the lock situation was to leave
the p_lock in place as a system lock and give the user access to the void *lock
for any additional locking needs. Thus I don't think it's actually redundant
here, but if you really don't like it we can take a closer look at it.

comment:3 by jhoblitt, 20 years ago

I've modified the definition of psImage in the SDRS to match the implimentation.

I don't understand what you meant when you referred to a "system lock" and I

can't find a requirement for it. Please remove the p_lock memeber from psList.

comment:4 by jhoblitt, 20 years ago

Cc: eugene@… added
Severity: normalblocker

This bug needs to be resolved before the next release of pslib.

comment:5 by David.Robbins@…, 20 years ago

Resolution: fixed
Status: newclosed

Most of the api-delta changes have been made now. This bug is generally fixed
or out-of date at this point.

comment:6 by Paul Price, 20 years ago

Keywords: VERIFIED added

Bug has been resolved.... closing.

comment:7 by Paul Price, 20 years ago

Keywords: VERIFIED removed

Bugs have been fixed... closing.

Note: See TracTickets for help on using tickets.