ImageJ2: ImageJ for the next generation of scientific image data

Background

• ImageJ, released in 1997, became widely used in scientific work, particularly in life sciences, and ImageJ2 is a total redesign intended to build on its successful qualities.The redesign aims to keep the software accessible to newcomers, powerful for experts, and relevant to its growing community.Source: Background · pp. 1–2
• ImageJ2 responds to increasingly complex image data, opportunities for software collaboration, and a desire to broaden ImageJ’s reach across scientific disciplines.Its motivations include modularity for library use, new interfaces, external integration, and generalizing the codebase for fields beyond life sciences.Source: Background · p. 2
• ImageJ2’s six-part mission emphasizes community-driven design, open collaboration, cross-disciplinary relevance, backward compatibility, unified online resources, and clear development direction.The project notes that development pragmatically continues to address bioimaging needs while avoiding limiting ImageJ to bioimage analysis.Source: Background · pp. 2–3

Why ImageJ?

• ImageJ2 rearchitects ImageJ as a shared platform for integration and interoperability, building on its approachable plugin and macro environments.The project aims to foster cooperation among ImageJ, KNIME, CellProfiler, OMERO, and other tools through SciJava.Source: Why ImageJ? · p. 3

Design Goals

• ImageJ2’s technical design goals comprise functionality, extensibility, reproducibility, usability, performance, compatibility, and community.The section introduces these goals before discussing how they were met in practice.Source: Design Goals · p. 4

Functionality

• ImageJ2 separates its data model from display in a modular, multilayered design that supports headless operation on servers, clusters, or clouds.The design aims to meet expanding scientific image-processing and analysis requirements.Source: Functionality · p. 4
• ImageJ2 aims to support N-dimensional image data, including multispectral, lifetime, multi-angle, multi-position, and polarized-light imaging.Its design is intended to accommodate newly emerging imaging modalities.Source: Functionality · p. 4
• ImageJ2 is intended to provide built-in plugins for image processing, analysis, visualization, and file import and export, enabling out-of-the-box use.These default routines complement its modular framework.Source: Functionality · p. 4

Extensibility

• ImageJ2 aims to make community extensions easier and more powerful by separating image-processing plugins from the user interface.This separation allows new interfaces to be developed without loss of plugin functionality.Source: Extensibility · p. 4
• ImageJ2 is intended to enable ImageJ code to be used by other applications and toolkits, and to support open standards for data exchange.The paper frames interoperability as important because useful image-processing tools will remain available outside ImageJ.Source: Extensibility · p. 4

Reproducibility

• ImageJ should support reproducible open development through publicly accessible project resources, public discussions, and automated tests on reference datasets.These practices are intended to enable community contributions, transparent project decisions, and validation of consistent results.Source: Reproducibility · p. 5

Usability

• ImageJ2 seeks to keep a modular system understandable through sensible defaults and layered complexity, with an easy path for installing and updating extensions.Lower layers retain the full power, while higher layers simplify common tasks; a configurable distributed updater would let developers publish extensions on their own websites.Source: Usability · p. 5

Performance

• ImageJ2 must avoid degrading time and space efficiency while offering resource-use choices and sensible defaults for common scenarios.The stated resource dimensions include CPU and GPU computation, and RAM and disk storage.Source: Performance · p. 5
• ImageJ must scale to increasingly huge datasets by using algorithms that process data in parallel across growing numbers of CPU and GPU cores.The paper describes cloud elasticity as one approach to meeting this need through additional computing resources.Source: Performance · pp. 5–6

Compatibility

• ImageJ2 must faithfully support the many useful ImageJ 1.x plugins, macros, and scripts while providing a clear incremental migration path.These extensions have proven extremely useful to the user community.Source: Compatibility · p. 6

Community

• ImageJ2’s community goals include a central editable website, discussion forum, extension-management resources, and in-app bug reporting to online issue trackers.The application is intended to work in concert with these resources so users can report bugs directly when problems occur.Source: Community · p. 6

Implementation

• SciJava, ImgLib2, SCIFIO, and ImageJ provide shared application libraries, image representation, format I/O, and image tools, forming the ImageJ software stack.Each domain is divided into function-specific libraries, enabling targeted reuse and extension.Source: Implementation · p. 6

• SciJava Common provides the core framework for creating extensible applications and forms the ground floor of the ImageJ software stack.Source: SciJava Common · p. 7
• Each Context encapsulates runtime application state, including available extensions, open images and documents, and user settings.Source: SciJava Common · p. 7
• The application-container paradigm allows multiple independently configured SciJava applications to run concurrently within one Java Virtual Machine.Source: SciJava Common · p. 7

