How to use JIMI

The Java Image Management Interface -  version 1.0

JIMI (Java Image Management Interface) is a tool kit for loading, saving, and manipulating images in multiple graphics file formats.  JIMI quadruples the number of formats you can read, and adds the ability to save images in multiple file formats.  Using JIMI you have the unprecedented ability to write image file formats, and JIMI integrates seamlessly with the AWT ImageProducer / ImageConsumer interface.  JIMI is extensible, and efficient.   Images can be loaded in any of the file formats that are available with the current configuration, manipulated in a format neutral manner, and then saved as the same or a different file format.  JIMI rocks!
   

A note about this release

Activated Intelligence is committed to providing you with the strongest possible tool kit for Java image management that can be built.  All purchasers of Jimi 1.0 Pro will receive a free upgrade to Jimi 1.1 Pro; unfortunately we can not extend this offer to Jimi1.0 Core purchasers.  If you have specific needs or feature requests, or you would like to upgrade to Jimi 1.0 Pro, please contact us, and we will do our best to meet your needs.

Installing JIMI

The JIMI core classes are available in many forms.  To deploy JIMI with your application you must include the appropriate JimiCoreClasses.jar, or .zip file (or if appropriate the JimiProClasses.jar file) in the application classpath.  It is not necessary to unzip these classes, simply include one version of the archive in your application's classpath.

In order to keep your costs down every copy of JIMI must be licensed with a unique key class containing information specific to your application.  At the time that you purchase JIMI this class will be provided to you.  You must include your JimiKey.class class in your application's classpath as well as the JimiClasses archives.  To make it easier to deploy your application it is permissible to repackage the JimiKey.class into the JimiClasses archive.

For example if you are a Jimi Core customer you would change your classpath to include either JimiCore.jar or JimiCore.zip but NOT BOTH.  A Jimi Pro customer would add JimiPro.jar (or JimiPro.zip) to their classpath.  Both customers would need to add JimiKey.class to their classpath.

The documentation and archives are packaged as .ZIP archives and as an installer.  Simply unzip the archive or run the installer to extract the JimiCoreClasses.jar (or .zip) archive and the documentation.  Follow the same procedure for the Professional version.

The Jimi Demo version ships with BOTH the JimiProClasses and the JimiCoreClasses. You should only use the archive which is appropriate for your JimiKey and license. For evaluation and demonstration keys use the JimiProClasses archive.

Running the JimiBrowserApp demo

A number of demonstration applications and source code are included with JIMI.  These demonstrations are packaged as a separate ZIP archive called JimiDemos.zip.  You may extract this archive to examine the source code.

The JimiBrowserApp demo is a simple demonstration of an application that loads and saves images using JIMI.  The JimiBrowserApp demo does not provide a means of selecting format specific options, nor robust error handling, however it should prove as a guide and an introduction to JIMI.

To run the JimiBrowserApp demo simply install Jimi with the JimiCoreClasses archive in your classpath.  Add the JimiDemos.zip archive to your classpath, and "jre com.activated.jimidemo.JimiBrowserApp".  You should be able to load and save images using the appropriate file dialog.
 
A sample batch file for running JimiBrowserApp in Windows, Win32JimiBrowserApp.bat, is included as an example.

Loading Images

It is amazingly simple to load images using JIMI.  JIMI will automatically detect the image format you wish to load based upon the file type extension.  This means that for most images in most environments, JIMI simply needs the location of the image.  To load an image, call the public static method getImage in the Jimi class.  For example :
     java.awt.Image img =           com.activated.jimi.Jimi.getImage("c:\\Examples\\Jimi\\two_blind_men.png");
You can also use a URL :
  For added flexibility Jimi supports loading images from any InputStream.  Currently you must explicitly set the type of the image format to load the stream with.  In the future automatic file type detection will be implemented for many image formats.

All format types for JIMI use MIME type compatible strings, however convenience methods that check the file name extension and automatically use the appropriate MIME type string.  Please check the API documentation for these convenience methods.

