Hi Vito,<div><br></div><div>Good seeing you at the ImageJ conference, and my sincere apologies for taking so long to reply to your questions. To give you an idea of how busy things have been, I have had a total of 10 minutes coding time on ImageJ2 since returning from the conference!</div>
<div><br></div><div class="gmail_extra"><div class="gmail_extra">> The idea is to copycat the ImageJ (or fiji or any ImageJexecutable as</div><div class="gmail_extra">> we call it) folder in the analysis tab in ZEN</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Great, I think this integration will be very nice for ZEN users.</div><div class="gmail_extra"><br></div><div class="gmail_extra">> Question 1: while the majority of executable functions are macros</div>
<div class="gmail_extra">> (*.txt, *.ijm etc), I have included also jar and class files. I guess,</div><div class="gmail_extra">> however, it is much safer to allow only macros, i.e. request the users</div><div class="gmail_extra">
> package the desired functions into macros. A jar may be missing a run</div><div class="gmail_extra">> entry of something similar, so who needs jars anyhow in this list. Can</div><div class="gmail_extra">> you comment on that?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Since Fiji has a "--run" flag for launching a particular plugin, why not use that? I think it makes sense to allow any ImageJ code to be run, as long as supporting it is not overly burdensome.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If you have any users asking for this functionality, perhaps you could ask them directly what they need?</div><div class="gmail_extra"><br></div><div class="gmail_extra">
> Question 2: we scan the "usual suspects" in the system (program files,</div><div class="gmail_extra">> desktop etc) for possible ImageJexecutables. I would not mind at all</div><div class="gmail_extra">
> to limit it to ImageJ20 . but I guess this would be too assuming and</div>
<div class="gmail_extra">> aggressive. What do you suggest?</div><div class="gmail_extra"><br></div><div class="gmail_extra">IMO it is too early to limit support to only ImageJ2. I think it makes sense to support at least Fiji with ImageJ1 (the Fiji launcher has more features than the vanilla ImageJ one), if not also vanilla ImageJ installations.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As for scanning the system, that is fine, but you could also require the user to configure the desired path in an options dialog somewhere. Most users will be very happy to do this once, if it means a working ImageJ integration as a reward. It gives the user more control over which ImageJ gets used, and makes your job easier since there is less harm done if your detection algorithm fails.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">> Question 3: in ImageJ (1.46r) we check explicitely if LOCI has been</div><div class="gmail_extra">> installed - because without it , multidimensional image shuttling is</div>
<div class="gmail_extra">> not possible. Do we need to check in ImageJ2.0 (and, if you can answer</div><div class="gmail_extra">> this question) and in Fiji. If we need to check, any descrete way to</div><div class="gmail_extra">
> do it? Fiji keeps track of versions... May looking for *LOCI*.jar?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fiji ships with Bio-Formats. ImageJ2 currently ships with only SCIFIO (the core of Bio-Formats) for licensing reasons. Zeiss file formats (LSM, ZVI, etc.) are not supported in SCIFIO core, only in Bio-Formats.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">For the time being, one easy way to check is to look for plugins/loci_tools.jar or plugins/loci_plugins.jar in the installation. You can tell which version by looking in the JAR manifest, if that matters to you.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">> Question 4: how to assure syncronicity of commands? The macros that do</div><div class="gmail_extra">> something useful, have a form send image from ZEN to ImageJ process it</div>
<div class="gmail_extra">> send the resulting image from ImageJ to ZEN</div><div class="gmail_extra"><br></div><div class="gmail_extra">My initial thought would be to instruct ImageJ to run not just the requested macro, but an appended version of it that invokes some sort of callback mechanism upon conclusion. I haven't experimented in detail, but perhaps emitting something to stdout when the macro/script/plugin concludes would be sufficient. Then ZEN could block until it receives that callback. At worst, you could poll a temporary file (or use the OS's notification API), though there is likely a cleaner option.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">> Question 5: I would very much appreciate your help. i.e. hints, as<br></div><div class="gmail_extra">> regards getting the communication run the other direction as well i.e.</div>
<div class="gmail_extra">> from ImageJ to ZEN), I remember the original TCP/IP layer - the code</div><div class="gmail_extra">> looked so simple and elegant. ZEN can communicate on TCP/IP and</div><div class="gmail_extra">
> letting macros both side of the river communicate with each other via</div><div class="gmail_extra">> socket comm layer would be the simplest for the user. I understand it</div><div class="gmail_extra">> was security concerns that caused the abrupt change. I would like to</div>
<div class="gmail_extra">> hear about them (after all, my PayPal account runs on TCPIP as well)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I am likely to blame for this debacle, since I believe Wayne got the idea of the socket listener from me and my VisBio application (which suffers from the same security problems). The issue is not with TCP/IP itself of course, but rather how it was being used.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">When ImageJ opened its socket listener, there was no security to limit incoming connections to only other instances of ImageJ, or only processes of the same user, or even only processes from localhost! So someone (even remotely) could control another user's already-running ImageJ instance by launching macros & scripts which would then run with the permissions of that user.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Conversely, the RMI-based OtherInstance intentionally only allows connections from another ImageJ running as the same user.<br></div><div class="gmail_extra"><br>
</div><div class="gmail_extra"><div class="gmail_extra">For further details, see Johannes's original commit [1].</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regarding how to get two-way communication working, I think pipes and files are simple and proven ways to go. To use pipes, you might need to initially launch ImageJ from ZEN (not sure how to get a handle on its stdout if the user launched it externally). But to use files there is no such restriction. Just make sure every piece of code (macro, plugin, whatever) you ask ImageJ to execute ends by appending some information to a temporary file, which ZEN either polls or receives notifications about (via e.g. the FindFirstChangeNotification function [2]).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Perhaps ImageJ could be improved in the future to make this sort of two-way communication easier. If you have any suggestions along those lines, feel free to suggest on the ImageJ mailing list [3].</div>
<div class="gmail_extra"><br></div></div>HTH,</div><div class="gmail_extra">Curtis<br><br>[1] <a href="https://github.com/fiji/ImageJA/commit/06848874d990aeea2a0ad1df75311e9ca51b00dc">https://github.com/fiji/ImageJA/commit/06848874d990aeea2a0ad1df75311e9ca51b00dc</a><br>
[2] <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa364417(v=vs.85).aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/aa364417(v=vs.85).aspx</a></div><div class="gmail_extra">[3] <a href="http://imagej.nih.gov/ij/list.html">http://imagej.nih.gov/ij/list.html</a><br>
<br><br><div class="gmail_quote">On Fri, Oct 26, 2012 at 3:50 AM, Vito Smolej <span dir="ltr"><<a href="mailto:vito.smolej@zeiss.com" target="_blank">vito.smolej@zeiss.com</a>></span> wrote:<br><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">
<br><font face="sans-serif">Hi Curtis:</font><br><br><font face="sans-serif"> Thank you first for your cooperative
attitude! Much appreciated. </font><br><br><font face="sans-serif">So right away I'll bombard you with
a few simple questions, regarding the ImageJ plugin for ZEN. The idea is
to copycat the ImageJ (or fiji or any ImageJexecutable as we call it) folder
in the analysis tab in ZEN like this</font><br><br><img><br><br><font face="sans-serif">the leave nodes are always something
that gets executed in ImageJ, possibly requiring activeImage input and/or
producing activeImage output (input and output properties of the local
function nodes tree).</font><br><br><font face="sans-serif"><b>Question 1: </b>while the majority
of executable functions are macros (*.txt, *.ijm etc), I have included
also jar and class files. I guess, however, it is much safer to allow only
macros, i.e. request the users package the desired functions into macros.
A jar may be missing a run entry of something similar, so who needs jars
anyhow in this list. Can you comment on that? </font><br><br><font face="sans-serif"><b>Question 2: </b>we scan the "usual
suspects" in the system (program files, desktop etc) for possible
ImageJexecutables. I would not mind at all to limit it to ImageJ20 . but
I guess this would be too assuming and aggressive. What do you suggest?</font><br><br><font face="sans-serif"><b>Question 3: </b>in ImageJ (1.46r)
we check explicitely if LOCI has been installed - because without it ,
multidimensional image shuttling is not possible. Do we need to check in
ImageJ2.0 (and, if you can answer this question) and in Fiji. If we need
to check, any descrete way to do it? Fiji keeps track of versions... May
looking for *LOCI*.jar?</font><br><br><font face="sans-serif"><b>Question 4:</b> how to assure syncronicity
of commands? The macros that do something useful, have a form </font><br><ul><li><font face="sans-serif">send image from ZEN to ImageJ</font></li><li><font face="sans-serif">process it</font></li><li><font face="sans-serif">send the resulting image from ImageJ
to ZEN</font></li></ul><br><font face="sans-serif">We got again and again tons of
"save as" dialogs before realizing that saveAs in the third line
may occur before the "process it" in the second creates its output.
he Identical problem with "unique instance" listener - if the
exe file has not yet started all the threads, the new call for ImageJexecutable
will just spawn another instance into the system.</font><br><br><font face="sans-serif"><b>Question 5: </b>I would very much
appreciate your help. i.e. hints, as regards getting the communication
run the other direction as well i.e. from ImageJ to ZEN), I remember the
original TCP/IP layer - the code looked so simple and elegant. ZEN
can communicate on TCP/IP and letting macros both side of the river communicate
with each other via socket comm layer would be the simplest for the user.
I understand it was security concerns that caused the abrupt change. I
would like to hear about them (after all, my PayPal account runs on TCPIP
as well)</font><br><br><font face="sans-serif">Now, maybe you yourself would have a
question or two (g). Please feel free to ask. And thank you in advance.</font><br><br><font face="sans-serif">Regards</font><br><br><font face="sans-serif">Vito.</font><br><br><br><font face="sans-serif">_________________________________________________
<br>Carl Zeiss Microscopy GmbH<br>Geschäftsbereich BioSciences / BioSciences Division<br>Imaging Software München<br>Vorentwicklung / Advanced Development<br><br>P r o f . D r . V i t o S m o l e j<br><br>Kistlerhofstrasse 75, 81379 München<br>
Telefon/ Phone: <a href="tel:%2B49%2089%2090%209000-306" value="+4989909000306" target="_blank">+49 89 90 9000-306</a><br>Fax: <a href="tel:%2B49%2089%2090%209000-555" value="+4989909000555" target="_blank">+49 89 90 9000-555</a><br>
mailto:<a href="mailto:smolej@zeiss.de" target="_blank">smolej@zeiss.de</a><br><a href="http://www.zeiss.com/microscopy" target="_blank">www.zeiss.com/microscopy</a><br><br>_________________________________________________ <br>
<br>Carl Zeiss Microscopy GmbH<br>Vorsitzender des Aufsichtsrates: Dr. Michael Kaschke<br>Geschäftsführung: Dr. Ulrich Simon, Wilhelm Nörthemann, Dr. Bernhard Ohnesorge,
Dr. Frank Stietz<br>Sitz der Gesellschaft: 07740 Jena, Deutschland<br>Amtsgericht Jena, HRB 210.536, USt-IdNr: DE 814 503 774</font><font face="sans-serif"><font size="1" face="Times New Roman">
<br><br>----------------------------------------<br>
This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. <br>
<br></font></font></blockquote></div><br></div>