Related Topics: Java Developer Magazine, Open Web Magazine

Java Developer : Article

Medical Image Conversion

Converting to supported formats

In this article we'll discuss the conversion of image formats using Sun's Java Image I/O (ImageIO) and the NIH ImageJ APIs. The image formats of interest are DICOM, JPEG 2000, PNG, and TIFF. These formats are widely used in medical applications; however, most of the disciplines in medicine are standardizing on DICOM. A single API, ImageIO or ImageJ, supports the reading and writing of limited image formats. We'll describe the use of these two APIs to support the reading and writing of a larger number of image formats as well as the process of extracting rich metadata from DICOM files.

In general, medical image files contain the following information:

  • Image data, which may be in three dimensions and may be raw/unmodified or compressed.
  • Header data, which contains metadata such as patient information, image information, and equipment information. This information may be stored in different formats using a variety of standards - DICOM and JPEG 2000 standards are described below.
The Digital Imaging and Communications in Medicine (DICOM) standard was created by the National Electrical Manufacturers Association (NEMA) to standardize the imaging and communication format across multiple manufacturers to aid the distribution and viewing of medical images, such as CT scans, MRIs, and ultrasound. DICOM is an industry standard supported by most of the major medical imaging equipment manufacturers. It is a complex standard consisting of many parts, which are specified in the NEMA documents and can be found at

DICOM image compression can be lossy or lossless variants of the JPEG and JPEG 2000 formats, as well as a lossless Run-Length Encoding format.

JPEG 2000 is the successor of the JPEG standard and offers a better quality wavelet-based compression. It supports both lossy and lossless compression. JPEG 2000 is becoming a popular image format in image servers and medical imaging.

There are various image-conversion tools and software available, but most of them support a limited number of formats. It's often difficult or impossible to customize or integrate these tools with existing applications. ImageIO, Sun's Advanced Imaging API, (JAI), offers an open and extensible framework for image conversion. It supports the reading and writing of many formats such as TIFF, JPEG, and JPEG 2000. At present, it does not support the reading or writing of DICOM and PGM formats, two popular medical formats. ImageJ, a project funded by the National Institutes of Health (NIH), is another open and extensible API for image conversion. It supports the reading of DICOM, PGM, and other formats; however, ImageJ does not support formats such as JPEG 2000.

The Image I/O library is one of the standard APIs of the J2SE 1.4 release. The javax.imageio package contains the following classes that are useful for the current application:

  • ImageReader: An abstract superclass for parsing and decoding images
  • ImageWriter: An abstract superclass for encoding and writing images
  • ImageIO: A class containing static convenience methods for locating ImageReaders and ImageWriters and performing simple encoding and decoding
  • ImageReadParam and ImageWriteParam: Classes that describe decoding and encoding, respectively, of data streams
The set of supported image formats is not fixed. By default, the javax.imageio package can read GIF, PNG, and JPEG images and can write PNG and JPEG images. Calling the following static methods of the ImageIO class retrieves the complete list of available readable and writeable formats:
  • ImageIO.getReaderFormatNames()
  • ImageIO.getWriterFormatNames()
Sun provides JAI Image I/O Tools to support image readers/writers (also called codecs) in addition to the default formats supported in the Image I/O libraries of J2SE 1.4.

JAI Image I/O Tools can be downloaded from The readers available with the Image I/O tools are for TIFF, JFIF, WBMP, JPEG-LOSSLESS, JPEG2000, GIF, RAW, BMP, JPEG, PNM, and PNG formats. The writers available are for all the above formats except GIF.

ImageJ API
ImageJ is a public domain image processing API in Java, funded by the NIH. It can be downloaded from

It has classes to display, edit, analyze, process, save, and print 8-bit, 16-bit, and 32-bit images. It can read many image formats including TIFF, GIF, JPEG, BMP, DICOM, FITS, PGM, and RAW. It can write image formats such as JPEG, GIF, TIFF, BMP, RAW, etc. Note that some readers, such as DICOM, FITS, and PGM, are not available with ImageIO and some of the writers, such as JPEG 2000 and JPEG-LOSSLESS, that are available with ImageIO are not available with ImageJ.

