[ImageJ-devel] [ome-devel] strategy and 6D data

Munro, Ian i.munro at imperial.ac.uk
Fri Nov 30 11:44:19 CST 2012


Hi Curtis

Thans for the feedback. It's much appreciated.

Actually I oversimplified as our code is a Matlab GUI wrapping cross-platform c++ fitting code so bringing this together with slim may be relatively easy as the 2 GUIs seem to have a lot of common features.

In the shorter term I think we need to use the same strategy to store data in OMERO.

Clearly you have a better feel for the downsides of the ModuloAlong? solution than we do so can I ask how you intend to store your data in OMERO?


Regards

Ian





On 28 Nov 2012, at 20:10, Curtis Rueden wrote:

Hi Ian,

Thanks for this update; very informative. It looks like you have done a lot to bring FLIM processing into OMERO, which is great.

I want to draw your attention to some very similar work we are doing within ImageJ:
    http://loci.wisc.edu/software/slim-plugin

The SLIM Plugin is an ImageJ plugin (written in Java, of course), which uses the SLIM-curve library (written in cross-platform C) to perform the curve fitting (of TCSPC data).

> The Imperial/Photonics Group’s main FLIM analysis software is
> internally named “GlobalProcessing”. It is written in MATLAB and
> provides state of the art fitting of time domain data for both
> laser-scanning time-correlated single photon (TCSPC) and wide-field
> time-gated FLIM images.

Perhaps GlobalProcessing and SLIM-curve could join forces? It is much easier to access C code from Java than MATLAB code, but there are clearly features in GlobalProcessing missing from SLIM-curve (e.g., wide-field), and vice versa.

> 1) We intend to standardise on encoding FLIM data using ModuloAlongT.

Personally, I dislike ModuloAlongT, especially as a long-term solution. There are certain dimension orders that are simply impossible using it (e.g., XYbCZT, where "b" is lifetime bins, and T is actual time points). I would much favor us developing a true N-dimensional OME data model, and using that, moving forward.

> 2) Where should the functionality currently in IC-importer fit into
> the OMERO eco-system?

I agree that this functionality would work well as a Bio-Formats reader.

Regards,
Curtis


On Wed, Nov 28, 2012 at 5:11 AM, Munro, Ian <i.munro at imperial.ac.uk<mailto:i.munro at imperial.ac.uk>> wrote:
Hello all

Please find attached a document describing where the work of the Imperial satellite currently stands.
We've reached a point where our group is making decisions, regarding the handling of data with a 6th dimension,
that may well have future  implications for  the OMERO clients or for other groups working with 5+ dimensions.

As  a result we're looking for any feedback/improvements that anyone can offer on our current approach
In particular the 3 areas  highlighted on the second page of the document.

Thanks in advance for your time.

Ian



Ian




_______________________________________________
ome-devel mailing list
ome-devel at lists.openmicroscopy.org.uk<mailto:ome-devel at lists.openmicroscopy.org.uk>
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20121130/0d35b98b/attachment.html>


More information about the ImageJ-devel mailing list