[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