Here is an example of using an explicit format type to load an image :
 

If you wish to manipulate the images outside of the JIMI tool kit, you can obtain an ImageProducer instead of the Image itself.  Jimi.getImageProducer is used to do this. Using an ImageProducer avoids the overhead of having an AWT Image object created.
 

Saving Images

Saving images is very similar to loading them.  The method Jimi.putImage is used to save images.  When saving images it is necessary to explicit specify the image file format to use.  It is possible to specify different options when saving, see "Accessing Format Specific Options."

Example :

 

Of course, it is not necessary to create an output stream.  JIMI will do this for you if you simply specify the name of the file you wish to save into :
 
    Jimi.putImage("image/jpeg", testImage,
                            "c:\\Examples\\Jimi\\new_image.jpeg");

putImage will also take an ImageProducer instead of an image.  This can be more efficient since an AWT peer does not need to be created if no Image is made.
 

Accessing Format Specific Options

One of the most powerful features of JIMI is the ability to access format specific options.  You may wish to encode an image with a bit depth other than the default, or you may wish to use true color mode instead of indexed color mode.  JIMI allows users who wish this sort of advanced control easy access to these options through two interfaces, JimiReader and JimiWriter.  Both of these interfaces extend the PropertyOwner interface.  It is the PropertyOwner interface that provides the access to format specific options.  To specify a format specific option you simply set a property on a JimiReader or JimiWriter.

JimiReader's and JimiWriter's can be created by using the factory methods of the Jimi class. For example :

  com.activated.jimi.JimiWriter pngWriter = Jimi.createJimiWriter("PNG");

Once you have a reference to the appropriate JimiReader or JimiWriter you can use the setProperty method to specify the value of the format specific option.  Although the appropriate values for the properties is normally found in the documentation you can determine at runtime which values are supported, and which options may be set by using the getPropertyNames and getPossibleValuesForProperty methods.

A few of the format specific options can be found in the Formats.html document that shipped with JIMI.  The Pro version of JIMI comes with a Formats.html document that replaces the Core version's document.

A subclass of JimiException, InvalidOptionException will be thrown if you specify a value for a property which is not valid for the format.

Here is code snippet that turns interlacing on when saving a GIF image.
 

 
    JimiWriter JW = Jimi.createJimiWriter("GIF");
    // Or preferably :
    //    JimiWriter JW = Jimi.createTypedJimiWriter("image/gif");
    JW.setProperty("interlace", Boolean.TRUE);
    JW.setSource(image);
    JW.putImage(out);
     

Loading Images from Multiple Image Formats

We provide two API's to multiple images.  Each API is designed to address a specific need.

The means of accessing images from multiple image formats is to use the JimiReader.getImage(int num) method.  This method will return the requested image from the input stream.  The images are indexed starting at 0.  For InputStreams that support mark() and reset() it is possible to access images in any order, however in the cases where mark is unsupported a NoImageAvailException will be thrown if you attempt to get an image with a lower ordinal index than the greatest indexed image loaded so far.  Unfortunately it also means that you can not get the same image twice.  If you attempt to index an image which does not exist, a NoImageAvailException will be thrown.
(note: If a BufferedInputStream is used as the InputStream for decoding then the entire image in its raw undecoded will be buffered. Therefore this should be kept in mind and the JimiReader object with which this is used should be discarded as soon as possible to free that memory.)

The second means is used when you wish to get all of the images from the format one at a time in order.  The JimiReader.getImageEnumeration() method will return an enumeration for simple sequential retrieval of the images via the java.util.Enumeration interface.
 

Saving Images to Multiple Image Formats

As an example, we will use the GIF encoder to save multiple images as a single animated GIF.  The GIF Encoder saves each of the images as changes from a full frame along with a time delay between each image.  This time delay allows the images to be animated.  The time delay is set as a format specific option.

