tifffile reads TIFF far past the baseline spec

A single module that speaks TIFF and thirty vendor dialects

The scope of tifffile is unusual for a Python image library: it is not a general image package but a narrow one built around the Tagged Image File Format and its descendants. The stated jobs are storing NumPy arrays in TIFF files and reading image data plus metadata from TIFF-like files used in bioimaging.

The format list in the project documentation is the real differentiator. Reading covers TIFF, BigTIFF, OME-TIFF, GeoTIFF, Adobe DNG, ZIF, MetaMorph STK, Zeiss LSM, ImageJ hyperstack, Micro-Manager MMStack, NDTiff, SGI, NIHImage, FLIMage, Olympus FluoView and SIS, ScanImage, Molecular Dynamics GEL, Huron TIFF, Aperio SVS, Leica SCN, Roche BIF, PerkinElmer QPTIFF, Hamamatsu NDPI, Argos AVS, Philips DP, DICOM-TIFF and ThermoFisher EER. Writing is narrower and stays within TIFF, BigTIFF, OME-TIFF and ImageJ hyperstack compatible files.

That asymmetry matters when you plan a pipeline. Any file you create is standard TIFF in some form, so anything that reads TIFF can read your output. What you read, however, can be a microscope's native layout, and the file may not be readable by a generic tool without the vendor plugin that writes it.

The install line that pulls imagecodecs along with it

Installation is a single command, and the extra dependency group is the part worth understanding before you run it:

    python -m pip install -U tifffile[all]

The extras group exists because compression lives outside this package. The same package is also published through Anaconda, Debian and MSYS2, so a system package manager will hand you a version whose dependency set you did not choose.

The library also carries a command line entry point for inspecting and previewing TIFF files without writing any script:

    python -m tifffile --help

Beyond that, the project points at its own documentation site for the programming interface and at the image.sc forum for support. The repository itself is small in structure: a package directory, a tests directory, an examples directory holding earthbigdata.py, issue125.py and write_dng.py, plus the usual packaging files, with pyproject.toml setting a 79 character line length for black and isort and targeting Python 3.12 through 3.15.

Reading pages, series and pyramids into NumPy or Zarr

The read path is built around a hierarchy of objects rather than a flat loader. A TiffFile exposes pages, each page is an IFD, and a TiffSeries groups pages into something with shape and axes. Image data can be materialised as NumPy arrays or as Zarr arrays and groups, and the source can be strips, tiles, pages, SubIFDs, higher-order series or pyramidal levels.

This is the practical difference from a general purpose image reader. Where such a reader hands back a rectangular array of one image, tifffile can describe a five dimensional acquisition with a time axis, a channel axis and a z axis, and it can expose metadata as attributes rather than as sidecar text. The 2026.5.2 revision added asxarray methods to TiffFile, TiffPage and TiffPageSeries, which converts those series into xarray DataArrays when that optional dependency is present.

Beyond single files there is a whole file sequence concept. parse_filenames and FileSequence treat a numbered directory of images as one logical volume, and the revision notes show the cost of that abstraction: a fix for FileSequence.asarray leaving missing chunks uninitialized, and a ValueError now raised when two files map to the same index.

Compression lives in imagecodecs, not in tifffile

If you install without the extras, or without imagecodecs at your side, compressed segments simply are not available. The project documentation lists imagecodecs as required for encoding or decoding LZW, JPEG and similar compressed segments, and names the supported schemes through it: LZW, PackBits, Deflate, CCITT, PIXTIFF, LZMA, LERC, Zstd, JPEG in 8 and 12 bit lossless forms, JPEG 2000, JPEG XR, JPEG XL, WebP, PNG, EER, Jetraw, 24-bit floating-point, packed integers and horizontal differencing.

The dependency is version-coupled in a way that has caused breakage. The 2026.8.16 revision required imagecodecs >= 2026.8.16 because fsspec v3 stores using big-endian floatpred were incompatible with zarr>=3.3. The 2026.5.2 revision added a zarr format 3 compatible Tiff codec, and the 2026.10.15 revision fixed a codec configuration that was not JSON-serializable when it carried a slice key.

