Written and maintained by CASRAI Editorial Board
Last updated
A collaborator sends over a folder of microscope images, and the files won’t open. They carry extensions like .czi (Zeiss), .nd2 (Nikon), .lif (Leica), or .vsi (Olympus/Evident) — each one a proprietary format tied to the vendor’s own acquisition software, and you don’t have a license for it, or the license is seat-locked to a different machine or lab. This is a routine problem in any multi-instrument core facility or collaboration, and it has a standard, free, open-source solution: you almost never need the vendor software itself, just a reader that understands the format.
Why proprietary microscope formats cause this problem in the first place
Unlike a plain TIFF or JPEG, a microscopy file from a modern instrument is rarely just pixels. Acquisition software bundles the image data together with the metadata that makes the image scientifically usable: channel names and excitation/emission wavelengths, objective and numerical aperture, pixel size and z-step, stage position for each tile in a mosaic, timestamps for a time-lapse series, and often the full instrument configuration at capture time. Each vendor designed its own binary container to hold all of that alongside the pixel data, and by default only that vendor’s own software is guaranteed to read it correctly — the format specification is proprietary and not published in a way that guarantees interoperability.
That design makes sense from inside a single vendor’s ecosystem, but it becomes a real obstacle the moment image data crosses instrument, lab, or institutional boundaries: a Nikon confocal user receiving .lif files from a Leica collaborator, a core facility distributing .czi stacks to PI labs that never bought Zeiss ZEN, or a lab reanalyzing a decade-old .vsi archive after the original digital-pathology scanner has been retired. Buying a full seat of vendor software just to open someone else’s files is rarely worth it for occasional access.
The standard solution: Bio-Formats
The Open Microscopy Environment’s Bio-Formats is the software library that solves this for essentially the entire field. It is a free, open-source Java library purpose-built to read proprietary microscopy formats and translate both the pixel data and the metadata into the OME data model — independent of the vendor, the instrument, or the acquisition software that originally wrote the file. Bio-Formats maintains readers for the major proprietary formats researchers actually encounter, including Zeiss CZI, Nikon ND2, Leica LIF, and Olympus/Evident VSI, alongside dozens of other vendor and legacy formats, with varying depth of metadata support per format (some formats map more completely into OME’s metadata model than others).
You don’t typically install Bio-Formats on its own. It ships as a plugin inside Fiji (the “batteries-included” distribution of ImageJ built for life-sciences imaging) and is bundled or supported in most other open bioimage analysis platforms — napari, QuPath, OMERO, CellProfiler, and Icy all rely on the same library under the hood rather than maintaining their own format readers. In practice, this means the single most common way to open a .czi, .nd2, .lif, or .vsi file without the vendor’s software is: install Fiji, then use File > Import > Bio-Formats and point it at the file directly.
Quick inspection without a full conversion
If you just need to look at an image — check that an acquisition ran correctly, preview a channel, confirm a stage position — you don’t need to convert anything first. Opening the file directly in Fiji via the Bio-Formats Importer is the fastest path: it reads the proprietary file in place, displays the pixel data, and surfaces the embedded metadata (channel names, dimensions, pixel calibration) through its metadata viewer, without writing a new file anywhere. The importer dialog also lets you open just a specific series or a cropped region from a large multi-position file, which matters when a .vsi whole-slide scan or a large .nd2 time-lapse is too big to load in full.
A handful of dedicated free viewers exist too — some vendors ship a stripped-down, no-license-required viewer for their own format (for example, a basic ZEN Lite–style viewer for CZI), which can be useful if you specifically need the vendor’s own rendering conventions, but these are single-format and platform-limited. For anything involving more than one vendor’s files, or any actual analysis rather than a look, Fiji with Bio-Formats is the more useful default because it’s the same tool you’ll need for conversion and downstream processing anyway.
Converting to an open format
When the goal is to actually use the data — share it with a collaborator on a different platform, deposit it in a public repository, or feed it into an analysis pipeline that doesn’t itself support Bio-Formats — the standard move is to convert into OME-TIFF, an open, community-maintained TIFF variant that stores the full OME-XML metadata block alongside the pixel planes in a single file. Because OME-TIFF is openly specified rather than tied to any vendor, it can be opened by any tool that supports it, indefinitely, regardless of what happens to the instrument or software that originally produced the file — which is also why it’s the format most repositories and journals expect for shared or archived image data. Bio-Formats also supports writing to the newer chunked, cloud-friendly OME-Zarr format, a better fit than OME-TIFF for very large datasets (large tiled slide scans, big time-lapse volumes) that don’t need to be loaded entirely into memory at once.
Two practical routes to do the actual conversion:
- Through Fiji’s GUI: open the file with the Bio-Formats Importer, then use File > Save As > Tiff (Fiji’s save path for a Bio-Formats-opened stack writes a proper OME-TIFF with the metadata intact) or the dedicated Bio-Formats Exporter. Fine for one file at a time or a small batch.
- The command-line
bfconverttool, distributed with the Bio-Formats command-line tools package, for batch work: it converts one file per invocation, so a folder of files is handled with a simple loop or script rather than a GUI macro, and it’s the more reliable choice once you’re converting dozens or hundreds of files rather than checking a handful by hand. It’s also scriptable inside a Fiji macro (the Bio-Formats plugin exposes the same conversion functionality programmatically) if you want conversion folded into an existing ImageJ/Fiji analysis pipeline rather than run as a separate step.
What survives the conversion, and what doesn’t
Conversion is not lossless in the metadata sense, even though the pixel data itself transfers faithfully. Bio-Formats maps whatever it can into the standardized OME data model — acquisition channel definitions, pixel size and dimensional calibration, timestamps, objective and instrument settings that have a defined home in the OME schema — and those fields come through in the OME-XML block of the resulting OME-TIFF or OME-Zarr file. Vendor-specific settings that have no equivalent field in the OME model (proprietary instrument presets, some acquisition-software-specific annotations, certain hardware configuration details) either get dropped or, depending on the reader, retained as unstructured “original metadata” key-value pairs rather than as first-class OME fields a downstream tool can query directly. In practice this means: core scientific metadata a reviewer or a repository cares about (what was imaged, how, at what scale, over what time course) survives reliably; some vendor-software-specific convenience settings do not, and won’t be recoverable later if the original proprietary file is discarded after conversion.
Because of that gap, the safe practice is to keep the original proprietary file archived alongside the converted OME-TIFF/OME-Zarr rather than deleting it once conversion succeeds — storage cost is a much smaller risk than losing metadata you didn’t realize wasn’t carried over. Before relying on a converted file for anything downstream, open it back up and spot-check that channel names, pixel calibration, and dimension order (which axis is which) match what you expect; a mismatch here is the most common way a converted file silently produces wrong measurements later.
Frequently asked questions
Do I need to buy Zeiss, Nikon, Leica, or Olympus software just to open a file a collaborator sent me?
Almost never, for viewing or converting the file. Bio-Formats, used through Fiji, reads all four of these proprietary formats without any vendor license. You’d only need the actual vendor software for tasks that depend on its specific proprietary processing (certain deconvolution algorithms, stitching implementations, or acquisition-control features) rather than simply reading the stored image and metadata.
Is OME-TIFF the same thing as a regular TIFF file?
It’s a valid TIFF under the hood — most generic TIFF readers can open the pixel planes — but it adds a structured OME-XML metadata block that plain TIFF has no place for. A generic TIFF viewer will show you the image; only OME-TIFF-aware software will read the embedded acquisition metadata correctly.
Will converting to OME-TIFF change my pixel values?
No — the conversion re-encodes the same pixel data into a new container; it doesn’t reprocess, compress lossily, or alter intensity values unless you explicitly choose a lossy compression option during export, which isn’t the default.
What if Bio-Formats can’t fully read a specific file?
Format support depth varies by vendor and by how recently the vendor changed its file structure; a very new acquisition-software version can occasionally outpace the current Bio-Formats reader for that format. If a file won’t open or metadata looks wrong, check the Bio-Formats project’s supported-formats documentation for known limitations on that specific format before assuming the file itself is corrupted.
For related instrument and imaging-analysis context, see Confocal Microscopy: Principle, Setup, and When to Use It (a common source of .czi, .nd2, and .lif files), Digital Pathology Scanner: What to Evaluate Before Buying One (the instrument class that produces large .vsi whole-slide files), and Western Blot Densitometry in ImageJ for another practical ImageJ/Fiji workflow.
