<div dir="ltr">Hi Michael & Lee,<div><br></div><div style>Sorry for the delay in reply; it's a long thread. :-/</div><div><br></div><div>Michael wrote:</div><div><div>> Would it be possible to add a flag that surpresses previews checkboxes</div>
<div>> during dialog building?</div></div><div><br></div><div>It's tricky because right now, each preview checkbox is an input parameter to the command itself. But personally I don't like that approach. It is not a "real" input to the command, but rather intended to be toggled during input harvesting only. One option might be to label the visibility of those parameters as ItemVisibility.INVISIBLE. Then we could add a flag somewhere to hide INVISIBLE parameters, maybe.</div>
<div><br></div><div>But really, I am leaning toward a simpler solution: just remove the preview checkboxes, in favor of ImageJ2 *always* doing a preview (and of course, KNIP doesn't have to). And if the previews are too slow, we can optimize the preview() method to address it, rather than having this hacky checkbox like ImageJ1 does.</div>
<div><br></div><div>Lee wrote:</div><div><div>> I hadn't looked at the interactive commands with regard to</div><div>> CellProfiler. It looks like "buttons" could be interpreted as possible</div><div>
> headless actions that could be performed... at least in some cases.</div>
<div><br></div><div style>Yes, each button generally performs some action, which we should really make sure are always exposed as standalone commands (see next paragraph). We are going to add logic to make multiple sequential Button widgets render as a single button bar in our UI layout. Won't affect you though, Lee, since you do your own UI in Python.</div>
</div><div style><br></div><div style>Michael wrote:</div><div style><span style="font-family:arial,sans-serif;font-size:13px">> Why is the threshold plugin an interactive command?</span><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Let me explain the motivation here. Anything that extends InteractiveCommand is not *intended* to be run in headless mode. Rather, it is intended as a sort of "meta-command" that allows you to launch other commands. It will be filled with callback methods when various inputs change, which should, in a properly designed InteractiveCommand, trigger real command executions that are more well-behaved from a headless standpoint.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">Anything that extends InteractiveCommand should *not* be flagged with "headless = true" since it is not intended for that purpose.</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">So in the case of threshold, we need a "real" threshold command that has sensible inputs and outputs. Then the command exposed in the ImageJ UI as "threshold" is actually "Interactive Threshold" which fires off Threshold executions.</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">This is not all fully in place, but it is the direction we are going. </font><span style="font-family:arial,sans-serif">Sound reasonable?</span></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Lee wrote:</font></div><div style><font face="arial, sans-serif"><div>> For Threshold, I can see reasons for executing the callbacks for</div>
<div>> "auto", "apply" and "delete" in a headless context</div><div><br></div><div style>The above would also address your comments here, Lee. The interactive threshold command would not need to be exposed within CP because those buttons would each have a corresponding standalone headless-friendly command which *would* be exposed.</div>
</font></div><div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Michael wrote:</font></div><div style><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">is there a way to determine if a command is dynamic?</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Other than the hacky instanceof test you are doing, nope. I agree we should add API for it to ModuleInfo. Especially because it is possible for modules to be dynamic without extending the DynamicCommand class...</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Could you please file a ticket for it on the ImageJ Trac? I just made ImageJ Trac accounts for you, Christian & Martin; you should have an automated email about it. I know Trac is not ideal (GitHub Issues is nice) but we have all our ImageJ tickets in Trac now, migrating everything would be very involved, and I don't really want to start splitting between two issue trackers. Someday we might move...</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><div><font face="arial, sans-serif">> Are you planing to re-organize the plugins, e.g. such that plugins,</font></div><div>
<font face="arial, sans-serif">> which are interesting for any application reside in their own</font></div><div><font face="arial, sans-serif">> jar-file?</font></div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">This is probably a good idea. However, I agree with Lee that in some cases it may not be totally clear-cut [1]. You think splitting ij-commands into two JAR files is sufficient? If so, care to send a list of plugins you feel are *not* generally useful, and I can split them out?</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div><div><font face="arial, sans-serif">> Will the package path of the plugins be stable after ImageJ2 1.0.0 was</font></div><div><font face="arial, sans-serif">> released?</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">Yes, when ImageJ 2.0.0 final is released. From then on, we will always deprecate any necessary moves, to keep old code working. And of course will also try not to do it at all unless deemed really important.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">That said, I don't really like the current package prefix of "imagej.core.*" for various "core plugins." It is confusing that we have "ij-core" which is the core *library* and that code does *not* have prefix "imagej.core", whereas we have "core plugins" which *do* have package prefix "imagej.core". I would welcome a better idea!</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div><div><font face="arial, sans-serif">> Are there plans how the "dimension selection" will be integrated into</font></div><div><font face="arial, sans-serif">> ImageJ2, i.e. how algorithms can be run on arbitrary dimensions?</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">Yes. The img-metadata branch [2] is relevant here as far as axis names go.</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">I was thinking for starters, we could simply create new (headless-friendly) commands that narrow the view of a given dataset using the ImgLib2 Views class. Then from an end user perspective, if you want to limit the execution of the algorithm, you just run that command first. This fits in well with KNIME's node concept, where the answer to any given problem is usually to just insert another node for preprocessing or whatever.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Do you think more than that is needed?</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">Lee wrote:</div><div><div><font face="arial, sans-serif">> There isn't any mechanism to handle AxesNames algebra ... annotation</font></div><div><font face="arial, sans-serif">> improvements here would be nice.</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">I agree, but do not have time to work on it. Proposals and PRs very welcome. It would probably make the most sense to base any work on the Axis metadata design from the img-metadata branch of ImgLib.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Michael wrote:</div><div style="font-family:arial,sans-serif;font-size:13px">> ROIs: Are there plans to support Labelings in ImageJ2?</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Lee wrote:</div><div><div><font face="arial, sans-serif">> We're also looking forward to labelings being first-class entities</font></div>
<div><br></div></div><div style>This is something we should pursue further for beta9, which is intended to focus on ROIs.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
Michael wrote:</div><div><div><font face="arial, sans-serif">> Is "new ImageJ(services...)" replaced by "new Context(...services)"?</font></div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div></div><div style="font-family:arial,sans-serif;font-size:13px">Yes. Strictly speaking, that is correct.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
However, there is a new ImageJ "gateway" class in ij-app so that you can still say "new ImageJ(...)". And actually from that object you will get lots more functionality: you can query any built-in service with a compile-safe method. See the ImageJ tutorials for details [3].</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Michael wrote:</div><div style="font-family:arial,sans-serif;font-size:13px">> How can we query the ImageJ version?</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">I apologize that it is somewhat convoluted now. First, the code:</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div><div><font face="arial, sans-serif"> ImageJ ij = new ImageJ();</font></div><div><font face="arial, sans-serif"> App ijApp = ij.app().getApp(ImageJApp.NAME);</font></div><div><font face="arial, sans-serif"> String ijApp.getVersion();</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">This uses the AppService feature of SciJava Common. The rationale is that you may have a single SciJava Context with multiple associated applications such as ImageJ, SCIFIO and SciJava Common itself. And obviously they don't all have the same version. So you first have to ask the AppService for your application of interest, then query its version.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">We actually spit out this sort of stuff for *all* available applications in the SystemInformation command:</div>
<div><font face="arial, sans-serif"><a href="https://github.com/imagej/imagej/blob/imagej-2.0.0-beta-7/plugins/commands/src/main/java/imagej/core/commands/debug/SystemInformation.java#L84">https://github.com/imagej/imagej/blob/imagej-2.0.0-beta-7/plugins/commands/src/main/java/imagej/core/commands/debug/SystemInformation.java#L84</a></font><br>
</div><div><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">There are all sorts of goodies you can query, many of which are extracted from either associated Maven POMs or JAR manifests. :-)</font></div>
<div><div><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Michael wrote:</font></div><div><font face="arial, sans-serif">> the log level system property "System.setProperty("ij.log.level",</font></div>
<div><font face="arial, sans-serif">> "error");" doesn't seem to work any more</font></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">
With the migration to SciJava Common, the property changed to "scijava.log.level" but it works the same way.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
Michael wrote:</div><div><div><font face="arial, sans-serif">> we had to move ModuleService behind MenuService in the constructor</font></div><div><font face="arial, sans-serif">> call to avoid a null pointer during initialization</font></div>
<div><font face="arial, sans-serif">> (onEvent(ModulesAddedEvent) was called before initialize).</font></div><div><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif;font-size:13px">That is a bug, thanks for reporting. However, moving the module service after the menu service will not work because MenuService needs CommandService which needs ModuleService.</span><font face="arial, sans-serif"><br>
</font></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">What's weird to me is, I am not sure why we don't see this bug when running the end-user ImageJ application...</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I have some service initialization changes pending on ImageJ's startup-speed branch, which may affect this. So we should debug further once that branch is merged. Please feel free to file a Trac ticket for it and assign to me.</span></div>
<div style><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Michael wrote:</span></div><div><font face="arial, sans-serif">> Is there a </font><span style="font-family:arial,sans-serif">defined service order?</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">The order is defined by two things:</div><div style="font-family:arial,sans-serif;font-size:13px">
1) If a service has an @Parameter dependency on another service, the dependency gets initialized first.</div><div style="font-family:arial,sans-serif;font-size:13px">2) Otherwise, the "priority" property of the @Plugin annotation is used to order service initialization.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div><div><font face="arial, sans-serif">> ((So far, we have tons of ideas where we could do more things</font></div><div><font face="arial, sans-serif">> together. Thank you in advance for answering all these questions ;) ))</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">No problem, and again, sorry if the long delay reduces your momentum and/or enthusiasm. If you have any more questions, please fire away!</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Regards,</div><div style="font-family:arial,sans-serif;font-size:13px">Curtis</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">[1] You know what that easter egg does, right? Don't you *want* to generate ASCII images using KNIME??? I know I do!</div><div style="font-family:arial,sans-serif;font-size:13px">
[2] <a href="https://github.com/imagej/imglib/compare/master...img-metadata">https://github.com/imagej/imglib/compare/master...img-metadata</a></div><div style="font-family:arial,sans-serif;font-size:13px">[3] E.g.: <a href="https://github.com/imagej/imagej-tutorials/blob/885892b6b225fba2e1b32c4ca14ab330e39f384a/load-and-display-dataset/src/main/java/LoadAndDisplayDataset.java">https://github.com/imagej/imagej-tutorials/blob/885892b6b225fba2e1b32c4ca14ab330e39f384a/load-and-display-dataset/src/main/java/LoadAndDisplayDataset.java</a></div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 9:35 AM, Lee Kamentsky <span dir="ltr"><<a href="mailto:leek@broadinstitute.org" target="_blank">leek@broadinstitute.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Wed, May 15, 2013 at 9:08 AM, Michael Zinsmaier <span dir="ltr"><<a href="mailto:michael.zinsmaier@gmx.de" target="_blank">michael.zinsmaier@gmx.de</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div><span>Hi all,</span></div>
<div><br>
</div>
<div><span>after you guys have made so
much progress during the hackathon, we felt motivated to review
our</span><span> KNIME-</span><span>ImageJ2 integration and try to
further improve it, as we want to have everything set-up when
you release ImageJ2 ;-)</span></div>
<div><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div><span>Anyway, we discussed several
things and a lot of questions came up concerning ImageJ2</span><span>:</span></div>
<div><br></div></div></blockquote></div><div>Thx guys, lots of stuff below also applies to CellProfiler running ImageJ2.0 plugins. </div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div>
</div>
<div>* 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.<br></div></div></blockquote><div><br></div></div><div>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.</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div></div>
<div><br>
</div>
<div><br></div>
<div><span>* 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?</span></div>
<div><br></div></div></blockquote></div><div>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 ;-).</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>
</div>
<div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>
</div>
<div><span>*</span><span> Are the</span><span>re</span><span> 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?</span><span> (</span><span>see Doc hackathon!?</span><span>)</span></div>
<div><br></div></div></blockquote></div><div>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?</div>
<div><br></div><div>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.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>
</div>
<div><span>* ROIs: Are there plans to
support Labelings in ImageJ2? Or will Labelings somehow be
replaced in the future?</span></div></div></blockquote><div><br></div></div><div>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. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="im"><div>
<span> </span></div>
<div><span> </span><span> </span></div>
<div><span>*</span><span> </span><span>In the</span><span> current snapshot (compared to
beta6) some functionality</span><span> was moved</span><span> from ImageJ to sifio /
scijava (e.g. the Services). </span><span>Regarding this some
questions:</span></div>
</div><div class="im"><div> - The services seem to have
some ordering requirements now, we had to move<br></div>
<div><span> </span><span> ModuleService behin</span><span>d</span><span> MenuService in the
constructor call to avoid a null pointer during</span></div>
<div><span> </span><span>initialization
(onEvent(ModulesAddedEvent) was called before initialize). Is
there a defined</span></div>
<div><span> s</span><span>ervice order?</span></div></div></div></blockquote><div>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.</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div><span> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div><span> </span></div>
<div><span>((</span><span>So far, we have tons of ideas
where we could do more things together. Thank you in advance for
answering all these questions ;)</span><span> ))</span></div></div></blockquote><div><br></div></div><div>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. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><div text="#000000" bgcolor="#FFFFFF">
<div><br>
</div>
<div><span>Cheers,</span></div>
<div><br>
</div>
<div><span>Martin, Christian and Michael
Z.</span></div>
</div>
<br></div>_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
<br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
<br></blockquote></div><br></div>