[ome-devel] Uploading ICS files into OMERO and OMERO client API questions

[Curtis Rueden]

Hi Nick,

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

The latest working/draft version of the OME-XML schemas can be found here:

  http://ome-xml.org/browser/Xml/Working/

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).

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.

Our ideas about the new OME-XML/OME-TIFF:
>
> 1. Should be 'N' dimensional.
>
*snip*

2. In order to have any useful analysis, we think that OMERO should specify
> some "standard" dimensions.

*snip*
>

Yes, this is essentially one of the five proposals currently under
discussion, and my personal preference as well. :-)

3. Sander also suggested that it be possible for vendors to register
> dimensions.

*snip*
>

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.

Also, here are the answers you specifically had for LI-FLIM data:

*snip*


Thanks, makes sense.

-Curtis

On Wed, Aug 26, 2009 at 6:36 AM, Nick Perry <nperry at stanford.edu> wrote:

> Hi Curtis,
>
> 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?
>
> Our ideas about the new OME-XML/OME-TIFF:
>
> 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:
>
> 1. The total number of dimensions
> 2. The size of every dimension
> 3. The data type of a single data element
>
> 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.
>
> 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).
>
> 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:
>
> Dimension 0 has size 2 and is the "Channel"
> Dimension 1 has size 100 and is the "X"-dimension (width of image)
> Dimension 2 has size 200 and is the "Y"-dimension
> Dimension 3 has size 12 and is the "Phase" dimension
> Dimension 4 has size 30 and is the "Time" dimension
>
> 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.
>
> Also, here are the answers you specifically had for LI-FLIM data:
>
> 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.
> 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.
>
> 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.
>
> 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.
>
> If those need clarification, let me know.
>
> Thanks again,
> Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20090831/34fb7c7e/attachment.htm