#46 closed defect (fixed)
psImageClip/psImageClipNaN use of float parameters
| Reported by: | Owned by: | eugene | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | PSLib SDRS | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: |
Description
psImageClip/psImageClipNaN uses floats for such parameters as min,max,vmin,vmax,
and value.
The problem is that this function is to support a slew of datatypes, including
complex, double-precision float, and integers.
psC32/psC64: should I compare the absolute value of the complex pixel value to
the float? Should I then just set the complex number to the given float (i.e.,
a zero imaginary component)?
psC64/psF64: the value I'm comparing to and possible setting to is less
precision than the pixel values; is that really fine?
Maybe the better thing to do is make things like min/max/vmin/vmax/value (or at
least vmin/vmax/value) to be void*, which points to the same datatype as the
image pixels. That should fix the precision/complex problems above. Another
option is to reevaluate the need for these functions for things like complex
imagery.

regarding the precision aspect, we can probably safely use double (psF64) as the
data type for the min/max/value parameters and cast them to floats when the data
is of type psF32. If the min/max values are out of range for psF32, that is not
an error as the request will technically be satisfied. If the target value
(vmin/vmax) is out of range (a rare case) and the data is of type psF32, that
should probably raise an error since the request cannot be satisfied.
regarding the complex types, we will need to be able to clip complex input data
(ie, to filter out extreme data), but, as you point out, there are at least two
reasonable ways to interpret it. min/max could represent absolute values, in
which case the complex plane is limited to an annulus; min/max could represent
complex points, in which case the complex plane is limited to a rectangular
region. In principal, I like the idea of having the arguments be of type
p_psScalar, in which case both cases above could be easily defined. but, in
practice, most operations will be using the real data types, so that structure
would lead to unneeded code complexity. also, the operation would be implicit
on the data type, which may lead to confusion. let's restrict the
min/max/vmin/vmax values to double and specifiy this function to perform the
annular clipping for complex images. we'll add a different function which
handles the rectangular complex plane clipping:
int psImageClipComplexRegion (psImage *image, psC64 min, psC64 vmin, psC64 max,
psC64 vmax);