<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style>
<!--
@font-face
        {font-family:Calibri}
@font-face
        {font-family:Tahoma}
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif"}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline}
span.hoenzb
        {}
span.EmailStyle18
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
.MsoChpDefault
        {font-family:"Calibri","sans-serif"}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
div.WordSection1
        {}
-->
</style>
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Hi Curtis, Ian et al.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Thanks for raising this issue again.  We’ve certainly discussed it several times, on these lists and in our regular weekly meetings.  Fundamentally, Curtis
 is correct, we definitely need to address the issue of N-dimensional data thoroughly and completely.  This was the basis for the various studies we did of this problem in 2011/2012, the final summaries of which are:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><a href="http://www.openmicroscopy.org/site/support/file-formats/working-with-ome-xml/6d-7d-and-8d-storage">http://www.openmicroscopy.org/site/support/file-formats/working-with-ome-xml/6d-7d-and-8d-storage</a></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><a href="http://trac.openmicroscopy.org/ome/wiki/WorkPlan/NDimensionalData">http://trac.openmicroscopy.org/ome/wiki/WorkPlan/NDimensionalData</a></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">(deprecated page)</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Curtis stated he didn’t like the Modulo solution, and frankly, from a modelling point of view, we’re not fond of that either.   We fully appreciate the limitations
 of the approach.  As detailed above, however, the approach does allow us to move forward, begin to explore these different data types, and start to work with real applications in a broad number of domains, and allow us to develop knowledge and experience with
 new data types and their usage.  That provides the foundation for a significant re-design of essentially all of OME’s models and software.  Given the number of people who depend on these resources, we need to initiate large breaking changes when we are sure
 of what we are doing, and have good example datasets from as wide variety domains as possible.  For this reason, we previously decided to provide Ian and other with this type of multi-dimensional data with support for a Modulo-based approach, help get their
 analysis integrated with OME’s tool, and then get, for example, global analysis on FLIM data running in production. 
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">This does put off the inevitable, and we fully accept the additional burden this creates.  However, we are committed to making significant changes to OME’s
 APIs through a series of defined, known steps, where people working with OME-TIFF, Bio-Formats and OMERO are provided explicit, well-documented, working specifications and examples, are allowed to transition to a new framework. 
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Frankly, the other issue is that there are a large number of critical things to achieve in OME.  For a number of years, many institutions have insisted that
 we provide support for direct access to data from the filesystem, improved support for analysis, export, etc.  To do each of these correctly takes significant work and concentration by the whole team to deliver functionality across the whole stack.  That means
 we have to make strategic decisions, and choose our priorities.  We don’t have infinite resources, but what we do build and release has to be of high quality and usability. 
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Finally, discussions of N-dim will certainly continue to appear on the weekly team meeting agenda (<a href="https://www.openmicroscopy.org/site/community/minutes/conference-calls/2012">https://www.openmicroscopy.org/site/community/minutes/conference-calls/2012</a>). 
 Those meetings can also be used for more detailed, focussed conversations.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Thanks for the thoughtful comments;  look forward to more.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Cheers,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Jason</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></a></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif""> ome-devel-bounces@lists.openmicroscopy.org.uk [mailto:ome-devel-bounces@lists.openmicroscopy.org.uk]
<b>On Behalf Of </b>Curtis Rueden<br>
<b>Sent:</b> Wednesday, December 05, 2012 3:16 PM<br>
<b>To:</b> Munro, Ian<br>
<b>Cc:</b> ome-devel Development; ImageJ Developers<br>
<b>Subject:</b> Re: [ome-devel] strategy and 6D data</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Hi Ian,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">> Clearly you have a better feel for the downsides of the ModuloAlong?</p>
</div>
<div>
<p class="MsoNormal">> solution than we do so can I ask how you intend to store your data in</p>
</div>
<div>
<p class="MsoNormal">> OMERO?</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Regards,</p>
</div>
<div>
<p class="MsoNormal">Curtis</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On Fri, Nov 30, 2012 at 11:44 AM, Munro, Ian <<a href="mailto:i.munro@imperial.ac.uk" target="_blank">i.munro@imperial.ac.uk</a>> wrote:</p>
<div>
<p class="MsoNormal">Hi Curtis  </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thans for the feedback. It's much appreciated.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">In the shorter term I think we need to use the same strategy to store data in OMERO.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Regards</p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Ian</span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On 28 Nov 2012, at 20:10, Curtis Rueden wrote:</p>
</div>
<p class="MsoNormal"><br>
<br>
</p>
<p class="MsoNormal">Hi Ian, </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">Thanks for this update; very informative. It looks like you have done a lot to bring FLIM processing into OMERO, which is great.</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I want to draw your attention to some very similar work we are doing within ImageJ:</p>
</div>
<div>
<p class="MsoNormal">    <a href="http://loci.wisc.edu/software/slim-plugin" target="_blank">http://loci.wisc.edu/software/slim-plugin</a></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">> The Imperial/Photonics Group’s main FLIM analysis software is</p>
</div>
<div>
<p class="MsoNormal">> internally named “GlobalProcessing”. It is written in MATLAB and</p>
</div>
<div>
<p class="MsoNormal">> provides state of the art fitting of time domain data for both</p>
</div>
<div>
<p class="MsoNormal">> laser-scanning time-correlated single photon (TCSPC) and wide-field</p>
</div>
<div>
<p class="MsoNormal">> time-gated FLIM images.</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">> 1) We intend to standardise on encoding FLIM data using ModuloAlongT.</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">> 2) Where should the functionality currently in IC-importer fit into</p>
</div>
<div>
<p class="MsoNormal">> the OMERO eco-system?</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I agree that this functionality would work well as a Bio-Formats reader.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Regards,</p>
</div>
<div>
<p class="MsoNormal">Curtis</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On Wed, Nov 28, 2012 at 5:11 AM, Munro, Ian <<a href="mailto:i.munro@imperial.ac.uk" target="_blank">i.munro@imperial.ac.uk</a>> wrote:</p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Hello all<br>
<br>
Please find attached a document describing where the work of the Imperial satellite currently stands.<br>
We've reached a point where our group is making decisions, regarding the handling of data with a 6th dimension,
<br>
that may well have future  implications for  the OMERO clients or for other groups working with 5+ dimensions.<br>
<br>
As  a result we're looking for any feedback/improvements that anyone can offer on our current approach<br>
In particular the 3 areas  highlighted on the second page of the document.<br>
<br>
Thanks in advance for your time.<br>
<br>
Ian<span style="color:#888888"><br>
<br>
<br>
<br>
Ian</span></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt"><br>
<br>
</span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
ome-devel mailing list<br>
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.openmicroscopy.org.uk</a><br>
<a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a></p>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
<br>
The University of Dundee is a registered Scottish Charity, No: SC015096
</body>
</html>