Ticket #1559 (closed defect: wontfix)
Opened 2012-10-31T12:38:09-05:00
Last modified 2014-06-08T22:34:56-05:00
OPS: RealEquationFunction is limited by coordinate space
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: | imagej2-unscheduled |
| Component: | ImgLib2 OPS | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1467 |
Description (last modified by bdezonia)
RealEquationFunction works in long[] space. It should work in both long[] space and double[] space. This could be accomplished if OPS worked in Coordinate<?> space of which the two possibilities are implementations. Note that PointSets would then be made of Coordinates as did Functions.
Curtis thought a change like this to Imglib was outside the needs of the scientists who need to implement algorithms.
However right now RealFunctionEquation is hampered in its usefulness. To have two versions of the code would be bad. Two provide two compute() methods is kludgy too.
Change History
comment:3 in reply to: ↑ 1 Changed 2012-11-02T11:03:08-05:00 by bdezonia
Replying to bdezonia:
Initial investigation of this path shows changing RealEquationFunction to double[] space is not trivial. It reaches into numerous classes deeper than one would hope. It really does seem that the split between double[] coords and long[] coords is insidious.
comment:4 Changed 2012-11-02T11:43:13-05:00 by bdezonia
Note that as part of investigation I hatched coordinate adaptation functions (RealCoordinateAdapterFunction and IntegerCoordinateAdapterFunction). I have kept them around as they may prove useful going forward.
comment:6 Changed 2013-01-22T12:27:02-06:00 by bdezonia
- Milestone changed from imagej2-b7-ndim-data to imageJ-2.0.0-TODO
comment:7 Changed 2014-06-08T22:34:56-05:00 by curtis
- Status changed from new to closed
- Resolution set to wontfix
ImgLib2 OPS is retired in favor of ImageJ OPS. We'll tackle the above issue in the future only if a use case arises that needs it.
A workaround would be to define RealEquationFunction to work in double[] space. Then define an adapter function that allows a function that takes long[] input to adapt the coords to double[] space and invloke a func based on double[] coords. This would cause some performance hit having to continually translate input coordinates. But it would work and it would keep us from having to hatch two different ways to support RealEquationFunction.