[ImageJ-devel] [fiji-devel] Linking to Fiji/Plugins

[Curtis Rueden]

Hi Brad,

I have a general question about how to utilize ImageJ/Fiji...  Is it
> possible (and if so, what is the best way) to use ImageJ/Fiji as a
> general image processing framework?  Specifically, can it be
> incorporated into other Java applications?
>

The short answer is yes, you can use Fiji as a library, but with certain
limits. Unfortunately, you have encountered many of the major limitations of
ImageJ 1.x.

The good news is that we are striving to address these shortcomings with the
ImageJDev project (http://imagejdev.org/), with the first alpha of ImageJ
2.0 due on April 1, and the final release due October 1. There is still much
to be done but large portions of the core architecture are in
place—particularly UI-independent frameworks for plugins, tools and events.

  - a fair amount of plugins assume a UI interface (e.g. don't
> provide a simple method with which you can pass all the relevant
> parameters, instead they have a run() that pops up dialogs, etc
>

Fiji contains some hacks to enable headless operation in many cases, but as
you point out, if a plugin makes direct use of GUI code, then it will
generally not be usable headless.

To avoid this problem in ImageJ2, we have created an annotated plugin
framework where inputs and output parameters are labeled and automatically
harvested based on the application context (prompt user with a dialog,
collect from a configuration file if run on the command line, etc.). For
details, see: http://imagejdev.org/extensibility

Some ImageJ1 plugins running in compatibility mode will still not be usable
headless, but new IJ2 plugins will be much more flexible.

  - I haven't found a clean way to reference code that's under the
> Java default package in code that is not in the default package.  This
> could be mitigated if folks would put the computational logic in a
> named package, and make the plugin in the default package lightweight
> (e.g. just a run method that calls the class in the named package)
>

Hmm, I am not too familiar with this issue. It may continue to be a problem
with ImageJ2, unless someone knows a way around it.

  - it's been hard to get seamless image I/O, i.e., I haven't been
> able to get a seamless I/O class - for example, getting a simple
> ImageReader that would do either native file formats or seamlessly
> link to bioformats and create the relevant ImagePlus
>

We plan to add I/O extensibility to ImageJ2, as a particular subclass of
plugin. This will eliminate the need for HandleExtraFileTypes, and other
complicated centralized I/O logic present in ImageJ1. This work is not yet
complete, but you can track our progress at:
http://imagejdev.org/input-and-output

In the meantime, the LOCI plugins (http://loci.wisc.edu/bio-formats/imagej)
provide a very simple class for extracting an ImagePlus using Bio-Formats.
See:
http://dev.loci.wisc.edu:8080/job/Bio-Formats/javadoc/loci/plugins/BF.html--
in particular, BF.openImagePlus(String) and
BF.openImagePlus(ImporterOptions).

HTH,
Curtis

On Fri, Mar 18, 2011 at 9:27 AM, Brad <brad.t.moore at gmail.com> wrote:

> Hey all,
>
> I have a general question about how to utilize ImageJ/Fiji...  Is it
> possible (and if so, what is the best way) to use ImageJ/Fiji as a
> general image processing framework?  Specifically, can it be
> incorporated into other Java applications?
>
> That might be sound like a simple question (and an easy answer), but
> here's what I've tried:
> 1.  Executing Fiji via the command-line with --headless, -eval, -batch
>   + I could utilize Fiji plugins that were setup to work as a macro
>   - overhead with calling these operations as a separate process
>   - working in --headless mode produced odd results for some plugins
>
> 2.  Linking to various ImageJ/Fiji .jars
>   + could use it like a regular library
>   + speed
>   - a fair amount of plugins assume a UI interface (e.g. don't
> provide a simple method with which you can pass all the relevant
> parameters, instead they have a run() that pops up dialogs, etc
>   - I haven't found a clean way to reference code that's under the
> Java default package in code that is not in the default package.  This
> could be mitigated if folks would put the computational logic in a
> named package, and make the plugin in the default package lightweight
> (e.g. just a run method that calls the class in the named package)
>   - it's been hard to get seamless image I/O, i.e., I haven't been
> able to get a seamless I/O class - for example, getting a simple
> ImageReader that would do either native file formats or seamlessly
> link to bioformats and create the relevant ImagePlus
>
> I'd appreciate folks' input.  Is there something I should change about
> my basic approach...  Is there a doc/code/example I can be pointed to
> that successfully does this?  Intuitively, I'm trying to compare
> ImageJ/Fiji to a library/framework like OpenCV or ITK.  Can I use it
> like this?
>
> Cheers,
> -Brad
>
> --
> You received this message because you are subscribed to the Google Groups
> "Fiji-devel" group.
> To post to this group, send email to fiji-devel at googlegroups.com.
> To unsubscribe from this group, send email to
> fiji-devel+unsubscribe at googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fiji-devel?hl=en.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110321/2443c72b/attachment.html>