|Date||Wed May 24 15:08:10 CDT 2017|
|Founders||Curtis Rueden, Christian Dietz, Martin Horn, Johannes Schindelin|
|Leads||Curtis Rueden, Christian Dietz|
|Developers||Curtis Rueden, Christian Dietz, Brian Northan, Gabriel Einsdorf, Tim-Oliver Buchholz, Leon Yang|
|Debuggers||Curtis Rueden, Christian Dietz, Brian Northan|
|Reviewers||Curtis Rueden, Christian Dietz, Brian Northan|
|Support||Curtis Rueden, Christian Dietz, Brian Northan, Tim-Oliver Buchholz|
|Maintainers||Curtis Rueden, Christian Dietz|
|Contributors||Martin Horn, Johannes Schindelin, Richard Domander, Jan Eglinger, Andreas Graumann, Jonathan Hale, Kyle Harrington, Eike Heinz, Stefan Helfrich, Mark Hiner, Aparna Pal, Simon Schmid, Daniel Seebacher, Alison Walter, Michael Zinsmaier|
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 ImageJ, CellProfiler, KNIME, OMERO and Alida.
Ops has three major design goals:
- 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.
- 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.
- Very fast. Even though ImgLib2 is vastly more general than ImageJ 1.x'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 1.x. 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.
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
- Step-by-step guide: Adding new ops
- ImageJ Tutorial: Introduction to ImageJ Ops
- Extending ImageJ: Ops
- "Scripting in ImageJ - An introduction to ImageJ Ops" (February 2017 NEUBIAS2020) – slides
- "ImageJ2 scripts: Parameters + ImageJ Ops" (ImageJ conference 2015) – slides, video 1, video 2
- "The ImageJ Ops Framework: Image processing made easy" (January 2015) – slides
- "Intro to ImageJ Ops - Usage and Development" (November 2015) – slides
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.
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
Are there any Ops for image processing?
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:
- cannot possibly cover all possible implementations and
- 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
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.
- 2014-04-04 - Announcing ImageJ Ops news post