A bug report is a reproducible set of steps describing a problem. They are a common communication medium between users and developers. Users willing to take the time to write helpful bug reports drive the development of ImageJ, making it a better product for everyone.

TL;DR Summary

Help
	Overview
	FAQ
	Troubleshooting
	How to write bug reports
	Report an issue
	Editing the ImageJ Wiki

Report the issue using the Report a Bug plugin (in the Help menu).
Provide a minimal, complete, verifiable example (MCVE).
Describe what you already tried.
Put as much effort into your question as you expect to be put into its response.

Be concise

Here are some quick tips for writing a shorter letter:

Use bullet points to summarize.
Do not inline lengthy logs; use Gist or Pastebin instead.
Use formatting such as emphasis and code snippets to make text easier to read.
Use link syntax instead of relying on URL autolinking.
Use footnotes [1] for lengthy asides.
Most importantly, provide a Minimal, Complete and Verifiable example (MCVE), ideally as a standalone project.

[1] For technical matters, "too much" information is certainly much preferred to "too little" information. But long paragraphs also break up the flow of information, and bog down an otherwise concise and clear bug report or question. So there is certainly a balance to be struck.

Why put effort into bug reports

For light reading, there are numerous guides and essays on how and why to write excellent bug reports. ImageJ users should be aware that the development community is diverse: from publicly-funded individuals and teams to scientists and user contributors. For a largely open-source community like this, there are several key points to consider when submitting a bug:

Teams developing open-source code are typically smaller and lack dedicated testing teams. Developers thus rely on an active and vocal community to provide feedback and guide the development process by identifying the areas in need of attention (complaint-driven development).
If you encounter a bug, it is likely interfering with your desired workflow and needs to be resolved quickly. The better the bug report, the faster a developer will be able to reproduce and address the issue. Poorly written bug reports are more likely to sit unanswered—not because developers see the issue as unimportant, rather that the time required to clarify the bug report itself presents a significant barrier when setting priorities within an overflowing schedule.
When you find a bug, it is unlikely that you are the only individual affected by it. By reporting a bug in a way that developers can understand, identify and resolve the issue, you are performing a necessary and valuable service to the entire ImageJ community.

Components of a complete bug report

There are three critical components in an ImageJ bug report. If a report is missing any of these components, its usefulness may be limited.

Environment information

ImageJ is a flexible and extensible platform, so the actual "ImageJ environment" can vary from user to user. A common misunderstanding in bug reports is to just report the version of the base ImageJ component (e.g. 1.49e). This is helpful, but says nothing about what plugins, update sites, etc... are in use.

Errors can appear in any component of the software, and in some cases two plugins might work individually but have some negative interaction with each other. Thus a complete view of the ImageJ environment is imperative. Fiji currently ships with a Report a Bug command; this will automatically populate the complete environment information and include it in the bugzilla report; this bug-reporting functionality will be migrated to core ImageJ soon.

Note that if you file a bug manually or are enquiring to a mailing list, you can still copy and paste the contents of the "Useful information about your system" text box from the Report a Bug dialog. It will be greatly appreciated.

Minimal and precise steps to reproduce

When we're in a hurry, it's easy to provide a brief overview a bug without actually describing how to reproduce the error. We are also prone to providing too much information, which can confuse the issue and discourage thorough reading.

The actual text of your bug report should succinctly describe the fewest steps possible to reproduce your issue. For example:

1) Open sample image "blobs"

2) Run auto-threshold command

3) Run subtract background command

At this point, an evil kraken appears and sinks my hard drive.

Additional information is typically unnecessary... if a developer can reproduce the problem, they will do their best to fix it.

Sample data

Developers typically have a cache of sample data for testing their application. That said, we are still striving to reproduce the original environment of the error. Having the original image that caused the error is the best possible way to test.

If your test data is small and public, you can typically attach it to the bug report.

The easiest and safest way to provide sample data is via the Help › Upload Sample Image command. This sends the image to a private space accessible only by trusted developers. This allows proprietary data to be tested without fear of public distribution.

Note: if you do upload sample data via ImageJ, you should mention the name of the dataset in your bug report. This will help developers find your image(s) quickly.

For bugs working with excessively large datasets, you may need to communicate with a developer to determine the best way to test on your data.

While you're waiting...

If you have encountered and reported a bug that is completely blocking your work, you still have options available while waiting for the issue to be resolved.

Disable SCIFIO

ImageJ2 provides an alternative to the hard-coded case logic of ImageJ 1.x's image I/O: SCIFIO, plugin-based image I/O. While SCIFIO is more powerful, due to the vast scope of the overhaul, there are inevitably issues remaining. If your dataset used to open correctly for you, but is broken after updating, please disable the "Use SCIFIO when opening files (BETA!)" option in the Edit › Options › ImageJ2 dialog. This will revert to ImageJ 1.x's classic image I/O until the SCIFIO-driven I/O is fixed or improved.

Note: even if disabling SCIFIO fixes the issue for you, please still report the discovered bug. The long-term vision for ImageJ is to migrate completely to the new image I/O paradigm, so if there are problems we need to know about them.

Disable problematic update sites

The Report a Bug dialog provides several pieces of critical information. Some of the most important being:

Activated update sites
Files not up-to-date

The default update sites are intended to be fairly stable, but if you have additional update sites enabled there can be a risk of skewed or out of date dependencies (due to changes in core libraries), and some update sites are intentionally experimental.

Furthermore, if you have any LOCAL_ONLY or MODIFIED files, their behavior can not be guaranteed - as they do not match what's on the active update sites and thus can not be automatically updated in response to changes in their dependencies.

In cases where it is clear which class or classes are causing problems, you can do remove the offending component as follows:

If the problem is in an external plugin, simply delete the file(s).

If the problem is with an update site:

If necessary, identify the jar containing the problematic class(es), e.g. by using Plugins › Utilities › Find Jar for Class in Fiji.
Start the updater with Help › Update...
Switch to Advanced Mode
Search for the problematic components. Their associated update site will be listed here.
Select Manage Update Sites and disable the update site identified in 4.
Repeat 1-5 until your problem is resolved.

NOTICE: During this process it is critical to keep in mind that update sites take precedence in the order they are declared - update sites lower on the list will overwrite components in sites higher on the list.

Binary search through your external plugins

If it is not clear which update sites or external plugins are causing problems in your installation, a simple technique to help identify the cause of your problem is a binary search. The general procedure is such:

Start from your current installation
Remove half of your non-core update sites and/or local plugins.
Test to see if the erroneous behavior is resolved.
Repeat from 1) with only the "bad" pool of update sites/plugins enabled.

With this method you will continue to reduce your list of potentially bad candidates by 1/2, until you find the culprit(s).

Note: if the "erroneous behavior" is catastrophic to the point you can not start ImageJ, you can instead start from a clean build and re-introduce update sites and local plugins as detailed above until the problem is identified.

Catastrophic failure

We maintain lifeline ImageJ distributions on the Downloads page. You can use these until any outstanding issues are resolved.

ImageJ

Bug reporting best practices

Contents