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 <[email protected]> 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:[email protected]* <[email protected]> > *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 <[email protected]>* > Gesendet von: [email protected] > > 13.11.2012 23:54 > An > Vito Smolej <[email protected]> > Kopie > ImageJ Developers <[email protected]> > 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 > <*[email protected]*<[email protected]>> > 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:*[email protected]* <[email protected]> > *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. > >
<<ecblank.gif>>
_______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
