Every major fluorescence microscopy platform has its own proprietary file format. Zeiss instruments produce .czi files. Leica instruments produce .lif files. Nikon instruments produce .nd2 files. Imaris generates .ims files for 3D data. Each of these formats encodes not just pixel data but acquisition metadata — channel wavelengths, exposure times, spatial calibration, objective specifications, z-step sizes — that is essential for quantitative analysis and for reproducing experimental conditions.
The problem is not that these formats exist. It is that reading them correctly, extracting their metadata reliably, and ensuring that the numerical pixel values and spatial scales are interpreted accurately requires either the vendor's own software or a third-party reader that has reverse-engineered the format. When the vendor changes the format version — which happens with every major software release — readers that worked on the previous version may fail silently or partially on the new version. And when the vendor discontinues the software or discontinues a product line, the format may become unreadable without specific legacy tooling.
What Gets Lost in Proprietary Formats
The pixel data itself is generally the most durable part of a proprietary file — it is typically stored as a standard integer or floating-point array, often compressed with a documented algorithm. What is more fragile is the metadata.
Consider a .czi file from a Zeiss LSM 900 system. The file contains pixel data for four fluorescence channels, but it also contains: the exact emission filter bandpass for each channel, the pinhole diameter in Airy units, the detector gain setting in volts, the laser power at the source and the percentage transmission to the sample, the pixel dwell time, the objective serial number, the Z-step size, and the date and time of acquisition. Some of this information is stored in the TIFF-like IFD headers; some is stored in an XML block embedded in the file; some is stored in a proprietary binary substructure that is not documented in any public specification.
A generic TIFF reader reading a .czi file as a flat TIFF will retrieve the pixel data but will typically miss most of the embedded metadata. A standard scientific TIFF reader will retrieve more, but whether it correctly parses the channel information, the physical pixel size, and the per-channel calibration depends on the reader version and the specific .czi file version. Silent metadata errors — where the file appears to open normally but the reported pixel size or channel order is incorrect — are a real and common problem in cross-platform microscopy workflows.
The OME-TIFF Standard: What It Solves and What It Does Not
The Open Microscopy Environment (OME) consortium, established in 2000, developed OME-TIFF as an open, community-maintained file format for microscopy data. OME-TIFF stores pixel data in a standard multi-page TIFF structure and embeds an XML block in the first page that contains structured metadata following the OME data model. The metadata schema covers channels, objectives, detectors, sample descriptions, and acquisition parameters in a standardized vocabulary that is independent of any particular vendor's terminology.
The key advantage of OME-TIFF is that the metadata is machine-readable without vendor-specific knowledge. Any application that implements the OME-XML specification can extract the physical pixel size, the channel emission wavelengths, and the z-step size from an OME-TIFF file, provided the file was generated with accurate metadata. For long-term data archiving and for multi-site workflows where data from different vendor systems must be processed in a common pipeline, OME-TIFF substantially reduces the metadata fragility of proprietary formats.
The limitation of OME-TIFF is that it depends on accurate conversion from the source proprietary format. Conversion tools (Bio-Formats, vendor SDK-based exporters, and Cytely's own import pipeline) extract metadata from the source file and map it to the OME schema, but the quality of the extraction depends on the converter's support for the specific format version. OME-TIFF also does not solve the pixel data compression problem for very large datasets: uncompressed or losslessly compressed TIFF files from whole-slide imaging or light-sheet microscopy can reach hundreds of gigabytes per acquisition, making file management and transfer non-trivial.
The Zarr/OME-Zarr Trajectory
For large multi-dimensional microscopy data — particularly light-sheet and high-content screening datasets — the community has increasingly moved toward OME-Zarr (also called NGFF — the community's successor file format specification). Zarr is a cloud-native, chunked, compressed array storage format; OME-Zarr adds the OME metadata schema on top. The primary advantage is hierarchical multi-resolution storage: a single OME-Zarr dataset contains the full resolution image alongside downsampled pyramid levels, enabling fast visualization and streaming access to large datasets without loading the full file.
OME-Zarr support in analysis tools is currently patchy but growing. FIJI/ImageJ supports it via the MoBIE plugin. Python-based workflows can read OME-Zarr via the zarr and ome-zarr libraries. For new large-scale data generation projects — particularly those that will require long-term archiving or cloud-based collaborative analysis — OME-Zarr is worth evaluating as the primary storage format from the start.
What "Standardized" Means for Metadata in Practice
We are not saying that proprietary formats are inherently problematic for current-day analysis — Bio-Formats provides well-maintained reading support for all major proprietary formats in current use, and most modern analysis platforms (CellProfiler, ImageJ/FIJI, MATLAB Image Processing Toolbox) can read .czi, .lif, .nd2, and .ims files reliably in their current versions.
The risk is deferral. An experiment whose primary data exists only as .lif files is accessible today because Leica's Bio-Formats plugin is maintained and functional. In ten years, that accessibility depends on: continued maintenance of the Bio-Formats reader for the specific .lif version, availability of the reader for the operating system and analysis platform in use at that time, and the absence of silent changes in how the pixel values or metadata are interpreted. None of these are guaranteed.
The practical recommendation is a two-tier approach. Preserve the original proprietary files as the primary archive — they contain the most complete metadata representation from the acquisition software. Simultaneously, export to OME-TIFF at the point of acquisition (or immediately after), validate that the exported metadata is complete and accurate (spot-check physical pixel size, channel wavelengths, and z-step size against the acquisition software display), and use the OME-TIFF files as the primary input to the analysis pipeline. The OME-TIFF export is the durable record; the proprietary file is the backup in case the export missed something.
File Format as a Reproducibility Decision
Microscopy data that will be deposited in a public repository — required by many journals and funding agencies for publications involving imaging — should be deposited in OME-TIFF or OME-Zarr format. The EMBL-EBI BioImage Archive, the IDR (Image Data Resource), and OMERO-based institutional repositories all support these formats and provide stable long-term access. Depositing proprietary format files in public repositories is technically possible but creates an interpretability burden for any researcher trying to reproduce or build on the work.
The metadata preserved in a correctly generated OME-TIFF — physical pixel size, channel calibration, acquisition parameters — is exactly the information that is required to apply standardization corrections (flatfield correction, intensity normalization, cross-instrument calibration) reproducibly. If the metadata is lost or degraded during format conversion, the standardization corrections cannot be reproduced from the deposited data even if the pixel values are intact.
File format is a workflow design decision with reproducibility consequences that extend well beyond the current experiment. Making the choice to work in open formats from the point of acquisition costs relatively little; recovering from a proprietary format that has become unreadable five years after data collection costs substantially more, and some data is simply not recoverable.
