Source-linked AI summary

ImageJ2: ImageJ for the next generation of scientific image data

Curtis T. Rueden, Johannes Schindelin, Mark C. Hiner, Barry E. DeZonia, Alison E. Walter, Ellen T. Arena, Kevin W. Eliceiri

arXiv:1701.05940v4cs.SEq-bio.QM

TL;DR

ImageJ’s long growth exposed limits in its architecture and data model for modern scientific imaging. ImageJ2 redesigns the platform around extensibility, interoperability, flexible data, and backward compatibility, yielding a framework that supports varied interfaces and external software integration.

  • Problem

    ImageJ’s sustained growth exposed architectural and data-model limitations that constrained support for modern scientific imaging requirements.

  • Method

    ImageJ2 redesigns ImageJ around decoupled components, extensible plugins, flexible data containers, interoperable formats, and compatibility with ImageJ 1.x.

  • Results

    ImageJ2 supports headless and multiple simultaneous user interfaces while enabling its components to run in and integrate with other software projects.

  • Takeaways & Limitations

    ImageJ2 provides a flexible framework for extending image analysis and connecting ImageJ capabilities with external applications and development ecosystems.

  • Takeaways & Limitations

    Migrating ImageJ 1.x functionality is a years-long, necessarily incomplete process while ImageJ2 APIs continue to evolve and stabilize.

Abstract

from arXiv · show

ImageJ is an image analysis program extensively used in the biological sciences and beyond. Due to its ease of use, recordable macro language, and extensible plug-in architecture, ImageJ enjoys contributions from non-programmers, amateur programmers, and professional developers alike. Enabling such a diversity of contributors has resulted in a large community that spans the biological and physical sciences. However, a rapidly growing user base, diverging plugin suites, and technical limitations have revealed a clear need for a concerted software engineering effort to support emerging imaging paradigms, to ensure the software's ability to handle the requirements of modern science. Due to these new and emerging challenges in scientific imaging, ImageJ is at a critical development crossroads. We present ImageJ2, a total redesign of ImageJ offering a host of new functionality. It separates concerns, fully decoupling the data model from the user interface. It emphasizes integration with external applications to maximize interoperability. Its robust new plugin framework allows everything from image formats, to scripting languages, to visualization to be extended by the community. The redesigned data model supports arbitrarily large, N-dimensional datasets, which are increasingly common in modern image acquisition. Despite the scope of these changes, backwards compatibility is maintained such that this new functionality can be seamlessly integrated with the classic ImageJ interface, allowing users and developers to migrate to these new methods at their own pace. ImageJ2 provides a framework engineered for flexibility, intended to support these requirements as well as accommodate future needs.

Background … Functionality

ImageJ2 redesigns the widely used ImageJ platform to address modern scientific imaging requirements while preserving its accessibility, extensibility, and broad disciplinary relevance. Its functionality centers on modular separation of concerns, robust N-dimensional data support, interoperability, and built-in image-processing capabilities.

  • Background: ImageJ, released in 1997, became a widely used image-processing platform, particularly in the life sciences.It was developed by Wayne Rasband at the NIH and has supported many scientific endeavors.
  • Background: ImageJ2 emerged from the need to scrutinize and refactor a platform whose sustained growth exceeded its original scope.The restructuring aimed to keep ImageJ accessible to newcomers, powerful for experts, and relevant to its expanding community.
  • Background: Modern imaging now records multidimensional information including spatial and temporal coordinates, spectral channels, polarization, phase, frequency, and rotation angles.ImageJ2 was designed to support the next generation of increasingly sophisticated image-acquisition data.
  • Why ImageJ?: ImageJ2 seeks to broaden ImageJ beyond bioimage analysis by exploiting commonality across scientific disciplines.Although development has tended toward bioimaging because of its user and contributor base, image-processing algorithms are generally applicable.
  • Why ImageJ?: ImageJ2 rearchitects ImageJ as an open, shared platform for integration and interoperability across bioimaging software packages.Its platform model supports discovery, adaptation, and deployment of new image-analysis methods rather than restricting ImageJ to a monolithic purpose.
  • Design Goals: ImageJ2’s technical design goals comprise functionality, extensibility, reproducibility, usability, performance, compatibility, and community.These seven categories define the project’s goals from its outset.
  • Functionality: ImageJ2 applies separation of concerns through a modular, multilayered architecture in which each layer is encapsulated and builds on lower layers.The overriding principle is software capable of meeting expanding requirements in scientific image processing and analysis.
  • Functionality: ImageJ2 supports N-dimensional image data for multispectral, hyperspectral, lifetime, multi-angle, multi-position, and polarized-light experiments.The data model is intended to express image dimensions beyond conventional time and space.

