Page history Edit this page How do I edit this website?
Original MediaWiki page
This page describes content relating to the ImageJ2 platform. Click the logo for details.

ImageJ Ops

The content of this page has not been vetted since shifting away from MediaWiki. If you’d like to help, check out the how to help guide!

ImageJ Ops is a framework for reusable image processing operations. Ops extends Java’s mantra of “write once, run anywhere” to image processing algorithms.

The central goal is to enable programmers to code an image processing algorithm in the Ops framework, which is then usable as-is from any SciJava-compatible software project, such as ImageJ2, CellProfiler, KNIME, OMERO and Alida.

Design goals

Ops has three major design goals:

  1. Easy to use and extend. There must be a wealth of easy-to-use image processing operations (“ops”), as well as an easy framework for extending those ops in new directions.
  2. Powerful and general. An op should be able to consist of any number of typed input and output parameters, operating on arbitrary data structures, including images of N dimensions stored in a myriad of different ways: as files on disk, programmatically generated in memory, or in remote databases. Using the powerful ImgLib2 library achieves this ambitious goal.
  3. Very fast. Even though ImgLib2 is vastly more general than ImageJ’s data model, that generality should not come at the expense of performance. Otherwise, users must pay a time tax to do the same things they could already do in ImageJ. The ImageJ Ops framework needs to provide a means to override any general-but-slow op with a faster-but-more-specific alternative, fully transparently to the user.

Getting started

Start by reading these Jupyter notebooks:

Ops are a special type of ImageJ plugin, so a basic understanding of the SciJava plugin framework is strongly recommended.

In addition to cloning the imagej-ops itself, the following components have useful Ops examples:

Tutorials and workshops

FAQ

Why not implement algorithms as “plain old Java” methods?

The Ops matching framework provides extensibility. Ops are plugins, so any developer can override the behavior of a particular op as needed—e.g., for improved performance of a special case. See “Design goals” above.

Can a C/C++ or MATLAB function be converted to an op?

Yes, but there is no automagic wrapping of native/external functionality in Ops. The ops-experiments project is an ongoing effort to work out a maven based build system for ops that use native code. The efforts so far have focused on wrapping, cuda, mkl and tensorflow implementations of deconvolution algorithms using javacpp.

Is there a list of Ops somewhere with brief descriptions of their functionalities?

For an interactive tool to see all available Ops, see the Op Finder documentation.

For the core Ops available, you can go to the ImageJ Ops javadocs. Any class under the package net.imagej.ops is related to Ops.

You can also use the Script Editor in ImageJ and actively search using Ops itself. For example in groovy language:

// @OpService ops
print ops.help()

in groovy will give a list of every Op signature. The help op can also provide information about ops or namespaces; e.g., ops.help("add") will return info about available add ops.

Are there any Ops for image processing?

Yes, there are. Take a look at the existing ops using the Ops Browser or the net.imagej.ops.* packages in the ImageJ javadocs.

What are the Ops that need to be developed in the future?

Ops is under development at the moment, as indicated by the 0.x.x version number. For ideas and discussions of future developments visit the ImageJ Ops GitHub page and take a look at the issues and pull requests.

Why is matching important?

This is a necessary part of any plugin-based infrastructure (see Inversion of control). The core library (ImageJ Ops) has many built-in operations, but:

  1. cannot possibly cover all possible implementations and
  2. would be impractical if a user had to explicitly call the precise signature for their arguments.

Ops matching is an additional layer that allows plugin selection to be tailored to the arguments of the function being called.

A contrived example: Suppose the default ops implementation of add(array, array) iterates over the arrays and combines their values.

Then guava comes up with a way to combine arrays that is 100x faster; we do not want a guava dependency in the base ops library, but we can have an “imagej-ops-guava” component that provides a GuavaAddArrayOp.

Then an independent developer comes up with a new way to add the arrays that’s 50,000x faster. They turn it into a closed-source, proprietary Op and sell it.

Regardless of this proliferation of implementations, a user just has to write ops.math().add(array1, array2) and it will work. If they have the guava implementation on their classpath it will be faster, and if they purchase the proprietary implementation it will be faster still. But their code does not have to be adjusted.

See also