New plugins can be developed using the ImageJ API to support additional formats, for instance, encoding in JPEG 2000 and JPEG-Lossless formats. A detailed tutorial for writing new plugins can be found at This article describes an alternate method that relies on integrating ImageJ and ImageIO instead of extending or writing plugins for ImageJ. As will be evident, this is a simpler and less time-consuming approach because it does not require writing new encoders.

ImageJ supports a wide variety of features such as geometric operations, editing, image enhancements, and analysis. For the purpose of a conversion tool, only input/output ( and plugin (ij.plugin) packages are used. It contains the following classes and packages that are useful for the current application:

  • A package that contains classes for reading/decoding and writing/encoding image files.
  • A convenient class used to open and read a supported image.
  • ij.plugin: A package that contains the encoder and decoder classes.
  • ij.ImagePlus: A class that represents an image in ImageJ. It has methods for getting the AWT image and image dimension. Using the AWT image object, a BufferedImage object can be constructed.
Description of Conversion Code
ImageJ and ImageIO each support various image formats and either of them can be used to develop an image conversion program. However, neither supports the conversion of some important image formats, for instance, the DICOM format cannot be converted to either JPEG-LOSSLESS or JPEG 2000. We will use the two APIs to develop an application to support the conversion from and to a larger set of image formats, particularly the conversion of DICOM to JPEG 2000. The process for image conversion is shown in Figure 1.

The algorithm and high-level steps are as follows:

  1. Given an image, check whether it's in a format readable by ImageIO. If yes, create BufferedImage using the ImageIO read method.
  2. If ImageIO does not have a reader for that format, try to open using ImageJ and create BufferedImage.
  3. If both ImageIO and ImageJ do not have a reader to open the image, report that the image cannot be processed.
  4. Use the ImageIO write method to convert the image to a specified format.
  5. If ImageIO does not support the writer for the specified output format, report that the image cannot be converted.
The code outline corresponding to these steps is shown in Listing 1. This conversion code outline can handle new formats that may be supported by ImageJ and ImageIO in the future, that is, new formats can be incorporated without the need to change the code because both of these APIs provide extensibility for future compatibility. Both ImageIO read and ImageJ Opener class are capable of reading any format supported by the corresponding APIs.

Reading Metadata from DICOM Images
The DICOM file contains image data as well as image metadata such as patient information, image information, equipment information, etc. This metadata is stored in the file header. Each metadata field has a code associated with it, for instance, the patient name field has a code of (0010,0010). An outline of the program for extracting metadata is shown in Listing 2. Code corresponding to the metadata fields of interest are stored in the dicomKeys array. Information corresponding to this code is retrieved and stored in a hashtable.

Future Enhancements

  • The metadata extraction code should be extended to store the metadata information in XML files or in a database.
  • The DICOM writer/encoder should be supported. Writing a DICOM encoder as a new plugin in ImageJ can achieve this.
  • Retrieving and storing metadata from images with formats other than DICOM should be supported.
The ImageJ API from the NIH is used with the ImageIO API from Sun to convert formats of medical images. The approach presented increases the number of supported medical image formats for conversion, without writing new encoders/decoders. The conversion code may be downloaded from

1.  Medical Image Format FAQ:

2.  Advanced Imaging Image I/O API RC 1.0:

3.  ImageJ Homepage:

4.  DICOM Homepage:

More Stories By Pramod Jain

Pramod Jain is president of Innovative Decision Technologies, Inc. (INDENT,, in Jacksonville, FL. Their clients include Recruitmax, NASA, and NIH. Pramod has a PhD from the University of California, Berkeley.

More Stories By Yayati Kasralikar

Yayati Kasralikar is lead programmer at INDENT. He has an MS from the University of Central Florida, Orlando.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
John Smith 08/11/06 10:15:44 AM EDT

The links to the project in the article do not work.

Alfred Li 08/04/04 07:00:57 PM EDT

Most medical images (i.e. CT, MRI, XRay) are 16 bits grayscale image. If ImageJ is used to read the image, one should use the ImageJ image processor and export the data as an array (i.e. short[]) to create the BufferedImage. Exporting as an AWT image will compress the grayscale info into 8 bits and information will be lost.