Extensibility · Reproducibility

ImageJ2 treats community extensibility, interoperability, and reproducibility as core requirements for scientific image analysis. It aims to preserve user-driven modification while supporting open exchange, open development, and practical management of extensions.

  • Extensibility: ImageJ’s greatest strength is its extensibility through community-developed plugins and macros.ImageJ 1.x has supported user-created plugins and macros since its inception, and many have been shared and published.
  • Extensibility: ImageJ2 is designed to preserve ease of modification while leveraging separation of concerns.The redesign is intended to maintain community extension while benefiting from a more clearly separated architecture.
  • Extensibility: ImageJ2 prioritizes interoperability because users benefit from exchanging information among complementary image-processing tools.The project aims to enable ImageJ code to be used from other applications and toolkits, and vice versa.
  • Extensibility: ImageJ2 supports open standards for data storage and exchange to facilitate interoperability with alternative tools.The paper frames interoperability as necessary because no single image-processing system or extension collection can address every need.
  • Reproducibility: Scientific usefulness requires ImageJ to be open source and fully reproducible through an open development process.The paper presents open development as an appropriate fit for open scientific inquiry and as a way to avoid legal or other restrictions on exchanging ideas.
  • Reproducibility: ImageJ2 minimizes complexity by choosing sensible defaults that make simple tasks easy while retaining the possibility of difficult tasks.Lower software layers define the program’s full power, while higher layers reduce visible complexity through suitable default parameters.
  • Reproducibility: A built-in, configurable automatic update mechanism is proposed to make installing and maintaining extensions painless.The mechanism should be scalable and distributed, allowing developers to publish extensions on their own websites without central permission.

Performance

ImageJ2 must preserve performance efficiency as image dimensionality and dataset size grow, while supporting diverse usage choices and scalable processing across expanding computing resources.

  • Performance: ImageJ2 must avoid degrading time efficiency on CPUs and GPUs or space efficiency in RAM and disk as datasets expand.N-dimensional images and increasingly large datasets raise computation requirements for analysis routines.
  • Performance: ImageJ must scale to increasingly huge datasets, potentially through elasticity that transparently provisions additional computing resources.Cloud computing commonly addresses scalability by adding more computers to the problem.
  • Performance: ImageJ algorithms should process increasingly large data in parallel across growing numbers of CPU and GPU cores.Both computation and storage are described as scalable resources available from remote server farms in the emerging Big Data era.

Compatibility

ImageJ2 preserves compatibility with the extensive ecosystem of ImageJ 1.x plugins, macros, and scripts while providing an incremental path to the new framework.

  • Compatibility: ImageJ2 supports existing ImageJ 1.x plugins, macros, and scripts as faithfully as possible.The extensions are described as broadly useful to the user community.
  • Compatibility: ImageJ2 provides a clear incremental migration path for adopting its new framework.Users and developers can transition to new methods progressively.

Community

ImageJ2 is designed to support an evolving, growing community through unified online resources and application integration. Its extensible architecture organizes functionality into domains and libraries, including SciJava’s core application framework.

  • Community: ImageJ2’s principal non-technical goal is to serve its evolving and growing community through unified online resources and application integration.Planned resources include a central community-editable website, discussion forum, and online technical resources for managing extensions; the application should support direct bug reporting.
  • Architecture: ImageJ2 components are broadly classified into four domains, with SciJava providing application-independent functionality for extensible applications.SciJava also represents a collaborative initiative focused on code reuse and cooperation among organizations.
  • Architecture: Separating domains into individual libraries enables targeted reuse and extension of specific functionality.The architecture separates concerns by organizing each domain into libraries that target particular functions.
  • Architecture: SciJava Common provides the core framework for extensible applications through a Context class that encapsulates runtime application state.A Context includes available extensions, open images and documents, and user settings, while supporting concurrently running independently configured application instances.

Service framework

ImageJ2’s application container dynamically initializes services that provide core operations and collectively form most of its API. The framework allows developers to add new services or override existing system behavior, supported by fundamental SciJava Common services such as plugin discovery and event handling.

  • Service framework: The application container dynamically initializes services that open data, manipulate images, and display user-interface elements.Together, these service methods constitute the bulk of ImageJ’s API.
  • Service framework: Developers can extend the system with new services or override any aspect of its behavior.The service-oriented design supports customization of application functionality.
  • Service framework: SciJava Common provides fundamental services including compile-time-indexed plugin discovery, hierarchical publish/subscribe events, environment-agnostic logging, and a central typed object index.The plugin index bootstraps the application context because services are themselves plugins.

