Copy To System and asynchronicity

[Fred Damen]

Greeting Wayne,

An annoyance/bug and a question.

With a ImageWindow current/active and the Edit>Copy to System is invoked
and then no other ImageJ window becomes active the contents of the
aforementioned ImageWindow gets placed into the system clipboard. If
another ImageJ window gets activated, i.e., made current, a short time
later (as dictated by current system conditions and possible OS
peculiarities) the newly current window is what is put on the system
clipboard.  As these are asynchronous method calls, the current
ImageWindow can, and in my case does, change in between
ij.plugin.Clipboard.scopy calling system Clipboard.setContents and the
system Clipboard calling ij.plugin.Clipboard.getTransferData, n.b.
getTransfterData refetches the current window. Caching the image before
the call to setContents and use thereof in getTransferData should rectify
this issue.

I have noticed that the processing of the screen rendering of the
GenericDialog, specifically the removal thereof from the screen, and the
return of the showDialog method are asynchronous of each other.  Is there
a way to make sure the GenericDialog window has been removed from the
screen?  I have written a method that resizes and raises an ImageJ
image/nonimage window and then using Robot to take a snapshot of this
window, OS adornments included; although about half the time the
GenericDialog has not yet been removed from the screen and is covering
window, thus corrupting the snapshot.  I have tried putting waits in, but
to no avail.  I suspect that the thread that was displaying the
GenericDialog is being blocked by the thread that had called the
showDialog, n.b., OS is Fedora 31.

Thanks in advance,

Fred

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael P Ellis]

Dear Wayne,

I am currently using ImageJ as jar library for my own project. I am reading some
proprietary TIFF files that have information stored in the IMAGE_DESCRIPTION (TIFF TAG 270)
in every page of a multi-page TIFF file.

Currently ij.io.TiffDecoder.OpenIFD()

Only picks up the IMAGE_DESCRIPTION for the first page.
Is there any reason that this cannot be relaxed to pick them all up?

I have modified the code (just commented out the ifdCount test) and in my use case,
I have not seen any problems. All the information is conveniently accumulated and
available in the ImagePlus::getProperty("Info");

in File ij.io.TiffDecoder.java, from line 549, in method OpenIFD()

   case IMAGE_DESCRIPTION:
      // if (ifdCount==1) {
      byte[] s = getString(count, lvalue);
      if (s!=null) saveImageDescription(s,fi);
      // }
      break;

The advantage, obviously, is IMAGE_DESCRIPTION data stored in all the planes is now
available within ImageJ

As far as I can see any use of the String returned  by ImagePlus::getProperty("Info");
probably requires parsing and testing so it would seem unlikely that this would cause
much of a compatibility problem.

----------------------------

Here is an example of the output from the Image->Show Info... for my use case.

ImageDescription: "Cy5.5" enabled slide_name = "" operator_name = "" patient_name = ""
experiment_comment = "" comment = "Cambio 24 Colour MFISH" position = (0.0,0.0,0.0) sense =
"Fluorescence" tint rgb = (0,0,255) norm lu = (27,255) brightness = (100) autobright probeweight =
(0) location = "|merge|1" frame = 1/1
ImageDescription: "Cy5" enabled slide_name = "" operator_name = "" patient_name = ""
experiment_comment = "" comment = "Cambio 24 Colour MFISH" position = (0.0,0.0,0.0) sense =
"Fluorescence" tint rgb = (255,0,255) norm lu = (51,217) brightness = (100) autobright probeweight
= (0) location = "|merge|1" frame = 1/1
ImageDescription: "Cy3.5" enabled slide_name = "" operator_name = "" patient_name = ""
experiment_comment = "" comment = "Cambio 24 Colour MFISH" position = (0.0,0.0,0.0) sense =
"Fluorescence" tint rgb = (255,255,0) norm lu = (45,221) brightness = (100) autobright probeweight
= (0) location = "|merge|1" frame = 1/1
ImageDescription: "Cy3" enabled slide_name = "" operator_name = "" patient_name = ""
experiment_comment = "" comment = "Cambio 24 Colour MFISH" position = (0.0,0.0,0.0) sense =
"Fluorescence" tint rgb = (255,0,0) norm lu = (48,215) brightness = (100) autobright probeweight =
(0) location = "|merge|1" frame = 1/1
ImageDescription: "Fitc" enabled slide_name = "" operator_name = "" patient_name = ""
experiment_comment = "" comment = "Cambio 24 Colour MFISH" position = (0.0,0.0,0.0) sense =
"Fluorescence" tint rgb = (0,255,0) norm lu = (15,220) brightness = (100) autobright probeweight =
(0) location = "|merge|1" frame = 1/1
ImageDescription: "Dapi" enabled slide_name = "" operator_name = "" patient_name = ""
experiment_comment = "" comment = "Cambio 24 Colour MFISH" position = (0.0,0.0,0.0) sense =
"Fluorescence" tint rgb = (255,255,255) norm lu = (1,238) brightness = (100) autobright probeweight
= (0) location = "|merge|1" frame = 1/1
--------------------------------------------
ImageJ 1.53c; Java 14.0.1 [64-bit]; Mac OS X 10.15.6; 27MB of 4096MB (<1%)

