# Fiji is ImageJ with the plugins already installed and kept current

> Fiji is a GPL licensed, batteries-included distribution of the ImageJ scientific image processing application, with a portable launcher and a large menu-organised plugin catalogue, and it compares to ImageJ the way Ubuntu compares to Linux. The repository is only the top-level project, since every component lives in its own repository.

**fiji/fiji** — A "batteries-included" distribution of ImageJ :battery:

- Repository: https://github.com/fiji/fiji
- Website: https://fiji.sc/
- Stars: 1,042 · Forks: 259
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/fiji-fiji

## Fiji is ImageJ the way Ubuntu is Linux

The README makes the comparison itself. Fiji is a batteries-included distribution of ImageJ, a popular, free scientific image processing application, which includes a lot of plugins organized into a coherent menu structure. Fiji compares to ImageJ as Ubuntu compares to Linux.

That analogy is the most efficient description of the project available, because it captures both the value and the boundary. Ubuntu is Linux plus a package manager, a coherent set of default applications and a maintained release cadence. Fiji is ImageJ plus a portable launcher and a menu structure that makes the bundled plugins findable. What you get is a working environment; what you do not get is a different imaging engine.

The main focus, as the README states it, is to assist research in life sciences, and that focus explains the shape of the distribution. The target audience is a scientist who wants to open a microscopy dataset and analyse it, and the distribution is assembled around that workflow rather than around a feature checklist.

The platform list is short and current: Windows arm64 and x64, Linux arm64 and x64, and macOS arm64 and x64. The presence of arm64 on all three is the notable part, since the Apple Silicon transition made a Java-heavy scientific application a common source of friction, and a distribution that ships arm64 builds removes that problem for a large share of new laptops.

The intent is stated as being the most painless, easy, quick and convenient way to install ImageJ and plugins and keep everything up to date.

## Installation is unpacking an archive and double-clicking the launcher

There is no installer and no package manager entry in the README. The setup is as easy as unpacking the portable archive and double-clicking the Fiji launcher, and the distribution is meant to be handed over without source so the download stays as small as possible. In the basic version, Fiji is a portable application, which means it should run wherever you copy it.

That portability is a real design constraint rather than a slogan. Because the whole environment is self-contained and relocatable, a researcher can copy a Fiji directory to a lab machine, put it on a USB drive, or hand it to a collaborator, and the plugin set travels with it. A system-wide installation of ImageJ plus a pile of manually installed plugins does not behave that way.

The launcher is the entry point and it does the setup work. The starting point is the Fiji launcher, which will launch Java, set up the environment, and call ImageJ or ImageJ2. Arguments are passed on the command line, and the convention for separating ImageJ arguments from Java Virtual Machine arguments is a double dash.

```bash
$ ./fiji -Xmx128m --
```

In other words, if you want to override the memory setting, you call Fiji like that, with the JVM options before the separator. Anything after the separator goes to ImageJ itself, and anything before it goes to the JVM. That single detail is the whole command line interface, which tells you the project is not aiming at automation.

The build badge in the README points to a GitHub Actions build workflow, and the site is fiji.sc, with the project site describing the downloads, the documentation and the update mechanism.

## One repository per component, with the main repo holding only the scaffolding

The most important structural fact about the Fiji project is that the repository you are reading is not the project. Fiji's source code is split up into a main repository, containing the top-level project and support scripts, while all components live in their own repositories in the Fiji organization on GitHub.

The convention is stated as a rule of thumb: the file name and the project name correspond pretty well, for example fiji-lib.jar is maintained in the fiji-lib repository. So the jar files you find in a Fiji installation map one to one onto the repositories in the organisation, and a plugin is a separate project with its own history, its own releases and its own maintainer.

The top-level entries in this repository reflect that split. The Contents/ directory holds the metadata that describes what goes into a distribution, and alongside it there are config/, images/, luts/, macros/, matlab/, plugins/, resources/ and scripts/ directories, plus bin/ and src/, a pom.xml for the Maven side of the build, a LICENSE.txt and a LICENSES file.

The luts/ directory is worth a word, because it is one of the things that distinguishes a scientific distribution from a plain one. A lookup table is the colour mapping that turns a raw 16-bit or 32-bit sensor image into something a human can read, and shipping a curated set of them is what makes a fresh install immediately usable on real data.

The build workflow in the README is what assembles the pieces. The main repository is the recipe, and the components are the ingredients, which is also why the same source tree produces builds for six platform and architecture combinations.

## The default licence is GPL v2, with exceptions listed in one file

The licensing story needs to be read carefully, and there is a wrinkle worth flagging.

The README says that the majority of Fiji is licensed under the GNU Public License version 2, with exceptions listed in the LICENSES file in the repository. The repository metadata, on the other hand, reports the licence as GPL-3.0, and the top-level file is named LICENSE.txt. So the metadata and the prose do not match, and the prose is the more informative of the two because it names the exception mechanism.

The reason a distribution like this needs an exception file is that a plugin collection pulls in code from many sources with different terms. When a scientist publishes a paper and shares the analysis scripts, the licence of the toolchain they used matters, and the practical question is which plugins carry terms other than GPL v2. The LICENSES file is where you would look, and it is one file rather than a per-plugin audit because the exceptions are recorded centrally.

The project is explicit about why it is open source, and the reasoning is aimed at exactly this audience. Open source allows other developers to port the application to new platforms that the original authors did not begin to think of, it allows scientists to study the code to understand the inner workings of the algorithms used, and it permits others to use the program in totally new ways and enhance it in all imaginable ways.