Plugin framework

SciJava Common provides a unified, runtime-discovered plugin mechanism organized by priorities and type hierarchies. ImageJ2 uses this framework for extensible operations, interfaces, and tools while reducing the code required to create or modify plugins.

  • Plugin framework: SciJava Common defines plugins as extensions that add or modify software features, discovers them at runtime, and orders them by priorities and types.Plugin types form hierarchies that specify how each plugin fits into the system.
  • Plugin framework: Commands are typed-input and typed-output operations that can appear in menus or be exposed through interoperability mechanisms such as KNIME nodes and CellProfiler modules.ImageJ users commonly use “plugin” to mean a Command.
  • Plugin framework: UserInterface plugins provide application interfaces, allowing alternative UIs—including a wrapper for ImageJ 1.x—without changes to the core system.ImageJ2 includes a Swing-based UI modeled closely after ImageJ 1.x.
  • Plugin framework: Interface-driven design and default method implementations reduce the code developers must write, lowering the barrier to creating and modifying plugins.This simplicity strategy is applied throughout the codebase.

Module framework

The module framework decouples executable routines from user interfaces through typed, parameterized modules that can run across graphical and headless contexts. It combines extensible data modeling with SCIFIO infrastructure for interoperable, scalable image and metadata handling.

  • SciJava modules: SciJava uses parameterized modules with declared, typed inputs and outputs, implemented as Command plugins or scripts in supported languages.The framework separates module execution from interface-specific interaction.
  • SciJava modules: Modules are user-interface independent: the framework harvests inputs, executes code, and processes outputs through context-appropriate mechanisms.The same module can use a Swing dialog in ImageJ or command-line arguments and standard output when run headlessly.
  • SciJava modules: Module pre- and postprocessors, including InputWidget plugins, make execution extensible and allow typed inputs to be collected or automatically populated.An active-image preprocessor can populate a single declared image parameter.
  • ImageJ Common: ImageJ Common unifies ImgLib2’s type- and storage-independent data model with SciJava plugins through Dataset objects representing images, metadata, ROIs, visualization settings, coordinates, and calibrations.The model is designed for arbitrary dimensions, data types, and image sizes, although its structures were still stabilizing when described.
  • SCIFIO: SCIFIO provides extensible format and translator plugins for reading, writing, chunked processing, and translation across image formats and discipline-specific metadata models.Chunked I/O pages data on demand and caches pixel changes on disk, while translators support models such as OME-XML.

ImageJ Ops

ImageJ Ops is ImageJ2’s shared, extensible library of reusable image-processing operations, designed for ease of extension, generality, and high performance. Its plugin-based framework supports specialized, composable operations and can select implementations for available hardware environments.

  • Library scope: As of version 0.33.0, the core Ops library provides 788 Op plugins across nearly 350 operation types in more than 20 namespaces.The library covers image arithmetic, trigonometry, Fourier transformations, deconvolution, thresholding, statistics, and filtering.
  • Design: Ops uses plugins with named, typed parameters and extensible case logic to support easy extension, powerful generality, and high performance.Callers typically specify the desired operation rather than an exact implementation, allowing the framework to match suitable Op plugins.
  • Hardware integration: Ops can express GPU- and cluster-based implementations so that suitable algorithms may be selected automatically according to the available hardware environment.The passage identifies OpenCL, CUDA, and Apache Spark as example implementation libraries.
  • Operation model: Unlike general modules, each Op must be a deterministic pure function with a fixed number of parameters, no side effects, and typed inputs and outputs.Ops extend SciJava’s Command and are therefore usable wherever SciJava modules are supported.
  • Composition: Special ops enable type-safe, efficient repeated chaining by declaring primary input types and avoiding repeated operation-matching overhead.They currently support nullary, unary, and binary arities.

ImageJ Updater

The ImageJ Updater manages ImageJ’s available and installed components through configurable update sites. It tracks versioned files and supports modular distributions such as Fiji while preserving compatibility with existing installations.

  • ImageJ Updater: The Updater manages ImageJ’s available and installed components through flexible update sites containing versioned file collections.Users can choose which update sites to enable, while the base ImageJ site is enabled by default.
  • ImageJ Updater: Distributions such as Fiji extend the base ImageJ site with plugins, scripts, sample images, and color lookup tables.These distributions leverage update-site functionality to provide additional features.
  • ImageJ Updater: The Updater uses db.xml.gz metadata, checksums, and timestamps to classify local files as current, old, modified, or untracked.Update sites are served to users over HTTP.
  • ImageJ Updater: The Fiji Updater’s logic was migrated into ImageJ2 and refactored to be user-interface agnostic while preserving backwards compatibility for existing Fiji installations.This design allows multiple user-interface plugins to share the same updater core.
  • ImageJ Updater: At launch, ImageJ automatically runs an “Up-to-date check” and displays the Updater interface when enabled sites offer updates.The interface appears only if updates are available from the currently enabled update sites.

