embedding ImageJ in DICOM viewer/editor

[Kevin Archie]

I've been working on a DICOM viewer and editor that uses ImageJ to
display the pixel data.  Right now, I'm just creating an ImageJ instance
in my Java code, which is nice because then I can have my code assemble
ImagePlus objects from whatever DICOM files the user selects, then hand
them off to ImageJ for viewing and manipulating the images.

 

What isn't so nice is that ImageJ doesn't seem to be set up to be
embedded in another application (except as an applet); in particular, I
don't want it to create a SocketListener (for an assortment of reasons),
and I don't want to it to call System.exit when it closes, UNLESS all my
other windows have closed, in which case I do want to tell ImageJ to
exit when it's done.  All of this is pretty easy to do - just a few
lines changed in ImageJ.java - but I'd really prefer to be able to use a
stock ij.jar rather than branching off (which always leads to headaches
months or years down the line).

 

Two possibilities come to mind: I'm an ImageJ novice, so maybe I'm just
doing this all wrong.  Maybe instead of embedding, I should be running
ImageJ in its own JVM (note that platform independence is important for
us) and telling it somehow which DICOM files I want loaded into which
stacks.  Alternatively, maybe I'm doing this essentially right, in which
case it would be nice to make ImageJ more friendly to embed in the
general case.  Obviously I have some ideas about what changes would be
necessary, though someone who actually knows ImageJ would make better
decisions than I have.

 

Comments from ImageJ experts would be greatly appreciated.  I've
included a diff against ImageJ.java (from 1.38j) to illustrate the
changes I've made.  Also, the viewer, which may be of interest to anyone
using DICOM files, is available at
http://nrg.wustl.edu/projects/DICOM/DicomBrowser.jsp (source available
at http://nrg.wustl.edu/viewvc)

 

Thanks!

  - Kevin



70c70

<          public static final String VERSION = "1.38j-DicomBrowser";

---

>          public static final String VERSION = "1.38j";

98,101d97

<     public ImageJ(java.applet.Applet applet) {

<          this(applet, false);

<     }

<

104c100

