Graphic STI
logo EPFL
text EPFL
english only
Biomedical Imaging Group
IP-lAB
EPFL > BIG > Teaching > IP-LAB > Tutorial
CONTENTS

Home page

News & Events

Seminars

People

Research

Publications

Tutorials & Reviews

Recent Talks

Demos

Download Algorithms

Jobs and Trainees

Teaching

Student Projects

Intranet

 

IP-LAB

Concept

Download Sessions

Demo

Tutorial

EPFL Student access

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 :

Main features of ImageJ

ImageAccess

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).

© 2009 EPFL • webmaster.big@epfl.ch • 03.12.2009