---

Below you will find a discussion of some common issues and questions relating to both LOCI's involvement in the Open Microscopy Environment (OME), and the OME project as a whole. For a basic overview of OME, please see the OME website, including the discussion of Why OME?, the OME File Formats overview, and the Getting Started/Tutorial software guide. If you still have general questions about OME after reading these documents, please feel free to ask on the ome-users mailing list, or contact Curtis Rueden and Kevin Eliceiri directly.

Topics: [ Bio-Formats | OME-TIFF and OME-XML | The OME Consortium | OME and OMERO ]

Why is LOCI developing Bio-Formats?

Bio-Formats's primary purpose is to convert proprietary microscopy data into an open standard called the OME data model, particularly into the OME-TIFF file format. See the Bio-Formats manifesto for a thorough explanation and rationale.

---

How do I get started using Bio-Formats?

To use Bio-Formats with ImageJ, just download loci_tools.jar and place it in the ImageJ plugins folder. Start ImageJ, click the Plugins menu, choose LOCI, then "Bio-Formats Importer," and choose a data file to import.

To use it as a library, you can use loci_tools.jar (it is a bundle containing all the functionality of Bio-Formats plus optional libraries), or you can use bio-formats.jar separately and download only those optional libraries you need. We have created a guide to using Bio-Formats as a library that will hopefully be useful to you. For further details, see the Bio-Formats web page.

---

How do I add support for a file format to Bio-Formats?

Bio-Formats is an open project, and as such we strongly encourage other developers to contribute file format reader modules. Our time is limited, and we can use all the help we can get. We have created a guide to coding new file format readers that will hopefully be useful to you in your endeavor, and we would be happy to assist you with any questions or problems you encounter—just email us.

---

How can I cooperate with the Bio-Formats developers to improve support for a format?

If you are a programmer, you can help by writing and contributing a file format reader module for Bio-Formats—see "How do I add support for a file format to Bio-Formats?" above.

If you are a user, but do not control the format, you can help by letting us know you are interested in the format, and sending us some sample data if possible. Several currently supported formats were added specifically because someone emailed us asking about them. We have an FTP server set up for users to upload large data to us—email us for details.

If you do control the format, you can start by releasing technical details to the community. Publishing a file format specification document, sample data files, and example source code to your web site is extremely useful for external developers to successfully deal with your format. Once you do, we invite you to let us know and we will be glad to work on adding support for the format as our time permits.

If you are a company unwilling to release details publically, we urge you to reconsider—see "Why should my company open our file format to the community?" below. If you insist upon keeping your format secret, you could implement your own Bio-Formats file format reader module to enable support in third party applications such as ImageJ, OME and VisBio. Or you could send technical details to the Bio-Formats developers, who will attempt to add support for it, as time permits.

---

Why should my company open our file format to the community?

You may feel that by concealing the details of your format, you can "lock in" your customers to a particular software package, or protect your organization in case of errors, but hiding your format has drawbacks:

1. You will generate animosity among your users when they cannot easily perform needed operations on their data. As a result, your users may switch to another vendor, or even build their own systems, the next time they upgrade their hardware (or perhaps even immediately).


2. Your format will almost certainly be reverse engineered anyway, unless you poison your format by hiding behind the DMCA or similar law, in which case your format will be unusable and customers will abandon it completely. Since a reverse-engineered implementation is less likely to completely and correctly reflect the quality and depth of your format, it would be more in your interest to assist the community in an open implementation, or at least provide them with a specification document so that they can create one themselves.

What is OME-XML, and how does it relate to OME-TIFF?

See the OME-XML web site for a quick introduction to OME-XML and OME-TIFF.

Why TIFF? What about other container formats?

The one word answer is: compatibility. TIFF files are readable in a large number of existing software tools, and when coupled with OME-XML also flexible enough to accommodate the needs of the microscopy imaging community.

That said, OME-TIFF is merely one example of an alternate pixels container for OME-XML metadata; others are certainly possible. If you do not like TIFF for some reason, you can use the OME-XML format directly, or utilize a different container format. However, we urge you to consider using the OME-XML standard for metadata, rather than creating yet another incompatible metadata representation.

OME-XML is insufficient to my group's needs, so we provide our own format instead. You'll support it via Bio-Formats anyway, right?

Such an attitude does not serve the best interests of the community, nor is it likely to be advantageous to you, ultimately. Supporting OME-TIFF directly will earn good karma points with your users/customers, while providing yet another impenetrable, incompatible format that makes your users feel trapped and powerless will certainly earn some bad karma.

As OME-XML becomes more prevalent, users will increasingly demand direct support for it at acquisition time. It makes more sense to provide this support yourself, rather than rely on a third party such as Bio-Formats to convert the data after the fact.