• ImageJ’s application container dynamically initializes services whose methods form most of its API, and developers can add services or override existing behavior.This design avoids relying on global static state and functions that are difficult or impossible to override or enhance downstream.Source: Service framework · p. 7
• SciJava Common supplies core plugin, event, logging, object, thread, I/O, and preference services; compile-time indexed plugin discovery bootstraps the application context.Services are themselves plugins, and the plugin index is generated by a Java annotation processor.Source: Service framework · p. 7
• Like Spring, SciJava Common offers DI and IoC patterns tailored to collaborative scientific projects, while downstream plugins provide format-specific I/O capabilities.The library provides generalized I/O for opening data from any source without built-in knowledge of XML, microscopy formats, or numerical spreadsheets.Source: Service framework · p. 7

Plugin framework

• Plugins are discovered at runtime and ordered by priority and type, allowing dedicated plugin types to extend or modify virtually any application aspect.The framework presents applications such as ImageJ as collections of plugins and services, with a consistent path for overriding behavior.Source: Plugin framework · pp. 8, 10
• Services provide related functionality through one singleton per application context, while I/O plugins read or write data such as text and image files.ImageJ Common specializes lower-level functions for opening and displaying images using higher-priority plugins.Source: Plugin framework · pp. 8, 10
• Commands expose operations as modules with typed inputs and outputs, while script-language plugins execute scripts and converters transform data between otherwise incompatible types.Commands can appear in the UI or be exposed through interoperability mechanisms; converters can, for example, parse numeric strings or bridge image data structures.Source: Plugin framework · p. 8
• Module preprocessors prepare inputs before execution, and postprocessors handle outputs afterward, with each chain running plugins in priority order.Examples include restoring last-used input values as defaults and displaying module outputs after execution.Source: Plugin framework · p. 9
• UI, platform, input-widget, and display plugins support custom or simultaneous interfaces, machine-specific behavior, typed-input collection, and visualization of images, text, or tables.Extensions can provide widgets for their own input data structures, while display plugins are commonly used to show module outputs.Source: Plugin framework · p. 9
• Tool plugins bind user input to display or data actions, and console-argument plugins extend command-line handling for headless operation; interface-driven defaults reduce plugin-writing effort.Tools include panning and drawing actions, while default method implementations minimize the code plugin developers must write.Source: Plugin framework · p. 10

• SciJava modules are executable routines with declared, specifically typed inputs and outputs, expressed as Command plugins or scripts in supported languages.This decouples algorithms from the user interfaces and applications that expose them.Source: Module framework · p. 10
• The framework handles prompting for inputs, executing module code, and processing or displaying outputs without requiring the module to assume a particular interface.Inputs can be typed—for example, a string and an integer—and the framework chooses how to collect and present them.Source: Module framework · p. 10
• Adapters make SciJava modules available in other tools, including CellProfiler, KNIME, and the OMERO image server.A module can run through an ImageJ Swing dialog or headlessly through command-line arguments, with outputs displayed in a window or echoed to standard output.Source: Module framework · p. 11
• ModulePreprocessor and ModulePostprocessor plugins extend and customize what happens during module execution.Input harvesting collects module inputs, while displaying handles outputs after execution.Source: Module framework · p. 11
• InputWidget plugins harvest specific input types, preprocessors can populate inputs such as the active image, and display plugins present outputs such as text, images, or tables.The active-image preprocessor can supply the current image without explicit selection while retaining its status as a declared input.Source: Module framework · p. 11
• Converter plugins enable automatic use of analogous data types as module inputs, such as MATLAB matrices as ImageJ images or ImageJ images with ITK-based algorithms [39, 40].This can make modules that accept only MATLAB matrices transparently accept ImageJ images when a suitable converter is present.Source: Module framework · p. 11

ImageJ Common

• ImgLib2 supports arbitrary dimensions, varied numeric and non-numeric types, and multiple storage layouts, while separating pixel algebra, data access, and representation through virtual access.Source: ImageJ Common · p. 12
• ImageJ Common unifies ImgLib2’s type- and storage-independent design with SciJava plugins through Dataset, which represents images, collections, and metadata for higher-level operations.Dataset metadata includes regions of interest, visualization settings, sample coordinates, and physical calibrations; plugins and services support opening, saving, generating, and processing datasets. The data model and services were still stabilizing at the time of writing.Source: ImageJ Common · p. 12

SCIFIO

• SCIFIO defines Format and metadata Translator plugins to read, write, and translate image data into ImageJ Datasets and between domain-specific metadata models.Source: ImageJ Common · p. 12
• SCIFIO reads image data in chunks on demand, paging it in and out of memory, while disk-backed caching preserves pixel changes when chunks leave memory.Source: ImageJ Common · p. 13
• SCIFIO Translator plugins connect image formats and scientific metadata models; its OME-XML translators link that model with ImageJ Common, potentially bridging discipline-specific software.Source: ImageJ Common · p. 13

