[ImageJ-devel] experiments with a new ops framework for imglib2

[Christian Dietz]

Hi Tobias,

this sounds amazing. I'm looking forward to adapt our KNIME related code 
to the new ops/ROIs. See below for some comments on the problems you 
mentioned.

Am 05/07/2013 03:26 PM, schrieb Tobias Pietzsch:
> Problems
> ========
> Performance:
> We have seen that we now are at nesting levels where the JIT becomes quite
> unpredictable. So performance tuning for this stuff is not easy. In Madison,
> Johannes showed that for special cases we can become very fast using javassist
> to basically compile it ourselves.

This is really important for us. We should think about optimizing
the iteration over special ROIs like 0-1-planes in a n-dimensional 
image, as we already started in Octobre 
(https://github.com/imagej/imglib/tree/subinterval-cursor).

> Temporaries:
> One problem that is completely unsolved in this proposal is the creation of
> temporary results (pixels, images, etc...). I had discussions with Christian
> Dietz about this, because they really need this in KNIME. I mainly remember,
> that there are all kinds of problems and we couldn't come up with a satisfying
> solution. Christian, maybe you can comment a bit, on what the requirements for
> temporary creation are.

If you concatenate operations, you are often not interested in the 
intermediate results. For example if you do n-iterations of a 
morphological erode, you really just need to know the final output.
If you process tons of images, one may want to avoid creating an output 
(e.g. a temporary image) for each of the intermediate results, as in 
many cases one temporary image is sufficient.

So the requirements would be, that if you concatenate ops, some 
OperationBuilder is capable to reduce the amount of created temporary 
images. Ideally, the OperationBuilder would also recognize, that e.g. a 
Img<FloatType> could be used as a Img<BitType> temporary image.

> Copying Ops:
> For parallelization it is necessary that we copy Ops (which can be rather
> complicated nested trees) in order to run on partitions of the input data in
> parallel. This is not trivial, because the copying mechanism has to decide
> which temporaries to recreate, reassign ports between copied ops, etc...

This is also crucial for us. As we already run the current ops in 
parallel on partitions of the input data.
Two more questions: Are there plans to merge your 
implementations/concept of ROIs with the work of Lee? What about 
Labelings in ImgLib2 and ImageJ2, did you talk about them?

Best regards,

Christian