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

Tue Aug 25 22:02:15 BST 2009

Hi Nick,

1. I noticed that I can successfully import .ics files for FLIM data.
> However, they can't be visualized within the OMERO server (understandably
> since I imagine the algorithm for reconstruction images isn't design for
> FLIM data).

ICS is a flexible file format, capable of representing many dimensional
organizations. While OMERO (Bio-Formats) is capable of importing ICS data,
it may not get the dimensional structure right in every case. In the case of
FLIM data, it is assuredly wrong, because the OME data model does not yet
support the FLIM dimensions of phase & frequency (in the case of frequency
domain) and time bin (in the case of time domain).

You can use the Bio-Formats command line tools (
http://www.loci.wisc.edu/ome/formats-tools.html) to study how metadata is
being mapped from the original structure into the standardized OME model.
Try this command:

  showinf myData.ics -nopix -omexml

The -nopix flag instructs Bio-Formats to skip reading any pixel data, and
the -omexml flag instructs it to standardize the metadata into the OME data
model.

Towards the end of the output, you will see a block of text bracketed by
"<OME>" and "</OME>" that describes the standardized dimensional structure.
You can also check the SizeC, SizeZ and SizeT values in the "core metadata"
output near the top. My guess is that at the moment, Bio-Formats is
inappropriately compacting the phase and frequency dimensions into one or
more of the Z, C and T dimensions, or else dropping them completely. Either
way, the information subsequently pulled into the OMERO database is invalid.

Now, until FLIM data, which is 7 dimensional, is somehow fit into the
> OME-TIF data model (which would likely require a change in the OME-TIF
> specification itself), I wonder if the FLIM data can just be stored on OMERO
> servers as .ics files?

OMERO is capable of preserving the original data files. However, its primary
function is to digest the data (both pixels and metadata) into a
standardized form. Bio-Formats converts the metadata into an OME data
structure, which is then used to populate the OMERO database. It also
decodes the pixels and stores them into a raw pixels repository on disk, for
efficient access later.

Since the OME data model does not yet support the FLIM-specific dimensions,
this digestion will mangle the dimensional parameters of your data.

Does the OMERO server do anything to change these files as it tries to
> interpret them? Or does it just store it like any data storage server would?
> Essentially, if I put the FLIM data which is incompatible to any sort of
> function OMERO uses right now into .ics files and upload them (they upload
> successfully according to importer) would OMERO just store them as they are
> and not tamper with the files in any way?

Hopefully the above explanation answers these questions. If not, please ask
for clarification and we will be happy to explain in more detail.

> If so, could I then access these files through API with analysis software
> acting as an OMERO client and edit the files themselves on the server?
>

With the OMERO API, you can: A) access the digested data for further
analysis with your software; and B) access the original, untouched ICS data.

In the case of A, the digested data is invalid, due to the lack of support
for FLIM. While your software could theoretically untangle any mangling that
occurred during import, it would make more sense to wait until OMERO
properly supports the FLIM dimensions.

In the case of B, your software could process the returned ICS data stream
exactly like an ICS file on disk. But in that case, it seems unnecessary to
go through the rigamarole of storing the files in OMERO in the first place.
Why not use a regular networked file system instead?

2. If I have software available that analyzes the specific FLIM data we use,
> how long would it take (best guess would do here; I just need some sort of
> concept of the scale of this type of project) to interface the OMERO server
> with this software via the OMERO API?
>

It depends on the software, and the type of integration desired. If it is
closed source, proprietary software from a vendor, then you have no control
over its feature set. However, assuming you are talking about in-house
and/or open source software, you have a way forward. One of the cool things
about OMERO is its use of Ice (http://www.zeroc.com/ice.html), allowing
cross-platform client access to the server from a number of different
programming paradigms including C++, Java, .NET, Python, PHP, Ruby, and
Objective-C.

There are different kinds of clients, as well. The server is capable of
delivering compressed, rendered image planes on demand, reducing the
processing burden on the client as well as the necessary network bandwidth
-- this approach is how the OMERO.insight client works. But the server can
also deliver raw image planes for the client to use with completely custom
processing.

I would also like to respond to some points you raised in an email to Kevin:

Part 1) Get LI-FLIM data inside OMERO (what you called the smart file
> server).
> Part 2) Add support for LI-FLIM analysis be in it the form of a module,
> direct implementation into the source code of OMERO, etc (I am more unclear
> at this point how this portion would work).
>

I agree that these two steps are what is needed. However, accomplishing Part
1 requires an extension to the OMERO data model, as described above, since
OMERO does more than just storing original data.

Part 1 is ideally what I could contribute to during the rest of my stay.
> Here is a more in-depth explanation of what I'm thinking:
>
> When you use the LI-FLIM system, you take both Sample and Reference images
> (stored in two separate files sample.fli and reference.fli). Each of these
> images is 7 dimensional in terms of the file format.
>