<          public ImageJ(java.applet.Applet applet, boolean
isStandalone) {

---

>          public ImageJ(java.applet.Applet applet) {

107,109d102

<                      if (isStandalone && applet != null)

<                          throw new IllegalArgumentException("ImageJ in
applet is not standalone");

<

170c163

<                      if (isStandalone)

---

>                      if (applet==null)

433,437c426

<

<     public void setExitWhenQuitting(final boolean ewq) {

<          exitWhenQuitting = ewq;

<     }

<

---

>          

[Albert Cardona]

Kevin,

I agree that the GUI-making and the app-launching code should be
separate, so that one can be called independently of the other (keep in
mind you are looking at the eldest class of ImageJ,  dating back to when
it was an experimental applet). Perhaps Wayne will see value in it and
implement it.

In the meanwhile, if your new 'isStandAlone' flag is not included, you
can always set the 'exitWhenQuitting' flag to false with reflection:

    Field f = ImageJ.class.getDeclaredField("exitWhenQuitting");
    f.setAccessible(true);
    f.set(IJ.getInstance(), new Boolean(true));


Remember you can setup a sed script that edits your ImageJ.java file to
include the changes you need when updating your embedded ij.jar. Yes,
hackerous, but if you are going to be releasing the ij.jar anyway with
your app then it shouldn't be such a problem.


Albert

[Johannes Hermen]

ImageJ Interest Group <[hidden email]> wrote on 02.03.2007 06:12:08
PM:

> I've been working on a DICOM viewer and editor that uses ImageJ to
> display the pixel data.  Right now, I'm just creating an ImageJ instance
> in my Java code, which is nice because then I can have my code assemble
> ImagePlus objects from whatever DICOM files the user selects, then hand
> them off to ImageJ for viewing and manipulating the images.

We have been working on a small DICOM Viewer on top of ImageJ in our
research center too.
We use our own component to show/zoom/window the DICOM  images, but have
the posibillity to open the files in ImageJ to do some extra operations.

What we do is to create an ImageJ instance in the code too, but i can't
reproduce your problem that if ImageJ is closed, the whole application is
closed. Maybe the part of my code might help you.

----------snip--------------------------------------------------
this.actionOpenImageJ = new AbstractAction("open in ImageJ",
Icons.getIcon(Icons.ACTION_IMAGEJ)) {
                        private static final long serialVersionUID = 1L;
                        private ImageJ m_ImageJ;
                        public void actionPerformed(ActionEvent e) {
                                      if (m_ImageJ == null) {
                                          m_ImageJ = new ImageJ();
                                          m_ImageJ.setVisible(false);
                                      }
                                      if (image != null) {
                                        WindowManager.addWindow(new
ImageWindow(new ImagePlus("Optimage
debug",image.getProcessor().duplicate())));
                                      }
                                      m_ImageJ.setVisible(true);
                        }
                };
----------snap--------------------------------------------------

You can find our viewer at:
http://santec.tudor.lu/projects/optimage/dicomtools/

P.S. The viewer is still a beta version which was build for our internal
projects. There are still some bugs and missing features in it.


Greets
        Johannes

-----------------------------------------------------------------
Johannes Hermen  -  Ingenieur de Recherche
[hidden email]
-----------------------------------------------------------------
CRP Henri Tudor  http://www.santec.tudor.lu
29, Avenue John F. Kennedy
L-1855 Luxembourg
-----------------------------------------------------------------

[Wayne Rasband]

With ImageJ 1.38l and later, create an ImageJ frame using

     ImageJ ij = new ImageJ(null, ImageJ.EMBEDDED);

and ImageJ will not start the SocketListener. V1.38l also adds a public
exitWhenQuitting(boolean) method that determines whether or not
System.exit is called when ImageJ quits.

-wayne

> I've been working on a DICOM viewer and editor that uses ImageJ to
> display the pixel data.  Right now, I'm just creating an ImageJ
> instance
> in my Java code, which is nice because then I can have my code assemble
> ImagePlus objects from whatever DICOM files the user selects, then hand
> them off to ImageJ for viewing and manipulating the images.
>
> What isn't so nice is that ImageJ doesn't seem to be set up to be
> embedded in another application (except as an applet); in particular, I
> don't want it to create a SocketListener (for an assortment of
> reasons),
> and I don't want to it to call System.exit when it closes, UNLESS all
> my
> other windows have closed, in which case I do want to tell ImageJ to
> exit when it's done.  All of this is pretty easy to do - just a few
> lines changed in ImageJ.java - but I'd really prefer to be able to use
> a
> stock ij.jar rather than branching off (which always leads to headaches
> months or years down the line).
>
> Two possibilities come to mind: I'm an ImageJ novice, so maybe I'm just
> doing this all wrong.  Maybe instead of embedding, I should be running
> ImageJ in its own JVM (note that platform independence is important for
> us) and telling it somehow which DICOM files I want loaded into which
> stacks.  Alternatively, maybe I'm doing this essentially right, in
> which
> case it would be nice to make ImageJ more friendly to embed in the
> general case.  Obviously I have some ideas about what changes would be
> necessary, though someone who actually knows ImageJ would make better
> decisions than I have.
>
> Comments from ImageJ experts would be greatly appreciated.  I've
> included a diff against ImageJ.java (from 1.38j) to illustrate the
> changes I've made.  Also, the viewer, which may be of interest to
> anyone
> using DICOM files, is available at
> http://nrg.wustl.edu/projects/DICOM/DicomBrowser.jsp (source available
> at http://nrg.wustl.edu/viewvc)
>
>
> Thanks!
>
>   - Kevin

[TonyOHagan]

I've just posted this Client API that is designed for embedding ImageJ into applications.

http://www.nabble.com/Client-API-for-embedding-ImageJ-tf3863033.html

It supports both a local JVM and the SocketListener interface.  
If you wish to avoid the socket interface you can just use IJClientLocal.

Regards,
Tony O'Hagan