Hi Ian,<div><br></div><div><div>> Clearly you have a better feel for the downsides of the ModuloAlong?</div><div>> solution than we do so can I ask how you intend to store your data in</div><div>> OMERO?</div></div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Regards,</div><div>Curtis</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 30, 2012 at 11:44 AM, Munro, Ian <span dir="ltr"><<a href="mailto:i.munro@imperial.ac.uk" target="_blank">i.munro@imperial.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
Hi Curtis
<div><br>
</div>
<div>Thans for the feedback. It's much appreciated.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>In the shorter term I think we need to use the same strategy to store data in OMERO.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div><br>
</div>
<div>Regards</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Ian</div></font></span><div><div class="h5">
<div> </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>On 28 Nov 2012, at 20:10, Curtis Rueden wrote:</div>
<br>
<blockquote type="cite">Hi Ian,
<div><br>
</div>
<div>
<div>Thanks for this update; very informative. It looks like you have done a lot to bring FLIM processing into OMERO, which is great.<br>
</div>
</div>
<div><br>
</div>
<div>I want to draw your attention to some very similar work we are doing within ImageJ:</div>
<div> <a href="http://loci.wisc.edu/software/slim-plugin" target="_blank">http://loci.wisc.edu/software/slim-plugin</a></div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>
<div>> The Imperial/Photonics Group’s main FLIM analysis software is</div>
<div>> internally named “GlobalProcessing”. It is written in MATLAB and</div>
<div>> provides state of the art fitting of time domain data for both</div>
<div>> laser-scanning time-correlated single photon (TCSPC) and wide-field</div>
<div>> time-gated FLIM images.</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>> 1) We intend to standardise on encoding FLIM data using ModuloAlongT.</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>> 2) Where should the functionality currently in IC-importer fit into</div>
<div>> the OMERO eco-system?</div>
</div>
<div><br>
</div>
<div>I agree that this functionality would work well as a Bio-Formats reader.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Curtis</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Nov 28, 2012 at 5:11 AM, Munro, Ian <span dir="ltr">
<<a href="mailto:i.munro@imperial.ac.uk" target="_blank">i.munro@imperial.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div><font><span style="font-size:10pt">
<div>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><font color="#888888"><br>
<br>
<br>
<br>
Ian</font></span></div>
</span></font></div>
<div><font><span style="font-size:10pt">
<div><br>
<br>
<br>
</div>
</span></font></div>
</div>
<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><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div></div></div>
</blockquote></div><br></div>