Skip to main content

Frequently Asked Questions

One core principle of the scientific method is repeatability: the ability to continually retest and refine hypotheses. As computer software plays an increasingly large role in science, it is vital that that software be fully transparent and available to researchers: software is simply too complex to be easily reproduced from scratch by every research group. In contrast, closed source software presents a barrier to open research, because the implementation details of algorithms cannot be freely modified or even necessarily verified.

The Science Code Manifesto provides a clear and succinct list of five principles surrounding scientific software. There have also been a number of publications in recent years discussing these issues and ideas:

Further, we strive for ImageJ to be a community driven project. It is not merely an open source product, but an open source process. ImageJ follows open development practices, and provides open development tools online:

Using these resources, you can always observe the latest progress of the project, get an idea of where the project is heading, contribute code to the project yourself using GitHub, or write documentation, tutorials and other information on the wiki.

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.

Wayne RasbandThe current, stable version is known simply as "ImageJ"—or sometimes "ImageJ1" or "IJ1" to differentiate it from ImageJ 2.x, which is still in beta.
ImageJ developers
ImageJ 2.x, referred to as "ImageJ2" or "IJ2" for short, is currently in development. 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. 2009Active
ImageJAJohannes Schindelin

ImageJA is a project that provides a clean Git History of ImageJ1, 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. 2005Active
FijiFiji 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. 2007Active
MBF ImageJTony 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 went hand in hand with a comprehensive manual describing how to use the bundle with light microscopy image data. It was a great resource by microscopists, for microscopists. Unfortunately, the manual went offline in late 2012. Nonetheless, it is often possible to add specific plugins from MBF ImageJ to a Fiji installation, combining the best of both programs.

(Last update:
Dec. 2009)
ImageJ2xRawak SoftwareImageJ2x is a fork of ImageJ1, modified to use a Swing interface.
Last update:
Sep. 2012
SalsaJEU-HOUSalsaJ is a closed-source 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.UnknownLast update:
Aug. 2012
ImageJXGrant 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. 2009Superceded by ImageJ2
NIH ImageWayne RasbandNIH 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 earlierSuperceded by ImageJ
ImageSXMSteve BarrettImage SXM is a version of NIH Image that has been extended to handle the loading, display and analysis of scanning microscope images.May 1993Active

We are working to create an architecture where the programs work together and preserve compatibility. Fiji is just ImageJ with extras, and ImageJ2 includes 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.

Fiji and ImageJ2 are fundamentally the same software, using the same launcher. However, if you download Fiji from and run it, it starts up in ImageJ1 mode at the moment. But Fiji includes ImageJ2 too, and you can launch it in that mode instead if you prefer—or switch to ImageJ2 mode after launching using the "Switch to Modern Mode" command under the Help menu.

