[ome-devel] JOGL'ing with Tikal

[Joshua Moore]

Harry Hochheiser wrote:

> As far  as the C bindings and JOGL goes, .... I'm always reluctant to 
> suggest to somebody else that they port code to JOGL, but JOGL is such 
> a thin layer and so close to OpenGL that it shouldn't be too painful.
> ...
> Can you tell us a bit more about what Tikal does? That might help us 
> form opinions about whether it would seem worthwhile to port it to 
> Shoola?


The current (pertinent) functionality in Tikal includes:
    * registration (The AIR package as well as an internally developed one)
    * 4D tracking
    * 4D visualization
    * image processing (filters like anistropic diffusion, etc.)

Also available, and central to the data structure, is a "history" 
concept in which alterations to an image stack are kept within a vector. 
A single 5D image is loaded. Each operation adds a new pixel set to the 
history. This history vector is called a project, and is (currently) 
stored in a proprietary format.

The GUI handles this stack, typical I/O (loading, saving, etc.), and the 
OpenGL visualization with Z & T sliders and a menu for channels. 
Everything else is handled by the LIB which is based on libtiff. In 
order to have long running registration, etc. handled by the cluster, we 
are preparing service wrappers (*SOAP*, don't tell) around each of the 
Tikal functions. For that, we'd just use filesystem reads/writes.

Our first priority with Tikal is to make it read from/write to OME. This 
is a matter of implementing two functions, for this we need the C API. 
At that point, the LIB would be ready for invocation from anywhere in 
OME (client or server).

For Shoola to use the library, it would obviously need to add a menu for 
the operations which are available and quite possibly some sort of 
history concept in addition to the necessary visualization. What we 
might look into is whether that functionality is already in VisBio.

-Josh