In addition to ops in general, which can have M inputs and N outputs of whatever type, there are three kinds of “special” ops: computer, function and inplace. See this javadoc for a summary. In the unary case (single primary input), we have:
Computer - An op which computes a result from the given input I, storing the result into the specified preallocated output reference O.
Function - An op which computes a result from the given input I, returning the result as a newly allocated output O.
Inplace - An op which mutates the contents of its argument in-place.
And some “hybrid” ops are capable of operating in more than one of these ways.
In SciJava terms, when you pass a preallocated output to a computer op, for its contents to be filled in, that output is actually a parameter of type “both”—you give it as input, and it is mutated. Same for inplace. Of the three, only function synthesizes a new output object and returns it.
We have all three of these because they fulfill different requirements and use cases for callers. And because different algorithms have different requirements as well, due to space/time complexity tradeoffs, etc.
FillHoles has no unit tests, which is a bummer. However, its cousin
ExtractHoles does; maybe looking at it helps.
@dietzc Any ideas?
Note that for succinctness, you can use:
Img<BitType> mask = ArrayImgs.bits(lblimg);
The short answer is: the
DefaultFillHoles function behavior is currently broken.
Your invocation above is an unsafe and unchecked cast, which you should not do, and which was not intended to be needed here. The
DefaultFillHoles function method signature should instead have a return type of
Img<BitType>. The fact that it does not is a bug in the
DefaultFillHoles implementation is a hybrid computer/function, but with a generic
T parameter in its output type. This is bogus and needs to be changed: the function version of
FillHoles needs to return a concrete type such as
BitType. Otherwise, there is no way to infer the
T at runtime within the implementation. Right now,
DefaultFillHoles requests an op which can create the output from the input, performing an unchecked+invalid cast from
UnaryFunctionOp<Interval, DoubleType> to
UnaryFunctionOp<RandomAccessibleInterval<T>, RandomAccessible<T>> where
T extends BooleanType<T>.
Anyway, as a workaround for now, try calling the computer method signature:
<T extends BooleanType<T>> RandomAccessibleInterval<T> fillHoles(RandomAccessibleInterval<T> out, RandomAccessibleInterval<T> in)
You will need to construct a preallocated output image to pass as