<div dir="ltr">Hi all,<div><br></div><div><div>> we are discussing how best to support execution of ImageJ commands and</div><div>> scripts from an OMERO server.</div></div><div><br></div><div style>For those interested in following this work, there is now a ticket tree in the OME Trac:</div>
<div> <a href="http://trac.openmicroscopy.org.uk/ome/ticket/10608">http://trac.openmicroscopy.org.uk/ome/ticket/10608</a><br><div class="gmail_extra"><br></div><div class="gmail_extra" style>It covers the various avenues of interoperability discussed in this thread.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Regards,</div><div class="gmail_extra">Curtis</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 10:30 AM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</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"><div dir="ltr">Hi Josh & everyone,<div class="im"><div>
<br></div><div>> Thoughts on moving to ome-devel?</div><div><br></div></div><div>Rerouting as suggested!</div><div><br></div><div>For those newcomers: we are discussing how best to support execution of ImageJ commands and scripts from an OMERO server. The idea is that you could upload desired ImageJ (probably only ImageJ2) scripts to your OMERO installation, where they could run server-side (or potentially delegated to a cluster, etc.) and return their results straight back into OMERO, very similar to how you can run Python scripts from OMERO now.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>I have also forwarded my initial and revised plans originally discussed amongst the OME team internally (see bottom). Comments, suggestions, thoughts, etc., from the OME developer community are very welcome!</div>
<div><br></div></div><div class="im"><div class="gmail_extra">> There's a description framework:</div><div class="gmail_extra"><br></div></div><div class="gmail_extra">Thanks for all the pointers, Josh. I will dig in today.</div>
<div class="im"><div class="gmail_extra">
<br></div><div class="gmail_extra">> Don't know if you've seen the script guide:</div><div class="gmail_extra"><br></div></div><div class="gmail_extra">Nope, but I will read it now! Thanks!</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Curtis<br><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Mar 21, 2013 at 5:01 AM, Josh Moore <span dir="ltr"><<a href="mailto:josh@glencoesoftware.com" target="_blank">josh@glencoesoftware.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">Thoughts on moving to ome-devel?<br>
<div><br>
On Mar 20, 2013, at 9:49 PM, Curtis Rueden wrote:<br>
<br>
> Hi Josh, J-M, et. al,<br>
><br>
>> If these files are uploaded to lib/scripts (like all other scripts),<br>
>> then they should show up in the drop-down menus, assuming there is the<br>
>> proper Ice params wrapper from above.<br>
><br>
> Are you suggesting there would be one (or some constant C) Ice params<br>
> wrapper which would enable ImageJ support? Or that each ImageJ script added<br>
> to the server would have its own (autogenerated?) Ice params wrapper?<br>
<br>
</div>There's a description framework:<br>
<br>
<a href="https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/components/blitz/resources/omero/Scripts.ice" target="_blank">https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/components/blitz/resources/omero/Scripts.ice</a><br>
<br>
So each script would define it's own INs and OUTs, just like the Python scripts would do. In fact, the clients wouldn't really even know which was which, other than perhaps the file endings.<br>
<br>
What's necessary to make that work is some logic which when called with a special property ("omero.script.parse=true") it just tells the server what its params are and doesn't execute:<br>
<br>
<a href="https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/components/tools/OmeroPy/src/omero/scripts.py#L391" target="_blank">https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/components/tools/OmeroPy/src/omero/scripts.py#L391</a><br>
<div><br>
<br>
>> NEXT STEPS: - Jean-Marie is going to email me with some code links<br>
>> to the Python scripting infrastructure of OMERO.<br>
> ...<br>
>> Thinking back to our conversations in Paris (2 years ago? 3?), the<br>
>> alternative would be for there to be JVM code (jython?) which produces<br>
>> the Ice params objects. There are 2-3 server code locations which<br>
>> would need to be taught how not to only check for "*.py"-based<br>
>> scripts, but also "*.m" (matlab) and whatever else IJ2 would<br>
>> want/need.<br>
><br>
> Could either Josh, J-M or both send me some pointers into the OMERO<br>
> codebase for getting started? I would like to grok how the current Python<br>
> scripting stuff works before discussing the development directions much<br>
> further, since right now I am pretty clueless.<br>
<br>
</div>Ah, and I lied slightly: It's not just the file-endings, also the mimetype, which makes sense, I guess:<br>
<br>
<a href="https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/components/server/src/ome/services/scripts/ScriptRepoHelper.java#L305" target="_blank">https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/components/server/src/ome/services/scripts/ScriptRepoHelper.java#L305</a><br>
<br>
Here are the rough steps that happen:<br>
* Admin places a file under OMERO_DIST/lib/scripts<br>
* Client asks for a list of scripts and chooses the newly appeared file<br>
* Client requests the params for the files<br>
- if the server has the params cached, these are returned<br>
- if not, the file is executed with omero.scripts.parse=true<br>
* Client generates a dialog based on the params.<br>
* Script is executed with params in a separate session.<br>
* ...<br>
<br>
Don't know if you've seen the script guide:<br>
<br>
<a href="https://www.openmicroscopy.org/site/support/omero4/developers/Modules/Scripts.html" target="_blank">https://www.openmicroscopy.org/site/support/omero4/developers/Modules/Scripts.html</a><br>
<a href="https://www.openmicroscopy.org/site/support/omero4/developers/Modules/Scripts/Guide.html" target="_blank">https://www.openmicroscopy.org/site/support/omero4/developers/Modules/Scripts/Guide.html</a><br>
<br>
But that's outlined in more detail (at least from the client perspective) there.<br>
<br>
Cheers,<br>
~Josh.<br>
<br>
<br>
NB: To do this with no code changes, here's what a wrapper Python script would look like:<br>
<br>
<a href="https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/examples/ScriptingService/NativeWrapperExample.py" target="_blank">https://github.com/openmicroscopy/openmicroscopy/blob/dev_4_4/examples/ScriptingService/NativeWrapperExample.py</a><br>
<div><div><br>
<br>
> Thanks!<br>
> -Curtis<br>
><br>
><br>
> On Wed, Mar 20, 2013 at 11:37 AM, Josh Moore <<a href="mailto:josh@glencoesoftware.com" target="_blank">josh@glencoesoftware.com</a>>wrote:<br>
><br>
>><br>
>>> SHORT TERM GOAL: Expose ImageJ2 commands as OMERO scripts. We believe<br>
>> this<br>
>>> can be done in a fairly general way, perhaps by generating Python<br>
>> wrappers<br>
>>> on demand.<br>
>>><br>
>>> NEXT STEPS:<br>
>>> - Jean-Marie is going to email me with some code links to the Python<br>
>>> scripting infrastructure of OMERO.<br>
>>> - I will start investigating how to enhance it in a way that makes ImageJ<br>
>>> commands accessible to OMERO in a seamless way.<br>
>>> - We will get images working first, with other data types (e.g., ROIs) to<br>
>>> come later.<br>
>><br>
>> Thinking back to our conversations in Paris (2 years ago? 3?), the<br>
>> alternative would be for there to be JVM code (jython?) which produces the<br>
>> Ice params objects. There are 2-3 server code locations which would need to<br>
>> be taught how not to only check for "*.py"-based scripts, but also "*.m"<br>
>> (matlab) and whatever else IJ2 would want/need.<br>
>><br>
>>> During our discussion, Jean-Marie & I noted that the ImageJ GUI is very<br>
>>> good at "rapid prototyping" of a workflow or script, using the Macro<br>
>>> Recorder and related tools. Once you have the ImageJ script the way you<br>
>>> want, it would be very useful to be able to upload it to OMERO, for<br>
>>> execution across many images on the server side.<br>
>><br>
>> If these files are uploaded to lib/scripts (like all other scripts), then<br>
>> they should show up in the<br>
>> drop-down menus, assuming there is the proper Ice params wrapper from<br>
>> above.<br>
>><br>
>> ~J.<br></div></div></blockquote><div><br></div><div><br></div></div></div><div>---------- Original proposal from November ----------</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Date: Wed, Nov 28, 2012 at 1:47 PM<br>
</div><div class="gmail_extra"><div class="gmail_quote">Subject: OME/ImageJ interoperability plan<div class="im"><br><br><div>Hi all,</div><div><br></div><div>Most of you know me, but for those new to the OME team: my name is Curtis Rueden and I am the lead software developer at the Laboratory for Optical and Computational Instrumentation (LOCI) at the University of Wisconsin-Madison. LOCI has been one of the core OME teams since 2004, spearheading the OME-TIFF and Bio-Formats projects, and we now are looking forward to development of better ImageJ and OME interoperability.</div>
<div><br></div></div><div class="im"><div>The purpose of this mail is to outline my plan for OMERO/ImageJ interoperability. It is something we have been discussing for years, and have put various scattered efforts toward, but it did not have dedicated funding until the recent Wellcome Trust award.<br>
</div><div><br></div><div>I see three major short-term areas of ImageJ/OMERO interoperability:</div><div><br></div><div>1. With OMERO.server</div><div>2. With OMERO.insight</div><div>3. OMERO-backed ImgLib2 images</div><div>
<br></div><div><br></div><div>== OMERO.server ==</div><div><br></div><div>At the Dresden hackathon last December Josh & I & others discussed the ability for OMERO to be able to execute ImageJ2 plugins on the server side. Since ImageJ2 plugins are much more flexible than ImageJ1 (no AWT or other UI dependencies, in general), this is very doable. We made some progress toward this goal at the hackathon, but since then little has been done.</div>
<div><br></div><div>Once it is possible to execute ImageJ plugins and scripts server-side, it becomes simply another scripting option usable from all OMERO-enabled tools such as Insight and the web client. Presumably we could reuse whatever infrastructure already exists to upload scripts to the server, etc., but as JAR files that contain ImageJ2 plugins.</div>
<div><br></div><div><br></div><div>== OMERO.insight ==</div><div><br></div><div>Also at the hackathon, Jean-Marie worked on making Insight capable of executing ImageJ2 plugins, with some small assistance from me, and by the end he had it working. But again (J-M, correct me if I am wrong), I don't think much has happened with that since then.</div>
<div><br></div><div>Running ImageJ plugins from Insight is on the one hand really straightforward, but on the other a bit tricky because you have to decide what sort of image data to feed to the plugin. Rendered data from the client side? Raw data pulled on demand from the server? And what happens to modified pixels? Of the three areas listed above, this is the one I am least sure about w.r.t. the specific details.</div>
<div><br></div><div><br></div><div>== OMERO + ImgLib2 ==</div><div><br></div><div>One of the things ImageJ2 was supposed to improve upon was the agnosticism (or generality if you will) of image data sources. It must be equally possible to process image data drawn from disk on demand, from arrays in memory, or from an OMERO database over the wire—and neither the user nor the algorithm being used should care about that data source. Fortunately, ImgLib2 was designed with exactly this sort of thing in mind. The ImgLib2 architecture is extremely general, and already supports image data from various sources.</div>
<div><br></div><div>However, there does not yet exist an "image container" for OMERO-backed image pixels. This is what I want to create. Stephan Saalfeld (one of the primary architects of ImgLib2) already created a CATMAID-backed image container together with what he refers to as "stupid caching", meaning it caches blocks in and out on demand. And he demoed this at the last two ImageJ conferences (Barcelona & Luxembourg). So there is already code proving this sort of thing is feasible. Someone (me) just needs to do the same for OMERO.</div>
<div><br></div><div>Once we have this OMERO-backed ImgLib2 image with good caching (probably using the Ehcache project which Josh suggested), working with your OMERO data from within ImageJ2 will become much closer to a reality. There are still some (relatively minor) architectural changes we need to make in ImageJ2 itself to fully realize this potential, but it is absolutely the direction we are going anyway.</div>
<div><br></div><div><br></div><div>== Next steps ==</div><div><br></div><div>My next step will be to focus on the OMERO-backed image container for ImgLib2. Our 2.0.0-beta7 release of ImageJ2, slated for late January, is focused on "robust core support for N-dimensional data, including very large image data, and data/display decoupling." This is perfectly in line with the needed OMERO+ImgLib2 development. It would be an awesome showcase for ImageJ2 if I could get a prototype of OMERO interoperability working in conjunction with beta7, or soon thereafter.</div>
<div><br></div><div>I am really excited about the other avenues of interoperability as well, but they can wait a bit longer until we have the core OMERO-backed data in place.</div><div><br></div><div><br></div><div>== Longer term ==</div>
<div><br></div><div>Josh reminded me that we will also need various other OMERO features available from ImageJ, such as tagging, metadata querying, server-side rendering, and so on. And we will obviously need the ability to e.g. commit modified data back to the database (although there is an open question of how the versioning should work with that). We can think about further planning for these features once we have made some initial progress on the above, though.</div>
<div><br></div><div>Lastly, in general, we want to continue to explore areas where OMERO.insight and ImageJ2 can be brought closer together, reusing functionality where possible.</div><div><br></div><div>All feedback welcome.</div>
<div><br></div><div>Regards,</div><div>Curtis</div><div><br></div><div><br></div></div><div>---------- Revised proposal from earlier this month ----------</div><div><br><div class="gmail_quote">Date: Tue, Mar 5, 2013 at 10:43 PM<br>
Subject: Re: OME/ImageJ interoperability plan<br><br><div dir="ltr"><div class="im">Hi everyone,<div><br></div><div>Thanks everyone for last week's meeting. Jean-Marie & I had a great discussion and ideas session for the OMERO/ImageJ interoperability project. The following are my notes, along with my response to earlier discussion in this thread.</div>
<div><br></div><div>As mentioned previously, there are two main ways for ImageJ to operate with respect to OMERO:</div><div>1) executed as a job on the server side;</div><div>2) communicating with OMERO as a client.</div>
<div><br></div><div>From various discussions, suggestions, perspectives, etc., it is clear that we need both. But we spent much of our meeting time discussing server-side functionality.</div><div><br></div></div><div><div class="im">
<div>As many of you know, right now, OMERO scripts are all Python based. This allows both OMERO.web and OMERO.insight to discover and invoke available Python scripts fairly easily.<br>
</div><div><br></div></div><div class="im"><div>SHORT TERM GOAL: Expose ImageJ2 commands as OMERO scripts. We believe this can be done in a fairly general way, perhaps by generating Python wrappers on demand.<br></div><div>
<br></div><div>NEXT STEPS:</div>
<div>- Jean-Marie is going to email me with some code links to the Python scripting infrastructure of OMERO.</div><div>- I will start investigating how to enhance it in a way that makes ImageJ commands accessible to OMERO in a seamless way.</div>
<div>- We will get images working first, with other data types (e.g., ROIs) to come later.</div><div><br></div></div><div><div class="h5"><div>LONGER TERM: ImageJ2 scripts should attach structure annotations describing how the results were acquired (which parameter values, input data, etc.). On the other hand, this may be a good use case for a more general-purpose data provenance data schema, though, like Bob Murphy brought up during one of the presentations.<br>
</div><div><br></div><div><div>Kevin asked the Davis Lab which ImageJ plugins they would like to see supported in OMERO first. Here is the list so far:</div><div><br></div><div><div>- Image/stacks/Z project</div><div>- Image/stacks/orthogonal views</div>
<div>- stacks/tools/combine</div><div>- stack/tools/slice remover</div><div>- image/transform/ "all the different options"</div><div>- image/adjust/threshold</div><div>- process/binary/make binary</div><div>- process/math/ "all the different options"</div>
<div>- process/image calculator</div><div>- analyse/tools/ROI manager</div><div>- analyse/set measurements</div><div>- analyse/measure</div><div>- process/macros/run "used with custom macros"</div><div><br></div>
<div>- denoising (bilateral filter)</div><div>- deconvolution (deconvolution lab and/or Bob Dougherty's iterative 3D)</div><div>- normalization (normalize local contrast, quantile-based?)</div><div>- enhance local contrast (CLAHE in 3D)</div>
<div>- 3D spatial filters (mean, median, gaussian, convolve)</div><div>- 3D FFT and bandpass</div><div>- registration (stackreg, turboreg)</div><div>- SPIM registration & multi-view fusion</div><div>- FeatureJ (Laplacian, Hessian) and/or surfaceness, tubeness, vesselness</div>
<div>- Weka machine learning / segmentation</div><div>- Tracking (TrackMate)</div><div>- colocalization: coloc_2, JACoP</div><div>- batch macro runner</div></div><div><br></div><div>Some of these are already part of ImageJ2, which are the ones we will target first. Others may not be practical in their current form: we will need to be split them into an iterative/interactive portion which calls the programmatic operation portion, the latter of which is what can be scripted from OMERO. We will certainly not to try tackle everything on the above list, but will pick a few "low hanging fruit" as a proof of concept. After that, we can reexamine which ones to pursue next.</div>
<div><br></div></div></div></div><div class="im"><div>During our discussion, Jean-Marie & I noted that the ImageJ GUI is very good at "rapid prototyping" of a workflow or script, using the Macro Recorder and related tools. Once you have the ImageJ script the way you want, it would be very useful to be able to upload it to OMERO, for execution across many images on the server side.</div>
<div><br></div></div><div><div class="h5"><div>We then discussed several other key "upload to OMERO" type operations we would like to have within ImageJ on the client side:</div><div>- upload script to OMERO</div>
<div> -- obviously though we need server-side script discovery & execution too<br>
</div><div>- upload image</div><div>- upload results table</div><div> -- either: global, or user specifies which image it's associated with</div><div>- upload ROIs</div><div> -- from ROI manager, or from active selection</div>
<div> -- again, must somehow decide to what they are attached</div><div><br></div><div>We were thinking we could start by implementing a simple suite of ImageJ commands that perform the above actions, one for each bullet point.</div>
<div><br></div><div>Another topic we discussed was the newly minted SciJava Common plugin/service framework [1]. I showed Jean-Marie how it works [2], and he commented that Insight had invented a "Container" that covered essentially the same concepts: it acts as an application context that houses all of Insight's state. So Jean-Marie is going to investigate whether SciJava Common could meet Insight's needs there instead. One advantage of switching is that with SciJava Common, Insight would have not only a working service framework and application context, but an extensible plugin framework, meaning that it could define its own types of Insight plugins for various purposes [3].</div>
<div><br></div><div>I think that ImageJ2, SCIFIO and Insight all sharing this common framework goes a long way toward interoperability between them.</div></div></div></div><div><div class="h5"><div><br></div><div>Lastly, I will reply to some of Jean-Marie's earlier comments:</div>
<div><br></div><div><div><div>> Following recent discussions with users, some adjustments will be made</div><div>> to the "insight plugin" Solution to save data back to OMERO while used</div><div>
> as a plugin is in progress.</div><div><br></div></div><div>That sounds good. The ability to "save data back to OMERO" can initially be fulfilled in the various ways we listed above (upload script, upload image, upload results table, upload ROIs). Writing each as a separate ImageJ command makes the most sense to me. We can have a GUI to invoke the commands, but fundamentally writing them as commands provides maximum flexibility: they would be usable headless from ImageJ macros and scripts, for example.</div>
<div><br></div><div><div><div>> Insight as an Image2 plugin and running ImageJ2 plugin in insight but</div><div>> due to the development stage of ImageJ2 too many things had to be</div><div>> hard-coded/assumed. Since then ImageJ2 has matured, so we could</div>
<div>> re-activate that work.</div><div><br></div></div><div>If you want to pursue that sort of integration as a feature of Insight when run standalone, OK. But since Insight can already work as an ImageJ plugin, it may be unnecessary. Users can invoke Insight from within ImageJ2; it may not be necessary to also enable invocation of ImageJ2 from within Insight.</div>
</div></div><div><div><br></div><div><div>> During the meeting held in Dundee in November, I made good progress on</div><div>> the OMERO/imglib2 front (cf. Jason's report). I have 2 working</div><div>
> prototype reading data from OMERO using different approaches (for one</div><div>> I follow catmaid example)</div></div><div><br></div></div><div>Excellent. I saw one of the approaches, using OmeroReader. This is ultimately how I want to do it, too, except that we also need a smart ImgLib2 container that can page in and page out blocks from a source, using some arbitrary mechanism (in our case, a Bio-Formats reader). Eventually I want to have this container also support writing data into memory too, and caching out those "dirty blocks" to disk, with the modified data overriding the original input mechanism. That way, you could read in blocks of data from disk or from OMERO using Bio-Formats, make changes by running ImageJ commands, etc., all on a huge dataset with bits of it being cached in and out of memory using scratch space on disk. Finally you could save the changed image back to OMERO using the "upload image to OMERO" command (see above).</div>
<div><br></div><div>Regarding the other approach—the one you modeled after Stephan Saalfeld's CATMAID integration—where is that code? I would love to check it out.</div><div><div><br></div><div><div>> Looking closely at the code of ImgLib2, some assumptions are made so</div>
<div>> they will need to be modified in order to work and we will also need</div><div>> to re-discuss the dependency stack of imglib2 (cf. Dresden discussion)</div></div><div><br></div></div><div>Could you elaborate on that a bit? I designed the ImgLib2 build system, so can comment on any potential dependency issues there. The typical solution to such things is to modularize code, both to avoid circular dependencies, and to split code with differing dependencies into separate sub-projects.</div>
<div><div><br></div><div><div>> Following Dresden hackathon, I started to modify insight so it can be</div><div>> used in headless mode (still some work to be done there) and this is</div><div>> tested/used as prototype by Knime, The reason for such work is that</div>
<div>> people will not have to re-invent the communication layer with OMERO</div><div>> and/or the caching (ehcache is already in used by insight!)</div></div><div><br></div></div><div>I would definitely like to reuse any OMERO communication layer that already exists. Initially, the OmeroReader class in ome-io is perfect for this, though later we can explore how to reuse parts of Insight that provide other sorts of communication beyond images. For this to work, though, it will be paramount for Insight to be modular, and structured as reusable libraries/JARs (ideally Maven artifacts) consumable within ImgLib2- and ImageJ2-based projects.</div>
<div><br></div><div>As for Insight's ehcache-based caching, it may be reusable from within ImgLib2 as part of the cell container implementation I mentioned above, but I would need to see the code. Could you send me a pointer to the relevant code you had in mind?</div>
<div><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Curtis</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] Background: It was originally the ImageJ2 plugin framework, but Mark Hiner & I realized that it would be ideal for SCIFIO to also use the same framework, rather than reinventing its own (which it was in the process of doing). So I split it out of ImageJ2, and now both ImageJ2 and SCIFIO are using it, to great effect. See also: <a href="https://groups.google.com/d/topic/scijava/1l61Nd_f9Tw/discussion" target="_blank">https://groups.google.com/d/topic/scijava/1l61Nd_f9Tw/discussion</a>, <a href="https://github.com/scijava/scijava-common" target="_blank">https://github.com/scijava/scijava-common</a><br>
<br><div class="gmail_extra">[2] <a href="https://github.com/imagej/imagej-tutorials/blob/b7c197a9/intro-to-imagej-api/src/main/java/IntroToImageJAPI.java" target="_blank">https://github.com/imagej/imagej-tutorials/blob/b7c197a9/intro-to-imagej-api/src/main/java/IntroToImageJAPI.java</a></div>
<div class="gmail_extra"><br></div>[3] One example in ImageJ2 that I showed Jean-Marie is that of the CalculatorOp, an ImageJ2 plugin type that extends the Image Calculator command with an additional operation. The Image Calculator command lets you process two images with a binary operation, but in ImageJ1 the operations were hardcoded. In ImageJ2 you can define your own. See: <a href="https://github.com/imagej/imagej/tree/518650c8/plugins/commands/src/main/java/imagej/core/commands/calculator" target="_blank">https://github.com/imagej/imagej/tree/518650c8/plugins/commands/src/main/java/imagej/core/commands/calculator</a><br>
<br></div><div><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 29, 2012 at 12:49 AM, Jean-Marie Burel <span dir="ltr"><<a href="mailto:j.burel@dundee.ac.uk" target="_blank">j.burel@dundee.ac.uk</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"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Hi Curtis</div><div><br></div><div>Few points to clarify</div><div>OMERO/ImageJ</div><div><br></div><div>I have modified the insight client to be an imageJ plugin (or other plugin e.g. It is used as a knime node too).This has been released and is already in use in various labs.</div>
<div>Following recent discussions with users, some adjustments will be made to the "insight plugin"</div><div>Solution to save data back to OMERO while used as a plugin is in progress. </div><div><br></div><div>
While in Dresden, I had integrations prototype with ImageJ2 </div><div>Insight as an Image2 plugin and running ImageJ2 plugin in insight but due to the development stage of ImageJ2 too many things had to be hard-coded/assumed. Since then ImageJ2 has matured, so we could re-activate that work.</div>
<div><br></div><div><br></div><div>OMERO/imgLib2</div><div>During the meeting held in Dundee in November, I made good progress on the OMERO/imglib2 front (cf. Jason's report).</div><div>I have 2 working prototype reading data from OMERO using different approaches (for one I follow catmaid example)</div>
<div>Looking closely at the code of ImgLib2, some assumptions are made so they will need to be modified in order to work and we will also need to re-discuss the dependency stack of imglib2 (cf. Dresden discussion)</div>
<div>
<br></div><div>Following Dresden hackathon, I started to modify insight so it can be used in headless mode (still some work to be done there) and this is tested/used as prototype by Knime,</div><div> The reason for such work is that people will not have to re-invent the communication layer with OMERO and/or the caching (ehcache is already in used by insight!)</div>
<div><br></div><div><br></div><div> As you can see, a lot of work has already been done and/or released.</div><div>Happy to discuss so we do not waste time and effort.</div><div><br></div><div>Ciao</div><div><br></div><div>
Jmarie</div><div><div><br></div><br>The University of Dundee is a registered Scottish Charity, No: SC015096</div></div></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br></div></div></div>