The last of those three is the one that separates Fiji from a closed tool. Being able to read the implementation of a segmentation or a measurement plugin is a real part of doing science with it, because the algorithm behind a published result has to be inspectable.

## Maintenance sits with LOCI, while ImageJ itself is Wayne Rasband's

The authors section separates the projects and their people, which is a useful thing for a user to know.

Fiji was created by Johannes Schindelin, who is the person behind the source-level tooling that most people know as dscho, and it is currently maintained by Curtis Rueden of LOCI at the University of Wisconsin-Madison. ImageJ was created and is maintained by Wayne Rasband, and ImageJ2 was created and is maintained by Curtis Rueden, so the same person maintains the modern rewrite and the distribution built on top of it.

The README thanks Rasband not only for being a dedicated ImageJ developer but for fostering an active and friendly community around it, and it thanks the community for being active, friendly and helpful to scientists understanding and analysing images every day. There is a developer chat badge pointing at a Zulip stream for the Fiji developers, and the Image.sc forum carries a tag for Fiji discussions.

The repository itself is not archived, the default branch is main, and the last push was on 2026-10-06, so the scaffolding and the support scripts are still being worked on. There are no GitHub releases for this repository, which is consistent with the model: the artefacts are the Fiji distributions assembled from many component repositories, and the update path for a user is the built-in updater rather than a versioned download of this tree.

That distinction matters when you evaluate the project. Nothing here is a frozen archive, but nothing here is also a single artefact you can pin. The component repositories are where versions actually move, and the update mechanism inside Fiji is what keeps a user on the current set.

## A GUI distribution is the wrong tool for a scripted pipeline

The realistic alternative is plain ImageJ, installed and configured by hand, with the plugins you need added one at a time. The difference in approach is exactly the Ubuntu to Linux comparison, applied in reverse.

Plain ImageJ gives you the same core application and none of the packaging work. You install it, you find the plugin jars yourself, you resolve their dependencies, you watch for version conflicts between plugins, and you repeat that on every machine. For a single researcher on a single machine who already has everything set up, that is a perfectly reasonable position, and it keeps you on the upstream application rather than a distribution.

Fiji wins when the plugin set is wide and the machines are many. The coherent menu structure means you do not have to know the name of a plugin to find it, the updater handles the dependency resolution that is otherwise your problem, and the portable layout means a colleague's machine can be brought up to the same state by copying a directory.

There is a third option that neither of these covers, and it is the limitation to hold in mind. Fiji is a desktop application with a launcher and a command line interface that consists of a memory flag and a separator. There is no documented scripting or headless mode in the README, so for a batch analysis pipeline where the same measurement runs over thousands of files, Fiji is not the instrument, and you would be back to driving ImageJ from a script yourself.

The other practical limit is the plugin catalogue itself. Because the plugins are separate projects with separate maintainers, the set is only as good as the health of each one, and a distribution that keeps a dozen of them current is doing real work on your behalf, but it is also work that depends on upstream people who are not the Fiji maintainers.

## Conclusion

Fiji fits a life sciences researcher or imaging scientist who wants ImageJ with a working plugin set rather than a bare install, on Windows, Linux or macOS across both x64 and arm64. It does not fit someone who wants to modify Fiji itself, since the top-level repository holds only the project and its support scripts, with every component elsewhere, and it does not suit a build pipeline that needs a pinned, source-based dependency. Before adopting it, read the LICENSES file for the exceptions to the default GPL v2 terms, check the platform list for your architecture, and use the launcher with the -- separator when you need to pass JVM options such as a memory override.

## FAQ

### What is Fiji and how does it relate to ImageJ?

Fiji is a batteries-included distribution of ImageJ that bundles a large set of plugins organised into a coherent menu structure, and the README compares it to ImageJ the way Ubuntu compares to Linux. Its focus is assisting research in life sciences, and it is intended to be the easiest way to install ImageJ and plugins and keep them up to date.

### How do I install Fiji and pass options to the JVM?

Unpack the portable archive and double-click the Fiji launcher, which starts Java, sets up the environment and calls ImageJ. To pass JVM arguments you separate them from the ImageJ arguments with a double dash, so overriding the memory setting looks like ./fiji -Xmx128m --.

### Which platforms does Fiji support?

The README lists Windows arm64 and x64, Linux arm64 and x64, and macOS arm64 and x64. Setup is by unpacking the portable archive, with no installation step required, and the distribution is designed to run wherever you copy it.

### What licence applies to Fiji and its plugins?

The README says the majority of Fiji is licensed under the GNU Public License version 2, with exceptions listed in the LICENSES file in the repository. The repository metadata reports GPL-3.0, so the LICENSES file is the place to check which components carry different terms.

### Where is the source code for Fiji components?

Only the top-level project and support scripts live in the main repository, while all components live in their own repositories in the Fiji organisation on GitHub. As a rule of thumb the file name and the project name correspond, so fiji-lib.jar is maintained in the fiji-lib repository.

## Sources

- [fiji/fiji on GitHub](https://github.com/fiji/fiji)
- [Issues](https://github.com/fiji/fiji/issues)
- [License: GPL-3.0](https://github.com/fiji/fiji/blob/main/LICENSE)
- [Project website](https://fiji.sc/)
- [README](https://github.com/fiji/fiji/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fiji-fiji