Unable to force single instance of FIJI/ImageJ

Hi there!

Every time I use the commandline interface to open a new image, I get a new instance of ImageJ/FIJI, regardless of whether there is an existing instance already open. This appears to be the opposite side of the problem detailed in this issue: Running multiple instances of ImageJ with Java 8 enabled.

To reproduce:

  1. In one terminal: <ImageJExecutable> <FilePath>
  2. In another terminal: <ImageJExecutable> <FilePath>

I’ve attempted to use the (undocumented?) flag --force-single-instance (from the issue linked to above), but it appears to have no effect.


  • Distribution: FIJI
  • OS: macOS Catalina
  • ImageJ version: 2.1.0/1.53c (build 5f23140693)
  • Java version: 8 (using the Java bundled with FIJI distribution)

Any tips for making certain only 1 instance of FIJI/ImageJ is launched?


Welcome to the forum, @gabeme!

It’s been awhile since I wrote that, but looking at the code, it appears there are several debug statements. Have you tried DEBUG=1 <ImageJExecutable> <FilePath> in the second terminal, to find out why the single instance logic isn’t taking effect? That could be helpful for troubleshooting.


An update while running in debug mode: in two separate terminals, I ran DEBUG=1 <ImageJExecutable> --force-single-instance <FilePath>. Note that I used two “different” files that are really the same exact file data, one a hardlink of the other with a different name.

In the first terminal, no surprise, I saw the following log output:

[DEBUG] Single instance mode ENABLED
[DEBUG] Invoking single instance logic.
[DEBUG] SingleInstance: starting server
[DEBUG] SingleInstance: server ready
[DEBUG] sendArguments: return false 

In the second terminal, I see the following log output:

[DEBUG] Single instance mode ENABLED
[DEBUG] Invoking single instance logic.
[DEBUG] sendArguments: Proxy[SingleInstance$ImageJInstance,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[](remote),objID:[8274aa2:17644a48ca6:-7fff, -6678379473892624374]]]]]
[DEBUG] publish(
	context = org.scijava.Context@3c0142fb
	consumed = false
	focus = false,null,null), called from non-EDT Thread:null
[DEBUG] sendArguments: return true 
[INFO] Detected existing ImageJ; passing arguments along
[DEBUG] publish(
	context = org.scijava.Context@3c0142fb
	consumed = false,null,null), called from non-EDT Thread:null
[DEBUG] Discovered user interface: net.imagej.legacy.ui.LegacyUI
[DEBUG] Discovered user interface: org.scijava.ui.swing.sdi.SwingSDIUI
[DEBUG] Discovered user interface: org.scijava.ui.awt.AWTUI
[DEBUG] Discovered user interface: org.scijava.ui.swing.mdi.SwingMdiUI
[DEBUG] Discovered user interface: org.scijava.ui.headless.HeadlessUI

At this point, the logs stop in the second terminal.

Graphically, I can see something interesting. In my macOS dock, there appear to be two Fiji instances running. On my desktop, both images are displayed, but the Fiji icon is still rendered with “Starting ImageJ…” frozen on top. And the interesting part: as I noted, the two files are really just one under the hood (created using a hardlink). The files, however, seem to have taken a different import path. The first OME TIFF (from the first terminal; for purposes of the screenshot below, is confusingly “2.ome.tiff”) is appearing correctly, with a scrubber underneath it for channels, and a separate scrubber for z-slices. The second OME TIFF (“1.ome.tiff”), however, only has 1 scrubber, with what appears to be a combination of channels and z-slices. I’ve attached a screenshot showing this.

1 Like

@ctrueden – Happy new year! Just a ping to see if you have any thoughts on what I posted above re: both the single-instance logic and the odd behavior noted with respect to the program opening the same OME TIFF in seemingly different ways.

Additionally, is this the correct forum for these types of questions, or would a Github issue be a better way to surface these questions/issues?

1 Like