BTW - we noticed that some IJ.run("command", args) work find without the
> GUI, while others will return a command not found error unless the GIU is
> Why is that?
It's probably because some ImageJ commands expect graphical output and so
need a graphics interface of some kind. You can get around this by fooling
the OS into thinking it is outputting to a valid display. We used xvfb
Why don't you save the Results table(s) instead? Do you really need to
display them as your code runs? If not, you can run ImageJ headless and
call from scripts. We did this a few years ago in a Debian environment
using the xvfb utility:
// Using ImageJ 1.48v, 64-bit. Runs "headless", called with a command such
// xvfb-run-safe ~/ImageJ/jre/bin/java -Xmx2048m -jar ~/ImageJ/ij.jar
// ~/ImageJ -batch CANAPI_HL.ijm arg1 arg2 > /dev/null &
# invoke with (e.g.,) xvfb-run-safe my_process args
# to avoid race conditions so long as no other users on your system are
also running xvfb.
# allow settings to be updated via environment
# assuming only one user will use this, let's put the locks in our own home
# avoids vulnerability to symlink attacks.
mkdir -p -- "$xvfb_lockdir" || exit
i=$xvfb_display_min # minimum display number
while (( i < xvfb_display_max )); do
if [ -f "/tmp/.X$i-lock" ]; then # still avoid an obvious open display
(( ++i )); continue
exec 5>"$xvfb_lockdir/$i" || continue # open a lockfile
if flock -x -n 5; then # try to lock it
exec xvfb-run --server-num="$i" "$@" || exit # if locked, run xvfb-run
(( i++ ))
done # end of xvfb-run-safe script
This way you can run many scripts simultaneously and collect the results by
having the Results Tables written out (and renamed if necessary). This
probably doesn't help you with Eclipse though.
> Hi Aryeh,
> BTW - we noticed that some IJ.run("command", args) work find
> without the GUI, while others will return a command not found
> error unless the GIU is launched.
> Why is that?
> It's probably because some ImageJ commands expect graphical output and
> so need a graphics interface of some kind. You can get around this by
> fooling the OS into thinking it is outputting to a valid display. We
> used xvfb under linux.
> Why don't you save the Results table(s) instead? Do you really need to
> display them as your code runs? If not, you can run ImageJ headless
> and call from scripts. We did this a few years ago in a Debian
> environment using the xvfb utility:
Some of the plugins that we run create the tables as a "side effect".
and we need to grab data from those tables. Also, in the end we want
people who are running stock Fiji on whatever OS (usually Windows) to
run the scripts from the script editor, so we do not want to do
something that will be OS dependent.
I do not mind launching the GUI, but it means that when I run it from
the script editor, I need to remove the code that launched the GUI
(since it is already launched). To do it right, I should learn how to
test for this, and launch the GUI only when needed.
Also, if we run the code again, without explicitly closing the GUI that
was opened, I will have two IJ frames open. If I close the main IJ
window before closing the various images that it opened, it appears that
these image are "orphaned", and cannot be closed without forcefully
killing various Jython processes that were spawned. All this makes
sense, but it leaves me with the feeling that I am not using the system
I started doing this in order to learn how to use a more powerful IDE,
and it has some nice conveniences, so I will muddle along
hopefully learn how to use it more effectively.
Faculty of Engineering
Bar Ilan University
Ramat Gan 52900 Israel