This page details our current work on VisBio, including software design notes, implementation status and our plan for the next few releases.

1. [In progress] Address efficiency issues
   • [Done] Improve efficiency of arbitrary slicing through the implementation of a smarter slicing algorithm
   • [Done] Improve efficiency of file format readers
     • [Done] Code better TIFF export including LZW compression, with support for writing progressively to a TIFF (avoids memory issues with very large TIFF files)
     • [Done] Look into QT reader's inefficiency – find ways to fix it
     • [Done] Look into Openlab reader's inefficiency – can it be sped up?
   • [In progress] Improve efficiency of animation with by-reference texturing in VisAD
     • Create a data renderer that can flip through thumbnails (and full resolution images) much more quickly. VisAD's default renderer isn't good enough. Should use by-reference texturing in Java3D if possible. Start with ImageRenderer and work from there.
   • [Done] More efficient representation of images in VisAD with FlatFields that can be 8-bit, 16-bit, etc. instead of 32-bit floats or 64-bit doubles
     • [Done] Create FlatField extension ImageFlatField, backed by a java.awt.Image. It works in the default renderer via packValues and unpackValues calls, but that's inefficient, so our custom data renderer will handle these cases specially with greater efficiency.
     • [Done] Update relevant VisAD file forms to use ImageFlatField.
   • More control over exactly what is in memory at a given time (e.g., keep an entire focal plane across time in memory, for ultra-fast animation)
     • Once file forms are more efficient (on par with ImageJ's read speed), and VisBio displays are more efficient (30 fps animation capabilities), implement feature to preload certain image planes (maybe along a desired axis?). Then VisBio should be able to animate at full-resolution as well as ImageJ can.
     • Data cache should store full resolution images in memory up to a certain limit. User should be able to configure this limit (e.g., the preloading image planes option described above). But the data cache should also cache transform results on disk to a certain (larger) limit. Otherwise, VisBio keeps calling expensive transforms over and over, which is inefficient.
   • More efficient Undo support using inverse operations in addition to state snapshots (Undo/Redo)


2. [In progress] Smarter file format support
   • [In progress] Integrated metadata support (convertible with OME-XML)
     • [In progress] Use metadata values as defaults whenever possible (e.g., micron values for physical dimensions)
   • [In progress] Proper import of files with 4+ dimensions (e.g., Olympus)
     • [Done] Identify block structure within each file using OME-XML conversion


3. [Done] Command-line interface data transform

1. [In progress] Better OME integration
   • [In progress] Browse and view data from OME database
   • [Done] Batch client-side uploader for queuing up multiple datasets


2. LifetimeCurves data transform for doing lifetime curve fitting
   • Automatically apply lifetime transform where appropriate
   • Automatically apply spectral transform where appropriate

1. VisBio (ImageJ/Jython) scripting language


2. Regions of interest
   • Ability to link 2D ROIs into multidimensional ones
   • Coring and other ROI analysis functions