Title: s22 _Frame_1.tif
Width: 832 pixels
Height: 768 pixels
Depth: 6 pixels
Size: 3.7MB
Voxel size: 1x1x1 pixel^3
ID: -2
Bits per pixel: 8 (color LUT)
Display range: 0-255
Image: 1/6
No threshold
ScaleToFit: false
Uncalibrated
Path: /Users/michaelellis/SmartType Cases/MFISH Yang/MFISH Yang.00001/s22 _Frame_1.tif
Screen location: 257,125 (1680x1050)
SetMenuBarCount: 2 (121ms)
Coordinate origin: 0,0,0
No properties
No overlay
No selection

-- Regards -- Michael Ellis (Digital Scientific UK)

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael P Ellis]

Dear Wayne,

I am currently using ImageJ as a jar library for my own project. I am currently running with Java 14 but not yet full transitioned to the Java Module System. Would it be possible to add a module-info.java file in the default package
in preparation for compatibility and support of modern java development.

I don't *think* this change would cause backward compatibility issues. But happy to stand corrected.

Other changes will be required too, including some reorganisation of files as has already seems to
be started in the ImageJA project at https://github.com/imagej/ImageJA.git

Regards -- Michael Ellis


module ij {
    requires java.desktop;
    requires java.rmi;
    requires java.compiler;
    requires java.scripting;
    exports ij;
    exports ij.gui;
    exports ij.io;
    exports ij.macro;
    exports ij.measure;
    exports ij.plugin;
    exports ij.plugin.filter;
    exports ij.plugin.frame;
    exports ij.plugin.tool;
    exports ij.process;
    exports ij.text;
    exports ij.util;
}

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

> On Aug 30, 2020, at 1:17 AM, Michael Ellis <[hidden email]> wrote:
>
> Dear Wayne,
>
> I am currently using ImageJ as a jar library for my own project. I am currently running with Java 14 but not yet full transitioned to the Java Module System. Would it be possible to add a module-info.java file in the default package
> in preparation for compatibility and support of modern java development.

I added a module-info.java file to the ImageJ 1.53e8 source at https://github.com/imagej/imagej1/commit/6037ff7c7b3bdc76a2cf9a9f78e81fed979ecefd.

-wayne

>
> I don't *think* this change would cause backward compatibility issues. But happy to stand corrected.
>
> Other changes will be required too, including some reorganisation of files as has already seems to
> be started in the ImageJA project at https://github.com/imagej/ImageJA.git
>
> Regards -- Michael Ellis
>
>
> module ij {
>    requires java.desktop;
>    requires java.rmi;
>    requires java.compiler;
>    requires java.scripting;
>    exports ij;
>    exports ij.gui;
>    exports ij.io;
>    exports ij.macro;
>    exports ij.measure;
>    exports ij.plugin;
>    exports ij.plugin.filter;
>    exports ij.plugin.frame;
>    exports ij.plugin.tool;
>    exports ij.process;
>    exports ij.text;
>    exports ij.util;
> }

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael P Ellis]

