Hi Nick,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">After
talking it over on our side and with Sander, we just thought it might
be useful to chip in our ideas about the new OME-XML specification.
Before I get into that, however, could you fill us in on exactly what
the plans are as of now for the new OME-XML/OME-TIFF specifications? Or
if nothing is really concrete what the main ideas are that are being
mulled around?<br>
</blockquote><div><br>The latest working/draft version of the OME-XML schemas can be found here:<br><br> <a href="http://ome-xml.org/browser/Xml/Working/" target="_blank">http://ome-xml.org/browser/Xml/Working/</a><br> <br>
Andrew Patterson and the rest of the team have made many changes and improvements since the 2008-09 release. AFAIK, we are planning another release very soon (2009-09 or 2009-10, probably).<br>
<br>Regarding expanding the model to handle lifetime data, we are still arguing internally. There have been at least five different proposals thrown around with various pros and cons. Once we have reduced it to a couple of more carefully considered options, we plan to poll the community for their input as well.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Our ideas about the new OME-XML/OME-TIFF:<br><br>1. Should be 'N'
dimensional.<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> *snip*</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. In order to have any useful analysis, we think that OMERO should
specify some "standard" dimensions. </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">*snip*<br>
</blockquote><div><br>Yes, this is essentially one of the five proposals currently under discussion, and my personal preference as well. :-)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3. Sander also suggested that it be possible for vendors to
register dimensions.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> *snip*<br></blockquote><div><br>Potentially. However, we would prefer to simply add support for new modalities as they emerge. Once we have an N-dimensional system in place there should not be much of a delay on such additions. We want to avoid having the schema be directly associated with any specific vendor -- e.g., the idea of "Phase" should not be directly owned by or affiliated with any particular company.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, here are the answers you specifically had for LI-FLIM data:</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
*snip*</blockquote><div><br>Thanks, makes sense.<br><br></div>-Curtis<br></div><br><div class="gmail_quote">On Wed, Aug 26, 2009 at 6:36 AM, Nick Perry <span dir="ltr"><<a href="mailto:nperry@stanford.edu" target="_blank">nperry@stanford.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Curtis,<br><br>After talking it over on our side and with Sander, we just thought it might be useful to chip in our ideas about the new OME-XML specification. Before I get into that, however, could you fill us in on exactly what the plans are as of now for the new OME-XML/OME-TIFF specifications? Or if nothing is really concrete what the main ideas are that are being mulled around?<br>
<br>Our ideas about the new OME-XML/OME-TIFF:<br><br>1. Should be 'N' dimensional. The obvious perk of this system is that it allows for any sort of microscopy in the future which could hypothetically utilize dimensions unknown at this time. Thus we will avoid having similar 'FLIM' compatibility issues like this
in the future. One point that I know Sander wanted to mention is that
it is both possible and trivial to efficiently extract ANY
2-dimensional plane from the N-dimensional data. To be able to do this, all the data file would need to have stored somewhere is: <br><br>1. The total number of dimensions<br>2. The size of every dimension<br>3. The data type of a single data element<br>
<br>Having this information stored somewhere in the data file would allow both extraction of planes as well as the ability to display the images (for insight, for example). Again this just means even if the data model is expanded N-dimensionally it's still possible to easily create the 2d images in OMERO simply by extracting 2 planes. No knowledge of what the two planes mean is necessary.<br>
<br>2. In order to have any useful analysis, we think that OMERO should specify some "standard" dimensions. This specification would require client software to implement this basic set of dimensions, for example X, Y, Z, Time, Channel. With what's mentioned above, this software could still display unknown dimensions even if it doesn't know what they are (for example, it could still display images with something like phase even if it doesn't know what to do with it).<br>
<br>3. Sander also suggested that it be possible for vendors to register dimensions. For example, somewhere in the meta data of the new OME-TIFF should be the following:<br><br><div dir="ltr" align="left"><span><font face="Arial" size="2">Dimension 0 has size 2 and is the "Channel"</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Dimension 1 has size 100 and is the "X"-dimension (width of
image)</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Dimension 2 has size 200 and is the "Y"-dimension</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Dimension 3 has size 12 and is the "Phase"
dimension</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Dimension 4 has size 30 and is the "Time"
dimension<br><br>Dimensions 0, 1, 2, 4 are 'standard.' However, Dimension 3 would be registered, for example, and either the file spec or the website would say that the dimension is registered and who it is registered by. The point of this is so that there is an official and standardized way for companies to introduce new dimensions into OME and not have overlap or have each company creating it's own special dimensional name for the same type of data. That way new types of microscopy that enters and wants to be OME compatible will see the officially registered dimension names, which companies registered them (to see if they mean 'Phase' in the same way, for example) and either use that already registered dimension name or register their own if they need something different.<br>
</font></span></div><br>Also, here are the answers you specifically had for LI-FLIM data:<br><br>1. Can LI-FLIM
reference/sample files ever have more than 1 channel? Curtis brought up the
example of having spectral lifetime that used multiple channels.<span><font face="Arial" size="2"> </font></span>
<div><span></span> </div>
<div><span><font color="#0000ff" face="Arial" size="2">In
practice, Reference and Sample data only have a single channel right now,
because there currently are no LIFA camera's / systems in the field that
produce "multi-color" images. However, LI-FLIM should not have a problem
loading multi-channel reference and sample stacks. It probably won't calculate
lifetimes as I believe I put an artificial check in the software that
only allows single channel source data for lifetime
calculations. (multi-channel-data is currently never produced by current
LIFA systems, so that case is assumed to be an error). I can imagine
this 'artificial check' being removed in the future, allowing for
multi-spectral FLIM.</font></span></div><div><span></span>
<div><br>2. Does the lifetime file have anything about maximum intensity at
each pixel, or background at each pixel? I haven't seen either so I think not
but I thought I'd ask.<span><font face="Arial" size="2"> </font></span></div>
<div><span></span> </div>
</div><div><span><font color="#0000ff" face="Arial" size="2">No.
It does use the "NaN" (not-a-number) floating point value for
pixels that should be ignored (because the average intensity
fell below threshold for instance). And we know that lifetimes should
roughly be in the 0 ... 150 ns range (units are nanoseconds in the
lifetime image data) for LIFA lifetimes, and, say 150 - 10000 ns for the
LIFA-X. The 'intensity' channel is usually between 0 and
65535.</font></span><br><br>If those need clarification, let me know.<br><br>Thanks again,<br>Nick<span><font face="Arial" size="2"> </font></span><br></div></blockquote></div><br>