The first step on our end is to add support for the LI-FLIM (.fli) file
format. We have the specification and some sample data from Sander de Jong,
so it is only a matter of time until we have an initial implementation. I am
planning to work on it later this week, actually.

However, Bio-Formats must be able to successfully map the additional
dimensions into the OME data model before the files can be robustly imported
into an OMERO server. This means extending the OME-XML data model. The OMERO
developers have been actively discussing how to do so in recent weekly
meetings, passing proposals back and forth, etc., and will share these with
the community as soon as we have something reasonable.

Once you have collected the sample and reference files, right now you load
> them into the LI-FLIM analysis software and IMMEDIATELY a lifetime image is
> created. No analysis is done at this point. From this point, everything you
> need for analysis is contained within the lifetime file. This lifetime file
> is also the same file format as the sample and reference files were.
>
> On a side-note, just for completeness, it seems that the reason the LI-FLIM
> file format is 7 dimensions is so that the format is broad enough to hold
> reference/sample data and lifetime data, which are fundamentally different.
>

Right; I have not yet seen a file that actually uses all 7 dimensions
simultaneously.

Reference/sample data only use X, Y, Z, T, Phase, and Frequency (channel is
> always 1, at least as far as I can tell with my demo software, so Sander
> should confirm). These files are therefore 6 dimensional.
>

In the case of combined spectral lifetime (SLIM) data, where the emission
data is split across multiple wavelengths, channels could be greater than
one. Not sure if any Lambert systems are capable of this, but we (LOCI) have
a home-built system based on the Becker & Hickl time domain approach that
does SLIM.

Lifetime data uses only X, Y, Z, T, Channel (phase and frequency are always
> 1, but again need confirmation). So lifetime.fli files are 5 dimensional,
> and use the same dimensions as the OME-TIF. So as far as CRUCIAL metadata is
> concerned, the OME-TIF format suffices.
>

Right. Fundamentally, "lifetime data" means that the pixel values have been
computed to match the expected lifetime values. Presumably, in the case of
multiple lifetime values (e.g., two-component), the lifetime data files
would have multiple channels? Also, what about other parameters such as
maximum intensity at each pixel, or background at each pixel? (These values
are more applicable to time domain; I am still getting my head around
frequency domain so perhaps they are irrelevant to the frequency approach.)

The reason I thought it is useful to be able to put lifetime data into OMERO
> and be able to analyze that, as opposed to reference/sample data, is that as
> far as I can tell, the computer connected to the LI-FLIM hardware itself
> needs to run the LI-FLIM software.

There is no reason you shouldn't be able to perform analysis of the
reference/sample data after the fact. So ideally we would like to support
storing the reference/sample data into the OMERO system.

I don't get the impression OMERO can control microscopes, but perhaps I'm
> wrong.

You are correct. OMERO is not intended as a tool for acquisition, though we
have made an effort to support data from many different acquisition systems,
including the open source Micro-Manager software.

As such, because we still need to be able to go through the LI-FLIM software
> at least initially, why not just let that software compile the raw
> sample/reference data into the lifetime data, which can readily fit into the
> existing OME data model since it uses the same 5 dimensions? This would save
> the hassle (at least for now) of re-designing the entire datamodel for
> OME-TIF.

Sure, makes sense.

> Once the lifetime image is collected on the LI-FLIM software running the
> hardware, then, that software could just save the lifetime data into the
> OME-TIF format since that's the only important file for image analysis at
> this point (per Sander's confirmation), and save the reference/sample data
> as .ics. Then all 3 files could be put into OMERO which would ultimately
> develop analysis tools (Sander could help here?) for analyzing the lifetime
> file.

Storing the reference/sample data as ICS and into the OMERO server is asking
for trouble at the moment, as explained above.

 That's how I figured the workflow would work anyway - the LI-FLIM software
> connected to the FLIM hardware just outputs the lifetime file, which would
> go into OMERO for storage and analysis, and which stores reference/sample
> .ics files for completeness.

There is an attachment mechanism in OMERO, to store arbitrary binary data
(such as PDFs, PPTs, etc.) along with an image. If you are intent on this
workflow, perhaps it would make more sense to store the original FLI files
as binary attachments, rather than parsing them in any way at the moment.
Then they would still be recoverable for processing with the LI-FLIM
software at a later time.

This also solves the metadata storage issue because all the metadata from
> the reference/sample files is in the lifetime file as well. And this data
> can easily just be put into the XML part of the OME-TIF (it's hardware stuff
> only, like something=x, something=y, etc.).
>

We still need to define a mapping from the FLI hardware metadata into the
standard OME data model. Best would be if the LI-FLIM software could export
to OME-TIFF -- but it doesn't do that now, does it? We will also want to do
the mapping in Bio-Formats, as an FLI file format reader, so that OMERO (and
other software packages that use Bio-Formats) can import the original FLI
files properly.

HTH,
Curtis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20090825/66ccfee2/attachment-0001.htm 