Better support for multi-screen setups in ImageJ/Fiji


Hi, I’ve made a few changes to ImageJ1 to better support multi-screen setups. Please see the list below.

I’d appreciate if you’d take a look and try it out. You can download the ImageJ1 Jar-File ij.jar and then do one of the following:

  1. Start ImageJ1 directly from the command line via java -jar ij.jar.
  2. Modify your Fiji by replacing the ImageJ1 Jar-File (currently ij-1.52n.jar) with the downloaded ij.jar. Please do this in the jars folder, e.g. /Applications/ if you’re on a Mac.

Main Changes

  • Reliably restore location of main ImageJ window and (first) image window
  • Placement of first image window is more predictable
  • Reliably determine the correct screen for a given location or window, for example to determine if a window can be enlarged for zooming in
  • If there is ambiguity about which screen to use, the one that contains the main ImageJ window will be chosen (e.g. for Plugins > Utilities > Capture Screen). Also, Window > Cascade and Window > Tile will rearrange all image windows on the screen with the main ImageJ window
  • Simplification, especially by removing special cases for Linux (didn’t break anything in my tests)



Hey @uschmidt83,

I just tested it and love it! It restores correctly main window and image window on my second screen (above my main laptop screen). Furthermore, a long lasting dream comes true: After disconnecting my secondary screen, windows open on my primary screen. Thanks for your efforts!


1 Like

Dear @Wayne,

I would be grateful if you could take a look at my pull request and let me know what you think.


1 Like

I will look at it. Where can I get the source code you used to generate the ij.jar file you made available?

1 Like

Thank you for the quick response.

Here are the actual changes that I made, and you can find the source code in this repository. Or simply download a Zip file with the code right here: (1.4 MB).



Tested it on my Mac laptop with a second screen on the right and a few things didn’t work as expected. When I move the “ImageJ” window to the second screen and press “n” (File>New>Image), the “New Image” dialog appears on the second screen but the image opens on the main screen. If I drag the image to the second screen and click on the maximize button, it is maximized on the main screen. In both of these cases, I would expect the image to stay on the second screen. I am using macOS 10.12.6 and Java 1.8.0_172.

1 Like

Thank you for testing, @Wayne!

When I move the “ImageJ” window to the second screen and press “n” (File>New>Image), the “New Image” dialog appears on the second screen but the image opens on the main screen.

The “New Image” dialog is modal and always appears on the same screen as its parent (either the current image window or the main ImageJ window). However, it was previously manually centered on the primary display by calling I have only changed to center a given window on the screen that it is currently on (and not always the primary screen).

Where the created blank image (or any opened image) appears depends on the location that is loaded from the preferences (IJ_Prefs.txt; this only applies to the first created image window).
This has previously been the case, I have just modified this to allow the location to be on any screen (not just the primary screen) and also check that the loaded location is valid on any of currently attached screens.

If I drag the image to the second screen and click on the maximize button, it is maximized on the main screen.

I can reproduce this on my Mac (with OS X 10.11.6), but this behavior/bug has already been there before I changed the code. However, I found what caused this problem and added another commit to the repository to fix it.



These changes are in the latest ImageJ daily build (1.52p2).


Thank you!

Looking at the changes you made to my code, I see that you opted to rather use the default screen in many situations. Fair enough.
If any issues or bugs arise due to my changes, feel free to reach out to me to address them.

PS: I have another (small) proposal to change the behavior of Image > Zoom > In [+] (changed lines of code and source code repository). We can also discuss this in a separate thread if you are willing to consider it.

Thanks again,


I tested this version and didn’t like the way zooming in changes the window aspect ratio and tends to fill the screen. It would be better if the aspect ratio didn’t change.


I understand and changed the code accordingly.



The updated Edit > Zoom > In [+] behavior, with aspect ratio preserved, is in the latest daily build (1.52p4).


Sorry to report that I do not think this is working properly.
In 1.52p6 under linux, when I zoom in, there is an unpredictable growth of the canvas depending on where the window is located. Eg zooming in the clown image located in the centre of the screen, when the canvas enlarges so it touches the bottom border of the screen, it carries on enlarging the image window vertically and pushes up the top (the window height increases!, but the x coordinate of the window position remains fixed. This results in the window changing position (upwards)
I think it would be best if the windows do not move.

With Java 6 it moves the window position while in the main or secondary screen, with Java 8 it moves when the window is in the secondary screen only.
With IJ 1.51 the moving of the window does not happen. I haven’t checked with other versions.

Also if I enlarge the window so it is larger than the image (white borders appear) when zooming in, it resizes it. Not sure if this was like this before, but the sudden resize results in the cursor not being on top of the image anymore.


This is probably a Java or window manager issue. Try the latest daily build (1.52p11). When zooming in, it maintains a margin at the bottom and right side of the screen.


Thanks for looking into it, but I am afraid that it does not solve it. Same issue as in the previous version.


Hi @gabriel and @Wayne,

I’m afraid my changes to the zoom-in had some more unintended consequences. For example, calling imp.getWindow().pack() in zoomIn will trigger a call to setSize, which will change dstWidth and dstHeight and thus influence the calculation of the maximum width and height in canEnlarge. For now, I vote to revert the changes to the state here.

(Difference to the 2019.04.27 (1.52p2; Multi-screen support) commit.)



The latest daily build (1.52p12) has the reverted version of zoomIn().


Dear @Wayne,

may I ask why you now disabled that the ImageJ window location can be restored to a secondary screen? Any why are all other restored locations also forced to go on the primary screen?


1 Like

The ImageJ window is restored to the primary screen to avoid having it “disappear” when the secondary screen is turned off. All you have to do is drag it to the secondary screen and all other windows will be restored to the secondary screen as long you are running 1.52p20 or later.


My code should’ve accounted for this. Conretely, GUI.getMaxWindowBounds(new Point(ijX, ijY)) should return null if the Point is not valid on any of the currently attached screens.

I will take a look once I can see the code.