Multithread support

Any way to encourage ImageJ to multithread calculations?

Having a problem with performance issues on my PC. my images aren’t terribly large, only about 30-40 MB TIF files, but when I do certain commands, so far I have identified ROI Manager > OR as being consistent, I tax the poor hamster wheel running my PC. The computer freezes as CPU usage skyrockets to sustained 100% on a single core (everything except the mouse is frozen/non-responsive). Windows 7 Resource Monitor shows steady 25+% CPU usage (which makes sense for a 4th gen i7 using only one core instead of both cores or hyperthreading). Once it settles down a few minutes later, control is restored.

And as a related question, can you write macros/plugins to leverage multithreaded processing?

Good day,

here is my comment about your complaint …
(Will say, there are highly competent coders observing this forum who may answer you questions in more detail.)

If “ROI Manager > OR” is really blocking your PC and the PC isn’t 20 years old and you don’t have thousands of ROIs, I guess there are other reasons than ImageJ.

ImageJ-PlugIns are written in Java, hence it is up to you to make them multithreaded. I appears quite straightforward with Java but you have to take care of waiting and race conditions etc.

Several of the available PlugIns and even some of those that are part of ImageJ are in fact multithreaded. Since the code of ImageJ is freely available, a quick look at the code will reveal what’s going on.



I just got this brand new Dell from our IT dept a month ago as a replacement from my previous lease, but it isn’t sporting a brand new CPU. It’s 4th gen i7, which under most circumstances is enough hamster wheel power in the chassis to get through the task. Typically under 400 ROIs, all straight lines, which is why I am puzzled, image sizes are 26-28 MB 8 bit greyscale images, ImageJ is allocating 6 Gb out of the 8 Gb total system memory. Doesn’t matter if I turn off everything else in the background (anti-virus, Outlook, web browsers, kill all non-essential tasks and services, etc.), the result is the same. I used to be an IT guy that fixed slow computers, I’m familiar with the drill on diagnosing these conditions.

As I said, the CPU usage goes up exactly to 25% usage, which is conveniently 1 out of the 4 logical cores in an i7. Multi-threading wouldn’t stop the PC from freezing, it would just get through the task faster and return control back to the PC faster.

Again, I agree that it is incumbent on plugin writers to enable multi-threading their code, but this is the ROI manager, which is a core function of ImageJ, not a plugin. If this was my own plugin I would be the first to tell myself to go fly a kite. However, I haven’t seen a section in the ImageJ references on good code which includes multi-threading support, I’ve only seen generic Java examples on other sites regarding making your code multi-thread friendly.

On a list of critical things to fix on ImageJ, it still works, it’s not broken, but there’s something “rotten in the state of Denmark” as Hamlet said. If a software bug misbehaves, and there’s no one around to see it happen, was how are people supposed to know there’s a problem? Just reporting it to the community so people can be aware, maybe test it out and report back to see if they see the same issue…

That seems suspicious indeed.

Have you seen the If ImageJ freezes or hangs section of the Troubleshooting guide? In this case, it’s not a hard freeze (ImageJ recovers eventually), but the operation takes much longer than expected. So taking a stack trace might shed some light on where all the time is being spent. If you are feeling technically inclined, see also the relevant section of the Debugging page.

Regarding multithreading in general, it is a design goal of the ImageJ Ops project to make multithreading easy, and in many cases even automatic. Unfortunately, it will be quite some time before that design “trickles down” to all the end user functions of the ImageJ user interface. But I am happy to elaborate on the technical details if you feel it would be useful.

You might find the following ImageJ wiki articles interesting:

This again shows a common misunderstanding of the structure of ImageJ. Most of what you call “core function” is provided by PlugIns that are a characteristic for the modularity of ImageJ.

With respect to

could you please be more specific about your installation? Do you use plain ImageJ, Fiji, or ImageJ2 with which version of Java under which Windows-version.

I can’t remember similar complaints in the past month.

Good luck


1 Like

When ORing straight lines in the ROI manager, ImageJ 1.x converts them all to polygons.

I did not debug to confirm but I am suspicious that this is triggering a significant number of redraws (which can not be multithreaded since they are running on a dedicated graphics thread).

I believe a simple way to test this issue would be to run the RoiManager.OR function from a macro in Batch Mode, to avoid the intermediate redraws.


Good catch, Mark !

BTW, of course, I assumed batchmode( true ) …



Starting with the latest ImageJ daily build (1.50h5), the “OR” command in the ROI Manager displays a progress bar and runs on a separate thread. This command should no longer cause ImageJ to freeze since it no longer runs on the event dispatch thread. It still runs on a single thread because I do not see an easy way to make it multi-threaded.

1 Like