Many thanks!

And more thanks for the excellent piece of software that ImageJ is and continues to be.

-- Michael Ellis

August 30, 2020 7:26 PM, "Wayne Rasband" <[hidden email]> wrote:

>> On Aug 30, 2020, at 1:17 AM, Michael Ellis <[hidden email]> wrote:
>>
>> Dear Wayne,
>>
>> I am currently using ImageJ as a jar library for my own project. I am currently running with Java
>> 14 but not yet full transitioned to the Java Module System. Would it be possible to add a
>> module-info.java file in the default package
>> in preparation for compatibility and support of modern java development.
>
> I added a module-info.java file to the ImageJ 1.53e8 source at
> https://github.com/imagej/imagej1/commit/6037ff7c7b3bdc76a2cf9a9f78e81fed979ecefd.
>
> -wayne
>
>> I don't *think* this change would cause backward compatibility issues. But happy to stand
>> corrected.
>>
>> Other changes will be required too, including some reorganisation of files as has already seems to
>> be started in the ImageJA project at https://github.com/imagej/ImageJA.git
>>
>> Regards -- Michael Ellis
>>
>> module ij {
>> requires java.desktop;
>> requires java.rmi;
>> requires java.compiler;
>> requires java.scripting;
>> exports ij;
>> exports ij.gui;
>> exports ij.io;
>> exports ij.macro;
>> exports ij.measure;
>> exports ij.plugin;
>> exports ij.plugin.filter;
>> exports ij.plugin.frame;
>> exports ij.plugin.tool;
>> exports ij.process;
>> exports ij.text;
>> exports ij.util;
>> }
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Fred,

concerning:
 > I have noticed that the processing of the screen rendering of the
 > GenericDialog, specifically the removal thereof from the screen,
 > and the return of the showDialog method are asynchronous of each
 > other.  Is there a way to make sure the GenericDialog window has
 > been removed from the screen?

It is a property of Java that changes to the GUI on the screen are
asynchronous; it is rather difficult to avoid this in ImageJ. There is
such code for images brought into the foreground, but it has been the
root for many problems (that are solved by now, as far as I can say). If
possible at all, it would be a pain to implement something like this for
the GenericDialog.

For your application of capturing the screen, the easiest would be a
short delay (which is not a very clean way of doing it).
If you have a NonblockingGenericDialog (which you can get for most
filters, enable it in the Misc options), you could try to explicitly put
the image window into the foreground with IJ.selectWindow(imageID). This
should wait until the image is really there. I did not try it however,
and I fear that it would not work for 'normal' (non-blocking)
GenericDialogs.
Instead of the screenshot, you might also try Plugins>Utilities>Capture
Image.

-----

Concerning the 'copy to system' race condition, I can confirm it.
Javascript code:

   impB = IJ.openImage("https://imagej.net/images/blobs.gif");
   impB.show();
   Thread.sleep(1000);
   impP = IJ.openImage("https://imagej.net/images/particles.gif");
   impP.show();
   Thread.sleep(1000);
   IJ.run("Copy to System", "");   //should copy the particles
   IJ.selectWindow(impB.getID());
   Thread.sleep(1000);
   IJ.run("System Clipboard", ""); //shows the blobs, not the particles

Michael
________________________________________________________________
On 30.08.20 05:38, Fred Damen wrote:

> Greeting Wayne,
>
> An annoyance/bug and a question.
>
> With a ImageWindow current/active and the Edit>Copy to System is invoked
> and then no other ImageJ window becomes active the contents of the
> aforementioned ImageWindow gets placed into the system clipboard. If
> another ImageJ window gets activated, i.e., made current, a short time
> later (as dictated by current system conditions and possible OS
> peculiarities) the newly current window is what is put on the system
> clipboard.  As these are asynchronous method calls, the current
> ImageWindow can, and in my case does, change in between
> ij.plugin.Clipboard.scopy calling system Clipboard.setContents and the
> system Clipboard calling ij.plugin.Clipboard.getTransferData, n.b.
> getTransfterData refetches the current window. Caching the image before
> the call to setContents and use thereof in getTransferData should rectify
> this issue.
>
> I have noticed that the processing of the screen rendering of the
> GenericDialog, specifically the removal thereof from the screen, and the
> return of the showDialog method are asynchronous of each other.  Is there
> a way to make sure the GenericDialog window has been removed from the
> screen?  I have written a method that resizes and raises an ImageJ
> image/nonimage window and then using Robot to take a snapshot of this
> window, OS adornments included; although about half the time the
> GenericDialog has not yet been removed from the screen and is covering
> window, thus corrupting the snapshot.  I have tried putting waits in, but
> to no avail.  I suspect that the thread that was displaying the
> GenericDialog is being blocked by the thread that had called the
> showDialog, n.b., OS is Fedora 31.
>
> Thanks in advance,
>
> Fred
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

