On Wed, May 15, 2013 at 9:08 AM, Michael Zinsmaier <michael.zinsma...@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@imagej.net > http://imagej.net/mailman/listinfo/imagej-devel > >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
