[ome-devel] Writing ImageJ2 plugins
Graeme Ball
graemeball at googlemail.com
Wed Oct 23 22:02:02 BST 2013
Hi Curtis,
thank you for your reply - that certainly clears up some of my questions.
Yes, my questions were motivated by the desire to write plugins for IJ1
that will not be obsolete in IJ2, and preferably be able to be run
headlessly, e.g. from OMERO.
If possible, when I write (ImageJ1) plugins I try to confine any GUI calls
to the run method, and all of the real work to an exec method that does not
require interactive input. It seems that ImageJ2 also uses a run method as
the entry point for running a command? (correct me if I am wrong) In that
case, at least the run method would have to be replaced.
I was not so worried about ImageJ1's dialogs (which I expected would *not*
be OK in a headless plugin), but was more concerned about ImagePlus, Roi
etc. which make heavy use of awt classes. If these also cannot be used
headlessly, then I guess a legacy mode with virtual UI, or re-writing to
use the IJ2 API are the only real options.
It sounds as though converting IJ1 plugins to use the IJ2 API is likely be
more productive than trying to use the legacy IJ1 API from an IJ2 plugin
(headless), but is the latter already known to be hopeless? If not, I might
be tempted to try a little.
Until now I have chosen to write for IJ1 since the IJ2 API is still a
moving target and has a smaller user base, but I guess IJ2 / ImgLib2
already makes a lot of sense for headless processing tasks. Would you say
that once imagej2-b9-rois is out, the IJ2 API will be fairly stable going
forward?
Thanks & Best Regards,
Graeme
On Wed, Oct 23, 2013 at 6:45 PM, Curtis Rueden <ctrueden at wisc.edu> wrote:
> Hi Graeme,
>
> Sorry for the delay in reply. Writing to a public mailing list is
> better. I am CCing imagej-devel and ome-devel since your questions are very
> technical, and related to those two projects.
>
> > I thought I would Email you directly because the ImageJ-devel
> > mailing list seems to be intended for core project development.
>
> From http://developer.imagej.net/mailing-lists:
> > ImageJ: For general user and developer discussion about ImageJ. This
> > list is the best place to go for help with your specific use case.
> >
> > ImageJ-devel: For technical and developer discussion of the ImageJ2
> > project. This list is for programmers contributing code to ImageJ2, or
> > interested in technical discussions surrounding such development.
>
> Both are public mailing lists intended for use by the community, not
> just for core project development. The wording of ImageJ-devel is phrased
> that way because ImageJ2 is still in beta and if you are using it for your
> projects, you are an early adopter who is almost certainly "interested in
> technical discussions" surrounding core development.
>
> > 1. I was looking for example plugins (& example minimal plugin
> > project), but get 404's when I try to look at the HelloWorld and
> > GradientImage examples here:-
> > http://developer.imagej.net/writing-imagej2-plugins
> > (I found the github repo & Fiji wiki ImgLib2 examples)
>
> All links on that page should be working again.
>
> > 2. I see an example of calling IJ2 from a legacy plugin, but am also
> > interested in doing the reverse, and unsure what the limitations are.
>
> The limitations are evolving. Legacy support is very challenging to get
> right. That said, it should work to call ImageJ1 data structures from an
> ImageJ2 style command. There is a LegacyService for converting between IJ1
> and IJ2 data structures, although the API still needs work.
>
> Note that at the moment, ImageJ2 commands are only discovered and
> exposed in the modern ImageJ2 UI. We are exploring ways of blending things
> in additional ways, such as allowing the ImageJ1/Fiji legacy UI to discover
> and allow execution of IJ2 commands.
>
> What is your goal? You want to write a plugin that is available from
> both IJ1 and IJ2? If so, structuring it as a legacy IJ1 plugin (which may
> or may not leverage certain IJ2 API internally as demonstrated in
> calling-modern-from-legacy) is the way to go for now.
>
> > 3. What are the constraints / requirements for running plugins
> > (including legacy wrapped in IJ2?) headless, with a view to running
> > from OMERO in future?
>
> In IJ2 terms, the ImgLib2 library is fully usable headless. If your IJ2
> command does not depend on ij-ui you probably will be able to run it
> headlessly. The requirements, in general, are the same as running any Java
> code headless: do not use AWT or Swing or other UI, especially
> Windows/Frames/Dialogs.
>
> Unfortunately, you cannot just take a legacy IJ1 plugin and "wrap in
> IJ2." The problem is that fundamentally, IJ1 is filled with java.awt
> references including some core classes extending java.awt.Dialog and
> java.awt.Frame, which are illegal to even instantiate headlessly.
>
> We have some crazy hacks in Fiji to allow limited execution of IJ2 code
> headless even when it would normally use those AWT window classes. It works
> by using bytecode manipulation (javassist library) to rewrite parts of IJ1
> at runtime to avoid references to those classes. However, in some cases
> things will still blow up. It should go without saying that any time an IJ1
> plugin asks the user for input (e.g., the WaitForUserInput dialog), it will
> fail when trying to run headless.
>
> All of that said, we may be able to support calling many IJ1 plugins
> headlessly from OMERO in the same way we support it headlessly in general:
> using by install Xvfb on the server side. This gets around the limitations
> of java.awt.headless=true, in favor of actually giving Java a
> virtual/offscreen UI. See: http://fiji.sc/Headless
>
> As of this writing, I have not yet tried to get legacy IJ1 plugins
> working from OMERO. The reason is that I know it will be a lot of effort,
> for something that would only be transitional. We are writing IJ2 precisely
> to avoid the sorts of problems incurred by IJ1's heavy use of AWT in core
> classes. IJ2 maintains a strict separation of concerns, and its commands
> have typed inputs and outputs, which are a natural match to other paradigms
> such as OMERO scripts, CellProfiler modules, and KNIME nodes. Mapping IJ1
> plugins to those paradigms is difficult not only due to headless issues but
> also because in general there is no easy way to know the actual inputs and
> outputs of the plugin, since IJ1 plugins do not declare that metadata.
>
> So in conclusion, while I sympathize with the desire to execute ImageJ1
> plugins from OMERO, ultimately a better direction is to rewrite plugins of
> interest as ImageJ2 commands so we truly get a "write once, run anywhere"
> effect with the whole software ecosystem interoperating with ImageJ2.
>
> > Apologies if I missed some documentation, or a more appropriate
> > community forum to ask these questions, and me know if I am jumping
> > the gun and would be better waiting a few months.
>
> Not at all; these are good questions and not well explained online. I
> added a couple of short entries to the online FAQ:
>
> http://developer.imagej.net/can-i-call-imagej2-api-imagej1-plugin
> http://developer.imagej.net/can-i-call-imagej1-api-imagej2-command
>
> Please let me know if there are other topics you would like to see
> covered on the website.
>
> Regards,
> Curtis
>
>
> On Thu, Sep 26, 2013 at 6:39 PM, Graeme Ball <graemeball at googlemail.com>wrote:
>
>> Hi Curtis,
>>
>> I have a few questions about writing plugins for ImageJ2,
>> and I thought I would Email you directly because the
>> ImageJ-devel mailing list seems to be intended for core
>> project development.
>>
>> 1. I was looking for example plugins (& example minimal
>> plugin project), but get 404's when I try to look at
>> the HelloWorld and GradientImage examples here:-
>> http://developer.imagej.net/writing-imagej2-plugins
>> (I found the github repo & Fiji wiki ImgLib2 examples)
>>
>> 2. I see an example of calling IJ2 from a legacy plugin,
>> but am also interested in doing the reverse, and
>> unsure what the limitations are.
>>
>> 3. What are the constraints / requirements for running
>> plugins (including legacy wrapped in IJ2?) headless,
>> with a view to running from OMERO in future?
>>
>> Apologies if I missed some documentation, or a more
>> appropriate community forum to ask these questions, and
>> let me know if I am jumping the gun and would be better
>> off waiting a few months.
>>
>> Thanks & Best Regards,
>>
>> Graeme
>>
>> --
>> ---------------------------
>> Dr. Graeme Ball
>> Department of Biochemistry
>> University of Oxford
>> South Parks Road
>> Oxford OX1 3QU
>> Phone +44-1865-613-359
>> ---------------------------
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20131023/f28098a0/attachment-0001.html>
More information about the ome-devel
mailing list