Headless ImageJ

[dscho]

Hello community,

recently the problem cropped up in a discussion with fellow developers,
how to run a batch macro on a machine (such as a node on a
cluster[*1*]...) that does not have any graphics environment installed.

[if you're interested only in the solution, you might want to skip forward
to the short explanation...]

<warning: detailed explanation on Java level follows>
At least on Linux, such a batch run will inevitably stop early, namely
when the class ij.Menus tries to instantiate a Menu. For some reason, it
seems, the Java developers decided in their infinite wisdom that a Menu
cannot live without a graphics environment. Even if you don't ever show
the Menu.

Oh, well.

I tried to get rid of the java.awt.Menu instances, but realized then, that
most plugins use a GenericDialog, which is directly derived from
java.awt.Dialog. An indeed, Java refuses to instantiate a Dialog (even if
it is never shown!) in the absence of a graphics environment.

But then, there _are_ plugins out in the wild, which depend on
GenericDialog to be derived from java.awt.Dialog, because they actually
update some preview or do other stuff that cannot be done directly with
the methods of the GenericDialog.

So there is the dilemma. Some plugins will not run _without_ GenericDialog
being a java.awt.Dialog, and headless operation will _not_ run _with_
GenericDialog being a java.awt.Dialog.
</warning>

A workaround, if you do not use any plugins that manipulate the
java.awt.Dialog directly (there are only a few out there, you know who you
are!), is to replace both ij.Menus and ij.gui.GenericDialog by classes
that will not instantiate anything graphical.

This workaround is available as "headless.jar", to be prepended to
the classpath, available from http://sourceforge.net/imageja/ in
binary form, or in source from from branch "headless" on
http://repo.or.cz/imageja.git.

Whew. That was a long explanation.

Short explanation:

To start a batch macro on a machine without graphics environment, you have
to download

http://downloads.sourceforge.net/imageja/headless.jar?use_mirror=osdn

and prepend the downloaded "headless.jar" to the classpath before ij.jar,
like this:

        java -classpath headless.jar:ij.jar ij.ImageJ -batch <macro>

On Windows, you have to replace the ":" between "headless.jar" and
"ij.jar" by a ";", although you are much more unlikely to run something
headlessly on Windows.

Somehow, I seem to be unable to come up with a better solution. If someone
has an idea how to do it in a less ugly way, please enlighten me.

Ciao,
Dscho

[*1*] ... and I mean a cluster here. Not something Microsoft conveniently
redefined to be a hot standby. No, a real cluster. Microsoft calls it a
grid. But it used to be called a cluster until recently.

[Wayne Rasband]

Another solution for this problem is to install Xvfb, the X window  
virtual framebuffer.

-wayne

On Jun 13, 2007, at 10:21 PM, Johannes Schindelin wrote:

> Hello community,
>
> recently the problem cropped up in a discussion with fellow  
> developers,
> how to run a batch macro on a machine (such as a node on a
> cluster[*1*]...) that does not have any graphics environment  
> installed.
>
> [if you're interested only in the solution, you might want to skip  
> forward
> to the short explanation...]
>
> <warning: detailed explanation on Java level follows>
> At least on Linux, such a batch run will inevitably stop early, namely
> when the class ij.Menus tries to instantiate a Menu. For some  
> reason, it
> seems, the Java developers decided in their infinite wisdom that a  
> Menu
> cannot live without a graphics environment. Even if you don't ever  
> show
> the Menu.
>
> Oh, well.
>
> I tried to get rid of the java.awt.Menu instances, but realized  
> then, that
> most plugins use a GenericDialog, which is directly derived from
> java.awt.Dialog. An indeed, Java refuses to instantiate a Dialog  
> (even if
> it is never shown!) in the absence of a graphics environment.
>
> But then, there _are_ plugins out in the wild, which depend on
> GenericDialog to be derived from java.awt.Dialog, because they  
> actually
> update some preview or do other stuff that cannot be done directly  
> with
> the methods of the GenericDialog.
>
> So there is the dilemma. Some plugins will not run _without_  
> GenericDialog
> being a java.awt.Dialog, and headless operation will _not_ run _with_
> GenericDialog being a java.awt.Dialog.
> </warning>
>
> A workaround, if you do not use any plugins that manipulate the
> java.awt.Dialog directly (there are only a few out there, you know  
> who you
> are!), is to replace both ij.Menus and ij.gui.GenericDialog by classes
> that will not instantiate anything graphical.
>
> This workaround is available as "headless.jar", to be prepended to
> the classpath, available from http://sourceforge.net/imageja/ in
> binary form, or in source from from branch "headless" on
> http://repo.or.cz/imageja.git.
>
> Whew. That was a long explanation.
>
> Short explanation:
>
> To start a batch macro on a machine without graphics environment,  
> you have
> to download
>
> http://downloads.sourceforge.net/imageja/headless.jar?use_mirror=osdn
>
> and prepend the downloaded "headless.jar" to the classpath before  
> ij.jar,
> like this:
>
> java -classpath headless.jar:ij.jar ij.ImageJ -batch <macro>
>
> On Windows, you have to replace the ":" between "headless.jar" and
> "ij.jar" by a ";", although you are much more unlikely to run  
> something
> headlessly on Windows.
>
> Somehow, I seem to be unable to come up with a better solution. If  
> someone
> has an idea how to do it in a less ugly way, please enlighten me.
>
> Ciao,
> Dscho
>
> [*1*] ... and I mean a cluster here. Not something Microsoft  
> conveniently
> redefined to be a hot standby. No, a real cluster. Microsoft calls  
> it a
> grid. But it used to be called a cluster until recently.