From the standpoint of development effort, the ImageJ2 and Fiji projects have indeed merged. ImageJ2 is the core software, and several pieces of infrastructure originally developed for Fiji have now migrated to ImageJ2 (e.g., the Updater, Launcher and Script Editor components). At heart, Fiji is now a big collection of life sciences plugins (though "Fijabcolsp" doesn't have quite the same ring to it). In other words, Fiji is just an ImageJ update site ("Fijius")—and as such, you can obtain a working Fiji installation by downloading ImageJ2, running the updater, and enabling the Fiji update site.

Ultimately, we probably do not want to get rid of the two distinct web sites and project names, since people are familiar with both. That said, we are integrating resources when feasible: e.g., the ImageJ wiki and the Fiji wiki are really both the same wiki with different skins, to make cross-linking more seamless. But we want to ensure it is clear that ImageJ2 is not a life-sciences-specific project, whereas Fiji is. Historically, because Fiji has a life sciences focus, there have been some users who refused to switch from vanilla ImageJ1 to Fiji even though Fiji makes users' lives easier in lots of ways. With ImageJ2, we want to avoid such misconceptions.

More effort is still needed to clarify web resources, to explain concisely and clearly where people should go in different circumstances. We also have plans to make bug reporting simpler and easier across the projects.

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.

As of December 2013, around 25% of Mac OS X systems still run version 10.6 Snow Leopard or older [1]. Unfortunately, Apple and the OpenJDK developer community decided to target OS X 10.7 Lion and above for Java 7. For the time being, to avoid abandoning older machines which cannot be upgraded from Snow Leopard, ImageJ continues to target Java 6.

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.

We have managed to create an almost-totally-compatible Beanshell version of the ImageJ1 macro language. As of this writing, it still needs a bit more work, but we believe that most ImageJ1 macros will run unchanged in ImageJ2, while also allowing to mix and match any Java API calls—something that was previously not possible with the macro language.

The ImageJ1 macro language has been extremely useful to many users. However, it has a substantial limitation: its functions are separate from those available from Java and the other scripting languages. In ImageJ2 the goal is to provide one unified set of functions, which is fully accessible from Java and all scripting languages. The Beanshell-based macro language helps to meet that goal, and also makes the reverse possible: calling macro functions from other scripting languages and from Java.

ImageJ2 plugins and scripts are more flexible than ImageJ1 plugins and macros. They can run headless on a server, and are accessible from various applications such as CellProfiler, KNIME, OMERO, and headless from the command line. We would encourage newly developed scripts and plugins to use the ImageJ2 API since it offers these advantages, but the ImageJ1 API will remain accessible, too.

If your software is written in Java, we recommend using Maven to structure your project. You can then add dependencies to portions of ImageJ that are of interest to you. See the ImageJ tutorials for examples.

If your software is written in another language such as C++ or Python, there are many ways to integrate Java functionality. You must choose which one is best for your particular requirements.

To facilitate some use cases, we provide a script for generating a combined bundle of all ImageJ-related JARs in a single "uber-JAR" library. To use, check out the ImageJ source code and execute:


For convenience, we provide a build of this combined JAR file from the latest DEVELOPMENT, UNSTABLE version of ImageJ:


This build includes the latest changes on the master branch of the source repository. It has not been thoroughly tested and may contain new bugs.

In some cases, use of this JAR file is appropriate and convenient; for example, CellProfiler uses it to integrate with ImageJ. However, you should consider carefully what would be best for your project:

Advantages: A single JAR file is simpler to deploy. There is no chance of mismatched versions of multiple JAR files. It is easier to construct a Java classpath, since only a single JAR needs to be included.


  • Every time you need to update the version of ImageJ, you must redeploy the entire uber-JAR (~48 MB as of October 2013). If you bundle individual JAR components, you need only update those that changed. This issue is of particular relevant to Java applications deployed via Java Web Start, since it automatically downloads the latest available version of each JAR dependency; in that case, your application startup time will suffer if you use the uber-JAR.
  • You cannot cherry-pick only the JARs containing the functionality you need, so your application's footprint may suffer from bloat.
  • If you rely on any of the same dependencies that ImageJ does, you may run into trouble (e.g., NoSuchMethodErrors) with multiple copies of those dependencies on your classpath, especially if you need to use a different version of that dependency than is bundled with the uber-JAR.

As you can see, it is important to understand how use of the uber-JAR will affect your application. In particular, Java applications will likely be better served using the individual component JARs, ideally managed using a dependency management platform such as Maven or Ivy. But for non-Java applications, the uber-JAR may be sufficient to your needs.

Yes, although it is not recommended. You will lose most of the advantages of ImageJ2 if you embed calls to ImageJ1 within your command. ImageJ1 is rather tightly coupled to AWT and hence does not work well headless. For details, see the Headless wiki page for details.
Yes, see the call-modern-from-legacy tutorial example.

We recommend running ImageJ using Java 6 rather than Java 7, since Java 6 is more stable. Unfortunately, newer versions of OS X come without Java installed, and only Java 7 is available from

However, you can reinstall Java 6 on OS X. You must log in to with your Apple ID, search for "java" and download the latest Java 6 SE.

At any time, you can verify which Javas are installed on your system using this script.

The first thing to do is make sure that ImageJ has a large enough "maximum heap" size:

  • Edit > Options > Memory & Threads
  • Change "Maximum Memory" to something larger (at most, 1000 MB less than your computer's total RAM).

Note that if you downloaded ImageJ recently (or are using the Fiji distribution of ImageJ), the ImageJ launcher will already have guessed at a reasonable value: ~75% of physical RAM.

If you are already at the limits of your computer's physical memory, the next step would be to add more.

About Java garbage collection: Java always automatically calls the garbage collector when the heap is getting full [1]. While it is possible to manually invoke the garbage collector by clicking ImageJ's status bar—or programmatically by calling run("Collect Garbage") in a macro or System.gc() in a plugin—it will not solve the fundamental problem of Java actually not having a sufficient amount of memory. (The only exception to this is a rare case where Java decides that garbage collection is happening too slowly, in which case you should see the message "GC overhead limit exceeded" [2]).

If you are looking to call ImageJ code from your MATLAB script, it is actually quite simple. Just embed the calls to fully qualified Java class methods directly in your scripts. MATLAB takes care of transparently converting between Java primitive types and arrays and its own matrices and cell structures. The Fiji distribution of ImageJ provides a helper program called Miji to simplify this approach even further. See the Miji page for further details.

Conversely, if you are looking to evaluate MATLAB code from within an ImageJ plugin or other Java code, MATLAB provides an interface called JMI for doing it. However, for it to work, you must launch your program from inside the MATLAB environment, so that it runs with MATLAB's JVM.

One easy way is to launch with the DEBUG environment variable set:

On Linux (from a console):


On OS X (from Terminal):

DEBUG=1 /Applications/

On Windows: Add DEBUG to your environment variables, then run ImageJ as usual. You may need to log out and back in again first though.

More control: You can control the log level more precisely by setting the scijava.log.level system property. E.g., on Linux:

$HOME/ -Dscijava.log.level=trace --

Valid levels include: none, error, warn, info, debug and trace.

Debugging the launcher: You can rename the executable from ImageJ-xxx to debug before launching, and the launcher will be more verbose about what it is doing.