It may be that OME-XML does not encompass every piece of information you wish to record. However, you can work with the community to extend the specification to accommodate your needs. There are advantages to leveraging the community's efforts:

1. You developers will spend their time more efficiently, and you will produce a more versatile final product. Though interfacing with the community will require some time investment, you will easily regain any time lost by harnessing community code, and your end result will be both more powerful and more maintainable than otherwise.
2. You will save on support, since many types of support requests will be directed at the community rather than at you specifically. Of course, you will still need to fix bugs in your software. But you will have help from external developers with tasks such as fixing bugs in Bio-Formats and extending the OME-XML specification, whereas if you develop your own proprietary solution, all of these support tasks become your organization's sole responsibility.
3. You will be recognized as a progressive, forward-thinking organization dedicated to improving available microscopy tools.

Who is OME? Can I join?

Absolutely, we encourage you to contribute. We welcome all additional help in developing effective software and promoting open standards in microscopy. A detailed list of member labs and active participants can be found on the OME website under Who is OME?.

---

What is LOCI's role in OME?

LOCI is interested in harnessing OME as a practical, effective data management system for multidimensional images. Our primary contributions thus far have been:

• Stronger file format support via development of the Bio-Formats library, which provides the ability to convert third-party formats into OME-XML and OME-TIFF, import them into the OME and OMERO servers, and read them with applications such as ImageJ and VisBio.
• Open file format standards with an emphasis on compatibility and efficiency. In particular, we have created OME-TIFF and are working to improve the OME-XML schema to encompass useful information relevant to 4D light microscopy and beyond.
• Client-side tools for interacting with both the OME server and OME-XML, including the OME plugins for ImageJ for transferring data to and from an OME server, VisBio and Data Browser tools for visualizing data from an OME database, the Java OME-XML library for reading and manipulating OME-XML trees, and OME Notes application for allowing users to view and edit OME-XML metadata in their datasets.

---

How is OME funded?

Historically, OME has not been funded directly, since the software and file formats themselves are not hypothesis-driven research. Rather, OME has been developed to facilitate specific research with an acute need for such tools.

LOCI's OME work is NSF- and NIH-funded through research grants. The Goldberg lab is funded directly through NIH. Development of OME in the Swedlow lab is supported by the Wellcome Trust and the BBSRC.

What is the OMERO server?

The OME Remote Objects Server (OMERO) is a partial port of the OME Perl Server (OMEDS and OMEIS) to Java, developed by the Swedlow Lab in Dundee. It is currently beta, meaning that although it is increasingly becoming more stable, it is not yet encouraged to use in a production environment. OMERO is available for download—but please note that the OME developers can offer only limited support for OMERO at this time.

---

How do OMERO and OME differ? Is OMERO replacing OME?

Ilya Goldberg has responded in detail to these questions on the mailing list, and Jason Swedlow has commented as well.

The short answer is that OMERO and OME are separate systems, with neither replacing or subsuming the other. OME is a robust and mature environment for server-side analysis and client-side interaction via XML-RPC, whereas OMERO is a new server with a focus on fast client- server communication and new applications that support client-side import, visualization and management of complex sets of image data. No image analysis is supported yet in OMERO.

Nonetheless, the eventual goal is to produce a server capable of fulfilling the needs of both systems. Given the performance gains of OMERO, it seems reasonable that with enough effort, OMERO could be extended to include server-side analysis functionality similar in scope to the current OME server.

---

Which server should I use?

First of all, to take advantage of the OME effort, you do not need to install either server. The OME-XML standard for metadata is in many ways the heart of OME, and LOCI is developing several tools to work with OME-TIFF and OME-XML outside of an OME database (i.e., directly from disk). For example, you can use Bio-Formats to import your data into ImageJ for analysis, without the use of an OME server. That said, the OME and OMERO servers are powerful tools, and there are many reasons to consider using them.

The answer is that it depends on your needs ("one size does not fit all"):

You want...	OME	OMERO
...to focus on server-side analysis with a powerful infrastructure for dynamic typing
...to integrate MATLAB functions into your data management server
...a simple tool for image visualization and data management
...to use a remote application on a laptop and get high-speed visualization of your images on a server
...to develop rich client applications with fast client-server interaction

In the long term, the OME Consortium hopes to offer an integrated solution that maximizes the respective strengths of both systems, while minimizing their weaknesses. We are currently seeking funds to support direct improvements to the OME infrastructure, including exploration of integration between OME and OMERO, and a migration path from both systems to the eventual integrated product.

---

Last update: Tuesday, March 25, 2008