[ome-devel] ImageJ-OMERO status report

[Curtis Rueden]

Hi everyone,

It's been awhile since my last email about ImageJ-OMERO [1], so here's a
status report.

For those who don't know: the ImageJ-OMERO project seeks to provide access
to ImageJ algorithms from the OMERO server side -- as well as to allow
access to an OMERO database from the ImageJ application.

This summer saw a huge push to get ImageJ2 out the door and fully
integrated into the Fiji distribution of ImageJ. There have been a lot of
obstacles there, but the gist is that Fiji is now built on top of the
ImageJ2 architecture, which expands the flexibility of ImageJ a great deal.
In particular, it provides support for the SciJava module framework (a.k.a.
parameterized inputs and outputs) such that ImageJ commands and scripts can
be executed in a variety of contexts, including from OMERO on the server
side. In June, we released ImageJ-OMERO version 0.1.0 (the first release
version) to the OMERO-5.0 update site.

One crucial consequence of this work is that ImageJ 1.x data structures
(e.g., ij.ImagePlus) can now be used as input parameters -- before this
change, it was only possible to work with ImageJ2 data structures which are
still in beta development phase.

This week, I fixed a critical problem in the ImageJ2 scripting
infrastructure preventing both Jython and JRuby from working properly in
the same installation [2]. I also have an initial fix for a bug which
resulted in the ImageJ menus being displayed out of order within OMERO.web
and OMERO.insight [3].

The next goal is to enable access to ImageJ 1.x plugins from OMERO by
wrapping them in IJ2-style scripts [4]. But I need to do more testing with
the latest version of ImageJ, since I expect some issues related to the
fact that we had to disable some aspects of the ImageJ2 integration by
default, at least temporarily, for performance reasons.

Next week, LOCI is hosting a hackathon for the ImageJ-OPS project [5]. OPS
is an exciting new aspect of ImageJ seeking to standardize and unify image
processing algorithms, much as Bio-Formats and SCIFIO have done for image
I/O operations. Each op plugin is an ImageJ module, meaning that as the OPS
library improves it will continue to expand the image processing
capabilities of OMERO, KNIME, CellProfiler, and any other application
interoperating with the SciJava module framework.

In general, the development path for ImageJ-OMERO is: 1. bug-fixes; 2.
tables; 3. ROIs. For details, see the project milestones [6]. All of this
work is slated to be finished before the end of the year. Stay tuned for
more frequent updates in the coming weeks.

Regards,
Curtis

[1] https://github.com/imagej/imagej-omero
[2] https://github.com/scijava/scripting-jython/issues/1,
https://github.com/fiji/fiji/issues/83
[3] https://github.com/imagej/imagej-omero/issues/21
[4] https://github.com/imagej/imagej-omero/issues/7
[5] http://imagej.net/ImageJ_OPS
[6] https://github.com/imagej/imagej-omero/milestones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20140912/9b1028e5/attachment-0001.html>