[ImageJ-devel] Nice to get connected!

Tue Nov 13 16:54:23 CST 2012

Hi Vito,

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!

> The idea is to copycat the ImageJ (or fiji or any ImageJexecutable as
> we call it) folder in the analysis tab in ZEN

Great, I think this integration will be very nice for ZEN users.

> Question 1: 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?

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.

If you have any users asking for this functionality, perhaps you could ask
them directly what they need?

> Question 2: 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?

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.

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.

> Question 3: 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?

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.

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.

> Question 4: how to assure syncronicity of commands? The macros that do
> something useful, have a form send image from ZEN to ImageJ process it
> send the resulting image from ImageJ to ZEN

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.

> Question 5: 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)

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.

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.

Conversely, the RMI-based OtherInstance intentionally only allows
connections from another ImageJ running as the same user.

For further details, see Johannes's original commit [1].

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]).

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].

HTH,
Curtis

[1]
https://github.com/fiji/ImageJA/commit/06848874d990aeea2a0ad1df75311e9ca51b00dc
[2]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364417(v=vs.85).aspx
[3] http://imagej.nih.gov/ij/list.html

On Fri, Oct 26, 2012 at 3:50 AM, Vito Smolej <vito.smolej at zeiss.com> wrote:

>
> Hi Curtis:
>
>  Thank you first for your cooperative attitude! Much appreciated.
>
> 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
>
>
>
> 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).
>
> *Question 1: *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?
>
> *Question 2: *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?
>
> *Question 3: *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?
>
> *Question 4:* how to assure syncronicity of commands? The macros that do
> something useful, have a form
>
>    - send image from ZEN to ImageJ
>    - process it
>    - send the resulting image from ImageJ to ZEN
>
>
> 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.
>
> *Question 5: *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)
>
> Now, maybe you yourself would have a question or two (g). Please feel free
> to ask. And thank you in advance.
>
> Regards
>
> Vito.
>
>
> _________________________________________________
> Carl Zeiss Microscopy GmbH
> Geschäftsbereich BioSciences / BioSciences Division
> Imaging Software München
> Vorentwicklung / Advanced Development
>
> P r o f . D r . V i t o S m o l e j
>
> Kistlerhofstrasse 75, 81379 München
> Telefon/ Phone: +49 89 90 9000-306
> Fax: +49 89 90 9000-555
> mailto:smolej at zeiss.de
> www.zeiss.com/microscopy
>
> _________________________________________________
>
> Carl Zeiss Microscopy GmbH
> Vorsitzender des Aufsichtsrates: Dr. Michael Kaschke
> Geschäftsführung: Dr. Ulrich Simon, Wilhelm Nörthemann, Dr. Bernhard
> Ohnesorge, Dr. Frank Stietz
> Sitz der Gesellschaft: 07740 Jena, Deutschland
> Amtsgericht Jena, HRB 210.536, USt-IdNr: DE 814 503 774
>
> ----------------------------------------
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20121113/dbd1bf42/attachment.html>