IP-LAB: Tutorial

Series of computer laboratoires for image-processing programmation in Java

ImageJ

ImageJ is a general-purpose image-process software inspired by the well-known NIH Image software. It is written in Java, meaning that it can run on any platforms with a Java Virtual Machine. The application and the source are freely available. The author, Wayne Rasband, is at the National Institutes of Health, Bethesda, Maryland, USA.

On the web site of ImageJ (http://rsb.info.nih.gov/ij/) you can :

Download a recent version and install ImageJ (take less than 1 minute)
Consult the user documentation
Download the source code and the API
Consult the source code and the API

Main features of ImageJ

Read and write various formats of an image file (e.g., TIFF, GIF, BMP)
Display capabilities: zooming, contrast and brightness controls
Copy/paste
Provide some statistical information: measurement, histogram, etc
Include standard image processing functions: filtering, morphology, etc
Extensible by adding plugins

ImageAccess

A high level class ImageAccess allows an access to the pixels of an image.

To have the complete list of methods, see:

the documentation in HTML format.
the Source code in Java.
the Class file.

We have developed a class, named ImageAccess, that provides a high-level and foolproof way of accessing the pixels of an image in ImageJ. The access is independent of the image type. The data retrieved by the methods of the ImageAccess class are always in "double" format. Hence, the image-processing code is written once only in double (best precision); the type conversion is handled automatically. The typical way to program is to retrieve an image block by using a method that begins with get...(). The block is processed and the result is written in the image using a put...() method. The block can be a single pixel, a row, a column, a 3*3 or a 5*5 neighborhood window. For locations outside the image, the methods of the ImageAccess class return pixel values by applying mirror boundary conditions. For example, when a student wants to retrieve a 3*3 block of an image centered on (0,0), the interface layer provides the block with mirror conditions. This frees the programmer from having to worry about what happens at the boundaries. It produces simpler code and results in more pleasant results (no frame or border artifacts on the output).

Conceptually, there is a clear advantage in separating the image-processing code (algorithm) from the access of the pixels, since the latter is a technical part that depends on the language, the platform, or the frame grabber. However this is not the approach taken in ImageJ because is has a computational cost associated with it. As a result, the typical image-processing routines in ImageJ are faster than ours but also significantly more complicated. Our method of access leads to an overhead. We consider this as an acceptable price to pay for substantial simplifications in algorithm transcription.
Thanks to this layer, an algorithm can be translated into Java almost literally, not to mention that the code is independent of the data type. This is in contrast with ImageJ's own operators which need to be implemented for each data type (e.g., byte, 32 bits).