ImageJ

2014 was a huge year for ImageJ core development!

A stable ImageJ2 application. Over the first half of the year, we fixed many bugs in ImageJ2, with the goal of a stable release of the ImageJ2 application in June. To reflect this, we promoted the “2.0.0-beta-X” numbering series to “2.0.0-rc-X” where “rc” stands for “release candidate.” The ImageJ2 application is now largely stabilized, although some components of ImageJ2, such as its N-dimensional image data model, still remain in beta. And the Fiji distribution of ImageJ is now fully built on top of ImageJ2. We believe the current design and component structure of ImageJ2 is fundamentally sound and stable, including the mechanism by which backwards compatibility with ImageJ 1.x is achieved. 2015 will turn its focus toward more bug-fixes and improvements of the next-generation ImageJ2 libraries themselves, and an easier, better documented migration path for software developers from ImageJ 1.x to ImageJ2 APIs.

Hackathons. In 2014, the ImageJ team participated in six different hackathons: collaborative coding sprints intended to make rapid progress on targeted issues. Four of the hackathons took place at LOCI in Madison, Wisconsin in the USA, and the other two in Konstanz and Wiesbaden, Germany. The ImageJ Ops project was born and grew thanks to these efforts, and the ImgLib2 stable release was accomplished at a hackathon as well. We also made progress on several related projects, including ImageJ-OMERO, Micro-Manager and OpenSPIM, and KNIME Image Processing.

Birth and growth of ImageJ Ops. The ImageJ Ops component was born at a hackathon in March 2014 at the University of Konstanz, in an effort to create a common image processing framework and library of operations which we could reuse and extend across many SciJava applications including ImageJ, KNIME, CellProfiler, OMERO and others. Many of the ideas of Ops have germinated for years across several design iterations: the KNIME/ImageJ Ops collaboration began as “ImgLib2 OPS” in early 2012 before being recast with an improved design as ImageJ Ops last March. Since then, the project has grown in controlled bursts as the people involved make time to focus on it, and the results so far are enormously exciting. Built on ImgLib2, the Ops project seeks to provide a “write once, run anywhere” solution to image processing algorithms, while still enabling targeted performance optimization for special cases. Expect new functionality and growth from the Ops effort throughout 2015.

ImgLib2 release. In October, the core ImgLib2 library reached stable release status, with version 2.0.0 released to Maven Central. This goal was the product of a very successful ImgLib2 hackathon at LOCI earlier that month. However, the updated ImgLib2 necessitated an across-the-board upgrade of many core ImageJ2 and Fiji components, which took two more months of infrastructural effort to complete, with the formal release announcement finally made in December.

Reproducible builds. This past autumn, the Fiji distribution of ImageJ for the life sciences was updated across all its components (more than 100) to use release version dependencies across the board, to achieve reproducible builds.

• We discovered than many Fiji component “releases” were not actually reproducible, due to their reliance on non-release dependencies. We improved the core SciJava build process to detect this situation and issue an error, to prevent such “tainted releases” in the future.
• We issued untainted releases for all components of Fiji. This was a vital step toward convergence of the Fiji update site (what users get when they run Help  › Update...) with the Fiji source repository (what developers get when they build Fiji from source).
• As part of this work, the BigDataViewer became part of the core Fiji update site!
• We established a formal process for a plugin to be included on the core Fiji update site. This document is one of several new articles on the wiki intended to document and clarify how ImageJ development works at various levels: philosophically, technically, socially and legally. We also expanded the wiki's plugin development guides, including an article on how to contribute to an existing plugin or library as well as one on the best ways to distribute your plugin to users.

Project-wide component standardization. 2014 saw a huge push toward final component organization and structure, across the SciJava, ImageJ, ImgLib2 and SCIFIO organizations on GitHub. Each component now lives in its own Git repository, is named in a standard way, and follows the same rules for versioning. The structure of ImageJ is now stable, and documented on the wiki’s Architecture page.

Better and more stable developer tools. Relatedly, we have made many improvements to the build infrastructure of the ImageJ software stack. We now have stable and documented tool-assisted processes for the development and release of SciJava software components, throughout all levels. The site status.imagej.net shows the status of each component’s source code, and in particular answers the question: have there been any changes since the last release? We also created the site javadoc.imagej.net which provides a central resource for Java API documentation across all components of the SciJava component collection, as well as common dependencies.

Web site improvements and unification. The ImageJ project previously had several different web sites (developer.imagej.net, wiki.imagej.net and mirror.imagej.net), which have now been unified to a single central information hub: imagej.net. The site is primarily a community-editable wiki, but also mirrors all ImageJ 1.x content as well. The old ImageJ2 development site is almost completely migrated to imagej.net now.

What’s next? 2015 began with a large and hugely successful 10-day hackathon in Konstanz. It is clear from discussions with other developers there that: A) the ImageJ2 software stack has gotten really usable now; and B) 2015 will see a renewed focus on software development. The tools and infrastructure are still not perfect, but they are good enough for everyday use. We must continue to stabilize the layers of SciJava “from the ground up”: the bottom-most library, SciJava Common, had its first release to Maven Central last February, and the ImgLib2 library was released to Maven Central in October. So this year will focus on stabilizing big-ticket features in the “middle” levels of the ImageJ software stack: 1) the ImageJ2 data model in the ImageJ Common component; 2) the ImageJ Ops library for reusable image processing algorithms; and 3) the SCIFIO library for image I/O. Once these components have stable 1.0.0 releases, ImageJ2 will have a fully mature codebase.

Some of the foremost plans for the coming year include:

• A unified SciJava I/O package, with many classes migrating upstream from SCIFIO and updated to the SciJava paradigm.
• Another major development iteration of the ImageJ2 data model. Late last year achieved a major unification and streamlining of ImageJ Common’s metadata-rich image API, but there is still more left to do. The overarching vision is for ImgLib2 to provide the low-level N-dimensional core API, while ImageJ offers a set of metadata-rich functionality on top.
• A continued push on ImageJ Ops. In particular, a powerful image expression parser, many more image processing algorithms, and other ease-of-use enhancements for users to make it dirt simple to perform powerful image processing workflows.
• Major SCIFIO performance improvements. We are actively making progress on this project every day.
• More interoperability improvements between key SciJava tools: ImageJ, KNIME, CellProfiler, OMERO.
• Usability improvements to the ImageJ application:
  • ImageJ Console window which shows all stdout and stderr output, but only pops up automatically when there are actual errors.
  • A graphical troubleshooter that helps report bugs when things go wrong, and offers advice on solutions to common problems such as images which appear all black. No talking paperclip, though.
• Further work on the ImageJ web site:
  • A stable download of ImageJ2 without the Fiji components.
  • Migrate the remaining Trac tickets to GitHub issues in the appropriate places.
  • Migrate the remaining developer.imagej.net pages to the ImageJ wiki.
  • Improve the navigation of the ImageJ wiki. Three calls to action: Learn about ImageJ, Use ImageJ, Develop for ImageJ.

Here’s to a productive and successful 2015!