NCSA HDF Java Products:

Release 2.1 Notes


Release Notes for JHV Version 2.1

Version 2.1 of the HDF Java products contains new features and significant bug fixes.

New Features

  1. Animation
      JHV 2.0 supported "animation" through the "z-axis" of a three dimensional SDS from an HDF file. JHV 2.1 supports animation in any of the three dimensions.

      Also, JHV 2.1 supports a similar animation through a series of two dimensional 8-bit raster images.

  2. Layers
      JHV 2.1 supports the overlay of any number of 8-bit raster images. The menu allows one color to be selected to be transparent.

  3. Pixel values
      The Image window has added several new features that display the values of the data in an image.
      • the value at the cursor can be tracked, giving either the pixel value, or the data value. If the data value is scaled or has units, the proper values are displayed.
      • For a selected region of the image, a histogram or radial plot of the pixel values may be displayed.

  4. Color Palettes
      JHV 2.1 has expanded the manipulation of color palettes, with many new options.

  5. 24-bit Raster Images
      The Java Virtual Machine does not support 24-bit images (yet?).

      In JHV 2.0, we used a native C routine to convert 24 bit images to 8 bits.

      In JHV 2.1, we have replaced the C code with Java code. This conversion is far from ideal.

      We are hoping that Java will directly support 24-bit images in the future, so we can eliminate this band-aid.

  6. 6. Java HDF Interface updated
      A few new routines and changes were added to the HDF API, and these were included in the JHI.

      A few minor errors in the JHI were corrected.

Bugs Fixed

  1. Out of memory when viewing a large image
      The JHV has problems displaying large images when the total size of the data exceeds the capacity of the Java Virtual Machine. For instance, a 2000 x 2000 8-bit image requires over 4 MB of storage, which is larger than most JVM's will support.

      The Java VM has a limited amount of memory available. This limit is specific to the version of the Java Virtual Machine you are using, and it is NOT the amount of memory installed on the system. Some JVM's have a switch to adjust the amount of heap memory (-mx), which may be used.

      In this version of the JHV we have done the best we can to limit the impact of this problem. We do not load data unless it is necessary. For large images, we initially display a subsampled image. The user may then select a region of interest, which will be displayed at full resolution. Obviously, if a large region is selected, it may not be possible to display it.

      Thus, the JHV can be used to browse a file, viewing the metadata and small images. If large images need to be handled, it will be necessary to use a more powerful tool.

      (See http://hdf.ncsa.uiuc.edu/tools.html for an incomplete list of tools.)

  2. Little-endian data was not correctly handled
      This has been fixed.

  3. Vdatas with multiple values per entry
      An HDF Vdata can have table columns that contain arrays of values. In the "spreadsheet" window, these values are displayed as a single string of the first 5 values.

      In JHV 2.0, the browser crashed if the entry was selected. This has been fixed.

      However, it is still not possible to display or manipulate the individual elements of the table entry. For instance, you cannot make histograms or scatterplots of data from an entry with more than one value.

  4. Problems with External Files
      Displaying an HDF file with External data does not always work because the external files must be in the current working directory.

      The workaround is to change to the correct directory before launching the JHV.

  5. Various problems with displays
      We have seen and heard of many problems with window placement, blank windows, and windows that hang. So far as we know, these problems stem from bugs in different implementations of the Java Virtual Machine.

      We have fixed as many problems as we can, and we hope that new versions of JVM will fix other bugs.

Note About "Supported" Platforms

The JHV is announced to work only for the platforms on which we have tested it. It will likely work on other platforms, although some fiddling may be necessary.

If Java is "platform independent", and "write once, run everywhere", why do we still have to deal with porting problems?

There are three reasons:

  1. The JHV is not available on all platforms, and is in different stages of development on different platforms. E.g., the JVM for Mac's is at least a year behind Windows, and there is no JVM at all for supercomputers, etc.

  2. The Java classes of the JHV can be run on any Java Virtual Machine without modification or recompilation.

    However, the JHV uses the Java HDF Interface, which links to the standard HDF library, which is written in C. (Fortunately, HDF is available for many more platforms than Java.)

    The JHV links the HDF library through the standard Java Native Interface. On most platforms, this requres the HDF library to be linked as a dynamic loading library. The details of this linkage are platform specific and are ususally not the standard build procedure for HDF.

    For these reasons, building the JHV on a specific platform may be slightly different for each platform.

  3. We simply have not had the resources to "port" the JHV to some platforms that it almost certainly will work on, such as Digital Unix.


NCSA
HDF Group

hdfhelp@ncsa.uiuc.edu

Date Modified: 15 March 1998