> On Aug 29, 2020, at 11:38 PM, Fred Damen <[hidden email]> wrote:
>
> Greeting Wayne,
>
> An annoyance/bug and a question.
>
> With a ImageWindow current/active and the Edit>Copy to System is invoked
> and then no other ImageJ window becomes active the contents of the
> aforementioned ImageWindow gets placed into the system clipboard. If
> another ImageJ window gets activated, i.e., made current, a short time
> later (as dictated by current system conditions and possible OS
> peculiarities) the newly current window is what is put on the system
> clipboard.

This bug is fixed in the ImageJ 1.53e10 daily build. The daily build also adds an ImagePlus.copyToSystem() method. Here is an updated version of Michael’s test script that uses this new method:

   impB = IJ.openImage("https://imagej.net/images/blobs.gif");
   impB.show();
   Thread.sleep(1000);
   impP = IJ.openImage("https://imagej.net/images/particles.gif");
   impP.show();
   Thread.sleep(1000);
   impP.copyToSystem(); // copies particles to system clipboard
   IJ.selectWindow(impB.getID());
   Thread.sleep(1000);
   IJ.run("System Clipboard", ""); //shows particles

-wayne

> As these are asynchronous method calls, the current
> ImageWindow can, and in my case does, change in between
> ij.plugin.Clipboard.scopy calling system Clipboard.setContents and the
> system Clipboard calling ij.plugin.Clipboard.getTransferData, n.b.
> getTransfterData refetches the current window. Caching the image before
> the call to setContents and use thereof in getTransferData should rectify
> this issue.
>
> I have noticed that the processing of the screen rendering of the
> GenericDialog, specifically the removal thereof from the screen, and the
> return of the showDialog method are asynchronous of each other.  Is there
> a way to make sure the GenericDialog window has been removed from the
> screen?  I have written a method that resizes and raises an ImageJ
> image/nonimage window and then using Robot to take a snapshot of this
> window, OS adornments included; although about half the time the
> GenericDialog has not yet been removed from the screen and is covering
> window, thus corrupting the snapshot.  I have tried putting waits in, but
> to no avail.  I suspect that the thread that was displaying the
> GenericDialog is being blocked by the thread that had called the
> showDialog, n.b., OS is Fedora 31.
>
> Thanks in advance,
>
> Fred

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings Michael,

Thanks for the reply...

I tried your suggestions of using IJ.selectWindow(imageID) with
NonBlockingGenericDialog and with GenericDialog, and the results are the
same as before.  At the moment, all concoctions, about 20% of the time the
snap(shot) of the window contains the part of the GenericDialog that was
overlaying the window when I clicked OK.  The visual screen, i.e., what I
see with my eyeballs, appears to be updated correctly before the results
of the screen shot are displayed, i.e., an ImagePlus with the results.
Increasing the IJ.wait time just extends the time between visual screen
update and image being produced, i.e., does not change the frequency of
this anomaly's occurrence.  I suspect that double buffering of the
screen's contents is going on, and the completion thereof is being blocked
stochastically; I would have suspected that new Robot().waitForIdle();
would have rectified this, but no joy.

The main impetus of writing this snap shot functionality is to capture
nonimage windows, namely GenericDialogs for putting in documentation
webpages; OS adornments included.  The impetus for the plugin itself is
that it is possible to adjust a window's width to zero - preventing it
from being seen, and, having a plethora of windows open such that the main
window Window menu extends past the bottom of the screen, rendering
selecting of the window impossible.  I have included the plugin in case
someone can spot if I am doing something wrong...

