Ticket #729 (new feature)
Opened 2011-08-17T14:21:51-05:00
Last modified 2012-12-06T11:21:08-06:00
Imglib OPS enhancement ideas
Reported by: | bdezonia | Owned by: | bdezonia |
---|---|---|---|
Priority: | major | Milestone: | imagej-2.0.0 |
Component: | ImgLib2 | Version: | |
Severity: | serious | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description
This ticket is an idea dump. New separate tickets should be hatched and tackled as appropriate. Ideas for enhancement:
IJ2 uses a lot of unary operations. A lot of these operations could be converted to binary operations between a ConstantFunction and the existing ImageFunction.
Make a function that is a composition of other functions (ComposedFunction). It maintains a local neighborhood for each subfunction and delegates evaluate() calls to the correct subfunction.
Given composed function idea it might be useful to track a functions domain and compose from domain compatible functions.
Make a PointNeighborhood which is a neighborhood whose neg & pos offets are all zero. Could hatch its own high speed iterator.
Find ways to performance improve the RealAverage & RealMedian functions. Median does a sort when it could find a faster means of finding the middle value(s). Knuth has such algorithms.
Make an Int class (like Bool, Real, Complex)? These might go away and transition to RealType, ShortType, Floattype, etc.
Flesh out numerous examples showing discrete integration, conditional assignment within the intersection of an ellipse and a square, hilighting all pixels on the border of a binary figure in an image, etc.
Old revisions had some ideas not yet present:
- boolean b = function.canAccept(numDimensions)
- functions that return a vector of primitive values
- a function that returns the distance from a fixed point
- the ability to pass a NullFunction to an ImageAssignement and collect stats via an Observer. Make these assigners handle Observers
- make assigners interruptable
Make this code multithreaded. Need to expand Function definition to have a duplicate() method. For each processor you duplicate() a function and pass each function to its own thread. They work on different parts of output image. Each cursor lives in its own thread this way.
Play with Complex and Continuous functions. See how we can take advantage of this.
I have many notes in a workbook at home that should be gleaned for further ideas.
Change History
comment:1 Changed 2011-09-14T10:52:23-05:00 by bdezonia
comment:2 Changed 2011-09-21T22:11:13-05:00 by bdezonia
More ideas:
- make a bunch of operations of type <Complex,Real> such as abs()/modulus()/magnitude(), arg(), real(), imag(), etc.
- make a sinc(pi*m) function
comment:3 Changed 2011-10-03T13:26:18-05:00 by bdezonia
Image assignment classes (Real and Complex) were made multithreaded recently.
comment:4 Changed 2012-05-14T14:34:06-05:00 by bdezonia
Note that once could find commonality between a UnaryRelation and a Condition. These might be two ways of looking at the same concept. See if we can eliminate one of them.
comment:5 Changed 2012-05-14T14:35:27-05:00 by bdezonia
There are two kinds of functions right now: Function<long[],T> and Function<PointSet,T>. Note that in the long[] case it is a PointSet of one point represented as a long[]. Maybe we can get rid of the distinction.
comment:6 Changed 2012-05-14T14:36:01-05:00 by bdezonia
Much documentation is needed for the code
comment:7 Changed 2012-05-14T14:38:44-05:00 by bdezonia
It would be nice if we could use partial coordinate specification. By this I mean what if we defined a 5d space and then partially specified an axis at a time (like just x, y, and c) and asked for median. The median func would sum on all ZT points with the XYC values already determined. This would simplify the definition of functions in general. They iterate all dims not specified.
comment:8 Changed 2012-05-14T14:40:26-05:00 by bdezonia
When PointSets went into OPS the ContinuousNeighborhood code disappeared. Think how PointSets (or in the future ProbabilityMaps) would work in a continuous space rather than dicrete long[]'s.
comment:9 Changed 2012-05-14T14:43:23-05:00 by bdezonia
When PointSets and InputIterators were adopted we lost code that allowed functions to reason about the relationship between a point and its surrounding neighborhood. I have maintained the idea by writing some functions and/or conditions such as Condition<Tuple2<long[],PointSet>>. The code compiles but there is no actual InputIterator defined to walk data in this fashion. Implement such code.
A simple implementation of ComposedFunction is complete.