[ome-devel] strategy and 6D data

[Curtis Rueden]

Hi Ian,

> 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?

When I wrote about my concerns with the Modulo approach last year, my goal
was to spark a technical discussion that could lead to a truly
N-dimensional solution in the OME schema. But that did not happen—the rest
of the team did not share my concerns—so the Modulo approach is AFAIK the
only way to store lifetime data within OMERO in the present day.

So it seems to me your best bet is to use Modulo, since that is what the
OMERO system provides, and hope that it stays well-supported in the long
term. The other option—proposing and implementing a truly N-dimensional
data model—would be something that only the core OMERO developers
realistically have the capability to do, given the complexity of the OMERO
software stack.

As for how LOCI will store spectral lifetime data in OMERO: we aren't
planning on doing so until the OME data model fully supports it. In the
meantime, it will be enough for us for Bio-Formats and ImageJ2 to support
it, since they are already N-dimensional.

Regards,
Curtis


On Fri, Nov 30, 2012 at 11:44 AM, Munro, Ian <i.munro at imperial.ac.uk> wrote:

>  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>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
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20121205/dd7a25f1/attachment.html>