• As of version 0.33.0, the core library provides 788 Op plugins across nearly 350 types of ops in more than 20 namespaces, spanning image processing, statistics, transformations, and 2D/3D geometry.Source: ImageJ Ops · p. 13
• Callers request an operation by name and arguments, and the framework matches typed parameters to the best-fitting plugin rather than requiring callers to select an implementation.Source: ImageJ Ops · p. 13
• Implementations can specialize for subclasses, generic parameters, and converters, allowing optimized and broadly compatible variants to coexist while runtime matching selects the most specific fit.Source: ImageJ Ops · p. 14
• Ops implementations for GPUs and clusters could be expressed as ops and selected automatically according to the available hardware environment.Source: ImageJ Ops · pp. 14–15
• Ops are deterministic, side-effect-free modules that operate only on given inputs and outputs, enabling result caching and headless use.Source: ImageJ Ops · p. 15
• Special ops support efficient, type-safe repeated calls by declaring primary input and output types and an arity; their function, computer, and inplace kinds trade off thread safety, buffer reuse, and input mutation.Source: ImageJ Ops · pp. 15–16

ImageJ Legacy

• ImageJ2 preserves the familiar ImageJ 1.x UI and API while enabling gradual migration through mixed use of the two APIs and delegation to ImageJ2 equivalents when possible.When delegation is unavailable, ImageJ2 falls back to the original ImageJ 1.x behavior.Source: ImageJ Legacy · p. 16
• The IJ1-patcher uses Javassist to modify ImageJ 1.x bytecode at runtime, exposing hooks for extensible integration without breaking existing macros and plugins.Hooks cover critical operations such as opening images, closing the application, and displaying UI components.Source: ImageJ Legacy · pp. 16–17
• ImageJ Legacy intercepts ImageJ 1.x requests and delegates them to ImageJ2 routines, such as using SciJava I/O and SCIFIO for File ▷Open. . ..This exposes extensibility points without requiring users to select individual loader plugins.Source: ImageJ Legacy · p. 17
• The legacy UI maps ImagePlus and Dataset instances through SciJava Converter plugins, so plugins can use either structure regardless of how an image was opened.Conversion is handled in ImageJ Legacy, so individual plugins need not manage synchronization themselves.Source: ImageJ Legacy · p. 17
• The legacy UI also maps logging, notifications, status, and other UI events; reference-based adapter wrappers translate data on demand and reflect underlying updates.Using a common interface for wrappers minimizes performance impact.Source: ImageJ Legacy · p. 17

Results and Discussion

• ImageJ2’s data model supports up to 2^31 − 1 dimensions and 2^63 − 1 elements per dimension, with flexible storage including cached disk-backed images.ImgLib2 supports storage on disk, remote URLs, databases, or generated on the fly; SCIFIO cell images provide block-based read/write caching.Source: Results and Discussion · pp. 19–20
• ImageJ2 supports multiple simultaneous ROIs and overlays, and ImgLib2 algorithms and Ops can process image subsets identified by ROIs without separate case logic.The Ops library can process data within a ROI as a single functional operation.Source: Results and Discussion · p. 20
• ImageJ2’s modular components can be independently deployed and combined at compatible versions, and its application container supports multiple instances and concurrent operations in one JVM.Projects such as KNIME Image Processing use ImageJ2 components, including SCIFIO, and can expose SciJava modules as workflow nodes.Source: Results and Discussion · pp. 20, 21, 23, 24
• ImageJ Ops provides more than 350 extensible operations that work across image types and containers, and new implementations can improve existing scripts.Op plugins can add algorithms, extend support for data structures, or optimize specific types without changing previously written code.Source: Results and Discussion · pp. 21–22
• SciJava plugins extend ImageJ2 with operations, tools, commands, and other plugin types, while SCIFIO provides more than 30 open formats and supports new format plugins.SCIFIO also wraps Bio-Formats, and custom format plugins can integrate proprietary formats and metadata standards without modifying core functions.Source: Results and Discussion · pp. 21–22
• ImageJ2 separates its data model from the user interface, enabling headless operation, multiple simultaneous UIs, and integration with other interface frameworks.A new UI requires UserInterface, display, and widget plugins; the project also explored Swing, SWT, AWT, Apache Pivot, and JavaFX implementations.Source: Results and Discussion · pp. 22–23
• SciJava parameters make scripts’ inputs and outputs declarative, reducing boilerplate by 50% or more and allowing plugins to work headlessly or in other applications.The cited comparison describes a plugin whose image-selection routine is no longer needed, while its actual copyLabels operation remains identical.Source: Results and Discussion · pp. 25–26, Figure 5 · p. 26
• The Updater simplifies component updates and broadens community sharing through user-selectable sites, automatic upgrades, and third-party repositories.Developers can publish sites without joining the core ImageJ or Fiji distributions; hundreds of third-party sites are available.Source: Results and Discussion · p. 27
• For most ImgLib2 containers, JIT optimization makes iteration and access comparable to ImageJ 1.x, while non-trivial processing converges in performance across data structures.Cell images can be measurably slower when loop overhead dominates, but that overhead is generally small.Source: Results and Discussion · p. 28
• ImgLib2’s uint12 type stores 12-bit detector samples in 12 bits rather than ImageJ 1.x’s 16, increasing space efficiency by 33%.Type- and container-agnostic algorithms also simplify code and can make it easier to optimize image storage.Source: Results and Discussion · p. 28