Thanks again,

Fred

import ij.*;
import ij.process.*;
import ij.gui.*;
import java.awt.*;
import java.awt.datatransfer.*;
import java.io.*;
import java.util.*;
import ij.plugin.*;
import ij.plugin.frame.*;

public class Find_Window implements PlugIn {

   public void run(String arg) {
      Vector<String> itv = new Vector<String>();
      itv.add("<choose>");
      int[] ids = WindowManager.getIDList();
      if (ids != null)
         for(int id : ids)
            itv.add(WindowManager.getImage(id).getTitle());

      Vector<String> wtv = new Vector<String>();
      wtv.add("<choose>");
      Window[] ws = WindowManager.getAllNonImageWindows();
      if (ws != null)
         for(Window w : ws)
            wtv.add(w instanceof Frame ? ((Frame)w).getTitle() :
((Dialog)w).getTitle());

      GenericDialog gd = new NonBlockingGenericDialog("Find Windows");
      gd.addChoice("Find Image:", itv.toArray(new String[0]), "");
      gd.addMessage("Applies only to ImageWindow(s)");
      gd.addCheckbox("Unlock",false);
      gd.addMessage("  ");
      gd.addChoice("Find Frame:", wtv.toArray(new String[0]), "");
      gd.addMessage("Applies to all Window(s)\n ");
      gd.addCheckbox("Here",true);
      gd.addCheckbox("Raise",true);
      gd.addCheckbox("100%",true);
      gd.addCheckbox("Snap",false);
      gd.showDialog();
      if (gd.wasCanceled()) return;
      //gd.setVisible(false);

      int iind = gd.getNextChoiceIndex();
      boolean unlock = gd.getNextBoolean();
      boolean here   = gd.getNextBoolean();
      boolean raise  = gd.getNextBoolean();
      boolean zoom   = gd.getNextBoolean();
      boolean snap   = gd.getNextBoolean();
      if (iind > 0) {
         ImagePlus imp = WindowManager.getImage(ids[iind-1]);
         if (unlock) imp.unlock();
         ImageWindow win = imp.getWindow();
         if (here)   win.setLocation(gd.getLocation());
         if (zoom)   win.getCanvas().zoom100Percent();
         if (raise)  IJ.selectWindow(imp.getID()); //win.toFront();
         ImageWindow.setNextLocation(gd.getLocation());
         if (snap)   { IJ.wait(1000); snapAndDisplay(win); }
         }

      int wind = gd.getNextChoiceIndex();
      if (wind > 0) {
         Window win = ws[wind-1];
         if (here)   win.setLocation(gd.getLocation());
         if (zoom)
            if (win instanceof GenericDialog) ((GenericDialog)win).pack();
                                         else win.setSize(500,500);
         ImageWindow.setNextLocation(gd.getLocation());
         if (raise)  win.toFront();
         if (snap)   { IJ.wait(1000); snapAndDisplay(win); }
         }
      }

   public static void snapAndDisplay(Window win) {
      ImagePlus imp = snap(win);
      if (imp == null) return;
      imp.show();
      clipboard(imp);
      }
   public static ImagePlus snap(Window win) {
      try {
         Rectangle r = new Rectangle(win.getLocation(),win.getSize());
         //new Robot().mouseMove(win.getX()+10,win.getY()+10);
         new Robot().waitForIdle();
         //win.setVisible(true);
         //win.requestFocus();
         //boolean flag = win.isAlwaysOnTop();
         //win.setAlwaysOnTop(true);
         ImagePlus imp = new ImagePlus("Snapshot",new
Robot().createScreenCapture(r));
         //win.setAlwaysOnTop(flag);
         return imp;
         }
      catch(Exception e) {
         IJ.showStatus("Could not grab snapshot of window");
         }
      return null;
      }
   public static void clipboard(final ImagePlus imp) {
      Toolkit.getDefaultToolkit().getSystemClipboard().setContents(
         new Transferable() {
            @Override public DataFlavor[] getTransferDataFlavors() {
                      return new DataFlavor[] { DataFlavor.imageFlavor };
                      }
            @Override public boolean isDataFlavorSupported(DataFlavor
flavor) {
                      return DataFlavor.imageFlavor.equals(flavor);
                      }
            @Override public Object getTransferData(DataFlavor flavor)
throws UnsupportedFlavorException {
                      if (!isDataFlavorSupported(flavor))
                         throw new UnsupportedFlavorException(flavor);
                      return imp.getImage();
                      }
            }, null);
      }
}


