Hi Oliver,<br><br>Good to hear from you again. Sorry for the long delay in reply, and thanks for checking out the ImageJ2 plugin framework.<br><br>First, a little background: as Johannes mentioned, there has been initial development of a "workflow engine" for ImageJ2:<br>
<br> <a href="http://dev.imagejdev.org/trac/imagej/browser/trunk/extra/workflow/src/main/java/imagej/workflow">http://dev.imagejdev.org/trac/imagej/browser/trunk/extra/workflow/src/main/java/imagej/workflow</a><br><br>We have begun a reconciliation of the workflow engine with the plugin framework. Essentially, the toplevel idea is that of a "module" with inputs and outputs; see:<br>
<br> <a href="http://dev.imagejdev.org/trac/imagej/browser/trunk/core/plugin/src/main/java/imagej/module">http://dev.imagejdev.org/trac/imagej/browser/trunk/core/plugin/src/main/java/imagej/module</a><br><br>The plugin framework implements the module interfaces, while providing the annotations needed to make writing standalone plugins easy:<br>
<br> <a href="http://dev.imagejdev.org/trac/imagej/browser/trunk/core/plugin/src/main/java/imagej/plugin">http://dev.imagejdev.org/trac/imagej/browser/trunk/core/plugin/src/main/java/imagej/plugin</a><br><br>The workflow engine was used to create a proof-of-concept UI called Workflow Pipes (similar to the ImageFlow project mentioned by Johannes) for graphically connecting together plugins into a directed object graph. In the future, we hope to flesh out this UI further and include with core ImageJ.<br>
<br>Anyway, none of this work precludes your implementation from being useful as well, since our focus was not on data provenance at all yet (though we are very interested in supporting it).<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Would it be possible to extend or modify the @Parameter annotation to<br>
categorize a field as input, output, parameter or supplemental?<br>
</blockquote><div><br>Certainly! How about a "visibility" enum with values: NORMAL (default), TRANSIENT (for no history), and INVISIBLE (for no recording nor history). If anyone has an idea for better names, I'm all ears. In the meantime, I have committed an initial version of this enum to SVN and updated the Parameter class:<br>
<br> <a href="http://dev.imagejdev.org/trac/imagej/changeset/2413">http://dev.imagejdev.org/trac/imagej/changeset/2413</a><br><br></div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Our annotation also takes an "explanation" string to describe the<br>
parameter in human-readable form, but it is not essential for the<br>
automatic documentation.<br></blockquote><div><br>Sure, I have added a "String description" field to @Parameter, which should serve:<br><br> <a href="http://dev.imagejdev.org/trac/imagej/changeset/2412">http://dev.imagejdev.org/trac/imagej/changeset/2412</a><br>
<br></div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">We would really like to merge these annotations, because the processing<br>
chain documentation could be easily employed by IJ plugins that use the<br>
@Parameter annotation and no additional annotation would be necessary.<br></blockquote><div><br>Great, please let us know what else you need to make this happen!<br><br></div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Another question: Is there any interest in an automatic documentation of<br>
the processing chain?<br></blockquote>
<br>I think so, but am not sure what you mean. Could you elaborate? What I would like to see is a way for plugins to self-document their parameters more thoroughly (tooltips etc.), similar to how the Bio-Formats Importer plugin works in ImageJ 1.x now. This would reduce the need for external wiki pages about plugins in many cases.<br>
<br>Lastly, I will second Johannes's question: are you planning to open source this work? Or is it already available somewhere? Would you be interested in integrating it into ImageJ2 core?<br><br>Regards,<br>Curtis<br>
<br>P.S. Sorry I have not had time to read over your manual. As we pursue this functionality further, hopefully I'll learn more about your data provenance model.<br><br><div class="gmail_quote">On Tue, Mar 8, 2011 at 6:26 AM, Oliver Gress <span dir="ltr"><<a href="mailto:oliver.gress@informatik.uni-halle.de">oliver.gress@informatik.uni-halle.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi all,<br>
<br>
we have developed a way for automatic documentation of the processing<br>
chain of an image or other results in ImageJ.<br>
For improved integration with IJ, we would like to discuss a<br>
modification/extension of the @Parameter annotation in IJ-Dev.<br>
<br>
The basic concept is to consider each processing step as an "operator",<br>
that takes some input and computes results, which might become input to<br>
another operator. Such an operator may be an ImageJ plugin or any java<br>
class that satisfies the specification.<br>
<br>
The specific interface of such an operator is described by inputs,<br>
parameters, supplementals and outputs.<br>
Inputs and outputs are used to trace the processing chain, from which a<br>
"history" graph is created.<br>
Parameters are inputs that are not traced but recorded. Supplementals<br>
are not recorded at all and are intended for parameters that have no<br>
effect on the results (e.g. a verbose flag).<br>
<br>
We employ java annotations to determine the above interpretation of the<br>
fields of a class and thus the interface of an operator.<br>
At the moment, we use our own annotation class, because @Parameter from<br>
IJ-Dev does not allow the detailed categorization of arguments that<br>
would be required by our concept. It only allows to specify if an<br>
argument is output or not.<br>
I know that @Parameter is intended to describe the parameters of a<br>
plugin, e.g. to create a parameter dialog automatically.<br>
I'd like to ask if the idea of @Parameter could be extended to a more<br>
general point of view:<br>
<br>
Would it be possible to extend or modify the @Parameter annotation to<br>
categorize a field as input, output, parameter or supplemental?<br>
Our annotation also takes an "explanation" string to describe the<br>
parameter in human-readable form, but it is not essential for the<br>
automatic documentation.<br>
<br>
We would really like to merge these annotations, because the processing<br>
chain documentation could be easily employed by IJ plugins that use the<br>
@Parameter annotation and no additional annotation would be necessary.<br>
<br>
Another question: Is there any interest in an automatic documentation of<br>
the processing chain?<br>
<br>
<br>
I have uploaded an excerpt of our manual for further reading on the<br>
operator and history concept:<br>
<a href="http://users.informatik.uni-halle.de/%7Egress/mitobo_manual_excerpt.pdf" target="_blank">http://users.informatik.uni-halle.de/~gress/mitobo_manual_excerpt.pdf</a><br>
The manual is rewritten at the moment, therefore only an excerpt. If you<br>
find a link to our website, please don't refer to the resources that can<br>
be found there because they are outdated. There will be a new version<br>
soon (depending on the annotation issue).<br>
<br>
Our annotation can be found here:<br>
<a href="http://users.informatik.uni-halle.de/%7Egress/MTBArgumentAnnotation.java" target="_blank">http://users.informatik.uni-halle.de/~gress/MTBArgumentAnnotation.java</a><br>
<br>
<br>
Best regards<br>
Oliver<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a><br>
<a href="http://imagejdev.org/mailman/listinfo/imagej-devel" target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a><br>
</blockquote></div><br>