Confocal Microscopy List

OME Compliant Specification

Classic

List

Threaded

8 messages Options

Jason Swedlow

OME Compliant Specification

Dear All-

Today, we are publishing a commentary on file formats in the Journal
of Cell Biology. The full text is available at:

http://jcb.rupress.org/content/189/5/777

The article represents OME's position on the continued explosion of
file formats in biological imaging. As we move towards more complex
data, greater opportunities for data sharing and collaboration, and
rapidly developing image repositories, we strongly contend that the
current situation must evolve. New file formats should not be created
with every new software release. At the very least, the option of
writing data to open, standardized file formats must be supported in
all software, whether open or proprietary. We understand that
exceptional cases exist where specialized image data or metadata
require proprietary, custom formats. However, our experience with
OME-XML and Bio-Formats suggests that the great majority of metadata
can be supported in open data formats. For this reason, we believe
that the option of writing image data to an open file format that
includes support for image acquisition metadata should be mandatory in
all imaging software.

Our article contains a number of recommendations for driving use of
standardized file formats. Most importantly, we believe that those
who decide on which platforms to invest in should use their purchasing
power to demand support for open file formats. Realistically, this is
the only way these file formats will be universally used and
supported.

In this article, we have announced a new spec, the OME Compliant
Specification. This simply uses standard OME-XML, and requires that
all components of the Image Element are filled in. We see this as a
first step towards a more complete set of metadata for imaging. The
documentation for the OME Compliant Specification is at:

http://ome-xml.org/wiki/CompliantSpecification

A key point is that an 'OME Compliant' file is as complete as
possible, but only contains metadata relevant to a specific imaging
experiment. The expectation is not that every field is filled out
regardless of the experiment, but that all fields that are relevant to
an experiment are completed. As an example, PockelCellSetting would
not be used in most wide-field microscopy experiments, but would be
mandatory for many multi-photon imaging experiments. The goal of that
'best-effort' should be to document an experiment as completely as
possible, so another person could, with the same sample and
microscope, reproduce the data recorded in the file.

