#154 closed defect (fixed)
psKernelGenerate
| Reported by: | Owned by: | Paul Price | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | PSLib SDRS | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: |
Description
I made the following assumptions regarding the formulation of a kernel from
the shift vectors:
- Each shift represents an equal amount of exposure time (i.e., it is in
formed by a fixed-frequency clock). If that is not be the case, another input
vector representing time between shifts would be required as well.
- The initial position (0,0) is implicitly used as the first position, i.e.,
for a shift vector length of n, there are n+1 time slices and the first time
slice is at (0,0)
- The shift values are all relative to the last shift,e.g., (1,0) "right";
(0,1) "up"; (-1,0) "left" would generate a square kernel with a value of 0.25
each (1/4 time spent at each location).
- The shift vectors have to be the same datatype, but that can be any
numeric type as long as the values are integer (e.g., can be a float or
complex vector, but each shift is always an integer amount in the real
domain).
Does these seem reasonable?
Change History (4)
comment:1 by , 22 years ago
| Owner: | changed from to |
|---|
comment:2 by , 22 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
JT says that the shifts will be specified along with the times, which may not
necessarily be uniform. Correspondingly, I have reworked the API in the SDRS:
Given a list of values (e.g., shifts made in the course of OT
guiding), \code{psKernelGenerate} shall return the appropriate kernel.
The API shall be the following:
\begin{verbatim}
psKernel *psKernelGenerate(const psVector *tShifts, const psVector *xShifts,
const psVector *yShifts, bool relative);
\end{verbatim}
The vectors \code{xShifts} and \code{yShifts}, which are a list of
shifts made at the times \code{tShifts}, are used to construct the
appropriate kernel. If \code{relative} is \code{true}, then each
shift is to be interpreted relative the shift made before; if
\code{relative} is \code{false}, then the shifts are to be interpreted
relative to some starting point. The elements of the vectors should
be of an integer type; otherwise the values shall be truncated to
integers. The output kernel shall be normalized such that the sum
over the kernel is unity.
If the vectors are not all of the same number of elements, then the
function shall generate a warning shall be generated, following which,
the longer vector trimmed to the length of the shorter, and the
function shall continue.
comment:3 by , 22 years ago
| Keywords: | VERIFIED added |
|---|
Should be fixed in SDRS-07 and ADD-06 (7 September 2004).
comment:4 by , 22 years ago
| Keywords: | VERIFIED removed |
|---|

Paul: check with JT on the expectations. I don't know if they will specify
relative or absolution positions, or if the stream is x,y,t or just x,y for
every interval. since any of these are possible, the API might be generalized
to handle the different cases. for the former option, we could use an enum to
specify which is desired (PS_KERNEL_ABS_SHIFTS, PS_KERNEL_REL_SHIFTS). for the
later, we could include a third vector which, if NULL, implies uniform dwell time.