Reading files

Basic file reading

Bio-Formats provides several methods for retrieving data from files in an arbitrary (supported) format. These methods fall into three categories: raw pixels, core metadata, and format-specific metadata. All methods described here are present and documented in loci.formats.IFormatReader. In general, it is recommended that you read files using an instance of loci.formats.ImageReader. While it is possible to work with readers for a specific format, ImageReader contains additional logic to automatically detect the format of a file and delegate subsequent calls to the appropriate reader.

Prior to retrieving pixels or metadata, it is necessary to call setId(java.lang.String) on the reader instance, passing in the name of the file to read. Some formats allow multiple series (5D image stacks) per file; in this case you may wish to call setSeries(int) to change which series is being read.

Raw pixels are always retrieved one plane at a time. Planes are returned as raw byte arrays, using one of the openBytes methods.

Core metadata is the general term for anything that might be needed to work with the planes in a file. A list of core metadata fields is given in the table below together with the appropriate accessor method:

Core metadata field	API method
image width	getSizeX()
image height	getSizeY()
number of series per file	getSeriesCount()
total number of images per series	getImageCount()
number of slices in the current series	getSizeZ()
number of timepoints in the current series	getSizeT()
number of actual channels in the current series	getSizeC()
number of channels per image	getRGBChannelCount()
the ordering of the images within the current series	getDimensionOrder()
whether each image is RGB	isRGB()
whether the pixel bytes are in little-endian order	isLittleEndian()
whether the channels in an image are interleaved	isInterleaved()
the type of pixel data in this file	getPixelType()

All file formats are guaranteed to accurately report core metadata.

Bio-Formats also converts and stores additional information which can be stored and retrieved from the OME-XML Metadata. These fields can be accessed in a similar way to the core metadata above. An example of such values would be the physical size of dimensions X, Y and Z. The accessor methods for these properties return a Length object which contains both the value and unit of the dimension. These lengths can also be converted to other units using value(ome.units.unit.Unit) An example of reading and converting these physical sizes values can be found in ReadPhysicalSize.java.

Format-specific metadata refers to any other data specified in the file - this includes acquisition and hardware parameters, among other things. This data is stored internally in a java.util.Hashtable, and can be accessed in one of two ways: individual values can be retrieved by calling getMetadataValue(java.lang.String), which gets the value of the specified key. Note that the keys in this Hashtable are different for each format, hence the name “format-specific metadata”.

See Bio-Formats metadata processing for more information on the metadata capabilities that Bio-Formats provides.

See also

IFormatReader

Source code of the loci.formats.IFormatReader interface

OrthogonalReader.java

Example of reading XZ and YZ image planes from a file

File reading extras

The previous section described how to read pixels as they are stored in the file. However, the native format is not necessarily convenient, so Bio-Formats provides a few extras to make file reading more flexible.

• The loci.formats.ReaderWrapper API that implements loci.formats.IFormatReader allows to define “wrapper” readers that take a reader in the constructor, and manipulate the results somehow, for convenience. Using them is similar to the java.io InputStream/OutputStream model: just layer whichever functionality you need by nesting the wrappers.

  The table below summarizes a few wrapper readers of interest:

  Wrapper reader	Functionality
  loci.formats.BufferedImageReader	Allows pixel data to be returned as BufferedImages instead of raw byte arrays
  loci.formats.FileStitcher	Uses advanced pattern matching heuristics to group files that belong to the same dataset
  loci.formats.ChannelSeparator	Makes sure that all planes are grayscale - RGB images are split into 3 separate grayscale images
  loci.formats.ChannelMerger	Merges grayscale images to RGB if the number of channels is greater than 1
  loci.formats.ChannelFiller	Converts indexed color images to RGB images
  loci.formats.MinMaxCalculator	Provides an API for retrieving the minimum and maximum pixel values for each channel
  loci.formats.DimensionSwapper	Provides an API for changing the dimension order of a file
  loci.formats.Memoizer	Caches the state of the reader into a memoization file

• loci.formats.ImageTools and loci.formats.gui.AWTImageTools provide a number of methods for manipulating BufferedImages and primitive type arrays. In particular, there are methods to split and merge channels in a BufferedImage/array, as well as converting to a specific data type (e.g. convert short data to byte data).

Troubleshooting

• Importing multi-file formats (Leica LEI, PerkinElmer, FV1000 OIF, ICS, and Prairie TIFF, to name a few) can fail if any of the files are renamed. There are “best guess” heuristics in these readers, but they are not guaranteed to work in general. So please do not rename files in these formats.

• If you are working on a Macintosh, make sure that the data and resource forks of your image files are stored together. Bio-Formats does not handle separated forks (the native QuickTime reader tries, but usually fails).

• Bio-Formats file readers are not thread-safe. If files are read within a parallelized environment, a new reader must be fully initialized in each parallel session. See Improving reading performance about ways to improve file reading performance in multi-threaded mode.