On Mon, August 31, 2020 4:53 am, Michael Schmid wrote:

> Hi Fred,
>
> concerning:
>  > I have noticed that the processing of the screen rendering of the
>  > GenericDialog, specifically the removal thereof from the screen,
>  > and the return of the showDialog method are asynchronous of each
>  > other.  Is there a way to make sure the GenericDialog window has
>  > been removed from the screen?
>
> It is a property of Java that changes to the GUI on the screen are
> asynchronous; it is rather difficult to avoid this in ImageJ. There is
> such code for images brought into the foreground, but it has been the
> root for many problems (that are solved by now, as far as I can say). If
> possible at all, it would be a pain to implement something like this for
> the GenericDialog.
>
> For your application of capturing the screen, the easiest would be a
> short delay (which is not a very clean way of doing it).
> If you have a NonblockingGenericDialog (which you can get for most
> filters, enable it in the Misc options), you could try to explicitly put
> the image window into the foreground with IJ.selectWindow(imageID). This
> should wait until the image is really there. I did not try it however,
> and I fear that it would not work for 'normal' (non-blocking)
> GenericDialogs.
> Instead of the screenshot, you might also try Plugins>Utilities>Capture
> Image.
>
> -----
>
> Concerning the 'copy to system' race condition, I can confirm it.
> Javascript code:
>
>    impB = IJ.openImage("https://imagej.net/images/blobs.gif");
>    impB.show();
>    Thread.sleep(1000);
>    impP = IJ.openImage("https://imagej.net/images/particles.gif");
>    impP.show();
>    Thread.sleep(1000);
>    IJ.run("Copy to System", "");   //should copy the particles
>    IJ.selectWindow(impB.getID());
>    Thread.sleep(1000);
>    IJ.run("System Clipboard", ""); //shows the blobs, not the particles
>
> Michael
> ________________________________________________________________
> On 30.08.20 05:38, Fred Damen wrote:
>> Greeting Wayne,
>>
>> An annoyance/bug and a question.
>>
>> With a ImageWindow current/active and the Edit>Copy to System is invoked
>> and then no other ImageJ window becomes active the contents of the
>> aforementioned ImageWindow gets placed into the system clipboard. If
>> another ImageJ window gets activated, i.e., made current, a short time
>> later (as dictated by current system conditions and possible OS
>> peculiarities) the newly current window is what is put on the system
>> clipboard.  As these are asynchronous method calls, the current
>> ImageWindow can, and in my case does, change in between
>> ij.plugin.Clipboard.scopy calling system Clipboard.setContents and the
>> system Clipboard calling ij.plugin.Clipboard.getTransferData, n.b.
>> getTransfterData refetches the current window. Caching the image before
>> the call to setContents and use thereof in getTransferData should
>> rectify
>> this issue.
>>
>> I have noticed that the processing of the screen rendering of the
>> GenericDialog, specifically the removal thereof from the screen, and the
>> return of the showDialog method are asynchronous of each other.  Is
>> there
>> a way to make sure the GenericDialog window has been removed from the
>> screen?  I have written a method that resizes and raises an ImageJ
>> image/nonimage window and then using Robot to take a snapshot of this
>> window, OS adornments included; although about half the time the
>> GenericDialog has not yet been removed from the screen and is covering
>> window, thus corrupting the snapshot.  I have tried putting waits in,
>> but
>> to no avail.  I suspect that the thread that was displaying the
>> GenericDialog is being blocked by the thread that had called the
>> showDialog, n.b., OS is Fedora 31.
>>
>> Thanks in advance,
>>
>> Fred
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html