[ImageJ-devel] A vary late follow-up on "Nice to get connected!" - and add. info re BioFormats GitHub issue

Wed Jan 9 12:31:24 CST 2013

Hi Vito,

> The ZEN Plugin for ImageJ is now out with ZEN 1.1A 2012 release

Great news, glad to hear it.

> I have opened an issue on GitHub, connected with "CZI files with
> bitdepths 12/14/36/42 can not be loaded",
> (https://github.com/openmicroscopy/bioformats/issues/309)

Looks like this issue is now taken care of. Please let us know of any
further problems.

> My apologies in case I am adressing you on a subject that may not be
> your turf. Feel free to redirect me resp. pass this on, where it is
> needed.

No worries. It's just that writing me a private mail is dangerous because I
might be too busy, or about to go on vacation for two weeks (which is what
happened this time; sorry for that). As you discovered, filing a GitHub
issue, or writing to a mailing list (ome-devel, imagej-devel, etc.) will
net you faster results because there are more involved developers who can
pounce on it.

> Regards and wish you a Merry Xmas and a successfull 2013

A belated happy new year to you as well!

Regards,
Curtis

On Wed, Dec 19, 2012 at 9:08 AM, Vito Smolej <vito.smolej at zeiss.com> wrote:

> Hi Curtis:
>
>
> The ZEN Plugin for ImageJ is now out with ZEN 1.1A 2012 release and I have
> opened an issue on GitHub, connected with "*CZI files with bitdepths
> 12/14/36/42 can not be loaded"*, (*
> https://github.com/openmicroscopy/bioformats/issues/309*<https://github.com/openmicroscopy/bioformats/issues/309>)
> something that would be great to see fixed in the next step.
>
> As I could not load the two CZI files discussed there into the issue
> tracker, I am enclosing them in this post.
>
>
>
> My apologies in case I am adressing you on a subject that may not be your
> turf. Feel free to redirect me resp. pass this on, where it is needed.
>
> Regards and wish you a Merry Xmas and a successfull 2013
>
> Vito
>
> PS: as regards are past contacts - On Nov 13th I started to write  the
> following feedback mail
> *"*
> *Hi Curtis:*
> *I instantly cc-d your mail to my colleagues who are involved with the
> ZEN plugin. Much obliged! See my comments below...*
> "
> ... and then stopped after a day or two. I will spare you details, because
> they were basically a string of Yesses and Thought so's. See it as a hint
> that now and again you and your help were on our minds.
>
> _________________________________________
> 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* <smolej at zeiss.de>
> *www.zeiss.com/microscopy* <http://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
>
>
>
> *Curtis Rueden <ctrueden at wisc.edu>*
> Gesendet von: ctrueden.wisc at gmail.com
>
> 13.11.2012 23:54
> An
> Vito Smolej <vito.smolej at zeiss.com>
> Kopie
> ImageJ Developers <imagej-devel at imagej.net>
> Thema
> Re: Nice to get connected! 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.
> It should allow a much easier and direct access to plugins people are
> using. A short summary:
>
>    - send current image from ZEN to ImageJ (button)
>    - Receive current image from IMageJ to ZEN (button)
>    - Apply <something>, which is actually an ImageJ primitive, bracketed
>    by the functions above
>
>
>
> > 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.
>
>  The scan is done first-ever-time-only  and theres a [...] entry, for
> adding entries later
>
> > 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.
> LOCI is of no more concern. And we are strictly on 1.47<something> and the
> latest snapshot of Fiji. The idea is, even if we warn against it, the users
> will update anyhow. We may require a given stable version later on, but
> right now it is a fall-back case and not yet requested.
>
>
> > 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.
> This is where the bug I placed in dev bugzille kicks in. The problem is
> the receive side: if SaveAs decides to save somewhere else as prescribed,
> the code can watch for the expected image file until the hell freezes over.
>
>
>
> > 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
> *<https://github.com/fiji/ImageJA/commit/06848874d990aeea2a0ad1df75311e9ca51b00dc>
> [2] *
> 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>
>
> [3] *http://imagej.nih.gov/ij/list.html*<http://imagej.nih.gov/ij/list.html>
>
>
> On Fri, Oct 26, 2012 at 3:50 AM, Vito Smolej <*vito.smolej at zeiss.com*<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* <%2B49%2089%2090%209000-306>
> Fax: *+49 89 90 9000-555* <%2B49%2089%2090%209000-555>
> mailto:*smolej at zeiss.de* <smolej at zeiss.de>
> *www.zeiss.com/microscopy* <http://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.
>
>
> *(See attached file: 36bits issue.zip)*
>
> ----------------------------------------
> 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/20130109/6a6b21f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130109/6a6b21f1/attachment-0001.gif>