About Bio-Formats

Bio-Formats is a standalone Java library for reading and writing life sciences image file formats. It is capable of parsing both pixels and metadata for a large number of formats, as well as writing to several formats.

The primary goal of Bio-Formats is to facilitate the exchange of microscopy data between different software packages and organizations. It achieves this by converting proprietary microscopy data into an open standard called the OME data model, particularly into the OME-TIFF file format.

We believe the standardization of microscopy metadata to a common structure is of vital importance to the community. You may find LOCI’s article on open source software in science of interest.

Help

There is a guide for reporting bugs here.

For help relating to opening images in ImageJ or FIJI or when using the command line tools, refer to the users documentation. You can also find tips on common issues with specific formats on the pages linked from the supported formats table.

Please contact us if you have any questions or problems with Bio-Formats not addressed by referring to the documentation.

Other places where questions are commonly asked and/or bugs are reported include:

• OME Trac
• ome-devel mailing list (searchable using google with ‘site:lists.openmicroscopy.org.uk’)
• ome-users mailing list (searchable using google with ‘site:lists.openmicroscopy.org.uk’)
• ImageJ forum (for ImageJ/Fiji issues)
• ImageJ mailing list (and archive)
• Fiji GitHub Issues
• Confocal microscopy mailing list

Bio-Formats versions

Bio-Formats is now decoupled from OMERO with its own release schedule rather than being updated whenever a new version of OMERO is released. We expect this to result in more frequent releases to get fixes out to the community faster.

See the version history for a list of major changes in each release.

Versioning policy

Bio-Formats does not yet conform to strict semantic versioning. The following set of rules describe the current policy (using RFC 2119):

• The version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version and Z is the patch version.
• The patch version Z MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
• Either the minor version Y or the major version X MUST be incremented when backwards-incompatible changes (model-breaking API) are introduced to the public API. These version increases MAY also include patch level changes.
• Either the minor version or the major version MUST be incremented if the version of a non-OME/external dependency is updated.

The exception to this policy is serialization. Serialization functionality was implemented as a ReaderWrapper called Memoizer in Bio-Formats 5.0.0 and is exposed to the community via a public API. Currently:

• Major/minor/patch version bumps of Bio-Formats are not backwards-compatible with regard to serialization in that cached memo files written with a previous version may not be readable by later versions and may need to be rewritten.
• Consumers with code relying on Bio-Formats caching stability should not upgrade their Bio-Formats version for now.
• Changes breaking the serialization should be grouped together as much as possible in order to minimize the number of breakages per series.

See this GitHub issue for further details.

Why Java?

From a practical perspective, Bio-Formats is written in Java because it is cross-platform and widely used, with a vast array of libraries for handling common programming tasks. Java is one of the easiest languages from which to deploy cross-platform software. In contrast to C++, which has a large number of complex platform issues to consider, and Python, which leans heavily on C and C++ for many of its components (e.g., NumPy and SciPy), Java code is compiled one time into platform-independent byte code, which can be deployed as is to all supported platforms. And despite this enormous flexibility, Java manages to provide time performance nearly equal to C++, often better in the case of I/O operations (see further discussion on the comparative speed of Java on the LOCI site).

There are also historical reasons associated with the fact that the project grew out of work on the VisAD Java component library. You can read more about the origins of Bio-Formats on the LOCI Bio-Formats homepage.

Bio-Formats metadata processing

Pixels in microscopy are almost always very straightforward, stored on evenly spaced rectangular grids. It is the metadata (details about the acquisition, experiment, user, and other information) that can be complex. Using the OME data model enables applications to support a single metadata format, rather than the multitude of proprietary formats available today.

Every file format has a distinct set of metadata, stored differently. Bio-Formats processes and converts each format’s metadata structures into a standard form called the OME data model, according to the OME-XML specification. We have defined an open exchange format called OME-TIFF that stores its metadata as OME-XML. Any software package that supports OME-TIFF is also compatible with the dozens of formats listed on the Bio-Formats page, because Bio-Formats can convert your files to OME-TIFF format.

To facilitate support of OME-XML, we have created a library in Java for reading and writing OME-XML metadata.

There are three types of metadata in Bio-Formats, which we call core metadata, original metadata, and OME metadata.

1. Core metadata only includes things necessary to understand the basic structure of the pixels: image resolution; number of focal planes, time points, channels, and other dimensional axes; byte order; dimension order; color arrangement (RGB, indexed color or separate channels); and thumbnail resolution.
2. Original metadata is information specific to a particular file format. These fields are key/value pairs in the original format, with no guarantee of cross-format naming consistency or compatibility. Nomenclature often differs between formats, as each vendor is free to use their own terminology.
3. OME metadata is information from #1 and #2 converted by Bio-Formats into the OME data model. Performing this conversion is the primary purpose of Bio-Formats. Bio-Formats uses its ability to convert proprietary metadata into OME-XML as part of its integration with the OME and OMERO servers— essentially, they are able to populate their databases in a structured way because Bio-Formats sorts the metadata into the proper places. This conversion is nowhere near complete or bug free, but we are constantly working to improve it. We would greatly appreciate any and all input from users concerning missing or improperly converted metadata fields.