[ImageJ-devel] ImageJ - KNIME Integration: open questions

[Lee Kamentsky]

On Wed, May 15, 2013 at 9:08 AM, Michael Zinsmaier <michael.zinsmaier at gmx.de
> wrote:

>  Hi all,
>
>  after you guys have made so much progress during the hackathon, we felt
> motivated to review our KNIME-ImageJ2 integration and try to further
> improve it, as we want to have everything set-up when you release ImageJ2
> ;-)
>
> Anyway, we discussed several things and a lot of questions came up
> concerning ImageJ2:
>
> Thx guys, lots of stuff below also applies to CellProfiler running
ImageJ2.0 plugins.

>

>  * Why is the threshold  plugin an interactive command? This for instance
> prevents the plugin from  beeing executing in headless mode (and hence from
> appearing as a KNIME node), which might be desirable in some use  cases.
>

I hadn't looked at the interactive commands with regard to CellProfiler. It
looks like "buttons" could be interpreted as possible headless actions that
could be performed... at least in some cases. I have CellProfiler analogs
for most of the parameter types, but that one is new. I'm thinking that I
might detect whether a plugin is interactive and, if so, display each
button as a radio button, so that the button's callback could be executed
in the context of a CellProfiler headless pipeline execution. For
Threshold, I can see reasons for executing the callbacks for "auto",
"apply" and "delete" in a headless context - unfortunately, CellProfiler
would convert the ThresholdOverlay to a binary mask, so "delete" doesn't
make much sense for us.

>
>
> * In KNIME we are currently loading all available plugins in the classpath
> which are headless executable. But therewith plugins like "Help",
> "Easteregg", "LoadDataSet" will appear as KNIME nodes as well. However they
> can't do anything useful in the KNIME context (as they are  ImageJ2
> specific). Are you planing to re-organize the plugins, e.g. such that
> plugins, which are interesting for any application reside in their own
> jar-file?
>
> We're using the plugin menu system to display the available plugins
hierarchically in CellProfiler. I guess that some plugins are less useful
or arguably useless but who am I to judge (I'm still waiting for someone to
publish a paper citing use of CellProfiler's "game of life" morphology
operation). Hopefully, the hierarchy leads the users to the most useful
plugins. I could see some other sort of annotation, e.g. "tags", but I
don't want to be the one who manages the tag ongology ;-).


>
 * Are there  plans how the "dimension selection" will be integrated into
> ImageJ2,  i.e. how algorithms can be run on arbitrary dimensions? (Mapping
> from  AxesNames to indicies of dimensions in images). Can we help here? (see
> Doc hackathon!?)
>
> CellProfiler does use the AxesNames to transform the N-dimensional arrays
to our representation. I think that there's enough functionality in the
restructuring commands to let power users pull out individual hyperplanes
for processing in lower dimensions. Perhaps a "ExtractData" and
"ReplaceData" plugin need to be added in order to create and reinsert
lower-dimension datasets?

There isn't any mechanism to handle AxesNames algebra - you don't know
whether a plugin will reduce or augment a dataset's dimensionality or
whether a plugin is only suitable for two dimensions. CellProfiler and, I'm
guessing, Knime do a lot of matching inputs to outputs which is a contrast
to ImageJ. I think our users can handle this ambiguity (they'd use only 2-D
or N-D plugins adaptable to 2-D), but annotation improvements here would be
nice.

 * ROIs: Are there plans to support Labelings in ImageJ2? Or will Labelings
> somehow be replaced in the future?
>

We're also looking forward to labelings being first-class entities in
ImageJ, partially my fault personally that this is not better developed.
I'm mostly interested in us having some agreement for the datatype for a
labeling parameter - I think that once we have that sort of
interoperability, we'll see lots of progress in both segmentation methods
and use of segmentations in downstream analysis.

>
>
> * In the current snapshot (compared to beta6) some functionality was movedfrom  ImageJ to sifio / scijava (e.g. the Services).  Regarding
> this some questions:
>   - The services seem to have some  ordering requirements now, we had to
> move
>     ModuleService behind  MenuService in the constructor call to avoid a
> null pointer during
>     initialization (onEvent(ModulesAddedEvent) was called before
> initialize). Is there a defined
>     service order?
>
It would be nice to have a headless service profile, something a little
easier than leaving out the AWT dependent jars and crossing fingers.
CellProfiler might instantiate both GUI and headless contexts in the same
JVM - we'd appreciate being able to choose the UI configuration in a simple
way.

>
>

> ((So far, we have tons of ideas where we could do more things together.
> Thank you in advance for answering all these questions ;) ))
>

Likewise, thank you, thank you - don't misconstrue any of the above as
demands. We all appreciate how all of this is being done and the time it
all takes.

>
>  Cheers,
>
>  Martin, Christian and Michael Z.
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130515/3967a1f5/attachment-0001.html>