Other optional dependencies have the same character. Xarray is needed to read xarray DataArrays, Matplotlib to plot, Lxml to validate and print XML, Zarr to use Zarr stores, and Kerchunk to open ReferenceFileSystem files. The docs state the versions the code was tested against: NumPy 2.5.4, imagecodecs 2026.10.10, Xarray 2026.9.0, Matplotlib 3.11.2, Lxml 6.1.3, Zarr 3.4.1 and Kerchunk 0.2.10.

The 2026.5.2 revision reshapes the series API

This library changes shape often, and the revision notes are blunt about which changes break callers. In 2026.5.2, TiffFile.series changed from a list to a callable TiffSeries sequence, TiffPageSeries squeeze became a single state instead of a dual one, and TiffPageSeries.get_shape, get_axes and get_coords were removed. Generic TiffPage coords were removed, dims and sizes moved to single-character axis codes, and the Zarr stores moved to zarr format 3 with multiscales at NGFF 0.5, while multiscales zarr format 2 fsspec files were updated to NGFF 0.4.

Later revisions continued the pattern. In 2026.6.1, NullContext was replaced with contextlib.nullcontext and the ome, imagej and shaped parameters of imwrite and TiffFile were deprecated in favour of kind, while aszarr was deprecated in favour of return_as. In 2026.7.31 and 2026.8.16 the store work continued. The 2026.10.15 revision went further, disallowing writable ZarrFileSequenceStore and raising a ValueError when FileSequence files map to the same index, both marked breaking.

For an adopter this is the central cost. Reading a changelog before pinning a version is not optional here, and a pinned old version means missing formats that later revisions added.

Vendor formats are where tifffile earns its keep, and where it stops

tifffile is a file parser first. It does not acquire images, it does not calibrate a stage, and it does not control a microscope. The vendor dialects it reads, NDPI, SVS, SCN, BIF, QPTIFF, EER and others, arrive already written by the acquisition software, and tifffile reconstructs their series and metadata from the file. That reconstruction is bounded by what the file contains, and the revision history shows where the boundaries sit: support for Mikroscan and Motic formats arrived in 2026.9.20 because they are structurally identical to SVS, and the same revision fixed unwrapping offsets in LSM files larger than 4GB with T, P and M dimensions. The 2026.7.14 revision added Huron TIFF, FLIMage FLIM, DECTRIS IFD and tags, and detection of the DICOM-TIFF dual-personality format.

The genuine alternative to this approach is not another TIFF library but the software that owns the format. An ImageJ user works in hyperstacks natively, an OME-TIFF producer writes metadata it controls, and a scanner package ships its own readers. tifffile differs in approach by arriving after the fact: it treats a finished file, in whatever dialect, and exposes it as arrays. If you need to create a file in a vendor format rather than read one, the write side stops at TIFF, BigTIFF, OME-TIFF and ImageJ hyperstack, and that boundary will not move.

BSD-3-Clause, a dedicated maintainer, and dated releases

The project is released under BSD-3-Clause, with the copyright line naming Christoph Gohlke and the SPDX identifier BSD-3-Clause recorded in the packaging script. The setup.py script writes the README, LICENSE and CHANGES files when it is run with the sdist argument, and derives the package version by searching the source for the version string, replacing .x.x with .dev0 for development builds.

Activity is easy to date precisely. The last push was on 2026-10-16, and the three most recent releases are v2026.10.15 published on 2026-10-16, v2026.9.20 on 2026-09-21 and v2026.9.15 on 2026-09-15. A single named maintainer produces these releases, and the schedule is dense enough that release notes should be treated as required reading rather than optional background.

The licence carries the usual obligations of a permissive three clause BSD grant, so it permits commercial and modified redistribution. That is a licensing observation only, not advice on how to apply it to your project.

Editorial conclusion

tifffile is the right choice for pipelines that read or write scientific TIFF, whole-slide or OME-TIFF data from Python and want metadata as arrays rather than pixels alone; it is the wrong choice for general photo work, and for codebases pinned to the pre-2026 series API. Before adopting it, check the breaking-change list from 2026.5.2 onward, confirm imagecodecs is installed when compressed segments are involved, and read a file of your own format with TiffFile before trusting the series it reports.

Frequently asked questions

Official sources

1. cgohlke/tifffile on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases