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 :
A high level class ImageAccess allows an access to the pixels of an image.
To have the complete list of methods, see:
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).