- Will ImageJ1 macros, plugins and scripts still work in ImageJ2?
- What is the difference between ImageJ, ImageJ2, ImageJDev, ImageJX, ImageJA, etc.?
- How can we be sure that ImageJ1, ImageJ2 and Fiji aren't going to diverge or fork over time?
- Would it make sense to create a version of ImageJ for the web browser, mobile devices, etc.?
- How are you addressing the fact that with increased modularity comes increased complexity?
- With Oracle buying Sun and Apple deprecating Java, does Java have a future?
Yes. We are completely committed to 100% backwards compatibility with ImageJ1. ImageJ2 includes the latest version of ImageJ1 "under the hood" so that existing macros, plugins and scripts will still run the same as before.
We have even gone so far as to model the ImageJ2 user interface after ImageJ1 to a very large extent, with all the same shortcut keys and behaviors whenever possible. ImageJ2 looks and feels like ImageJ1, but with a powerful new infrastructure allowing it to process a wider variety of image data more quickly and easily.
There are a few different flavors of ImageJ with very similar names, and some confusion is inevitable. Below is a table which should help to clarify the purpose of each. For the historical context of these projects, see the History of ImageJ.
| Name | Author/Maintainer(s) | Description | Initiated | Status |
| ImageJ ImageJ1 | Wayne Rasband | The current, stable version is known simply as "ImageJ"—or sometimes "ImageJ1" or "IJ1" to differentiate it from ImageJ 2.0 (still in development). | 1997 | Active |
| ImageJ2 ImageJDev | ImageJ developers | The ImageJDev project (this web site and associated community) is developing version 2.0 of ImageJ, referred to as "ImageJ2" or "IJ2" for short. It is a complete rewrite of ImageJ, but includes ImageJ1 with a compatibility layer, so that old-style plugins and macros can run the same as in IJ1. | Dec. 2009 | Active |
| ImageJA | Johannes Schindelin |
ImageJA is a project that provides a clean Git History of the ImageJ 1.* branch, with a proper 'pom.xml' file so that it can be used with Maven without hassles. It is what Fiji uses (see below) at its core. | Jul. 2005 | Active |
| Fiji | Fiji contributors |
Fiji is Just ImageJ, with extras. It is a distribution of ImageJ with many plugins useful for image analysis in the life sciences, an automatic updater, and improved scripting capabilities. It is actively maintained, with updates released often. We recommend Fiji as the preferred version of ImageJ. | Dec. 2007 | Active |
| MBF_ImageJ | Tony Collins | The MBF "ImageJ for Microscopy" bundle (formerly WCIF_ImageJ) is a collection of plugins and macros, collated and organized by the MacBiophotonics facility. It goes hand in hand with a comprehensive manual describing how to use the bundle with light microscopy image data. It is a great resource by microscopists, for microscopists. However, it is not maintained as actively as Fiji is (see above). For the most part it is possible to add specific plugins from MBF_ImageJ to a Fiji installation, combining the best of both programs. | 2005 | Last update: Dec. 2009 |
| SalsaJ | EU-HOU | SalsaJ is a fork of ImageJ1 intended for use with professional astronomy images. It was designed to be used in classrooms, and has been localized into over 30 different languages. | Unknown | Last update: Feb. 2010 |
| ImageJ2x | Rawak Software | ImageJ2x is a fork of ImageJ1, modified to use a Swing interface. It does not appear to be under active development anymore. | Unknown | Last update: Oct. 2008 |
| ImageJX | Grant Harris | ImageJX was created as a means to discuss and explore improvements to ImageJ. There was an ImageJX mailing list as well as an ImageJX software prototype. The ImageJX software prototype was a proof of concept—an attempt to reorganize ImageJ's internals to make it more flexible. The prototype demonstrated this flexibility by recasting the program in Swing. The ImageJX project formed the basis of an application to NIH for funding, which is what launched the ImageJDev project (see above). | Mar. 2009 | Superceded by ImageJ2 |
| NIH Image | Wayne Rasband | NIH Image is a public domain image processing and analysis program for the Macintosh. It is the direct predecessor of ImageJ, and is no longer under active development (though see ImageSXM below). | 1993 or earlier | Superceded by ImageJ |
| ImageSXM | Steve Barrett | Image SXM is a version of NIH Image that has been extended to handle the loading, display and analysis of scanning microscope images. | May 1993 | Active |
We are working to create an architecture where the programs work together and preserve compatibility. Fiji is just ImageJ with extras, and ImageJ2 will include ImageJ1 as-is for maximum compatibility. We plan to upgrade Fiji's core to ImageJ2 as soon as it is ready. Most importantly, all involved developers are strongly dedicated to avoiding divergence—we are working closely with both Wayne Rasband and the Fiji team to ensure that ImageJDev represents a continuation of ImageJ and Fiji, rather than a project fork.
Ultimately a web version of ImageJ would be desirable for a number of reasons, but there are several substantial challenges with current technology. In particular, it would be difficult for a Javascript-based ImageJ to maintain compatibility with existing plugins, macros and scripts. For now, our goal is to produce a Java version of ImageJ2, while remaining cognizant of developments in the web applications domain, to reduce the difficulties of a web version at some future date.
We are developing ImageJ with a careful eye toward modularity, avoiding gratuitous dependencies—particularly on AWT, which is not available on most mobile devices. We hope this approach makes it easier to port ImageJ to additional platforms in the future.
The key idea is to provide sensible defaults (e.g., the big green Xerox button) as a way of dealing with complex software programs. We also embrace the philosophy of convention over configuration utilized by many large software projects in recent years.
Yes. Java is one of the most popular programming languages and still one of the top choices for high-performance, cross-platform applications. Oracle is unlikely to attempt to "kill" Java, but even if they tried they probably couldn't—OpenJDK is open source and there is a massive community of Java developers behind it. Now that Apple is partnering with Oracle and the OpenJDK community, we are likely to see Java on Mac OS X get better, not worse. Java's popularity will eventually wane, but not because of any company's actions now. Rather, as with any programming language, new technologies will emerge and gain popularity, over a course of many years.