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.IFormatReaderinterface 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.IFormatReaderallows 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.
