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.  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, 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 that 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.
