SCIFIO is a project to generalize the Bio-Formats concept beyond the life sciences, and beyond the OME-XML data model. SCIFIO's focus is on extensibility, with the ability to write Format plugins to expand which file formats are supported, Metadata plugins to expand the available data models, and Translator plugins to provide the conversion logic between individual file formats and various metadata models. With this approach, Bio-Formats can be expressed as a "SCIFIO extension" containing a Metadata implementation for OME-XML, Format implementations for supported life sciences file formats, and Translator implementations for conversion of those formats into OME-XML. But other SCIFIO extensions for other data models and scientific fields are equally possible.

SCIFIO and Bio-Formats can interoperate now via the scifio-bf-compat glue layer. We are in the midst of a lengthy transition period, during which this is the mechanism by which the many Bio-Formats file format readers can be plugged in to SCIFIO, and soon vice versa. Once SCIFIO has emerged from beta status, we will work with the Bio-Formats developers to decide on the next steps for Bio-Formats to best harness the many improvements provided by the SCIFIO library.

The SCIFIO core is licensed according to a permissive Simplified BSD license, so that any software can include it and automatically gain access to all file format plugins available on the classpath. The SCIFIO core only provides support for open file formats. Conversely, the Bio-Formats project provides readers for proprietary file formats, and is licensed under the "copyleft" GNU Public License. For details on Bio-Formats licensing, see the OME licensing page.

Lastly, SCIFIO and Bio-Formats are part of the SciJava initiative to define a coherent software stack for scientific imaging in Java.

Please note: older versions of Bio-Formats may include a scifio.jar. This is not the same product—but a historical artifact that has been corrected in more recent versions of Bio-Formats.

See the Why Java? and Isn't Java too slow? FAQ entries on the LOCI web site.

Yes there are! Please use the Image.sc Forum with the scifio tag if you have any requests or questions.

SCIFIO contains a set of components, each performing a specific task in the image IO process. Convenience methods are provided to abstract this workflow, but the individual components can also be invoked manually. See the tutorials and javadocs.

Although Translators can be defined arbitrarily between Metadata types, our approach is as follows:

• Every Format-specific Metadata implementation provides core meta-information such as image dimensions.
• If a Format provides a Writer, it also defines a Translator from Metadata to its Format-specific Metadata implementation. Hence, it will be possible to convert any source Format to that destination Format. (In this way, core meta-information will be preserved, but not necessarily domain-specific meta-information.)
• Extensions are possible that enable preservation of domain-specific information during translation. The extension defines its own standard Metadata implementation (e.g., OMEMetadata in the case of the OME data model). The extension also provides Translators from each supported Format-specific Metadata implementation to that standard. In the case of Writers, the extension may also choose to provide Translators from its Metadata standard back to each Format-specific Metadata implementation. If it does so, all domain-specific meta-information compatible with the defined standard can then be preserved during format conversion.

In short, by converting via standard exchange formats such as OME (or the base Metadata interface itself), translation becomes an O(M) problem, rather than an O(M²) problem.

Lastly, note that translation is generally automatically by the TranslatorService (although it can also be done manually by querying the desired Translator directly). If you ask the TranslatorService to convert from, e.g., TIFFMetadata to APNGMetadata, it first looks for a direct TIFF-to-APNG Translator, and if one is not available, it then looks for a generic Metadata-to-APNG Translator. In the future, we may extend this logic to recognize Metadata implementations such as OMEMetadata as intermediary exchange structures, and explicitly look for Translators to and from such intermediaries.