OME's own file formats, OME-XML and OME-TIFF are well exercised and
supported by a number of commercial vendors
(http://openmicroscopy.org/site/support/about/partners). We continue
to work to develop and support these formats, and welcome any and all
feedback on their design, use, and documentation. However, we
recognize that OME-XML and OME-TIFF do not fulfill all requirements
for all imaging experiments. Many others (ICS, DICOM, NifTI) are
available and will be more or less appropriate, depending on a
specific experiment. Individual scientists should decide which of
these formats must be supported, and which they will use. The
critical point is that image data and metadata are complete and openly
available for viewing and analysis.

We appreciate any and all feedback on this issue.

As always, thanks for your support.

Cheers,

Jason

--
**************************
Wellcome Trust Centre for Gene Regulation & Expression
College of Life Sciences
MSI/WTB/JBC Complex
University of Dundee
Dow Street
Dundee DD1 5EH
United Kingdom

phone (01382) 385819
Intl phone: 44 1382 385819
FAX (01382) 388072
email: [hidden email]

Lab Page: http://gre.lifesci.dundee.ac.uk/staff/jason_swedlow.html
Open Microscopy Environment: http://openmicroscopy.org
**************************

Mark Cannell

Re: OME Compliant Specification

Jason Swedlow wrote:

> Dear All-
>
> Today, we are publishing a commentary on file formats in the Journal
> of Cell Biology. The full text is available at:
>
> http://jcb.rupress.org/content/189/5/777
>
> The article represents OME's position on the continued explosion of
> file formats in biological imaging. As we move towards more complex
> data, greater opportunities for data sharing and collaboration, and
> rapidly developing image repositories, we strongly contend that the
> current situation must evolve. New file formats should not be created
> with every new software release.

Hi Jason,

With respect, isn't this also introducing yet another "non-standard"
format? I don't think your "specification" fits some of the new imaging
modalities and contains no validation information (to help stop data
fabrication). I think this is a weakness of your suggested standard
-let alone security issues.

I can't help wonder why you did not consider pushing/using an existing
_scientific image_ format, such as FITS -just look at the huge amount
of work by the IAS to establish that scientific image data format? Since
FITS is established, tightly controlled and can hold (as far as I know)
all the data necessary to define machine/modality/processing why did you
pick the 'XML bandwagon'?

Please don't get me wrong, I'm not saying that your effort in trying to
establish a standard for scientific imaging files is not worthwhile and
needed but the specification just seems too focussed on some current
confocal modalities...

Many regards Mark

Jean-Yves Tinevez-3

Re: OME Compliant Specification

In reply to this post by Jason Swedlow

On May 31, 2010, at 4:59 PM, Jason Swedlow wrote:

Dear All-

Today, we are publishing a commentary on file formats in the Journal
of Cell Biology. The full text is available at:

[snip.]

New file formats should not be created
with every new software release. At the very least, the option of
writing data to open, standardized file formats must be supported in
all software, whether open or proprietary. We understand that
exceptional cases exist where specialized image data or metadata
require proprietary, custom formats.

Hi Jason.

Fantastic work; the paper is excellent.

But maybe we could turn the above fact upside down, and ask questions to manufacturers:

- If you are a software engineer working for a microscope company, why did you chose to create a new file format instead of using existing, open ones?

- Is there missing features, e.g. in OME specification that made you chose to go for your own?

- If they were implemented in OME 'tomorrow', will your product go for OME format?

I guess there is people working for Zeiss, Leica, Olympus, etc.. reading this mailing-list. Maybe they could care to give us a clue as why?

Best

Jean-Yves Tinevez

PFID - Imagopole

Institut Pasteur

25-28, rue du Docteur Roux

75724 Paris cedex 15

France

tel: +33 1 40 61 31 77

Michael Weber-4

Re: OME Compliant Specification

JY,

manufacturers might prefer a proprietary file format because
(a) it binds the customer to proprietary software sold by the same company
and (b) its development/future remains under control of the company.
I am pretty sure that the majority of customers uses image processing
software that comes with the microscope, or is at least distributed by the
same manufacturer. And the latter might fear unforeseeable developments of
the file format, such as a sudden death.

Don't get me wrong, I like the idea of a standardized file format for
microscopy, but I doubt that it will ever come - at least not as a direct
output of a company's acquisition software. The situation is quite
comparable to the photography market: every manufacturers has its own raw
format, a group of customers screams for support of a standardized format
such as png, but nothing really changes. A reasonable way (or
work-around?) would be to have a converter which automatically turns the
proprietary files into a single file format. In fact it does exist in form
of Bio-Formats.

Michael

> On May 31, 2010, at 4:59 PM, Jason Swedlow wrote:
>
>> Dear All-
>>
>> Today, we are publishing a commentary on file formats in the Journal
>> of Cell Biology. The full text is available at:
>>
>
> [snip.]
>
>> New file formats should not be created
>> with every new software release. At the very least, the option of
>> writing data to open, standardized file formats must be supported in
>> all software, whether open or proprietary. We understand that
>> exceptional cases exist where specialized image data or metadata
>> require proprietary, custom formats.
>
> Hi Jason.
> Fantastic work; the paper is excellent.
> But maybe we could turn the above fact upside down, and ask questions
> to manufacturers:
> - If you are a software engineer working for a microscope company, why
> did you chose to create a new file format instead of using existing,
> open ones?
> - Is there missing features, e.g. in OME specification that made you
> chose to go for your own?
> - If they were implemented in OME 'tomorrow', will your product go for
> OME format?
>
> I guess there is people working for Zeiss, Leica, Olympus, etc..
> reading this mailing-list. Maybe they could care to give us a clue as
> why?
>
> Best
> jy
>
>
>
>
> --
> Jean-Yves Tinevez
> PFID - Imagopole
> Institut Pasteur
> 25-28, rue du Docteur Roux
> 75724 Paris cedex 15
> France
> tel: +33 1 40 61 31 77

Jason Swedlow

Re: OME Compliant Specification

In reply to this post by Mark Cannell

Hi Mark-

Thanks much for your email-- very important questions. Answering in turn:

1. Aren't we just creating yet another format? Who needs that?

No, it's not another new format-- it's been around since 2004, and was
first 'published' in 2005:

http://genomebiology.com/2005/6/5/R47

It's supported by a number of commercial manufacturers:

http://www.openmicroscopy.org/site/support/about/partners

(and that list is increasing rapidly)

We aim to update the underlying model for this spec at least twice per year:

http://ome-xml.org/roadmap?show=all

In this 'Compliant Specification, we haven't changed anything, aside
from our regular updates and fixes. However, we do recognize that
that the full spec is alot to work with, and have been told repeatedly
that it is too large, too comprehensive (see below), and too much to
deal with (see http://ome-xml.org/browser/Schemas/OME/2010-04/ome.xsd),
and have been asked repeatedly to provide a recommendation on some
subset of the spec that 'should be' used.

Some time ago, after alot of discussion, we released a 'Minimal
Specification' (http://ome-xml.org/wiki/MinimumSpecification). This
is TRULY minimal-- it's what you need to display an image (in a
technical sense), and nothing more. Is this useful? That's
debatable, but it seemed to be a necessary starting point for
adoption. The 'Compliant' specification developed after alot
experience with many thousands of files donated to the Bio-Formats
repository and submitted to the JCB DataViewer-- it's the result of
alot of practical experience with what most people seem to be doing.

2. OME-XML doesn't fit some new imaging modalities-- why not?

For sure. Any specification will necessarily be behind the cutting
edge. We welcome feedback, and update the spec at least twice/year,
more often if necessary. However, we ONLY make changes if we have
authoritative information on how to model a new imaging mode. In
other words, this takes community input and comment. We've had lots
of comments and criticism (e.g., modeling multi-line TIRF, etc.) and
always welcome more. See http://www.openmicroscopy.org/site/community
for ways to contribute. You are also welcome to use this list-- some
of the OME gang follow this list as well.

In short, be specific, and hit us hard-- we'll respond.

3. Validation? See http://validator.openmicroscopy.org.uk. Also,
Bio-Formats (http://www.openmicroscopy.org/site/products/bio-formats)
has command line validation tools. Ask if you need more info.

4. Security? Let us know specifically what you're thinking of. This
is often discussed, and the use cases for security are complex. We'd
prefer to put this security into the applications that use these file
formats, but welcome other ideas.

5. Too focused on confocal? We try to be as broad as possible, but
we are certainly behind some of the latest innovations, as it always
takes time to define what is in fact necessary to properly document a
specific mode of imaging. We ARE too focused on fluorescence-- we
don't do DIC or Pol very well. Any specific suggestions are most
welcome.

6. Why not FITS?? Well, sure. Why not DICOM? HDF5? plain old
TIFF?? or any others (there are many, and each has its proponents)?
Each of those can certainly satisfy many of the requirements
microscopy has, and in some cases (e.g., DICOM) has made explicit
attempts to support biological microscopy.

There's a very important distinction to make here-- between the vessel
that stores the data (the file itself) and the structure of the
metadata. Starting with the first release of OME-XML, we made the
strategic decision to NOT specify the file format, but to focus on the
metadata only. This decision was simply the obvious and expedient
one-- as you point out, there were then, and are now, a multitude of
ways to store image data, and they are used for different applications
for good reasons. We shouldn't get in the business of arbitrating
that issue (Tom Leher's 'National Brotherhood Week' comes to mind).
However, in OME, we believe there should be a common way of expressing
the metadata that can be used in any vessel, or even live on its own
as a separate entity. FITS uses key-value pairs and doesn't provide
the flexibility we believe is necessary. XML provides a standardised
structure that can be well-documented, is supported in all software
environments, can be transformed, versioned, and converted into other
useful structures (like databases), and can also live on its own in a
known file. I am pretty sure that OME-XML could be added to the FITS
ASCII header, if that's what you wanted to do (I'm not sure of this,
and would defer to others on this).

As an example, we actively support OME-TIFF
(http://www.ome-xml.org/wiki/OmeTiff), which takes standard TIFF, and
adds OME-XML to the header. Why TIFF? Expediency. Most common lab
image processing programmes read TIFF, and TIFF can be used to store
single images, multiple image arrays, etc. Available libraries for
TIFF are well-optimised and openly available. OME-TIFF files can be
read by any software that reads TIFF (although it might not read the
metadata). In a similar vein, we are considering actively supporting
OME-HDF5, but there are some technical issues to consider. BTW, you
can write OME-TIFF from ImageJ using the Bio-Formats plug-in. Many
commercial software vendors now also write OME-TIFF.

Isn't this flexibility self-defeating? We don't think so. First,
it's simply unrealistic to believe that the whole microscopy and
bioimaging community will accept a single file format. There are too
many strongly held views (in most cases, legitimately), too wide an
array of applications, and much too rapid innovation. However, we do
believe a standardised metadata model can be used across at least most
of these domains, especially if we keep evolving the model and the
tools that support it.

How can live with so many different flavors of image files? That's
(relatively) simple-- Bio-Formats. It already supports a huge panoply
of file formats. If we standardized metadata, maintaining Bio-Formats
would be SOOOOOOO much easier. That's the point we were trying to
make in our article.

And if you've got a better idea, let us know. Any and all feedback welcome.

Hope that helps.

Cheers,

Jason

On Mon, May 31, 2010 at 10:31 PM, Mark Cannell <[hidden email]> wrote:

>
> Hi Jason,
>
> With respect, isn't this also introducing yet another "non-standard" format?
> I don't think your "specification" fits some of the new imaging modalities
> and contains no validation information (to help stop data fabrication). I
> think this is a weakness of your suggested standard -let alone security
> issues.
>
> I can't help wonder why you did not consider pushing/using an existing
> _scientific image_ format, such as FITS -just look at the huge amount of
> work by the IAS to establish that scientific image data format? Since FITS
> is established, tightly controlled and can hold (as far as I know) all the
> data necessary to define machine/modality/processing why did you pick the
> 'XML bandwagon'?
>
> Please don't get me wrong, I'm not saying that your effort in trying to
> establish a standard for scientific imaging files is not worthwhile and
> needed but the specification just seems too focussed on some current
> confocal modalities...
> Many regards Mark
>

--
**************************
Wellcome Trust Centre for Gene Regulation & Expression
College of Life Sciences
MSI/WTB/JBC Complex
University of Dundee
Dow Street
Dundee DD1 5EH
United Kingdom

phone (01382) 385819
Intl phone: 44 1382 385819
FAX (01382) 388072
email: [hidden email]

Lab Page: http://gre.lifesci.dundee.ac.uk/staff/jason_swedlow.html
Open Microscopy Environment: http://openmicroscopy.org
**************************

Jason Swedlow

Re: OME Compliant Specification

In reply to this post by Jean-Yves Tinevez-3

Hi Jean-Yves:

Thanks. Remember, many of the commercial vendors already support
output to OME formats, and more are working on it now. We welcome any
feedback, especially on quality of documentation and support. We're
not done with this by a long shot, so any suggestions most welcome.
We've already had great feedback from a number of commercial
developers and always welcome more.

Cheers,

Jason

On Tue, Jun 1, 2010 at 8:01 AM, Jean-Yves Tinevez <[hidden email]> wrote:

>
> On May 31, 2010, at 4:59 PM, Jason Swedlow wrote:
>
> Dear All-
>
> Today, we are publishing a commentary on file formats in the Journal
> of Cell Biology. The full text is available at:
>
>
> [snip.]
>
> New file formats should not be created
> with every new software release. At the very least, the option of
> writing data to open, standardized file formats must be supported in
> all software, whether open or proprietary. We understand that
> exceptional cases exist where specialized image data or metadata
> require proprietary, custom formats.
>
> Hi Jason.
> Fantastic work; the paper is excellent.
> But maybe we could turn the above fact upside down, and ask questions to
> manufacturers:
> - If you are a software engineer working for a microscope company, why did
> you chose to create a new file format instead of using existing, open ones?
> - Is there missing features, e.g. in OME specification that made you chose
> to go for your own?
> - If they were implemented in OME 'tomorrow', will your product go for OME
> format?
> I guess there is people working for Zeiss, Leica, Olympus, etc.. reading
> this mailing-list. Maybe they could care to give us a clue as why?
> Best
> jy
>
>
>
> --
> Jean-Yves Tinevez
> PFID - Imagopole
> Institut Pasteur
> 25-28, rue du Docteur Roux
> 75724 Paris cedex 15
> France
> tel: +33 1 40 61 31 77
>
>
>
>

Jason Swedlow

Re: OME Compliant Specification

In reply to this post by Michael Weber-4

Hi Michael-

Fully agreed; see response to Mark Cannell.

It's exactly why we do all the specification work AND develop,
maintain and release Bio-Formats (see
http://www.openmicroscopy.org/site/products/bio-formats for more
info).

Cheers,

Jason

On Tue, Jun 1, 2010 at 8:43 AM, Michael Weber <[hidden email]> wrote:

> JY,
>
> manufacturers might prefer a proprietary file format because
> (a) it binds the customer to proprietary software sold by the same company
> and (b) its development/future remains under control of the company.
> I am pretty sure that the majority of customers uses image processing
> software that comes with the microscope, or is at least distributed by the
> same manufacturer. And the latter might fear unforeseeable developments of
> the file format, such as a sudden death.
>
> Don't get me wrong, I like the idea of a standardized file format for
> microscopy, but I doubt that it will ever come - at least not as a direct
> output of a company's acquisition software. The situation is quite
> comparable to the photography market: every manufacturers has its own raw
> format, a group of customers screams for support of a standardized format
> such as png, but nothing really changes. A reasonable way (or
> work-around?) would be to have a converter which automatically turns the
> proprietary files into a single file format. In fact it does exist in form
> of Bio-Formats.
>
> Michael
>
>
>> On May 31, 2010, at 4:59 PM, Jason Swedlow wrote:
>>
>>> Dear All-
>>>
>>> Today, we are publishing a commentary on file formats in the Journal
>>> of Cell Biology. The full text is available at:
>>>
>>
>> [snip.]
>>
>>> New file formats should not be created
>>> with every new software release. At the very least, the option of
>>> writing data to open, standardized file formats must be supported in
>>> all software, whether open or proprietary. We understand that
>>> exceptional cases exist where specialized image data or metadata
>>> require proprietary, custom formats.
>>
>> Hi Jason.
>> Fantastic work; the paper is excellent.
>> But maybe we could turn the above fact upside down, and ask questions
>> to manufacturers:
>> - If you are a software engineer working for a microscope company, why
>> did you chose to create a new file format instead of using existing,
>> open ones?
>> - Is there missing features, e.g. in OME specification that made you
>> chose to go for your own?
>> - If they were implemented in OME 'tomorrow', will your product go for
>> OME format?
>>
>> I guess there is people working for Zeiss, Leica, Olympus, etc..
>> reading this mailing-list. Maybe they could care to give us a clue as
>> why?
>>
>> Best
>> jy
>>
>>
>>
>>
>> --
>> Jean-Yves Tinevez
>> PFID - Imagopole
>> Institut Pasteur
>> 25-28, rue du Docteur Roux
>> 75724 Paris cedex 15
>> France
>> tel: +33 1 40 61 31 77
>

Emmanuel Gustin

Re: OME Compliant Specification

In reply to this post by Michael Weber-4

For a slightly more optimistic view, allow me to refer to flow cytometry:
The ISAC-defined FCS format (currently 3.0) is widely supported, AFAIK
by most instruments currently on the market. It has some gaps, for example
there is a lack of conventions for file naming and storing well coordinates
for the increasing number of instruments with autosamplers. Nevertheless,
if you read the file format specification carefully, it is possible to
write code that will read the output of instruments of a number of
different suppliers, and equally important, different generations of
instrument as well.

A good standardized format needs to be flexible and allow space for people
who need to store extra data in addition to those foreseen (as required or
optional) by the standard. I think a well-designed standard would actually
be welcome to most software developers at imaging companies, because defining
a really good file format is not easy. (In the past -- no reflection on
present company -- I've found quite a few nasty surprises in proprietary
file formats.) We should not hope to cover 100% with any standard format,
but 80% would already be a big step forward.

And in fairness, it should be pointed out that in recent years, the
manufacturers *have* become open to the idea: Today the problem is more
the inability of the user community to set up a strong representation and
agree on what they actually want. Or to find funding for the development
of a standard.

I think that is surprising, because the need of standard data formats in
biological imaging is quite high. All but the smallest laboratories and
teams have different types of instruments, optimal for specific application
ranges, and they need to be able to analyze, manage and review data in
a somewhat consistent manner. That forces many groups to adopt some kind
of internal "standard" anyway, and they can't always make good choices.

I suspect a factor here is that data standards tend to go hand in hand with
quantitative analysis, and so much imaging is still only qualitative.

My personal view is very strongly that I want the *primary* output of an
instrument, any instrument, to be in a open format that can at least
be read without great effort; it should be well-documented and well-designed.
The ability to convert data from a proprietary format to a secondary export
format is at best a stop-gap, *especially* for large volumes of data. (But
I particularly loathe "exports to Excel" that generate files without proper
headers and often no predictable structure.)

Best Regards,

Emmanuel

--
Emmanuel Gustin, Tel. (+32) 15 46 1586, e-mail: [hidden email]

-----Original Message-----
From: Confocal Microscopy List [mailto:[hidden email]] On Behalf Of Michael Weber
Sent: dinsdag 1 juni 2010 09:44
To: [hidden email]
Subject: Re: OME Compliant Specification

JY,

manufacturers might prefer a proprietary file format because
(a) it binds the customer to proprietary software sold by the same company
and (b) its development/future remains under control of the company.
I am pretty sure that the majority of customers uses image processing
software that comes with the microscope, or is at least distributed by the
same manufacturer. And the latter might fear unforeseeable developments of
the file format, such as a sudden death.

Don't get me wrong, I like the idea of a standardized file format for
microscopy, but I doubt that it will ever come - at least not as a direct
output of a company's acquisition software. The situation is quite
comparable to the photography market: every manufacturers has its own raw
format, a group of customers screams for support of a standardized format
such as png, but nothing really changes. A reasonable way (or
work-around?) would be to have a converter which automatically turns the
proprietary files into a single file format. In fact it does exist in form
of Bio-Formats.

Michael