imagej/imagej-ops — pull request #4 by dietzc (2014-03-17 15:48:00+00:00)
Title: Descriptors

Hi,

the last few days I tried to convert the existing descriptors of scijava-ops (deprecated) to imagej-ops. This pull-request is the result of this effort. There a some points I would like to discuss in general before merging:

1. Sometimes it would be very convenient to ask the OpService for operations with certain inputs _and_ output types, as you want to use the result in the following code. I understand, that this might result in very complex code, so one idea would be, that one can ask for all "functions" with a certain input/output type? This would be very helpful

2. In many or nearly all functions (e.g. MeanIRT etc) in the compute(I in, O out) I have to check weather the output is null, create the output if possible and set the output. This is very error prone and additionally not very elegant, as its against the idea, that the passed output = the result of the compute. Anyway, I think Curtis already pointed that out in an E-Mail some days ago. What about a new interface and/or abstract class for dedicated functions which create the output? Only for these Functions the output would be optional!

3. DescriptorService / DefaultDescriptorService #1: Curtis if you ever find 5 minutes to review this code this would be amazing. This is code is more or less a proof of concept (it actually works) and I'm sure many things can be generalized or reused from what's out there. By far this code is not complete and a lot of functions are missing, but for the basic case it works.
So what is the basic case: Assume you want to compute a Mean. You pass "Mean" to the descriptor service and the descriptor service will resolve (if possible) all dependencies of mean and the dependencies of the dependencies and .... (recursion). In the end you have a so called ResolvedDescriptor where all dependencies actually are resolved.
Additionally the descriptor will register an InputUpdateListener to all fields which are assignable by my desired input type (e.g. an Img or a polygon or ...), such that if you update the ResolvedDescriptor with a new input, all dependent operations will be updated directly. The cool thing is, this is done in the correct order which means, that if you for example need the sum 10 times for one descriptor of an input, you only calculate it once and it will never be recalculated until next update. I managed to do this by just using the existing API.
Of course there are many assumptions behind this procedure (especially that we don't need any additional parameters but the input etc). But these assumptions seem to be fine in context of descriptors.

4. DescriptorService / DefaultDescriptorService #2: Curtis, here we need the generic stuff. I'm checking if an input fits to the type of a ModuleItem. If this module is a function which was typed, the input object always fits as AbstractFunction i.e. has Object for its input field.

In general: It's fun developing with this framework. Anyway, it would be really nice if one could be more precise about what kind of op he actually wants or what kind of function one actually wants (specify input/output of function).

Further plans after these points are all clarified: Adapt this branch to the changes, move more descriptors (Haralick, HoG, Zernike, Hu, Shape, ...) from scijava-ops to imagej-ops and waiting for request to implement more features!

I hope this all makes at least a little sense,

Christian