Scalability

• ImageJ2 supports scalable processing of datasets beyond available memory using cell images cached to mass storage, headless remote execution, and SCIFIO sample access.BigDataViewer, built on ImgLib2 cell images, enables visualization and exploration of massive datasets.Source: Results and Discussion · pp. 28–29

Results and Discussion

• The optimized single-threaded inplace ArrayImg op finished 7 times faster, and its multithreaded version 9 times faster, than the ImageJ 1.x addition command.The optimized ops were also comparable in efficiency to raw primitive-array operations.Source: Results and Discussion · p. 28, Figure 6 · p. 29

Compatibility

• ImageJ2 enables developers to combine ImageJ 1.x and ImageJ2 features, while backwards compatibility supports incremental migration that may take years as APIs mature.Parameterized commands and scripts can retain ImageJ 1.x structures and plugins while using ImageJ2 functionality; some existing plugins may never be updated.Source: Results and Discussion · pp. 29–31

Community

• ImageJ2’s wiki, forum, GitHub source and issue tracking support global contributions and help users understand plugin responsibilities, support status, bugs, and plans.These resources provide a social framework for managing community extensions throughout their development lifecycle.Source: Results and Discussion · p. 31

Future directions

• Remaining technical tasks include finalizing metadata support, broadening N-dimensional ROI coverage, making I/O plugin-driven, generalizing SCIFIO blocks, and completing launcher and documentation work.The data model is intended to attach metadata, including spatial metadata, that responds robustly to image transformations.Source: Future directions · pp. 31–32
• Future development includes a production-ready REST image server and web UI, expanded ImageJ Ops, bridges to other frameworks, cloud support, and improved user and community tools.The agenda also includes a friendlier updater, centralized resources, automated issue reporting, and continued responses to community requests.Source: Future directions · p. 32

Conclusions

• ImageJ2 addresses limits in analyzing modern datasets and adding functionality, while serving as an interoperable framework with a generalized data model and extensible plugin architecture.It remains open source and cross-platform, builds on existing ImageJ plugins, and supports a large collaborative community.Source: Conclusions · pp. 32–33

Availability of data and material

• The archived ImageJ2 release is net.imagej:imagej:2.0.0-rc-55, platform independent, written in Java, and licensed under the 2-clause BSD license.It requires Java 8 or higher, and the article includes all data generated or analyzed in the study.Source: Availability of data and material · p. 34

Competing interests

• The authors declare that they have no competing interests.Source: Competing interests · p. 34

Funding

• ImageJ2 received NIGMS and Wellcome Trust funding, while SCIFIO received National Science Foundation funding; additional support came from institutional sources.ImageJ2 funding included the Laboratory for Optical and Computational Instrumentation and the Morgridge Institute for Research.Source: Funding · p. 34

Authors’ contributions

• Contributors covered technical leadership and architecture, SCIFIO and legacy-layer development, ImageJ Ops and integration, manuscript editing, and project direction.All authors contributed to, read, and approved the final manuscript.Source: Authors’ contributions · p. 35

Figures and illustrations

• A parameterized script uses a UI dialog for name and age inputs, but headless command-line runs pass inputs as arguments and echo outputs to standard output.The figure panels show the script, UI, dialog, and headless execution contexts.Source: Figures and illustrations · p. 39, Figure S.1 · p. 39
• The supplemental figures present a time-performance comparison of ImageJ 1.x and ImgLib2 data structures and sample plugin usage in ImageJ 1.x and ImageJ2.Source: Figure S.2 · p. 39, Figure S.3 · p. 40

Tables and captions

• The supplemental tables catalog built-in SciJava input widgets, kinds and arities of special ops, and image types supported by ImageJ.Source: Table S.1 · p. 41, Table S.2 · p. 41, Table S.3 · p. 42