Usability

ImageJ2 improves usability through sensible defaults, streamlined scripting, automated updates, broad interoperability, and incremental compatibility with ImageJ 1.x. It also supports scalable image processing and community-driven plugin distribution while reducing maintenance burdens for users and developers.

  • Scripting: SciJava declarative parameters reduce scripting boilerplate, in some cases by 50% or more, while enabling headless and future-UI use.Annotations declare script inputs and outputs clearly and avoid ImageJ 1.x GenericDialog dependencies.
  • Sensible defaults: SciJava converters provide sensible type substitutions between ImageJ Dataset objects and paradigms such as MATLAB arrays and ITK images.Converter plugins encapsulate conversion logic for each case, while the framework selects applicable converters automatically.
  • Automatic updates: The ImageJ Updater enables automatic notifications and single-click upgrades, while Maven dependency management reduces broken end-user installations.Multiple update sites also let community developers and third parties distribute plugins independently of the core distributions.
  • Scalability: ImageJ2 supports scalable processing of massive datasets through cell images cached to and from mass storage, with tools such as BigDataViewer enabling exploration.Its type- and container-agnostic algorithms also simplify maintenance, while richer image types can improve space efficiency.
  • Compatibility: ImageJ2 preserves interoperability by allowing developers to combine ImageJ 1.x and ImageJ2 features and supporting incremental migration between them.Maintaining backwards compatibility remains a fundamental goal because many tools and plugins still rely on ImageJ 1.x data structures.
  • Community support: Community resources communicate plugin responsibilities, support status, bugs, and future plans, helping users assess and consume extensions.These resources support contribution, maintenance, and support across the community-driven plugin ecosystem.

Future directions

ImageJ2 remains an ongoing development effort, with technical tasks needed for stability and new directions enabled by its platform. Its redesigned architecture strengthens ImageJ as a flexible, interoperable, open-source platform for scientific image analysis.

  • Future directions: ImageJ2 still requires technical development and maintenance to achieve stability as imaging acquisition technology advances.The authors describe ImageJ as a living ecosystem requiring continued development and maintenance.
  • Future directions: Planned work includes completing metadata-aware data models, expanding N-dimensional ROI support, and improving plugin-driven I/O and arbitrary-block image handling.Additional tasks include migrating the desktop launcher to JavaFX and completing ongoing development efforts.
  • Future directions: ImageJ2 strengthens scientific image analysis by generalizing its data model, enabling interoperability, supporting permissive open-source extension, and building on existing plugins.The platform is intended to connect a broad range of external image visualization and analysis programs while enabling new plugin development.

Endnotes

The authors are affiliated with the Laboratory for Optical and Computational Instrumentation at the University of Wisconsin at Madison and the Morgridge Institute for Research, both in Madison, Wisconsin, USA.

  • Author details: Author affiliations include the Laboratory for Optical and Computational Instrumentation at the University of Wisconsin at Madison and the Morgridge Institute for Research.Both institutions are located in Madison, Wisconsin, USA.

Supplemental material

The supplemental material documents ImageJ’s module execution contexts, performance comparisons between ImageJ 1.x and ImgLib2 data structures, and plugin usage across ImageJ generations. It also catalogs SciJava input widgets, special operations, and supported image types, including backward-compatibility notes.

  • Figures: Supplemental figures cover module execution in different contexts, time-performance comparisons across ImageJ 1.x and ImgLib2 data structures, and sample plugin usage in ImageJ 1.x and ImageJ2.These topics are presented in Figures S.1–S.3.
  • Reference tables: Table S.1 lists the built-in SciJava input widgets.The table provides a reference for available widget types.
  • Reference tables: Table S.2 classifies special operations by kind and arity.It organizes the supported special ops according to these two properties.
  • Reference tables: Table S.3 catalogs the image types supported by ImageJ, including compatibility behavior for ImageJ 1.x and ImageJ2.ImageJ 1.x partially supports int8 and int16 through image calibration; ImageJ2 supports listed types for backward compatibility, while composite color mode offers a more flexible equivalent.
Loading 1701.05940v4…