[Ben Woodcroft]

FYI Johannes both your sourceforge and git links were dead. You mean

http://sourceforge.net/projects/imageja

and

http://repo.or.cz/w/imageja.git

I believe.


On 6/14/07, Johannes Schindelin <[hidden email]> wrote:

>
> Hello community,
>
> recently the problem cropped up in a discussion with fellow developers,
> how to run a batch macro on a machine (such as a node on a
> cluster[*1*]...) that does not have any graphics environment installed.
>
> [if you're interested only in the solution, you might want to skip forward
> to the short explanation...]
>
> <warning: detailed explanation on Java level follows>
> At least on Linux, such a batch run will inevitably stop early, namely
> when the class ij.Menus tries to instantiate a Menu. For some reason, it
> seems, the Java developers decided in their infinite wisdom that a Menu
> cannot live without a graphics environment. Even if you don't ever show
> the Menu.
>
> Oh, well.
>
> I tried to get rid of the java.awt.Menu instances, but realized then, that
> most plugins use a GenericDialog, which is directly derived from
> java.awt.Dialog. An indeed, Java refuses to instantiate a Dialog (even if
> it is never shown!) in the absence of a graphics environment.
>
> But then, there _are_ plugins out in the wild, which depend on
> GenericDialog to be derived from java.awt.Dialog, because they actually
> update some preview or do other stuff that cannot be done directly with
> the methods of the GenericDialog.
>
> So there is the dilemma. Some plugins will not run _without_ GenericDialog
> being a java.awt.Dialog, and headless operation will _not_ run _with_
> GenericDialog being a java.awt.Dialog.
> </warning>
>
> A workaround, if you do not use any plugins that manipulate the
> java.awt.Dialog directly (there are only a few out there, you know who you
> are!), is to replace both ij.Menus and ij.gui.GenericDialog by classes
> that will not instantiate anything graphical.
>
> This workaround is available as "headless.jar", to be prepended to
> the classpath, available from http://sourceforge.net/imageja/ in
> binary form, or in source from from branch "headless" on
> http://repo.or.cz/imageja.git.
>
> Whew. That was a long explanation.
>
> Short explanation:
>
> To start a batch macro on a machine without graphics environment, you have
> to download
>
> http://downloads.sourceforge.net/imageja/headless.jar?use_mirror=osdn
>
> and prepend the downloaded "headless.jar" to the classpath before ij.jar,
> like this:
>
>         java -classpath headless.jar:ij.jar ij.ImageJ -batch <macro>
>
> On Windows, you have to replace the ":" between "headless.jar" and
> "ij.jar" by a ";", although you are much more unlikely to run something
> headlessly on Windows.
>
> Somehow, I seem to be unable to come up with a better solution. If someone
> has an idea how to do it in a less ugly way, please enlighten me.
>
> Ciao,
> Dscho
>
> [*1*] ... and I mean a cluster here. Not something Microsoft conveniently
> redefined to be a hot standby. No, a real cluster. Microsoft calls it a
> grid. But it used to be called a cluster until recently.
>

[dscho]

Hi,

On Thu, 14 Jun 2007, Ben Woodcroft wrote:

> FYI Johannes both your sourceforge and git links were dead. You mean
>
> http://sourceforge.net/projects/imageja
>
> and
>
> http://repo.or.cz/w/imageja.git
>
> I believe.

Oops. Thanks,
Dscho

[dscho]

Hi,

On Thu, 14 Jun 2007, Rasband Wayne wrote:

> Another solution for this problem is to install Xvfb, the X window
> virtual framebuffer.

This has three possible problems I see:

- on MacOSX, Java is based on Aqua, not X. But I have not yet checked if
  ImageJ can run headlessly on these. Will do so later today, and keep you
  posted.

- on many clusters, you do not have enough quota to install Xvfb.

- for some setups, there is no readily available Xvfb package (since a
  cluster is _meant_ to run without X11), and it can cause real trouble to
  compile it yourself for these, especially where gcc is not installed.

All in all, it feels not really clean, having to install a (virtual)
graphics environment, in order to run without (a non-virtual) one.

Ciao,
Dscho