Jimi.putImage is the primary mechanism for encoding single images, however there is no corresponding Jimi.putImage(Image[] images) method at this time.  [We felt that it would be convenient, but multiple images will normally require the use of format specific options anyway.  We may provide a corresponding Jimi.putImage(EncoderOptions, Object[]).]  Instead, you should create an instance of a JimiWriter using Jimi.createJimiWriter() and use the setSource(Object[]) method to provide the images to be encoded.  Each of the source objects must be either an Image or an ImageProducer, but they do not all need to be the same type.

In the following example we load a series of 10 GIF images, which are then saved as a single animated GIF image.

        }
        

 FAQ

Within a few months we will see a new release of JIMI.  JIMI 1.1 will be a free upgrade for users of Jimi 1.0 Pro.  JIMI 1.1 will showcase a faster architecture, virtual memory, dynamic image creation and individual pixel manipulation, and support for loading and saving vector image formats.  For more information about the release date and the licensing information, please visit our website. The JIMI 1.0 Pro version supports many formats and because it is extensible will allow anyone to add more formats in the future.  The following formats are currently supported :
 
    GIF
    JPG
    TGA
    BMP
    TIFF
    PNG
    SunRaster
    PICT
    PSD

In addition, the following formats may be loaded only :

    TIFF
    XBM
    RLE
    DIB
    XPM
    ICO
    CUR

More formats are being developed, along with better support for existing formats.  These formats will be released as extensions or incorporated into future versions of JIMI Pro.  You should expect to see CALS, and PCX very soon.

JIMI Core includes only support for GIF, JPEG, and PNG encoding and decoding.
 

Most of the formats support some form of bit depth specification as well as properties such as GIF interlacing, and JPG compression.  You can use the runtime methods getPropertyNames and getPossibleValuesForProperty to discover these options, or you can refer to the Formats.html documentation.
  Absolutely.  Because JIMI works with its own platform neutral representation of image information, it is not necessary to ever create an AWT native peer.  JIMI can be used to dynamically convert PNG images to GIF's or JPEG's on the server side, or used in many other contexts.  When using JIMI in an environment without an AWT it is important that you do not attempt to use the Jimi.createImage method.  This method will attempt to create the AWT peer.  Instead use Jimi.getJimiImage. Remarkably efficient.  JIMI makes excellent use of memory, and takes advantage of the increasing speed of Java VM's.
  An extension mechanism has been developed for JIMI, however because we anticipate some changes to the API for Jimi 1.1, we are providing this documentation only on a limited basis.  Please contact  us if you are interested in creating your own decoder or encoder for JIMI, but please be aware that the API will change.

We will also provide extensions of our own for JIMI.  If you are interested in supplying format for general distribution you can contact us at info@activated.com.  We are always looking to expand the functionality of JIMI.
 

The functionality necessary to do advanced image manipulation and creation will be release in JIMI
1.1.
  Remarkably efficient.  JIMI makes excellent use of memory, and takes advantage of the increasing
speed of Java VM's.
  We are currently developing a virtual memory system that will allow you to manipulate huge images without worrying about using up the resources allocated to the Java VM.  The JIMI client will be able to explicitly specify whether to use VM for images, and the policies under which this VM runs - this will allow you to obtain maximum performance for your specific needs.  We should see this feature soon after the JIMI1.0 release.  It may or may not be restricted only to the Jimi Pro tool kit.
  No.  We originally developed JIMI because we could not find a product to meet our in-house needs.  No other product offers the unprecedented features and formats that JIMI offers.
 

Support

We hope you do not encounter any bugs in JIMI, but if you do we need to hear about them.  Please email us at Support@activated.com. Or visit our web-site at http://www.activated.com/support.html
 

Conclusion

We're sure that JIMI will meet your needs for image format support in Java.  JIMI Rocks!  We'd love to see what you do with JIMI.  If you'd like to showcase your project, or share the work you've done with JIMI, please contact us.
 
 
(c) 1998, Activated Intelligence, LLC
JIMI is a trademark of Activated Intelligence, all rights reserved.